SVN для NAS под Synology DSM 7.2. Записки Linux дилетанта

Гайд по установке SVN сервера на современных NAS от компании Synology. С небольшим лирическим отступлением в начале.

Преамбула

Впервые с NAS от Synology я встретился в 2017 году, когда у меня уже был некоторый опыт использования небольшого домашнего сервера, который я использовал для торрентов, гордо называя его NAS :-) Потом помог человечку одному завести небольшой двухдисковый NAS. Он использовался в качестве сетевого архива фоток. У меня к этому времени уже начали формироваться новые пожелания для своего NAS, в частности, кроме торрентов и свалки, эээ, бэкапа разной инфы хотелось иметь и свой SVN сервер. И вот, после простого создания базовых сервисов того NAS-а, я с удивлением обнаруживаю, что там есть легко устанавливаемые приложения и для торрента, и для SVN — это помимо всего прочего. C тех пор я крепко задумался о NAS именно от Synology. Но меня сильно смущало использование тех ARM со смешными скоростями, что были в их первых домашних NAS. Даже с базовыми сервисами они всё-таки тормозили. Ставить на них чего-то большее явно было бы тем ещё удовольствием.

Вскоре после этого появились NAS на Celeron. Получше, чем на ARM предыдущих поколений, но всё ещё не то. Но начал присматриваться. Попытался собрать сервер с NAS самостоятельно из остатков своих прошлых компов. Зря что ли 10 лет назад открыл тему NAS своими руками, которая за это время уже показывает 18 серию. Но понял, что цена этого пути на нормальной базе в реальности будет стоить не меньше, чем купить готовое устройство с массой готовых приложений. Да ещё эти бесконечные sudo -l gbt+ … И тут появляется DS1621+ на AMD Ryzen — а вот это уже интересно. И CPU явно побыстрее, чем Целероны, хоть это и не десктопные камни. Но для домашнего NAS DS1621+ великоват, да и цена не радует. В-общем, дождался DS923+, скидок на Black Friday — и вот оно, счастье в отдельно взятом домашнем офисе инженера.

Что такое «не везёт» и как с ним бороться

Поскрёб по сусекам, наскрёб на них три 3ТБ диска + 1ТБ диск Hitachi, купленные примерно в 2018 году специально для такого случая. Да, по нынешним временам это не самая умопомрачительная ёмкость. Почитав, как одну из веток форума, так и информацию на сайте Synology, в частности, об SHR, поиграв с Synology Raid Calculator, понял что всё не так уж грустно и печально. Пока будет 6.2ТБ, как начнутся проблемы либо с местом, либо с дисками, найду что-то побольше на очередной распродаже и поменяю.

А вот с софтом случилась неприятность. Synology убрала поддержку SVN при апгрейде своей системы с DSM6 на DSM7, что, вообще говоря, явилось шоком для большого количества пользователей NAS этой компании. Счастье в отдельно взятом домашнем офисе превратилось в некоторое уныние. Обращение за помощью в тему форума, посвящённую этим NAS, привело, для начала, к вопросу типа: «Зачем нужен SVN, если есть Git?» Да какая вам разница? Потом пошли «советы» через губу от завсегдатаев ветки: докер, проброс портов и реальный буллинг. В-общем, конечно плевать на буллинг, но в условиях отсутствия работы модератора это создаёт не самую приятную атмосферу. Хорошо, что среди участников ветки есть Кирилл Кочетков — дал ссылки на свои три статьи по построению домашней сети (ну, это я уже знал) и подключению Synology NAS к ней. Кое-что полезное я оттуда подчерпнул. Особенно из Строим домашнюю сеть. Сетевой накопитель Также Кирилл нашёл для меня несколько ссылок на докеры с SVN от различных авторов и подсказал, какой по его мнению, наиболее интересный. И англоязычный форум, где поднималась тема установки SVN на DSM7. Пора было выходить из уныния.

Поискал в сети информацию по докерам. Примерно понял, что это такое. Нашёл ещё SVN докеры, почитал документацию к ним. Все авторы уже имели ранее svn в своих системах, пути были настроены, порты настроены, а тут надо всё с нуля. Первую реальную помощь мне оказал модератор англоязычного форума, имеющий опыт не только в NAS, но и в Линуксе. Ради меня он поставил к себе один из серверов, хотя ему он был совсем не нужен и терпеливо отвечал на мои дилетантские вопросы. В общем, сервер я поставил, но, как оказалось, веб интерфейс у него был, но GUI не было. А я, как человек, измученный нарзаном, привык обращаться через графическую оболочку. Что делать дальше тот модератор не знал. Стал искать дальше. И всё-таки нашёл, то, что хотел. Более того, GUI показался мне даже более мощным, чем те, с которыми работал. Давал больше возможностей по управлению репозиториями и правами пользователей. И есть инструкция по установке. На французском языке, но кого это волнует в наше время. Проследовал по инструкции и, о чудо, оно заработало!!! НО!!! Как всегда — не работали пара заявленных возможностей (каких именно — будет ниже). Причём в документации было указано, как исправить это безобразие. Всего лишь поменять ключи в файле config. ini Всё бы ничего, но этот файл внутри докера и напрямую к нему доступа нет. И тут я снова залип. Открыл тему в форуме ixbt про программы в Unix. Описал проблему, спросил может знает кто, как с докером работать. И что вы думаете, один из первых вопросов: «Зачем SVN, если есть Git?» Да что ж вам неймётся то!!! И снова никакой помощи. Линуксоид нынче не торт… Но, как говорилось в тележурнале моего детства «Хочу всё знать»: «Мы не привыкли отступать!»

На сцену выступили… ChatGPT и Bard (Google AI). Сейчас могу сказать, что для нормального линуксоида задача минут на 30, ну может час максимум. Мне при помощи этих систем пришлось потратить суммарно около недели. Но оно того стоило — всё работает. И действительно с бОльшими возможностями по управлению, чем в других системах. Что касается самих систем AI понял один момент: нельзя с ними чататься очень долго. При длинном чате они теряют контекст общения, не могут отследить, какие результаты уже получены и тупят. Причём по-разному: ChatGPT начинает ходить по кругу, повторяя одно и то же. Bard начинает жаловаться: «Я только лингвистическая модель, не могу помочь с этим» :-)

Да, прелюдия несколько затянулась. Пора бы приступить непосредственно к акту…

Ставим SVN docker на DSM7.2

Здесь я опишу, как ставить SVN docker на новый NAS, который ещё не виден в интернете. Те, у кого доступ к интернету давно настроен или не нужен, могут его пропустить. Да, у меня стоит англоязычный интерфейс. Привычка такая. Думаю, это не должно сильно мешать при использовании русскоязычного интерфейса.

Первый шаг: подключаем NAS к интернету

По умолчанию DSM7.2 подключает NAS через механизм, названный QuickConnect, но данный интерфейс не подходит для подключения сервера SVN. Ему нужен IP адрес, неважно в виде цифр или строки. В статье Кирилла хорошо расписано про подключение портов, в новой DSM немного другой GUI, но в целом проблем вызвать не должно. Но хотелось бы добавить, что сейчас Synology предоставляет возможность выбора различных адресов хоста, которые можно использовать для доступа к своему NAS и SVN снаружи через DDNS

Шаг второй и основной: собственно установка SVN сервера

Устанавливаем Докер

В DSM7.2. он называтеся Container Manager. Устанавливается, как любое другое приложение системы

Скачиваем образ SVN сервера

Заходим в Registry, находим clamy54/svn-svnadmin и скачиваем его.

Особо интересующимся информацию по этому образу можно найти по следующим ссылкам:

1. https://hub.docker.com/r/clamy54/svn-svnadmin — сам образ на хабе докеров
2. https://github.com/clamy54/docker-svn-iF.SVNAdmin — Исходники этого контейнера. Может кто захочет создать свою версию :-) Состоит из двух частей — обрезанная Ubuntu и GUI для веб интерфейса к администрированию сервера
3. https://github.com/mfreiholz/iF.SVNAdmin — Исходники GUI
4. https://svnadmin.insanefactory.com/documentation/ — документация по этому GUI. К сожалению, весьма скудная, но мне помогла.
5. https://www.be-root.com/2021/11/25/synology-et-serveur-svn/ — страница на сайте автора докера по установке на французском языке, но кого это волнует при наличии онлайнового переводчика. Правда, перевод на русский язык весьма оригинальный — «subversion tools» переводится, как «подрывная деятельность», так что лучше ограничиться переводом на английский. :)

Ну и автор использует DSM 7.0 в то время, как актуальная версия DSM 7.2, в котором менюшки немного другие. Это один из моментов, который подвиг меня написать свои заметки по этому докеру. Может кому-то ещё пригодится. К тому же автор не довёл дело до конца.

Создание папок для SVN

Для начала при помощи File Station в директории docker создать папку svn  — корневая папка для SVN сервера. И уже в этом корне следующие папки, которые необходимы для работы сервера:

1. keys — служебные файлы сервера, сертификаты и что-то ещё, необходимое для его работы
2. dav_svn — файлы логинов и паролей пользователей. Пароли, естественно, в зашифрованном виде.
3. svn  — пользовательские проекты.
4. conf — для файла конфигурации. Автор контейнера не предлагает создание этой папки, это уже создано мной в процессе настройки для файла config.ini. Можно было бы его записать в keys, и это было бы достаточно логично. Но это может быть рисковано при апдейте контейнера, который не требует наличия такого файла.

HW, FW, fpga — это уже дополнительные папки для моих различных проектов. Об этом — позже.

Запуск установки докера

Здесь всё очевидно — выделить образ и нажать кнопку Run.

Создание контейнера

Вводим имя контейнера и разрешаем автоматический рестарт сервера при перезагрузке NAS. Нажимаем Next.

Настройка портов и путей соответствия локальных папок папкам контейнера

Для начала устанавливаем порты для обращения к заданным портам контейнера. Порт 443 используется для доступа серверу по интерфейсу svn://. Порт 80 — для обращения по http:// В принципе, порт 443 обычно никем больше не используется, поэтому в первом столбце можно его просто повторить. А вот порт обычно 80 используется для веб страниц — поэтому лучше его поменять. Но как справедливо писал Кирилл Кочетков в своих статьях, лучше поменять порты на какие-то другие нестандартные. Например, на год рождения любимой тёщи. Меньше вероятность, что кто-то попробует пробиться на Ваш NAS. Доступные номера портов — от 1024 до 65535.

Далее связываем локальные папки, которые былм созданы при помощи File Station с внутренними папками контейнера. Для чего кликаем на кнопке «+ Add Folder» и поочерёдно назначаем соответствие папок: keys, dav_svn и svn. Папку conf пока не трогаем. После нажатия кнопки Select будет появляться часть таблички, где в первом стольбце указан путь к локальной папке, а в центральную часть надо вписать путь к папке в контейнере. После заполнения всех трёх путей должна получиться следующая таблица:

После чего нажимаем Next и… собственно первичная настройка на этом закончена. Просто запускаем наш сервер:

Можно к нему обратиться по внутренней сети http://<nas_address>:10080 - ну, или год рождения любимой тёщи 😀, в зависимости от того, что было поставлено в настройках. В результате чего будет предложено ввести ваш логин и пароль. По умолчанию первый вход идёт с именем пользователя и паролем admin/admin. Естестественно пароль затем лучше изменить.

Дальше для знакомых с SVN будет всё более-менее понятно.

Настройка роутера

Сервер запущен. Но если хочется пользоваться им не только из внутренней сети, но и из интернета, то надо обратиться к настройкам роутера. Для этого надо прокинуть адреса внешних портов на внутренние порты, используемые сервером. Кстати, никогда не подумал бы, что английское «forwarding ports», к которому я привык в своём роутере, в русскоязычном IT обозначается, как «прокидывание портов», хотя смысл очевиден. Когда мне выдали это выражение в форуме, решил, что это сленг мамкиных компьютерщиков. Но GPT объяснил мне, что это сейчас общепринятый термин в русскоязычной IT среде. В-общем, давайте прокинем порты :-)

Конечно во всех роутерах интерфейс настройки немного разный. В моём Asus это выглядит следующим образом:

Как здесь видно, для File Station оставлен тот же порт, как и в статье Кирилла, для SVN те порты, что назначили ранее (например 10080 и 10443). Локальный IP адрес у всех трёх сервисов, естественно, одинаков. Port range (почему range…) — можно поставить те же, что и локально, но если хочется полностью запутать вероятных хакеров, которым вдруг стал интересен Ваш NAS, то можно поставить совсем другие. Главное — не забывать допустимый диапазон от 1024 до 65535.

Да, я обозначил, что на хх443 порту у меня сидит протокол https для моего SVN — это ошибка. Это для протокола svn://, которым я всё равно не пользуюсь. Но это чисто внутреннее название, ни на что не влияет.

После того, как нажали на Apply и подождали перезагрузки роутера можно в строке браузера ввести http://<внешний адрес>:<номер порта>/ и после согласия с браузером, что понимаете все риски, связанные с протоколом http:// получаете доступ к своему SVN через интернет.

Шаг третий: Добавляем недобавленное

«Хорошо, поздравляю, сервер заработал», — скажет нетерпеливый читатель: «А где же Linux?»

«Спокойствие, только спокойствие» (c)Карлсон. Подходим и к этому. Я, как человек, привыкший к GUI для администрирования SVN серверов был крайне удивлён, что пакет iF. SVNAdmin не предоставляет некоторых базовых возможностей:

1. Можно создать репозиторий, но нельзя его удалить. При том, что пользователям можно дать права на удаление проектов. Да, администратор может зайти на NAS и просто удалить соответствующую папку с проектом, но не через SVN.
2. Нет кнопки получения ссылки на репозиторий.
3. Невозможно создать модель: один репозиторий — много проектов. Только один репозиторий — один проект. Причём интерфейс сделан так, что теоретически возможно, но на практике получается только один проект, но в дополнительной папке. Лично я больше привык к модели 1:1, так что мне это не будет мешать, но как-то это неправильно.

Что двигало автором этого веб интерфейса для таких ограничений — непонятно. Но, как оказалось, в крайне скудной одностраничной документации есть указание для исправления первых двух пунктов. Надо всего лишь поменять пару ключей в файле config.ini. Bingo! Но есть одна тонкость. Сам пакет рассчитан на установку админом того Линукса, куда ставится этот пакет. У нас же докер, внутрь которого обычный пользователь не полезет. Пришлось перекквалифицироваться в необычного, по причинам, указанным в начале статьи. Благо, ChatGPT и Bard доступны и в их базе данных, безусловно, есть информация о системных возможностях Линукса. Да, для того, чтобы вытащить нужную информацию, приходится потратить некоторое время, но куда ещё можно податься Linux дилетанту… Что же, пора показать результат бдений с этими ИИ.

Достучаться до Linux

Для начала надо разрешить доступ к системе через любимый линуксоидами терминал. Ну какой же Linux без треминала. Для этого надо зайти в Control Panel -> Terminal & SNMP и разрешить Telnet и SSH

После чего запускаем любимую терминальную программу (обычно рекомендуют Putty, но я предпочитаю Tera Term), вводим имя хоста (внутренний адрес или его имя во внутренней сети), убеждаемся, что номер порта соответствует номеру порта в NAS, SSH выбран, версия SSH2, кликаем на кнопке OK,

вводим свои имя администратора и пароль, снова OK и вот он сладкий момент для каждого линуксоида — чёрный терминал с командной строкой

Впрочем, в Tera Term цвет терминала, как и фонт и его цвет, можно настроить под себя.

Получаем доступ к config. ini

Как уже было сказано ранее, у нас нет доступа к файлу config. ini, чтобы внести туда необходимые изменения в соответствии с документацией. Точнее, истинный линуксоид быстро разберётся и сможет отредактировать этот файл и внутри докера в строчном редакторе vi. Но это точно не путь дилетанта. Да и, скорее всего, пойдя по этому пути, придётся менять этот файл каждый раз при перезапуске контейнера. Вот этого дилетантам точно не надо. От слова совсем. Но, к нашему дилетантскому счастью, докер устроен так, что если связать некий внутрениий файл контейнера с файлом с таким же именем, но снаружи, то при каждом перезапуске он будет использовать этот внешний файл. Помните папку /svn/conf directory, про которую я писал выше при настройке контейнера. Вот сейчас мы и вынесем нужный нам файл в эту папку. В результате моих изысканий при помощи ИИ выяснилось, что необходимый файл в контейнере находится по пути: /var/www/html/data/config.ini. Можно, конечно воспользоваться этим послезнанием, но мало ли кто-нибудь когда-нибудь сделает апдейт этого контейнера и переместит этот файл в другое место. Так что лучше уточнить, что он именно там. Две следующие команды проверяют путь к нужному файлу и копируют его в папку снаружи контейнера:

sudo docker exec -it /<svn-name> find / -name config.ini 
sudo docker cp <svn-name>:/var/www/html/data/config.ini /volume1/docker/svn/conf/config.ini

Напоминалка для дилетантов.

1. sudo — притворяемся крутым администратором системы (super user). При этом система захочет уточнить этот статус и запросит пароль. Самое противное, что при вводе пароля в этом случае на экране терминала ничего не происходит. Если пароль введён правильно, то результатом будет указанная выше строка пути к файлу config. ini
2. <svn-name> — сюда вводится внутреннее имя NAS или его IP адрес
3. cd — Change Directory — перейти в другую папку. Применим чуть ниже.
4. ls — List — аналог dir в системах от Microsoft.

Файл мы скопировали, казалось бы пора его редактировать. Но не тут-то было. Он скопирован из-под аккаунта администратора и по умолчанию менять и удалять его может только администратор. системы. Для того, чтобы редактировать его с помощью встроенного в DSM текствого редактора надо поменять права доступа к нему, а для этого по-нашему, по-дилетантски добраться до папки, где он находится. Используем для этого пару команд:

cd .. // перейти на уровень вверх
ls    // прочитать директорию

до тех пор, пока после ls в списке файлов не появится название volume1

После чего вставляем ещё аналогичную пару команд и меняем права доступа к файлу config. ini

cd volume1/docker/svn/conf/ // идём сразу в нужную папку
ls                          // На всякий случай убеждаемся, что нужный файл находится на месте
sudo chmod 777 config.ini   // меняем права доступа к файлу для всех пользователей

Уфф. В целом с Линуксом для данной задачи закончили. Ну, почти. Зависит от желания некоторого расширения возможностей сервера. Но пока да, можно отдышаться.

Размораживаем замороженные возможности

На время написания этого текста я разобрался, как решить первые два пункта из списка выше. Но по порядку:

1. Открываем File Station
2. Проходим в docker/svn/conf
3. Открываем файл config. ini в текстовом редакторе системы.
4. В самом низу этого файла есть секция [GUI]
5. В этой секции надо поменять ключ RepositoryDeleteEnabled. Строчка должна выглядеть так: RepositoryDeleteEnabled=true
6. Добавляем строку CustomDirectoryListing=http://<svn-address>:<svn-port>/svn/%1/%2
7. Сохраняем файл.
8. Останавливаем контейнер
9. Заходим в Settings и нажимаем кнопку +Add File
10. Добавляем строку для config. ini (см. ниже)
11. Сохраняем изменения и нажимаем на Start.

После внесённых изменений и перезапуска сервера уже можно работать с достаточным уровнем комфорта.

Главное — при добавлении новых пользователей не забывать про установку уровня их прав.

Недостроенное. Задачки для недилетантов

Многопроектный репозиторий

SVN, как упоминалось ранее, может работать в двух режимах:

1. Один репозиторий, один проект. При этом каждый новый проект начинается с rev.1 и последовательно добавляет по единичке на каждый новый commit (сохранение текущего положения проекта). Лично для меня это наиболее привычный режим. Я бы сказал, что это режим для разработчиков.
2. Один репозторий, много проектов. Нумерация версий сквозная для всех проектов. Т. е., например, открыли первый проект. Он начался с rev. 1. Сделали несколько коммитов, дошли до rev.5. Потом создали второй проект, ему сразу присвоен rev. 6 И начинается свистопляска — каждый коммит увеличивает не порядок внесения изменений в проект, а в репозиторий. И у каждого проекта получаются прыжки между номерами версий, причём прыжки могут быть через сколько угодной ступеней. Если, скажем, у меня текущая версия проекта 233, то это совсем не значит, что предыдущая была 232, а не 172. Зато как удобно администратору — можно единым махом снести на хрен весь репозиторий со всеми проектами для очистки дискового пространства.

Но, как бы то ни было, установленная система позволяет создать второй «административный» тип репозитория.

Но вот только в таком случае в каждом мультипроектном репозитории получается создать только один проект. Попытка создания следующего вызывает ошибку. Хорошо, что хотя бы сервер не рушится :-)

============================================

Создание нескольких рабочих пространств/папок для репозиториев

Это разновидность первого режима. Просто создаются папки и в каждой можно добавлять репозитории первого типа. Довольно удобная штука. Выглядит это следующим образом:

Это один из вариантов дерева репозиториев в соответствии с темами моих проектов. Для какого-нибудь фрилансера может быть удобно разбить по компаниям, для которых делаются проекты. Чтобы случайно не перепутать и не дать доступ одному клиенту к исходника проектов другого. Как это сделать, покажу ниже.

Соответственно, при управлении репозиториями можно сразу определить к чему относится тот или иной проект

Так вот, создать проекты в этих директориях можно, но вот работать с ними — нет. Помните строчку их config. ini: CustomDirectoryListing=http://<svn-address>:<svn-port>/svn/%1/%2 ? Так вот, для моего набора типов проектов нужно иметь возможность вместо строки svn подставлять строчки hw, fw, fpga. Сделать какую-то привязку этого листинга к нужной папке репозитория.

=================================================

Скорее всего для решения этих двух задачек надо просто добавить какие-то строки в config.ini. Но для этого либо досконально знать команды управления svn, либо разобраться в исходниках используемого интерфейса, написанного, насколько я понял, на PHP. Либо и то, и другое. В общем занятие для недилетанта. Не исключаю, что для него это будет как два байта переслать :-)

Возвращение к истокам/Линуксу. Подготовка для многопапочного репозитория

В документации к iF. SVNAdmin есть упоминание о таком режиме использования. С примерами. Почему я и думаю, что это должно оказаться не особо сложным. Шаги для создания таких папок следующие

Добавление ключей в config. ini

Открываем в текстовом редакторе локальный файл config.ini. Там уже есть такие строки:

[Repositories:svnclient]
SVNParentPath=/var/svn
SvnExecutable=/usr/bin/svn
SvnAdminExecutable=/usr/bin/svnadmin

Добавляем в него после этой секции дополнительные (применительно к тем папкам, что я показал выше)

[Repositories:svnclient:1]
SVNParentPath=/var/hw
Description=Hardware Projects

[Repositories:svnclient:2]
SVNParentPath=/var/fw
Description=Firmware Projects

[Repositories:svnclient:3]
SVNParentPath=/var/fpga
Description=Verilog Projects

И сохраняем файл.

Ещё немного Линукса. Создаём папки для других репозиториев

Заходим в терминальную программу с SSH и прописываем следующие строки:

sudo docker exec -it <Имя SVN> /bin/sh  // запуск shell внутри контейнера, указанного в скобках
ls                                      // на всякий случай читаем директорий, чтобы убедиться, что папка var на месте
mkdir var/fw                            // создание папки fw или той, что надо
chmod 777 var/fw                        // "танцуют все!"

При необходимости последние две строки повторить для каждого нового репозитория. Но название папки для репозитория должно быть только маленькими буквами. Не спрашивайте меня почему :-).

Ну, теперь выдыхаем: пока Linux. До новых встреч!

Подключение локальных папок для новых репозиториев

Собственно, тут уже после всего, что прошли, совсем просто и очевидно 😀

Остановить контейнер, прописать соответствия путей, запустить контейнер. Это делали и ранее. Укажу только пути

Но напоминаю, пока кто-нибудь не подскажет нужные изменения в config. ini, пользоваться ими не получится. Если только не редактировать файл конфигурации каждый раз.

Дополнительные материалы

Чтобы не было вопросов типа «Почему не Git»

Потому что гладиолус. Вот очень хорошая и простая статья Git vs SVN: What Is The Difference?

Дисклеймер для GreenPeace

Во время установки SVN сервера на NAS ни один линуксоид не пострадал!