Власний сервер svnserve
Програма svnserve легкий сервер, здатний спілкуватися з клієнтами через TCP / IP, використовуючи власний простий протокол. Клієнти звертаються до сервера, svnserve використовуючи URL, який починається з svn: // або svn + ssh: //. В цьому розділі рсказивается про різні способи запуску svnserve. про те як клієнти автентифіковані на сервері і про налаштування відповідних правил доступу до сховища.
запуск Сервера
Існує кілька різних способів запустити програму svnserve. При запуску без параметрів, нічого крім довідкового повідомлення ви не побачите. Якщо ви плануєте запускати процес через inetd. необхідно вказувати параметр -i (--inetd):
При запуску з параметром --inetd. svnserve буде намагатися спілкуватися з клієнтом Subversion через stdin і stdout використовуючи власний протокол. Це стандартна поведінка для програм, що запускаються через inetd. IANA зарезервував порт 3690 для протоколу Subversion, тому на unix-подібних системах ви можете додати в / etc / services рядки подібні цим (можливо, вони там вже є):
Якщо система використовує класичний Unix-подібний демон inetd. в /etc/inetd.conf можна додати такий рядок:
Переконайтеся, що користувач «svnowner» має необхідні права для доступу до сховища. Після цього, коли від клієнта до сервера на порт 3690 прийде запит на з'єднання, inetd запустить процес svnserve для обслуговування цього запиту.
На Windows системах, існують засоби від сторонніх виробників, які запускають svnserve як сервіс. Список цих інструментів можна подивитися на веб-сайті Subversion.
Другий параметр запускає svnserve як автономний процес-«демон». Для цього використовується параметр -d:
Якщо svnserve запускається в режимі демона, можна використовувати опції --listen-port = і --listen-host =. щоб призначити потрібне значення порту і імені хоста, до якого «прив'язаний» svnserve.
Існує ще один, третій спосіб запуску svnserve. з параметром -t - це так званий «тунельний режим». Цей режим передбачає, що програми віддаленого доступу такі як RSH або SSH вже успішно аутентифицироваться користувача і запускають приватний процес svnserve від імені цього користувача. Програма svnserve працює в звичайному режимі (працюючи через stdin і stdout) і передбачає, що трафік автоматично перенаправляти по деякому тунель до клієнта. Коли svnserve запущений подібним тунельним агентом переконайтеся в тому що аутентіфіцірований користувач має повний доступ на читання і запис до файлів бази даних сховища. По суті, це відповідає зверненню до сховища локального користувача через URL виду file: ///.
Застосування параметра -r ефективно змінює місце розташування розглядається програмою як корінь файлової системи. Клієнти використовують URL, з якого вилучений цей шлях, в результаті чого URL виходить більш коротким (і менш викривальним):
Коли клієнт підключається до svnserve. відбувається наступне:
Клієнт вказує необхідну сховище.
клієнту може бути дозволено робити анонімні звернення, без запиту на ідентифікацію, АБО
клієнт може бути зроблений запит на ідентифікацію в будь-який момент, АБО
при роботі в «тунельному режимі», клієнт оголосить себе вже ідентифікованим.
Створення файлу користувачів і область сховища
Зараз, секція [general] в svnserve.conf має всі необхідні вам змінні. Почнемо з визначення файлу, що містить імена користувачів і паролі, а також з області сховища:
realm - це визначається вами ім'я. Воно повідомляє клієнтам, до якої «області ідентифікації» вони приєднуються; клієнту Subversion вона виводиться в запрошенні до аутентифікації, і використовується як ключ (разом з ім'ям сервера і портом) для кешування клієнтської ідентифікаційної інформації на диск (див. «Кешування клієнтської ідентифікаційної інформації»). Мінлива password-db вказує на окремий файл, який містить список користувачів і паролі в такому ж простому форматі. наприклад:
Значення password-db може бути абсолютним або відносним шляхом до файлу користувачів. Для більшості адміністраторів, його легше тримати в conf / області сховища, поруч з svnserve.conf. З іншого боку, можливо, ви захочете розділяти один і той же файл користувачів для двох або більше сховищ, в цьому випадку цей файл варто помістити в більш доступне місце. Сховища розділяють файл користувачів, повинні бути також сконфігуровані з однаковими областями, так як список користувачів по суті визначає область аутентифікації. Де б в результаті файл не знаходився, переконайтеся, що у нього виставлені відповідні права на читання / запис. Якщо ви знаєте від імені якого користувача (-ів) буде запускатися svnserve. то потрібно обмежити доступ на читання тільки тим користувачем, яким це потрібно.
Установка контролю доступу
Є ще дві додаткові змінні в svnserve.conf. вони визначають, що будуть допущені робити не ідентифіковані (анонімні) і ідентифіковані користувачі. Змінні anon-access і auth-access можуть мати значення: none. read. або write. Установка значення в none забороняє доступ будь-якого роду; read - доступ до сховища тільки на читання, а write - дозволяє повний доступ до сховища на читання / запис. наприклад:
Значення встановлені в прикладі - фактично значення за замовчуванням, вони будуть встановлені якщо ви не захочете визначити їх. Якщо ви хочете бути більш консервативним, то можете заблокувати повністю анонімний доступ:
The server process not only understands these «blanket» access controls to the repository, but also finer-grained access restrictions placed on specific files and directories within the repository. To make use of this feature, you need to define a file containing more detailed rules, and then set the authz-db variable to point to it:
The syntax of the authzfile file is discussed in detail in «Path-Based Authorization». Note that the authz-db variable is not mutually exclusive with the anon-access and auth-access variables; if all the variables are defined at once, then all of the rules must be satisfied before access is allowed.
Вбудована в svnserve ідентифікація може бути більш зручною, так як уникає необхідності створювати реальні системні облікові записи. Іншими словами, деякі адміністратори вже мають добре налаштовані SSH оболонки в своїх системах. У цій ситуації все користувачі проектів вже мають системні облікові записи і здатність до «SSH into» на серверну машину.
Найпростіше використовувати SSH в зв'язці з svnserve. Клієнти просто використовують для конекту схему svn + ssh: //:
Важлива річ для розуміння тут, це те що клієнт Subversion не з'єднує з запущеним демоном svnserve. Цей метод доступу не вимагає демона, ні робить повідомлення навіть якщо він присутній. Він використовує в цілому здатність ssh запускати тимчасовий процес svnserve. які завершується коли мережеве з'єднання закриється.
Коли для доступу до сховища використовується URL виду svn + ssh: //. пам'ятайте що це програма ssh запитує ідентифікацію, а не клієнтська програма svn. Це означає що немає автоматичного кешування паролів (див. «Кешування клієнтської ідентифікаційної інформації»). Клієнти Subversion часто роблять кілька з'єднань до сховища, хоча користувачі зазвичай не знають про це через можливість кешування паролів. Однак коли використовують URL виду svn + ssh: // URLs, користувачі можуть бути роздратовані ssh через повторюваних запитів пароля для кожного вихідного з'єднання. Вирішення цієї проблеми полягає у використанні окремого інструменту для кешування паролів SSH, подібних ssh-agent на Unix-подібних системах, або pageant в Windows.
Коли виконується через тунелювання, ідентифікація спочатку управляється правами операційної системи на файли бази даних сховища; це дуже схоже на те як якби Harry отримувала доступ до сховища безпосередньо через URL file: ///. Якщо кілька користувачів системи отримують доступ до сховища безпосередньо, ви можете захотіти помістити їх в загальну групу, і ви повинні будете бути дуже обережним при вирішенні (umasks). (Прочитайте «Supporting Multiple Repository Access Methods».) Але в кожному разі тунелювання файл svnserve.conf може продовжувати використовуватися для блокування доступу, простий установкою auth-access = read або auth-access = none. [42]
Ви не повинні думати що розповідь про SSH тунелювання буде закінчений тут. Subversion дозволяє вам створювати замовне поведінку тунеля в файлі config (дивись «Параметри часу виконання»). Наприклад, припустимо що ви хочете використовувати RSH замість SSH. У розділі [tunnels] файлу [tunnels] просто вкажіть подібно до цього:
І зараз ви можете використовувати нове визначення тунелю використовуючи схему URL яка відповідає імені вашої нової змінної: svn + rsh: // host / path. Потім використовуючи нову схему URL, клієнт Subversion буде виконувати команду rsh host svnserve -t за лаштунками. Якщо ви включите ім'я користувача в URL (на приклад, svn + rsh: // username @ host / path) клієнт також буде включати його в цю команду (rsh username @ host svnserve -t). Але ви може визначити нову схему тунелювання яка буде розумніша ніж ця:
Цей приклад демонструє пов'язані речі. З початку він показує як можна зробити щоб клієнт Subversion запускав дуже специфічну програму тунелювання (вона розташована в / opt / alternate / ssh) з деяким параметром. В даному випадку, доступ до svn + joessh: // буде залучати особливу програму SSH з аргументами -p 29934 - корисно якщо ви хочете з'єднати програму тунелювання на нестандартний порт.
Потім він показує як визначити призначену для користувача змінну оточення, яка може перекрити ім'я програми тунелювання. Установка змінної оточення SVN_SSH це зручний шлях для перекриття агента тунелювання SSH за замовчуванням. Але якщо ви потребуєте в декількох різних перекриттях, для різних серверів, кожен можливо взаємодіє з різними портами або передача різних конфігурацій в SSH, ви можете використовувати механізм показаний в цьому прикладі. Зараз, якщо ви цього встановіть змінну середовища JOESSH. її значення буде перекривати вміст змінної тунелювання - $ JOESSH буде виконуватися замість / opt / alternate / ssh -p 29934.
Трюки конфігурації SSH
Можливо не тільки управляти як клієнт виконує ssh. але також управляти поведінкою sshd на машині вашого сервера. В цьому розділі, ми покажемо як управляти тим, які саме команди svnserve викликаються sshd. а також про те, як кілька користувачів можуть використовувати одну системну обліковий запис.