Synology NAS DSM и ModX (и не только)

По работе регулярно требуется FTP, а с относительно недавних пор ещё и SFTP сервер, для выдачи заказчикам восстановленных данных, и для этих целей в нашей лаборатории давно используются решения от компании Synology. Восемь лет на этом поприще исправно трудился однодисковый старичок DS112J, а третьего дня было принято управленческое решение проапгрейдиться сразу по-взрослому, до четырёх-дискового DS920+

с усилением аппаратуры через SSD кеш (два 970 EVO Plus MZ-V7S250BW) и увеличением памяти до 20Gb (добавлением одной планки CT16G4SFD8266). С памятью пришлось повозиться, в итоге заработали только Micron (Crucial) Dual Rank, хотя у других заводились планки типа Apacer [ES.16G2V.GNH]. На моей коробке такая не заработала. К слову, 32Gb тоже не завелась, хотя была и Crucial и Dual Rank.

На него планируется навесить уйму всякого, в том числе виртуальную машину с сервером DrWeb, бэкапы, Photo Station и VPN сервер, и т.д. и т.п. В том числе и прикрутить сайт поддержки, с целью чего была предпринята установка лучшей CMS всех времён и народов, несравненного ModX Revo.

В процессе возник ряд успешно решённых проблем, с методами решения которых я тут и поделюсь.

Замена порядка дисков Synology Raid SHR

Начну с мини-лайф-хака. В коробку было поставлено 4-ре восьмитерабайтника и всё это богатство сконфигурировано в Synology Hybrid Raid (SHR) с форматированием в Btrfs. В целях эксперимента, после всех настроек выключил коробку и заменил порядок дисков с 1-2-3-4 на 1-2-4-3. Как и предполагалось, девайс этого даже не заметил. Видимо, при загрузке, ОС читает метаданные Raid и дальше строит виртуализации опираясь на эту информацию, фактический порядок физических дисков в слотах при этом роли не играет.

Ошибка 504 при установке CMS

После настройки Web Station, где по умолчанию используется веб-сервер Nginx, при установке ModX после всех предварительных настроек, проверки создания БД (используется пакет MariaDB, полностью совместимый с MySQL) после нажатия заветной кнопочки «установить», страница через некоторое время выпадала с ошибкой 504 Gateway Time-out.

Нашедшиеся в сети варианты решений вида ручного редактирования конфига «/var/packages/WebStation/target/misc/VirtualHost-nginx.mustache» не имеют смысла, т.к. там уже описаны переменные

которые задаются тут

Решение между тем диалектически очевидное-невероятное :) Ошибка 504 вызвана недостаточным значением «по-умолчанию» в 60 с. Следует выставить 3600, а если ваш Synology дохловат или загружен массой фоновой работы, то можно смело увеличить таймауты ещё вдвое, а то и втрое, и просто запастись терпением, пока не увидите заветное:

Настройки пользовательской конфигурации Synology Nginx

После успешной установки ModX в панели управления CMS мы увидим такой вот алярм:

«Каталог ядра в открытом доступе. MODX обнаружил, что папка ядра доступна (частично) извне. Это не рекомендуется и опасно для безопасности.». Опасно для безопасности, Карл! Как устранить опасность безопасности спросите вы? И я таки дам вам ответ.

Web Station предлагает опционально использовать для ваших сайтов веб-сервер Apache, но у труЪ кул-хацкеров это гавно должно быть в статусе «Не установлено»

Только Nginx, только хардкор! Я привык ко всяким хостерским VDS с заботливо установленными на них ISP Manager, серьёзно облегчающими администрирование этих ваших бэкендов и любимого всем прогрессивным человечеством нгинкса, но в Synology управление конфигами Nginx запрятано неочевидно. Во всей этой адовой цепочке подчиненных файлов конфигураций пользователю конечного сайта (в терминологии Synology Web Station это Virtual Host) доступен для настроек вот такой конфиг, которого нет :)

Удобнее все манипуляции производить с установленным на Syno DSM, Midnight Commander-ом и под учётной записью root, которую можно получить в терминале командой «sudo -i». Большинство конфигураций после перезапуска веб-сервера перезаписываются на дефолтные. Но в файле «.w3conf» который лежит по пути «/usr/local/etc/nginx/sites-available/» даётся ссылка на пользовательскую конфигурацию конкретного домена. В этой папке будет несколько файлов со служебными именами типа «659393e4-99f8-4cc3-ab0a-f4eba7abcba4.w3conf» или «c570d58a-39f0-422a-9d15-bd2cc48dddd4.w3conf». Найти нужный просто — в нём, в секции «Server», с самого начала, будет упомянут заданный вами в Virtual Host домен, а в конце файла будет ссылка на пользовательский конфиг вида «include /usr/local/etc/nginx/conf.d/служебный путь из буковок и циферок/user.conf*;» Файла «*user.conf» по указанному пути нет и его надо создать, дав на него права «655» пользователю «http»

В DSM версии 7.2 чуть сложнее стало. В «базовом» конфиге *.w3conf по пути«/usr/local/etc/nginx/sites-available/» в самом низу будет include на «conf.d/*.conf*;» и уже в этом конфиге который по адресу «conf.d/*» будет искомый конфиг, который начинается с переменной «root /volume1/web/домен», где в самом низу опять же ссылка «include /usr/local/etc/nginx/conf.d/служебный путь из буковок и циферок/user.conf*;»

Вместе с закрытием core Modx, я рекомендую воспользоваться httpaswd Nginx для защиты всего сайта. В результате, даже если из-за какой то уязвимости в CMS (что в Modx бывает крайне редко, и вот уже пару лет, как не попадалось вообще) ваш пароль на вход в CMS будет скомпрометирован, сотрудник службы безопасности Сбербанка хулиган не сможет войти в админ-панель, т.к. взлом грамотно настроенной Synology OS задача на порядки более нетривиальная.

Для этого в «user.conf» надо вписать такое:

location /manager/ {
    auth_basic "That's protected Area!";
    auth_basic_user_file /ВАШ ПУТЬ/.htpasswd;
}
location /connectors/ {
    auth_basic "That's protected Area!";
    auth_basic_user_file /ВАШ ПУТЬ/.htpasswd;
}
location /core/ {
    auth_basic "That's protected Area!";
    auth_basic_user_file /ВАШ ПУТЬ/.htpasswd;
}

Файл «.htpasswd» можно создать в любом онлайн-генераторе и положить его куда удобно, прописав к нему путь. После внесения изменений надо перегрузить Nginx для их применения. Перед рестартом рекомендую проверять синтаксис командой «nginx -t», которая пробежится по всем взаимосвязям и должна закончиться сообщением типа:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Перезапуск веб-сервера на DSM 7.1 для применения изменений в конфигах Nginx, после «sudo-i», выполняется командой «systemctl restart nginx». Доступны, так же, кроме «restart» другие полезные команды — «stop», «start» и «status». Результатом будет вот такое окно при входе в админ-панель, которое станет надёжным посредником между админкой (со своим логином\паролем, который тоже поди узнай) и внешним миром.

Перенос виртуальных машин с VMware на Virtual Machine Manager

Для того, чтобы осуществить миграцию (перенос) ранее созданной в VMware Workstation виртуальной машины на Synologe Virtual Machine Manager, первым делом потребуется провести экспорт в OVA формат.

Файлу при сохранении надо вручную указать расширение «*.ova». Далее в Virtual Machine Manager, на Synology DSM, выбираем «Создать» - «Импорт», указываем месторасположение файла (лучше заранее его сохранить в папку на самой коробке).

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

В случае возникновения проблем с загрузчиком, вида «no bootable device», надо будет сменить тип BIOS на UEFI.

В случае зависания на запуске графического режима потребуется запустить ОС в Safe Mode и удалить видеоадаптер, включая драйвера, либо сделать это на VMware, до экспорта. Для установки актуальных драйверов, в том числе и на виртуальный сетевой адаптер гостевой машины, в настройках надо подмонтировать ISO Synology VMM Guest Tool и запустить установку пакета после загрузки ОС.

Физически файлы виртуальных машин и снимки-снэпшоты находятся по адресу «/volume1/@iSCSI/LUN (/Snapshots)/VDISK_BLUN/служебные имена/vdisk.* Образ диска представлен файлом-посекторной копией без сжатия и шифрования (если при создании виртуалки не было указано иного).

DSM не грузится из-за нехватки памяти

Если вы столкнулись с ситуацией, когда NAS очень долго загружается, на email приходит уведомление «[DiskStation-Alert] В системе недостаточно памяти», а в логах многочисленные сообщения о том что тот или иной сервис или служба «stopped running because the system is out of memory», не помогает ни двойное нажатие на Reset, ни остановка всех пакетов из консоли.

Ключи для команды «synopkg»

start <package>	Запуск пакета.
stop <package>	Остановить пакет.
restart [--service] <package|searvice>	Перезапуск одного пакета/одной или нескольких служб.
resume <package>	Запуск пакета без изменения его состояния systemd enable. Это ничего не даст, если пакет отключен или уже активен.
pause <package>	Остановка пакета без изменения его состояния systemd enable. Это ничего не даст, если пакет уже неактивен.
start-depend <service>	Запуск всех пакетов зависит от конкретного сервиса.
stop-depend <service>	Остановить все пакеты, зависящие от конкретного сервиса.
onoffall start|stop [event] [param]	Запуск или остановка всех пакетов.
install <spk>	Установка пакета через локальный spk.
install_from_server <package> [volume] [user] [beta]	Установка пакета с сервера.
uninstall <package>	Деинсталляция одного или нескольких пакетов.
upgradeall [limitonly] [lang] [user]	Обновление всех обновляемых пакетов.
chkupgradepkg [lang]	Поиск всех обновляемых пакетов на сервере и принятие решения о необходимости обновления с учетом настроек пользователя.
checkupdateall [lang] [user]	Найти все обновляемые пакеты на сервере (сначала использовать кэш) и принять решение о необходимости обновления с учетом настроек пользователя.
status <package>	Получение статуса установленного пакета.
is_onoff <package>	Проверка наличия установленного и активного пакета.
version <package>	Получение версии установленного пакета.
query <spk>	Получение основной информации о пакете из файла spk.
list [--name] [--depend-on <package>]	Список установленных пакетов.
checkupdate <package> [lang]	Проверка обновляемости пакета.
show [--beta] [--lang <lang>] <package>	Показать детали пакета.
Show package details.	Показать все пакеты.

Для решения проблемы рекомендую вытащить все «родные» диски массива, вставить новый накопитель, поставить на него предыдущую версию DSM а потом вернуть массив обратно. В этом случае загрузка ОС встаёт на паузу до прогрузки служб, выжирающих оперативную память и появляется возможность переустановки DSM в автоматическом режиме.

Откат на предыдущую версию DSM

По-умолчанию в DSM невозможно вручную или автоматически поставить более раннюю версию операционной системы. Чтобы решить эту задачу понадобится прибегнуть к ручному редактированию файла «VERSION» от учётной записи «root», который лежит по пути «/etc.defaults/». После перезагрузки появится возможность вручную указать нужный *.pat файл для переустановки OS.