что исправляет установка гитолита?

gitolite info не работал, добавление ключей превращало их в ключ no access и НЕ создавало соответствующую запись в файле auth-keys.

Чтобы исправить это, запустите gitolite setup на сервере gitolite

Вопрос: что могло привести меня в эту неразбериху?

И что делает gitolite setup при вызове в n-й раз (он больше не настраивает вещи, в соответствии с документами, он исправляет хуки, но мне интересно, какой вариант использования был бы и какой был моим)?

Подробнее о гитолите

Команда gitolite info вызывается так:

> ssh git-user@ser-git
PTY allocation request failed on channel 0
hello git-admin, this is ...@... running gitolite3 3.6.7-2 (Debian) on git 2.17.1

 R W    some-repository
 R W    gitolite-admin
 R W    testing
Connection to ser-git closed.

Плохой вывод: FATAL: unknown git/gitolite command: 'info'

Подробнее: ключи без доступа.

gitolite sshkeys-lint показывал ключи с (no access), теперь у этих ключей есть доступ, когда я их установил (теперь это означает после gitolite setup).

ssh-keygen -lf /home/repo/.ssh/authorized_keys | wc -l (или без трубопроводной части, независимо) количество клавиш и их названия указывают на то, что я не добавлял самую новую.

Аналогичный вопрос, который не сработал для меня: записи каталога ключей не распространяются на authorized_keys


githooks gitolite
person LAFK says Reinstate Monica    schedule 25.09.2018    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Думаю, у Docs был ответ, когда я копнул глубже. Что довольно приятно для @sitaramc.

  • Без опций 'gitolite setup' - это общая команда "исправить все" (например, если вы внесли репозиторий извне, или кто-то испортил хуки, или вы внесли изменение в файл rc, которое влияет на правила доступа и т. Д.) )

Симптомы ключей перестали распространяться и ошибка FATAL: unknown git/gitolite command: 'info' на ssh git-user@ser-git. Исправление заключалось в запуске gitolite setup. Итак, первый вопрос, заголовок:

что исправляет установка гитолита?

  1. gitolite setup реализовано здесь

  2. мой Perl довольно слабый, но есть функция настройки в строка 56. Он вызывает args (который анализирует параметры, поэтому здесь нечего было разбирать), затем, если h_only (перехватывает только arg для настройки), который не использовался, поэтому мы пропускаем триггеры compile и POST_COMPILE и переходим к перехватам.

    дополнительные настройки {my ($ admin, $ pubkey, $ h_only, $ message) = args ();

    unless ($h_only) {
    setup_glrc();
    setup_gladmin( $admin, $pubkey, $message );

    _system("gitolite compile");
    _system("gitolite trigger POST_COMPILE");
}

hook_repos();    # all of them, just to be sure

    }

  3. в пакете Gitolite::conf::store есть hook_repos(), line noreferre.pm#L228"> rel=2 / a>: мы меняем каталог на базовый каталог репо (согласно файлу конфигурации), и для каждого phy_repo мы делаем hook_1(phy_repo). Что такое phy_repo? физический.

  4. тот же пакет, другой метод и строка: hook_1($repo) в строке 354.

Метод hook_1($repo)

Речь идет буквально о том, чтобы исправить все крючки.

  1. Воссоздает каталоги для обычных и административных хуков.
  2. Переписывает update_hook (общий) и post_update_hook (admin).
  3. Устанавливает 755 разрешений как для обычных, так и для административных хуков.
  4. Затем с помощью ln_sf он связывает папки с обычными хуками / админками.
  5. ln_sf находится в общем модуле, в строке
person LAFK says Reinstate Monica    schedule 28.09.2018