конспект
Необходимые задания по установке svn с поддержкой ключей и установке приложения Collabnet keyring_tool уже выполнены для наших серверов Linux.
1) Настройте клиент SVN для использования связки ключей:
1.1) Редактирование ~ / .subversion / config
[auth]
password-stores = gnome-keyring
1.2) Редактировать ~ / .subversion / серверы
[global]
store-passwords = yes
store-plaintext-passwords = no
2) Создайте брелок для вашего пароля. Вам будет предложено создать новый пароль для разблокировки набора ключей; это может быть что угодно:
keyring_tool --create=svn
3) Установите новый набор ключей по умолчанию:
keyring_tool --setdef=svn
4) В .bash_profile или .bash_login (при условии, что вы используете bash в качестве терминала)
if [ -e /usr/bin/gnome-keyring-daemon ]; then
if [ ! -z "`kill -0 $GNOME_KEYRING_PID 2>&1`" ]; then
# Create dbus transport link for SVN to talk to the keyring.
eval `dbus-launch --sh-syntax`
# Start the keyring daemon.
# The use of export here captures the GNOME_KEYRING_PID, GNOME_KEYRING_SOCK
# env values echoed out at startup.
export `/usr/bin/gnome-keyring-daemon`
fi
fi
5) В .bash_logout
# Kill the message bus established for SVN / Keyring communication
if [ ! -z "`kill -0 $DBUS_SESSION_BUS_PID 2>&1`" ]; then
kill $DBUS_SESSION_BUS_PID > /dev/null 2>&1
fi
# Kill the Gnome Keyring Daemon prior to logout.
if [ ! -z "`kill -0 $GNOME_KEYRING_PID 2>&1`" ]; then
kill $GNOME_KEYRING_PID > /dev/null 2>&1
fi
Задний план
Я столкнулся с подобной проблемой, пытаясь создать простой способ обеспечить доступ авторизованного пользователя к определенным репозиториям SVN на работе. По сути, нам приходилось принудительно проверять учетные данные каждый раз, когда пользователь обращается к серверу, поэтому даже для команды svn update потребуется аутентификация. Ясно, что хранилище паролей в виде простого текста отсутствовало, поэтому после небольшого исследования я наткнулся на использование gnome-keyring как способа преследования нашей пользовательской базы постоянными запросами аутентификации, в то же время не допуская посторонних пользователей в хранилища, которые они не должны иметь для просмотра.
Большая часть нашей повседневной работы выполняется через туннели ssh до сервера RedHat без поддержки X, поэтому мне пришлось искать способ обойти поддержку X11. После некоторых поисков мне удалось найти способ обойти это здесь:
Исходный материал
http://support.wandisco.com/index.php?/Knowledgebase/Article/View/362/17/how-to-setup-encrypted-svn-password-storage-using-gnome-keyring-in-an-ssh -session
Они используют ключ Collabnet keyring_tool для создания связки ключей без клиента gnome-keyring-manager и установки dbus-launch самостоятельно, а не позволяют SVN обрабатывать настройку. SVN использует DBUS для соединения с демоном gnome-keyring-daemon и влияет на общую аутентификацию. Запуская и прерывая сеанс dbus вручную с -sh-синтаксисом, вы избегаете попытки подключиться к X-клиенту при запуске dbus. Если вы просто запустите gnome-keyring-daemon и попытаетесь использовать SVN, он все равно запросит у вас пароль для связки ключей, но затем также запросит учетные данные SVN. Dbus потерпит неудачу, когда SVN попытается запустить его из-за отсутствия X-клиента; по-видимому, SVN не использует никаких специальных флагов при запуске dbus.
--login
Вариант довольно полезен, хотя я уверен, что не захочу хранить свой хэшированный пароль в сценарии или помещать его в командную строку. чтение в неподходящем режиме из скрипта (не на языке оболочки), который затем передает этот ввод порожденному демону, вероятно, будет хорошим способом сделать это. Мне нужно только запустить этот процесс один раз за загрузку, поэтому имеет смысл ввести пароль; Мне просто нужно иметь возможность сделать это в командной строке, а не через диалог GTK.