Если изложить кратко, то новый сервер мы строим на Debian 9 вместо 8, SQL меняем на открытую MariaDB, а PHP 5 на более быстрый PHP 7. Движок Nextcloud обновится с версии 11 до 13. Так же я упомяну как немного походим по граблям — сначала вдоль, а потом и поперёк.
Оглавление
Часть 1. Настройка среды Debian для повседневного использования
Часть 2. Создание сервера — настройка LAMP в Debian
Часть 3. Создание персонального облака — установка и настройка Nextcloud
Часть 4. Актуализация 2018 – Debian 9 и Nextcloud 13
Быстрая навигация по главе
Настройка среды Debian для повседневного использования
Создание сервера — настройка LAMP в Debian
Установка и настройка Nextcloud
Пара ссылок для чтения по Nextcloud
Настройка среды Debian для повседневного использования
Основная настройка изложена в первой части. Графический интерфейс и набор программного обеспечения в целом мало изменились и эти изменения интуитивно понятны.
В панели управления не нужно назначать кнопку переключения языков так как переключение задаётся на этапе установки системы. Вместо этого стоит назначить комбинацию клавиш для быстрого запуска консоли:
— Клавиатура: Комбинации клавиш -> Дополнительные комбинации -> Добавить новый пункт с названием «Terminal» и командой «x-terminal-emulator». После добавления щёлкаем по надписи «Выключен» и вводим комбинацию двух клавиш: Super (Win) + t.
У нас девятая версия системы Debian с кодовым именем Stretch. Поэтому список репозиториев теперь будет выглядеть следующим образом:
deb security.debian.org/debian-security stretch/updates main contrib non-free
deb-src security.debian.org/debian-security stretch/updates main contrib non-free# updates
deb httpredir.debian.org/debian stretch-updates main contrib non-free
deb-src httpredir.debian.org/debian stretch-updates main contrib non-free# binary and source packages
deb httpredir.debian.org/debian stretch main contrib non-free
deb-src httpredir.debian.org/debian stretch main contrib non-free# backports
# deb httpredir.debian.org/debian stretch-backports main contrib non-free
# deb-src httpredir.debian.org/debian stretch-backports main contrib non-free
На этапе настройки gnome стоит удалить файл /usr/share/applications/gksu.desktop, потому что в этой версии запуск из меню терминала суперпользователя всё равно работает через раз, если вообще работает. Мы вернулись в этом плане к Debian 7. Вообще непонятно почему в восьмёрке это стабильно работало, так как в одном из пояснений от разработчика gnome я понял, что подобный функционал выпиливается ввиду его небезопасности. В Debian 9 для доступа к консоли суперпользователя нужно открыть обычный терминал (Win+T) и ввести команду
$ su
после чего ввести пароль от суперпользователя.
Настройки через gnome-tweak-tool не претерпели никаких изменений. Но смогли удивить: в новой версии среды gnome невозможно настроить выключение компьютера по кнопке питания! Очень спорных ход команды разработки GUI, быстрого решения я не нашёл, поэтом настроил секцию электропитания следующим образом:
— Электропитание: при нажатии на кнопку питания установить действие Nothing
— Электропитание: ВКЛ «Не переводить в ждущий режим при закрытии крышки»
В первой статье я не обратил отдельного внимания на особенность работы gksu. Если запустить Double Commander [root] из меню и ввести пароль, то при следующих вызовах некоторое время пароль суперпользователя запрашиваться не будет. Это кеширование не очень безопасно, поэтому настройка gnome заканчивается следующими действиями:
— Открыть из меню избранного Double Commander [root], снять галочку «Запомнить пароль» (теперь по умолчанию она снимется для всех приложений) и ввести пароль root
— Скопировать на рабочий стол ярлыки /usr/share/applications/doublecmd.desktop и /usr/share/applications/firefox-esr.desktop и запустить их, разрешив выполнение.
Со сборкой нового Double Commander получилось поле граблей, по которому я находился вдоволь. Вообще говоря, собирать его вовсе и не обязательно – можно скачивать и ставить уже готовые пакеты. Смысл есть, если вам точно нужна свежая версия программы. Проблемы началась с того, что ранее настроенное IDE компилировать скачанный проект не захотело. Пришлось почитать страничку разработки и выяснить, что для Double Commander ветки 0.9.х рекомендовано использовать среду разработки Lazarus 1.6.4 (ссылка для скачивания пакетов указана в первой части):
# dpkg -i fpc_3.0.2-170225_amd64.deb
# dpkg -i fpc-src_3.0.2-170225_amd64.deb
# dpkg -i lazarus-project_1.6.4-0_amd64.deb
Далее скачивается и компилируется исходный код. Нужно обратить внимание, что, начиная с версии 0.8.х, появился новый компонент, поэтому теперь их список выглядит следующим образом:
— chsdet/chsdet.lpk
— CmdLine/cmdbox.lpk
— multithreadprocs/multithreadprocslaz.lpk
— dcpcrypt/dcpcrypt.lpk
— doublecmd/doublecmd_common.lpk
— KASToolBar/kascomp.lpk
— gifanim/pkg_gifanim.lpk
— synunihighlighter/synuni.lpk
— viewer/viewerpackage.lpk
После сборки и установки пакета открывается неприглядная картина: нет списка языков, не отображаются значки тулбара и ярлыки файлов в файловых панелях, всё выглядит криво. Сначала я думал, что где-то ошибся с IDE или настройкой сборки. После того как эффект воспроизвёлся пару раз на чистой системе (вот оно — преимущество использования запасённых виртуальных машин) пришлось вернуться в среду Debian 8.x, но и там меня постигла неудача. Я пробовал собирать в Lazarus 1.8.0/1.8.2 на Debian 8/9, но везде было одно и то же, кроме одного раза (!), когда всё же я получил нормальный пакет. На форуме программы мне особо не помогли, пришлось разбираться самому. Если на две одинаковые системы поставить собранный «плохой» и «хороший» пакеты, то можно заметить некоторые интересные вещи, которые наводят на мысль о том, что при сборке пакета как-то неправильно срабатывает checkinstall.
В /usr/lib/doublecmd должны находиться символьные ссылки doc, highlighters, language, pixmaps. А в реальности эти ссылки размещены в одноимённые папочки: doc/doc, highlighters/highlighters и т.д. Если в /usr/lib/doublecmd вручную восстановить ссылки из этих папок, а папки удалить, то получается полностью рабочий Double Commander.
Эту ситуацию я разрешил перепаковкой пакета с нужными мне изменениями. Не самый лучший вариант, откровенный костыль, но это работает.
Допустим, я получил «плохой» пакет doublecmd_0.9.0-1.gtk2_amd64.deb.
Сначала нужно открыть (разархивировать) полученный пакет:
# mkdir dir | dpkg-deb -R doublecmd_0.9.0-1.gtk2_amd64.deb dir
Следуем по пути dir/usr/lib/doublecmd и видим вместо символьных ссылок на doc, highlighters, language, pixmaps присутствуют реальные директории, которые и содержат нужные нам ссылки — пакет однозначно собрался криво и необходимо из соответствующих папок скопировать куда-нибудь символьные ссылки, удалить папки и перенести ссылки обратно:
# cp -P dir/usr/lib/doublecmd/{doc/doc,highlighters/highlighters,language/language,pixmaps/pixmaps} dir/
# rm -R dir/usr/lib/doublecmd/{doc,highlighters,language,pixmaps}
# cp -P dir/{doc,highlighters,language,pixmaps} dir/usr/lib/doublecmd/
# rm dir/{doc,highlighters,language,pixmaps}
Собираем пакет обратно и удаляем рабочую директорию:
# dpkg -b dir doublecmd_0.9.0-1.gtk2_amd64.deb_good.deb
# rm -R dir
Создание сервера — настройка LAMP в Debian
Подробная настройка сервера изложена во второй части. Принцип настройки и работы с веб-сервером не поменялся, так как основные его компоненты мало изменились. Apache только обновился. Обновление SQL на MariaDB происходит беспроблемно, что и неудивительно, учитывая закладываемую высокую совместимость с MySQL. PHP хоть и сильно хорошеет, но обновляется вовсе незаметно. Возможно стоило бы поменять apache на nginx и отказаться от самоподписного сертификата в пользу бесплатного Let’s Encrypt, но, видимо, не в этот раз.
Установка программного обеспечения:
# apt-get install apache2 apache2-doc
# apt-get install mariadb-client mariadb-server phpmyadmin
# apt-get install php7.0 php7.0-mysql libapache2-mod-php7.0
При установке phpmyadmin нужно выбрать преднастройку для apache2 сервера. При запросе о первичной настройке базы ответить утвердительно и задать пароль для будущего пользователя phpmyadmin.
Далее настройка происходит в точности так же, как и описано во второй части. Версии apache2 и openssl изменились незначительно, поэтому код конфигурации параметров SSL практически не отличается:
# 29-04-2018 / for apache2 2.4.25 & openssl 1.0.1f
# from mozilla.github.io/server-side-tls/ssl-config-generator
# parametrs help: raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.html
# modern configuration, tweak to your needs
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off# OCSP Stapling, only in httpd 2.3.3 and later
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/var/run/ocsp(128000)
При настройке PHP для кеширования данных я установил не только Memcached, но и Redis, специально настраивать который нет необходимости (настройка Memcached приведена во второй части):
# apt-get install memcached php7.0-memcached php7.0-apcu
# apt-get install redis-server, php-redis
В конце второй части я привёл полезный справочный материал. Несмотря на высокую совместимость MySQL и MariaDB справочный материал по MySQL становится несколько некорректным и требует обновления.
Начать стоит с того, что при работе от суперпользователя в терминал mariadb нас пускает под любым паролем! По умолчанию, при запуске клиента mysql под системным пользователем root, и при указании логина -u root, он по умолчанию соединяется через, так называемый, UNIX Sockets, и не проверяет пароль, даже если он есть и/или указан. Исправляется эта ситуация следующим образом.
Войти в mysql (пароль — любой!):
# mysql -u root
Переключить базу:
MariaDB [(none)]> use mysql;
Отключить UNIX Sockets:
MariaDB [mysql]> update user set plugin=» where User=’root’;
Выход из mysql:
MariaDB [mysql]> quit;
Если теперь попробовать войти в терминал mysql, то система запросит пароль. Для включение подобного функционала обратно необходимо повторит те же действия, но вместо отключения включить UNIX Sockets:
MariaDB [mysql]> update user set plugin=’unix_socket’ where User=’root’;
Изменение паролей пользователей несколько усложнилось. Для установки нового пароля pass123 пользователя user123 (для пользователя root меняется аналогично) необходимо выполнить следующие действия.
Войти в mysql:
# mysql -u root -p
Установить новый пароль:
MariaDB [(none)]> SET PASSWORD FOR ‘user123’@’localhost’ = PASSWORD(‘pass123’);
Обновить таблицу привилегий:
MariaDB [(none)]> FLUSH PRIVILEGES;
Выйти из mysql:
MariaDB [(none)]> exit
Установка и настройка Nextcloud
Подготовка сервера и принцип установки полностью идентичны описанию третьей части, разве что дополнительно нужно установить некоторые модули для PHP7:
# apt-get install curl libcurl3 libcurl3-dev php7.0-curl
Далее разворачиваем движок и организуем постоянное место для подключения контента. И тут нас поджидают хорошие грабельки. Дело в том, что, если в качестве места будет использоваться папка, подключенная через VMWare Shared Folders, то ранее используемая команда для «правильного» монтирования этой папки, равно как и скрипт nxcdata_automount.sh работать откажутся. Это было неожиданно и с этим пришлось какое-то время разбираться. Причина оказалась в том, что по какой-то причине не установился модуль vmhgfs. Изначально я подумал, что проблема в том, что я не стал ставить linux-headers и модуль vmhgfs не скомпилировался, но это было бы заметно сразу да и… папки-то VMWare Shared Folders в системе как-то автоматически монтируются! Затем была череда экспериментов с Debian 8/9 и различными версиями vmware-tools, но всё было тщетно – именно этого модуля никогда не оказывалось в установленных пакетах в Debian 9. Узнать какие установлены пакеты с названием, начинающимся на vm, можно так:
# lsmod | grep -i vm
После поисков в уже изрядно поломанном роскомнадзором интернете, когда по нужной тебе исключительно технически-справочной, явно не террористической, не экстремистской или иной аналогичной направленности, ссылке появляется заглушка типа «Сайт заблокирован по решению…», я обнаружил инструкцию на сайте VMWare, в которой предлагалось сначала установить open-vmtools, а потом уже «накатить» оригинальный набор vmware-tools. Но и это не помогло. Причина крылась совсем в другой стороне. На гитхабе, я нашёл топик, из которого удалось понять то, что в Debian 9 используется ядро 4.9 вместо 3.16 в Debian 8 и клиент Shared Folders перевели на подключение через FUSE, поэтому теперь команда монтирования будет выглядеть следующим образом:
# mount -t fuse.vmhgfs-fuse -o allow_other,umask=007 .host:/vmw-nxcdata /mnt/vmw-nxcdata
Соответственно, мой скрипт тоже претерпит изменения:
#!/bin/sh # nxcdata_automount.sh 1.1 ### BEGIN INIT INFO # Provides: myscript # Required-Start: # Required-Stop: # Default-Start: 1 2 3 4 5 # Default-Stop: 0 6 # Short-Description: nxcdata_automount.sh 1.1 # Description: nxcdata_automount.sh 1.1 ### END INIT INFO . /lib/lsb/init-functions # Start actions perform_start() { log_daemon_msg «Start nxcdata_automount» sleep 30 mount -t fuse.vmhgfs-fuse -o allow_other,umask=007 .host:/vmw-nxcdata /mnt/vmw-nxcdata #mount -t ntfs-3g -o uid=www-data,gid=www-data,fmask=007,dmask=007 /dev/sdb1 /mnt/sdb1 #mount -t ext4 /dev/sdb1 /mnt/sdb1 log_end_msg 0 return 0 } # Stop actions perform_stop() { log_daemon_msg «Stop nxcdata_automount» umount /mnt/vmw-nxcdata log_end_msg 0 return 0 } case $1 in start) perform_start ;; stop) perform_stop ;; *) echo “Usage: /etc/init.d/myscript {start|stop}” exit 3 ;; esac После организации места хранения контента и первичной настройки сервисе через браузер нужно внести изменения в config.php. Эти изменения я опишу полностью ниже.
Обратите внимание, что в скрипте nxcdata_automount.sh 1.1 пропала строка перезапуска сервиса fail2ban. Дело в том, что ранее сервис криво запускался из-за того, что при загрузке системы ещё не было смонтировано место хранения контента, что приводило к недоступности лог-файла nextcloud.log. Логичное решение проблемы – перенести лог в директорию /var/log. Проблема в том, что в Nextcloud 11 у меня почему-то не получалось перенести лог в другое место, но в Nextcloud 13 с этим не возникло никаких проблем.
Создаём файл:
# touch /var/log/nextcloud.log
Настраиваем доступ:
# chmod 644 /var/log/nextcloud.log
Изменяем права:
# chown www-data /var/log/nextcloud.log
Открываем файл:
# nano /var/www/nextcloud/config/config.php
Добавляем нижеследующее перед «);»:
‘log_type’ => ‘file’,
‘logtimezone’ => ‘/Europe/Moscow’,
‘logfile’ => ‘/var/log/nextcloud.log’,
‘loglevel’ => ‘2’,
Включаем кеширование — добавляем нижеследующее перед «);»:
‘memcache.local’ => ‘\OC\Memcache\Redis’,
‘redis’ =>
array (
‘host’ => ‘localhost’,
‘port’ => 6379,
),
‘memcache.distributed’ => ‘\OC\Memcache\Memcached’,
‘memcached_servers’ =>
array (
0 =>
array (
0 => ‘localhost’,
1 => 11211,
),
),
Обратите внимание, что мы заменили кеширование на Redis, который теперь будет использоваться для локального кеширования. Однако для распределенной системы облачных хранилищ будет использоваться Memcached.
Включаем механизм безопасного разрешения проблемы блокированных файлов — добавляем нижеследующее перед «);»:
‘filelocking.enabled’ => true,
‘memcache.locking’ => ‘OCMemcacheRedis’,
‘redis’ => array(
‘host’ => ‘localhost’,
‘port’ => 6379,
‘timeout’ => 0.0,
‘password’ => », // Optional, if not defined no password will be used.
),
Разрешаем внешний доступ к сайту — в секцию trusted_domains добавляем в массив IP адрес сервера, на котором установлен NexCloud, например, для адреса 192.168.233.100:
‘trusted_domains’ =>
array (
0 => ‘127.0.0.1’,
1 => ‘192.168.233.100’,
),
Необходимо помнить, что при запуске сервера из виртуальной машины, для доступа из локальной сети, в список нужно будет добавить IP адрес сетевого интерфейса хостовой машины.
В соответствии с рекомендациями на странице справки Nextcloud включаем opcache для PHP.
Открываем файл:
# nano /etc/php/7.0/apache2/php.ini
Добавляем нижеследующее в секцию opcache:
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
Старые настройки fail2ban для Nextcloud 13 никуда не годятся – мне пришлось скорректировать описание фильтра nextcloud.conf (/etc/fail2ban/filter.d/nextcloud.conf) и теперь оно выглядит вот так:
[INCLUDES] failregex = {"reqId":".*","level":2,"time":".*","remoteAddr":".*","user":".*","app":"core","method":"POST","url":".*","message":"Login failed: '.*' (Remote IP: '')","userAgent":".*","version":".*"}
ignoreregex =
Кроме этого пришлось немного подправить файл jail.local:
# выявляем неудачные попытки ввода пароля к nextcloud
[nextcloud] enabled = true
port = http,https
protocol = tcp
filter = nextcloud
logpath = /var/log/nextcloud.log
maxretry = 6
Как вы видите изменился не только путь к файлу лога, который будет парсить fail2ban, но и добавился параметр maxretry, говорящий о количестве ошибочных попыток авторизации. Зачем это нужно было делать, если в секции DEFAULT мы и так задали это значение на этапе настройки сервера LAMP? Дело в том, что у меня это не работало. fail2ban упорно меня банил с трёх попыток. Причём секция DEFAULT в целом работала. Почему так случилось и кто в этом виноват я так и не разобрался.
Помимо этой неприятности я вдоволь намучился с автобаном по правилу apache. Дело в том, что я решил закрыть доступ к корневой папке сервера удалив файл /var/www/.htaccess. Казалось бы, в настройках хоста default-ssl.conf доступ к поддиректории /var/www/nextcloud разрешён и так можно сделать. Но как только я набирал адрес сервера на другом компьютере, apache бодро рапортовал в свой лог ошибок нечто типа такого:
[Mon May 07 20:35:42.113958 2018] [authz_core:error] [pid 3211] [client 192.168.0.2:50738] AH01630: client denied by server configuration: /var/www/login
[Mon May 07 20:35:43.161755 2018] [authz_core:error] [pid 3210] [client 192.168.0.2:50744] AH01630: client denied by server configuration: /var/www/apps
[Mon May 07 20:35:43.547090 2018] [authz_core:error] [pid 3212] [client 192.168.0.2:50740] AH01630: client denied by server configuration: /var/www/js
[Mon May 07 20:35:43.610228 2018] [authz_core:error] [pid 3211] [client 192.168.0.2:50738] AH01630: client denied by server configuration: /var/www/js
[Mon May 07 20:35:43.618623 2018] [authz_core:error] [pid 3209] [client 192.168.0.2:50743] AH01630: client denied by server configuration: /var/www/apps
И fai2ban меня практически моментально банил так как браузер обращался к объектам вне директории /var/www/nextcloud. Вопрос почему происходило такое безобразие тоже остался без ответа – то ли некорректно работает браузер, то ли сам движок Nextclod отдаёт некорректные данные. Я просто вернул файл /var/www/.htaccess с разрешающей директивой:
Require all granted
Дополнительную «тонкую» настройку Nextcloud, изложенную в третьей части проводить не нужно. Первую проблему блокированных файлов мы разрешили так, как рекомендовали разработчики, задействуя механизм redis. Вторая проблема – с ошибками типа «Undefined index… Storage.php#757» ещё не проявилась и, надеюсь, не проявится. В любом случае ждать придётся немало, так как на версии 11 она проявилась только через несколько месяцев после ввода сервера в активную эксплуатацию. С третьей проблемой – невозможностью синхронизировать htaccess – получилась очередная история граблей. Изначально я настроил nextcloud, получив шаблонную виртуальную машину. После её размещения на рабочем компьютере, смене логинов и паролей и подключением жесткого диска для контента я запустил сервис, предварительно перенеся «начальные» данные пользователей admin и user в новое месторасположение. Сервер «поднялся» и без проблем работал ровно до тех пор, пока я не зашёл на него под учётной записью нового пользователя, допустим user1, которую я создал уже на месте развёртывания сервиса. Проблема заключалась в том, что сервер возвращал ошибку 500 (внутренняя ошибка) и отказывался далее работать. На него можно было зайти под пользователями admin и user, но больше никак. Эксперимент показал, что «эталонная» виртуальная машина ведёт себя точно так же. Не помогает манипуляция с изменением места хранения контента или отключением защиты. Учитывая изменения в сервере можно думать на что угодно – для исключения корректности его настройки надо разворачивать сервис на старом сервере, который ещё под Debian 8. Что я и сделал - и получил точно такой же результат. Вся проблема изящно крылась в редактировании файла varwwwnextcloudlibprivateFilesFilesystem.php, в котором я как раз и правил $blacklist, исключая htaccess из чёрного списка. Видимо, я изменил этот файл и nextcloud понял это. В файле сигнатур coresignature.json хэш на этот файл присутствовал и для версии 11, но 11-ая версия, видимо, ещё допускала подобные вольности. Очевидно, что в 13-ой версии в плане безопасности всё гораздо получше.
В целом, новый сервер у меня отработал около недели, поэтому можно делать какие-то выводы о его надёжности. Nextcloud 13 субъективно работает быстрее, но нужно понимать, что это и заслуга самого веб-сервера, построенного на более быстром PHP7 и несколько ином подходе к кешированию.
Так же осталась открытой тема с обновлением движка с сохранением данных. Почитав форумы у меня создалось впечатление, что всё может быть далеко не так просто. У меня накопился приличный объём архива и связываться с дополнительными вероятными проблемами при его обновлении мне откровенно не хотелось, так как моя ситуация вполне допускала просто запустить сервис заново. Если же вы будете обновляться настоятельно рекомендую сделать резервную копию не только работающего сервиса, но и архива пользовательских данных.
Пара ссылок для чтения по Nextcloud
Немного дополнительного чтения по Nextcloud.
- Обзор Nextcloud 12, в том числе со стороны пользовательского интерфейса и картинками из админки сделал wtigga в своей статье «Чем загрузить VPS: своё «облако» Nextcloud». В этой же статье описана установка LetsEncrypt с автоматическим обновлением сертификата раз в три месяца.
- Вы знаете, что на базе Nextcloud можно развернуть свой мобильный мессенджер с аудио и видеозвонками? denismosolov в своей статье «Nextcloud Talk» описал свой личный опыт использования подобного сервиса на базе Nextcloud 13.
Вернуться в начало, к оглавлению.
История создания домашнего облака. Часть 4. Актуализация 2018 – Debian 9 и Nextcloud 13.
Версия текста: 1.0.0.
Дата первой публикации: 17.05.2018.
Дата последней правки: 17.05.2018.
Наверное, вы все заметили, что со стилем текста к концу статьи стал какой-то непорядок. Всё правильно, в этот раз я просто не стал маскировать этот эффект. Про баг форматирования на GT было аккуратно написано 8 февраля 2018 года в третьей части. В саппорт я обращался через веб-форму на сайте, но, как видите, за 4 месяца мало что изменилось 😉
Источник
