С момента публикации трёх прошлых частей я получил несколько отзывов от людей, которые, никогда не пользовавшись linux, по предложенным инструкциям смогли успешно «поднять» свои домашние сервера. Я не собирался делать дополнение по обновлению софта, предполагая, что есть хорошая база, отталкиваясь от которой каждый сможет вполне самостоятельно, при наличии времени и желания, актуализировать свой веб-сервер и облачный движок. Однако, после того как я занялся этим сам, как всегда появились некоторые моменты, освещение которых может помочь новичку сэкономить время. И я решил написать эту «дифференциальную» часть, отступив от принципа «всё в одной статье». Поэтому, в первую очередь, этот материал будет интересен тем, кто достаточно подробно ознакомился с тремя предыдущими статьями и/или положил их в закладки. Использование нового программного обеспечения делает неверными некоторые ранее изложенные инструкции и четвёртая часть будет содержать только обновление подобной информации.

Если изложить кратко, то новый сервер мы строим на 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' => '\OC\Memcache\Redis',
'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. Что я и сделал - и получил точно такой же результат. Вся проблема изящно крылась в редактировании файла \var\www\nextcloud\lib\private\Files\Filesystem.php, в котором я как раз и правил $blacklist, исключая htaccess из чёрного списка. Видимо, я изменил этот файл и nextcloud понял это. В файле сигнатур \core\signature.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.

Лог обновлений
1.0.0 [17-05-2018]
Первая версия.



Наверное, вы все заметили, что со стилем текста к концу статьи стал какой-то непорядок. Всё правильно, в этот раз я просто не стал маскировать этот эффект. Про баг форматирования на GT было аккуратно написано 8 февраля 2018 года в третьей части. В саппорт я обращался через веб-форму на сайте, но, как видите, за 4 месяца мало что изменилось ;)

Комментарии (35)


  1. pred8or
    17.05.2018 11:02

    (комментарий удалён)


  1. nosko_stojachkov
    17.05.2018 11:28

    Возможно стоило бы поменять apache на nginx и отказаться от самоподписного сертификата в пользу бесплатного Let’s Encrypt, но, видимо, не в этот раз.

    Обязательно используйте nginx. А Let’s Encrypt уже выдает wildcard сертификаты.


  1. ildarz
    17.05.2018 11:31

    отказаться от самоподписного сертификата в пользу бесплатного Let’s Encrypt, но, видимо, не в этот раз.

    Если бы я делал домашний сервер, вот как раз этого я бы не стал делать ни в коем случае. А сделал бы именно самоподписанный сертификат и certificate pinning в каком-то виде на клиентах.


    1. NeuroHunter
      17.05.2018 11:38

      А можно поподробнее — почему не Let's Encrypt?


      1. ildarz
        17.05.2018 12:36

        Потому что нет смысла, у Let's Encrypt другая цель. Сертификат с публичным доверием вам нужен, если вы собираетесь пускать на свой ресурс круг лиц, которых вы никак не контролируете. И идеология Let's Encrypt (частая смена сертификатов) плохо сочетается с certificate pinning (когда клиент жестко привязывается к сертификату сервера, и при любой смене последнего выдает предупреждение), а второе — в случае домашнего сервера "для своих", на мой взгляд, куда более надежная мера защиты, чем то, что пропагандирует Let's Encrypt.


        1. geisha
          17.05.2018 13:12

          Так и доменное имя не нужно потому что за него платить и его могут отозвать / увести.


        1. Sergey78
          17.05.2018 15:49

          Одно из удобств NC, это раздать файл кому-то. Не надо ничего никуда закачивать, просто дал ссылку и все, она еще и удалиться сама через указанное время. В таком случае самоподписанный сертификат не удобен, т.к. вызывает лишние вопросы, особенно если на «той» стороне не слишком разбирающийся в вопросе пользователь.


          1. ildarz
            17.05.2018 16:20

            По-моему, предельно ясно, что всё зависит от сценария использования. Делаете публичный сервис — нужно зарегистрированное доменное имя, сертификат от публичного УЦ, и т.п. Делаете чисто для себя и близких — всё это нафиг не нужно и может быть даже вредно.


  1. Silvatis
    17.05.2018 12:28

    а почему не owncloud? Интересны преимущества.


    1. ksenobayt
      17.05.2018 13:07

      Nextcloud является форком Owncloud, разработку которого ведёт та же команда и тот же автор, что начал оригинальный проект. К нынешнему Owncloud они никакого отношения уже не имеют.


      1. Silvatis
        17.05.2018 15:15

        но тем не менее, какова причина выбрать форк?


        1. ksenobayt
          17.05.2018 16:08

          Я лично его выбрал потому, что Nextcloud продолжают активно развивать те же люди, которые изначально придумали и запилили Owncloud. Всё, что сейчас делает Owncloud GmbH — отпиливает «премиум-функционал» community edition, и навязывает платный саппорт и хостинг этого облака на каких-то своих серваках где-то там.


          1. AlexanderS Автор
            17.05.2018 18:34

            Все верно, моя мотивация, когда озадачился выбором, именно поэтому склонилась к NC.


        1. justhabrauser
          17.05.2018 17:57

          Там примерно та же история, что и с eGroupware:
          1. была дружная команда, пилили чистый opensource долгими зимними вечерами
          2. потом решили, что колпашить саппортом 24/7 бесплатно как-то некузяво — и запилили типа «VIP-доступ»: «за дегни — любой каприз». Заметим: opensource — основное, все причуды — за дегни (это — нормально)
          3. деньги пошли, начальству понравилось — и возник вопрос…
          4. и commerce превратилось в основное, а opensource — по остаточному принципу
          5. ну и пацаны разругались (там тоже свой Столман есть)
          Итого: местный столман форкнул egroupware, переобозвал, накинул ништяков — и продает VIP-доступ кому нужно (схема примерно как RedHead).
          Ну и использует преимущества opensource по-полной (бесплатное тестирование, например)
          Короче — «всё сложно» (tm)


          1. ksenobayt
            18.05.2018 09:22

            Ну, справедливости ради, RedHat не отдаёт готовые образа RHEL даже под freeware, позволяя по лицензии лишь 14-дневный триал. Да, никто не спорит, образ качается без проблем, потом к нему винтятся EPEL и что-нибудь там ещё, и все живут долго и счастливо — но вопрос формального нарушения лицензии остаётся.

            То, что есть CentOS — оставим за рамками, это предмет отдельной дискуссии.


  1. gudron
    17.05.2018 14:38

    Ох уж эти новомодные облачные self-hosted стораджи с интерфейсом и блекджеком вокруг этого…

    Вот бы кто запили тулзу которая синхронизировало бы указанные мной папки в какой нить S3 или OpenStack Swift. И что бы на удаленном сторадже держало непременно шифрованную версию. Есть такие представители как rclone и syncany, но они как-то не про фоновый режим. Точнее первый не про фоновый режим, а второй заброшен.

    А свистопляски с крутым web-gui… нафига она мне. Если это для энтерпрайза разных уровней, то там их стошнит от одного упоминания PHP на бекенде. А если для домашней синхронизации личных файликов, то web-gui нафиг мне не нужен.


    1. onlinehead
      17.05.2018 22:17

      А чем плох rclone (если хочется шифрование) или вообще s3 sync (если без шифрования) + cron?


      1. gudron
        18.05.2018 08:50

        тем что я хочу «типа дропбокс». что бы изменил файлик и он отправляется в облако. а не ждать когда выполниться cron-task


        1. onlinehead
          18.05.2018 10:23

          Ну ок, Fswatch для получения изменений + rclone. Обернуть в маленький демон на любом знакомом (или не очень) языке и все. Делов меньше чем на день.


          1. gudron
            18.05.2018 10:32

            rclone — имеет возможность работы на винде, fswatch исключительно линуксовая приблуда.
            но в целом спасибо. попробую


  1. Sergey78
    17.05.2018 15:58

    Я конечно извиняюсь, но зачем там вообще GUI и особенно сборка чего-то из исходников?
    Я насколько понял, вы там какой-то файловый менеджер собираете? Он чем так особенно хорош, что нужен именно он?
    Для вашей связки, по моему мнению, имеет смысл взять минимальную сборку debian, netboot вроде называется и поставить ее без GUI. Из физической консоли надо только поставить sshd и mc. А дальше уже ставить пакеты подключившись по ssh. Это же банально удобнее, чем за клавиатурой «сервера» сидеть.
    Ну и как и многие, я бы предложил nginx. Ставится все из пакетов. Примеров конфига полно.


    1. AlexanderS Автор
      17.05.2018 18:14

      Да, всё верно. Этот вопрос неоднократно поднимался в комментах к первой части)

      Основная задача моей писанины — показать тем, кто впервые с Linux, что им можно удобно и привычно пользоваться как и Windows и при этом ещё и решить вполне себе практичную задачу. GUI линукса дорос до этого — это уже совсем не то, что было 15 лет назад. С момента публикаций прошлых статей мне три человека написали, что по этим мануалам сделали себе сервис вообще ранее про Linux только читая. По моему — это круто. Это значит я столько времени писал получается всё же не зря. Нечего новичка сразу садить на голый терминал и говорить как это всё круто — ввод должен быть плавным и понятным. А сделать «по нормальному» чисто утилитарный веб-сервер — это поставить ОС без графики и далее настраивать по мануалам, старательно пропуская всю графическую часть. Но это моё, чисто субьективное представление о том, что человеку, который связывается с линук очень редко проще создать каталог или символьную ссылку через удобный графический интерфейс, а не вспоминать через гугл, что надо вводить ln -s и чего-то там дальше.

      По поводу файлового менеджера — это больше религиозный вопрос) Я без тотала в виндовс не представляю как работать) Наиболее приближенный к нему в линукс, из того, что я перебрал в своё время, — это дабл коммандер. Там даже по плагинам совместимость некоторая есть. И за эти три года этот софт хорошо эволюционировал.


      1. justhabrauser
        17.05.2018 18:30

        «По поводу файлового менеджера — это больше религиозный вопрос)»
        Это не религиозный, а очень технический вопрос.
        В Windows хорошо — там только Проводник и подвязанные на него через WinAPI virtual FS (and nothing else).
        В Linux всё намного хуже (демократия в действии):
        * mc — своя пачка костылей
        * Gnome — gnome_vfs (или как его там) с подлежащими
        * KDE — kio_*
        * xfse, lxde и иже — gvfs_*
        * icewm — «пилите, Шура»
        * тысячи их


        1. AlexanderS Автор
          17.05.2018 18:38

          То есть, разработчикам файлового менеджера приходится поддерживать совместимость? Но они же не работают с самой ФС — наверняка на уровне какой-то абстракции? Просто насколько это сложно я не могу себе представить.


          1. justhabrauser
            17.05.2018 19:13

            «Я тебе скажу один вещь — только ты не обижайся...» © к/ф «Мимино»:
            * на сегодня не существует единого механизма подключать «просто так» любые ресурсы (hdd/sdd/usb storage/ftp/ssh/webdav/иное") к любым ОС (Windows/MacOS/iOS/Android/Linux/иное).
            * разработчики корячатся, как могут. Особенно когда Microsoft воспринимает и реализует стандарт WebDAV по-своему — это реально бесит.
            * на уровне абстракций — это FUSE, но там для пользователя сильно не PnP. Ну и тормоза дикие.


    1. justhabrauser
      17.05.2018 18:18

      1. «Я конечно извиняюсь, но зачем там вообще GUI и особенно сборка чего-то из исходников?»
      Скорее всего человек не очень гуру в линухе, поэтому «не стреляйте в пианиста — играет как может».
      Одно то, что он транслирует свои первые впечатления — очень дорого стоит.
      Те, кто родился с линухом на борту, знают: ОС — отдельно, графика — отдельно. В Windows GUI встроено в ядро, и это накладывает свой отпечаток на восприятие ОС.
      Не стреляйте в пианиста.
      2. По тексту он ничего не собирал («make install» not detected)
      3. насчет nginx: оно, конечно, турбо — но периодически валится. Заваленный апач я вижу на два порядка реже. Но это — дело вкуса, конечно.


      1. AlexanderS Автор
        17.05.2018 18:32

        Верно, не гуру. Но дело даже не в этом, а в целевой задаче. 7 лет назад, ещё на хабре, я написал свою первую статью на ресурсе, которая была посвящена настройке FTP-сервера. И там, да — там была одна консоль и народ сказал, что статья отличная. А ведь это был реально как-то первый опыт — я ж вообще ничего не знал и мало что понимал. Сейчас задача совсем иная — получить окружение на которое можно перелезть с винды. А веб-сервер и NC это просто как дополнительные плюшки «а вот что ещу можно сделать», за что я и получаю критику. Ведь стоит изменить название и всё встанет на свои места, но оно написалось уж как написалось.


        1. justhabrauser
          17.05.2018 18:57

          «Сейчас задача совсем иная — получить окружение на которое можно перелезть с винды»
          Это очень сложно.
          Вы хотите из любого приложения любого Linux открыть любой файл на любом ресурсе.
          На сегодня это не реально.
          I'm sorry

          PS. вишенка на торте: линух хотя бы пытается это сделать; Microsoft и Apple — нет.


      1. kolu4iy
        17.05.2018 21:57

        По пункту 3: у меня обратный опыт. Особенно когда апача внезапно переполняется беклог (по различным причинам). Правда, я использую только стабильные версии nginx и настраиваю сетевой стек. От того предлагаю данный пункт считать религиозными и из обсуждения убрать )


  1. justhabrauser
    17.05.2018 17:46

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

    \var\www\nextcloud\lib\private\Files\Filesystem.php
    /var/www/nextcloud/lib/private/Files/Filesystem.php

    Не понял…


    1. AlexanderS Автор
      17.05.2018 18:18

      Ну, это мой косячёк, но проблема была масштабнее. Надо было скриншотить)
      Штука заключаласьв том, что если код фильтра nextcloud.conf был обрамлён в теги «code», то этот стиль почему-то применялся до конца статьи. Сейчас уже нормально всё — за день починили)


    1. AlexanderS Автор
      17.05.2018 19:24

      Случайно восстановил косяк)
      Оказывается глобально никто ничего не исправлял — всего скорее администрация втихаря (мне никто ничего не писал!) просто подправили проблемный кусок текста.


  1. Barafu_Albino_Cheetah
    18.05.2018 06:21

    А ещё можно было всё это сделать в Docker. Получился бы файлик для Docker-compose, который можно было бы скопировать на любой сервер и запустить, и всё сразу само поднимается. И никаких конфигов.


    1. barbanel
      18.05.2018 10:44

      А можно с этого момента подробнее?
      Не знаком с Docker.


      1. Barafu_Albino_Cheetah
        18.05.2018 12:49

        Подробнее — в коммент не влезет. Ставите вместо всего

        apt install docker.io docker-compose
        , создаёте файл docker-compose.yml с конфигом, запускаете
        docker-compose up -d
        и всё — имеете фтп, прокси и почту. Параметр image гуглится, остальное берётся из справки к image. Сам всё скачает, запустит, и следить будет, чтобы не упало. И в файрволле дырочки просверлит.