воскресенье, 5 апреля 2009 г.

Автоматический whoami при работе через SSH

В статье рассматривается простой пример использования (документированных) возможностей как sshd, так и bzr, для автоматической установки идентификатора пользователя при работе на удаленной машине.

Сценарий

Имеется общий компьютер, на котором могут работать несколько человек под одной учетной записью. Этот компьютер может использоваться как тестовый полигон, либо как машина для компиляции окончательной версии программы, или для сборки инсталляционных пакетов. Либо же это тестовый/боевой сервер, на котором запущен веб-сайт или другое приложение. Разработчики используют SSH для работы на этом общем компьютере.

Для отслеживания изменений, производимых разработчиками на общем компьютере, используется одна или несколько bzr-веток.

Проблема

При такой совместной работе остро стоит вопрос адекватной идентификации разработчиков, которые фиксировали свои изменения. По умолчанию bzr использует автоматический идентификатор, состоящий из имени учетной записи и имени компьютера, например: root@server. А поскольку под одной учетной записью могут работать несколько человек, то нельзя установить глобальный идентификатор через команду bzr whoami.

Способы идентификации

Базар позволяет идентифицировать автора ревизии несколькими способами: глобальная идентификация, идентификация на уровне ветки, или через использование переменных окружения.

При всем богатстве выбора, для рассматриваемого сценария работы подходят далеко не все варианты. Первый вариант (глобальная идентификация), как мы уже сказали ранее, здесь категорически не приемлем. Вариант с идентификацией на уровне отдельной ветки может подойти, если каждый разработчик имеет отдельную ветку и работает только в ней. Чаще всего это не так, да и легко забыть о необходимости настраивать идентификатор для каждой новой ветки. Так что этот вариант скорее всего тоже отпадает.

Остается вариант с использованием переменных окружения. Базар использует значение переменной окружения BZR_EMAIL или EMAIL в качестве идентификатора пользователя. Если одна из этих переменных определена, то она имеет приоритет как над глобальным идентификатором, так и над идентификацией на уровне ветки.

Вариант с использованием переменных окружения тоже имеет свой недостаток: в начале каждой новой SSH-сессии разработчик должен установить переменную окружения BZR_EMAIL. О необходимости установки этой переменной легко забыть. К счастью имеется возможность автоматизировать этот скучный процесс при использовании аутентификации пользователей при помощи SSH-ключей.

Использование файла authorized_keys

При аутентификации при помощи SSH-ключей используется файл ~/.ssh/authorized_keys (или ~/.ssh/authorized_keys2). В этом файле сохраняется список публичных SSH-ключей, которым разрешена аутентификация. Однако кроме самих ключей, дополнительно могут быть указаны различные параметры соединения, либо ограничения доступа, либо директивы запуска некоторой программы при аутентификации конкретным ключом. Либо директива установки переменной окружения при аутентификации конкретным ключем. Именно эта директива нам и нужна.

Директива установки переменной окружения при логине указывается в виде:
environment="ИМЯ=значение"
Подробнее о формате и параметрах в файле authorized_keys читайте в man sshd.

Таким образом для настройки автоматической идентификации пользователей необходимо применить вход на общий компьютер через SSH-ключи, и для каждого пользователя (перед его публичным ключем) указать свою директиву environment, например:

--------------------Файл: authorized_keys-------------------------------------
environment="BZR_EMAIL=Vasya Pupkin <pupkin@mail.ru>" ssh-dss AAAAB3NzaC1kc3MAAACAcdSwa...
------------------------------------------------------------------------------

Таким образом каждый из участников проекта может работать в любой ветке на общем компьютере, и все фиксируемые изменения будут сохраняться от имени конкретного человека.

3 комментария:

  1. Спасибо, полезная заметка! Жду когда тут что-нибудь появится о написании плагинов для bzr - ведь это одна из его сильных сторон.

    ОтветитьУдалить
  2. Обязательно напишем и про плагины, и про то как их писать.

    ОтветитьУдалить
  3. Спасибо, сильно помогло, не знал про доп. опции в authorized_keys.

    ОтветитьУдалить