Давно хотел написать целостный туториал по поднятию Owncloud в условиях домашнего сервера или небольшой компании до 500 пользователей. Owncloud — это прекрасный open-source проект, который позволяет на собственной инфраструктуре поднять свой вариант сервера синхронизации. По возможностям очень похож на Dropbox, а в чем-то его и превосходит. Огромный плюс — отсутствие ограничений по объемам хранения, полный контроль над сервером. Минусы тоже очевидны: вам самим придется следить за всем этим безобразием и беспокоиться о надежности сервера, валяющегося на антресолях или в шкафу.
Совсем недавно мне подвернулась задача по развертыванию Owncloud в домашне-боевых условиях. Я честно отработал свои два литра кошерного русского имперского стаута и решил поделиться своим опытом, собрав все воедино. Итак, сегодня мы рассмотрим:
- Развертывание актуального LEMP-stack
- HTTPS. Let's Encrypt для Nginx с автоматическим обновлением сертификата
- Конфигурирование Nginx для Owncloud
- Кэширование php-apcu
- Подключение внешнего основного хранилища по NFS
Стартовый комплект
Операционная система под наш сервер — Ubuntu 16.04.1 Server (torrent). Оптимальный вариант — виртуальная машина. Это довольно удачное решение благодаря легкости миграции, возможности динамического выделения ресурсов, снапшотов и прочих плюшек. Размер виртуальной машины — 10-15 ГБ. Этого более чем достаточно под систему.
Внешнее хранилище (каталог data для owncloud), где будут храниться все ваши данные. Размер — в зависимости от ваших потребностей. Я бы рекомендовал рассматривать вариант от 100 ГБ. Разделение хранилища и основной логики сервера дает большую гибкость конфигурации. В данном случае — SSD для системы и HDD от NAS для данных. При подключении внешнего раздела с данными появляется гибкость в плане миграции и возможность нарастить скорость или объем, если вдруг потребуется.
Домен и внешний ip-адрес — в условиях умирающего пула свободных ipv4 адресов провайдеры все реже отдают просто так белый внешний адрес. Если у вас серый адрес, то тут уже мало, что можно сделать. Только пробрасывать VPN-туннель на свою VPS с белым IP и плясать оттуда. Но иногда провайдеры отдают вполне белые адреса, но не статику, а динамику. Причем адрес может меняться просто по велению левой пятки, сессия рваться в полночь, и абонент получает новый IP. В текущем кейсе стоит роутер MikroTik, который умеет бесплатный динамический DNS, начиная с RouterOS v6.14. Находится эта радость в разделе IP/Cloud. После подключения функции роутер получает доменное имя вида 123456b7890f.sn.mynetname.net. Домен этот всегда указывает на ipv4 адрес, выданный провайдером.
Домен отдают 4-го уровня. Обычный StartSSL и другие сертификационные центры не станут с вами работать, если вы не владеете 2 уровнем. Раньше это приводило к использованию самоподписанного сертификата, на который ругался браузер. Теперь появился Let's Encrypt, который проблему решает.
Есть и альтернативные варианты, которые хорошо описаны в публикации Домашний хостинг сайтов с динамическим IP пользователем spectreob.
Развертываем LEMP
Начинать, пожалуй, стоит с установки наиболее привычных утилит для работы: htop, iotop, iftop, mc. Затем приступаем к самому LEMP — Linux, Nginx (его произносят как Engine X), MySQL/MariaDB и PHP. Linux у нас уже есть. Почему Ubuntu 16.04, а не, скажем, Debian или CentOS? Я не люблю rpm, и с Ubuntu проще в плане репозиториев со свежими версиями софта. Очень не люблю практику «make install» на боевых серверах. Все же более оптимальным является путь использования пакетного менеджера. Этого принципа и будем придерживаться.
Добавляем репозиторий с более свежими версиями nginx. Там были закрыты некоторые баги и уязвимости. Копируем GPG ключ разработчиков Nginx и создаем новый источник-репозиторий для apt:
wget http://nginx.org/keys/nginx_signing.key
sudo apt-key add nginx_signing.key
sudo nano /etc/apt/sources.list.d/nginx.list
В файл добавляем ссылки на репозиторий для Ubuntu 16.04 Xenial:
deb http://nginx.org/packages/mainline/ubuntu/ xenial nginx
deb-src http://nginx.org/packages/mainline/ubuntu/ xenial nginx
Устанавливаем nginx, сконфигурируем позже:
sudo apt-get update
sudo apt-get install nginx
Развертываем MariDB (актуальный форк MySQL) и проверяем работоспособность сервиса:
sudo apt-get install mariadb-server mariadb-client
sudo systemctl status mysql.service
Выполняем hardening-процедуру, отключая тестовые базы и прочие потенциальные дыры в защите:
sudo mysql_secure_installation
Будет запущен диалог, в котором надо будет ответить на серию вопросов. В этом же диалоге мы задаем пароль для root. Он потребуется позже, когда будем создавать базу для owncloud.
Устанавливаем PHP7.0, php-fpm и модули, необходимые для работы owncloud, с сопутствующими сервисами:
sudo apt-get install php7.0 php7.0-mysql php7.0-fpm php7.0-gd php7.0-json php7.0-curl php7.0-zip php7.0-xml php7.0-mbstring
Также для работы Owncloud требуется отредактировать переменные окружения:
sudo nano /etc/php/7.0/fpm/pool.d/www.conf
Необходимо раскомментировать следующие строки:
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp
Настраиваем Let's Encrypt и конфигурируем Nginx
Let's Encrypt — это некоммерческая инициатива, предоставляющая бесплатный, автоматизированный и открытый центр сертификации. За что им огромное спасибо. Вероятно, сертификационные центры, которые торгуют, по сути, своей репутацией, теперь будут вынуждены получать основную прибыль из сертификатов высокого класса — Organization Validation (OV) или Extended Validation (EV). Такой тип сертификата доступен только для юридических лиц и подтверждает факт существования условного ООО «Рога и Копыта». При этом проверяется владение доменом, сама компания, нотариально заверенные документы и другие нюансы.
Для личного использования нам вполне будет достаточно Domain Validation сертификата от Let's Encrypt. Этот вариант по сути лишь удостоверяет тот факт, что вы соединились именно с доменом example.com. И заодно защитит нас от Man-in-the-Middle атак, инжекции всякой дряни на целевую страницу (передаю привет MosMetro Wi-Fi и сотовым операторам) и перехвата паролей при использовании общественных сетей. Идеальный вариант для собственного Owncloud. Почему не использовать самоподписанный сертификат?
В Owncloud есть отличная функция «share link», которая позволяет передать человеку ссылку на файл или каталог. Очень удобно, когда внезапно нужно передать что-то весом в 50 ГБ, а более привычные Dropbox и Google Drive бесплатно такое не позволяют. Вы точно не хотите объяснять бухгалтеру Олимпиаде Сигизмундовне, почему ее браузер пылает красным и кричит, что
Основная идея Let's Encrypt — выдача автоматически сертификаты с коротким сроком действия — 90 дней. По мнению авторов проекта, это увеличит безопасность благодаря автоматическому выведению из оборота скомпрометированых сертификатов. Для валидации домена сервис предлагает certbot-auto с несколькими сценариями работы:
- Apache — автоматически получает и устанавливает сертификат для Apache 2.4. Использует 443 порт
- Nginx — автоматически получает и устанавливает сертификат для Nginx. Альфа версия, для продакшена рано. Использует 443 порт
- webroot — создает в корневом каталоге действующего сервера файлы необходимые для валидации домена. Использует 80 порт
- standalone — поднимает автономный сервер, который отвечает на необходимые запросы извне для валидации. Использует 80 или 443 порт. Для систем, которые не имеют действующего веб-сервера и других случаев.
- manual — полностью ручной режим, требующий ручной копипасты. Применяется в том случае, когда вы генерируете ключи не на целевой машине. Например, для роутера.
В результате мы имеем хороший универсальный набор для разных сценариев использования, включая ситуации, когда у вас нет полного контроля на сервером. Автоматическую установку сертификата в Nginx мы не будем использовать из-за ее альфа статуса, а редактирование конфига рабочего веб-сервера — процесс крайне интимный. Очень не хочется столкнуться с кривой работой не отлаженного скрипта. Тем не менее, процесс получения сертификата мы автоматизируем.
Для начала выкачаем и установим последнюю версию certbot:
cd /usr/local/sbin
sudo wget https://dl.eff.org/certbot-auto
sudo chmod a+x /usr/local/sbin/certbot-auto
Редактируем конфиг nginx и разрешаем доступ к тому каталогу, в который будет писать webroot вариант certbot'а:
sudo nano /etc/nginx/sites-available/default
Добавляем строки:
location ~ /.well-known {
allow all;
}
Перезапускаем сервис nginx:
sudo service nginx restart
Теперь можно запустить certbot и сгенерировать сертификаты для нашего домена. В нашем конкретном случае это домен аж четвертого уровня от Mikrotik DDNS. Никто другой валидные для браузеров сертификаты вам не подпишет даже для третьего. UPD: я ошибся с путем webroot по дефолту. В Ubuntu 16.04 не /usr/share/nginx/html, а /var/www/html. На всякий случай проверьте то, что написано в /etc/nginx/sites-available/default после директивы root. Например root /var/www/html;
sudo certbot-auto certonly -a webroot --webroot-path=/var/www/html -d example.sn.mynetname.net
В диалоговом окне нужно будет ввести адрес электронной почты и согласиться с условиями использования:
Certbot складывает актуальные версии сертификатов в каталог /etc/letsencrypt/live/, создавая симлинки. Внутри будут лежать файлы:
- cert.pem: сертификат вашего домена
- chain.pem: chain сертификат Let's Encrypt
- fullchain.pem: комбинированный сертификат из cert.pem и chain.pem
- privkey.pem: приватный ключ вашего сертификата
Генерируем ключ Диффи — Хеллмана:
sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096
Отлично. Теперь, прописав в конфиге Nginx ссылку на /etc/letsencrypt/live/, мы будем иметь всегда актуальную версию. Создаем новый конфиг для нашего домена:
sudo nano /etc/nginx/sites-available/example.sn.mynetname.net
Конфигурационный файл был переписан с учетом замечаний, отдельное спасибо grozaman. Теперь ценой отказа от поддержки Windows XP и некоторых устарвеших систем, мы повысили уровень безопасности. Также увеличен ключ Диффи — Хеллмана до 4096. Это немного увеличит время хендшейка, но не должно быть существенным. Впрочем вы можете использовать 2048 бит. Добавлен ssl_stapling и ряд дополнительных заголовков для увеличения безопасности.
С этим вариантом конфигурации сайт набирает А+ на https://www.ssllabs.com.
Также с данным конфигом получаем A-grade на https://securityheaders.io.
upstream php-handler {
#server 127.0.0.1:9000;
server unix:/run/php/php7.0-fpm.sock;
}
server {
listen 80;
server_name meklon.net;
# Редирект на HTTPS версию сайта.
return 301 https://$server_name$request_uri;
}
server {
# Поддержка HTTPS
listen 443 ssl;
server_name meklon.net;
# Задаем главную страницу
index index.php index.html index.htm index.nginx-debian.html;
# Включаем логгирование
error_log /var/log/nginx/cloud.error.log;
access_log /var/log/nginx/cloud.access.log;
### SSL CONFIGURATION ###
ssl on;
ssl_certificate /etc/letsencrypt/live/meklon.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/meklon.net/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/meklon.net/fullchain.pem;
ssl_dhparam /etc/ssl/certs/dh4096.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EECDH+CHACHA20:EECDH+AES256:!AES128";
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.4.4 8.8.8.8;
### КОНЕЦ КОНФИГУРАЦИИ SSL ###
# Дополнительные заголовки для увеличения безопасности, в частности, первая строчка добавляет поддержку HSTS
add_header Strict-Transport-Security 'max-age=631138519; includeSubDomains; preload' always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' blob data:";
add_header X-Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' blob data:";
add_header X-WebKit-CSP "default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' blob data:";
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Xss-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Proxy-Cache "EXPIRED" always;
# Дополнительные заголовки от разработчиков Nextcloud
add_header X-Robots-Tag "none" always;
add_header X-Download-Options "noopen" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
# Корневая директория сайта
root /var/www/;
# Максимальный размер файла, который мы сможем загрузить и увеличенный буфер
client_max_body_size 3G;
fastcgi_buffers 64 4K;
# C gzip бывают проблемы в случае с Nextcloud, поэтому разработчики рекомендуют его отключить
gzip off;
# Кастомные страницы ошибок 403 и 404.
error_page 403 /core/templates/403.php;
error_page 404 /core/templates/404.php;
### Далее мы принудительно разрешаем/запрещаем чтение определенных директорий и файлов ###
### Помимо этого мы устанавливаем редиректы для красивых URL ###
rewrite ^/.well-known/carddav /remote.php/carddav/ permanent;
rewrite ^/.well-known/caldav /remote.php/caldav/ permanent;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
location ~ /.well-known {
allow all;
}
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
location ~ ^/(?:\.htaccess|data|config|db_structure\.xml|README){
deny all;
}
location ~ ^/(build|tests|config|lib|3rdparty|templates|data)/ {
deny all;
}
location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
deny all;
}
location ~ \.php(?:$|/) {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param HTTPS on;
fastcgi_param modHeadersAvailable true; #Avoid sending the security headers twice
fastcgi_pass php-handler;
fastcgi_intercept_errors on;
}
}
upstream php-handler {
#server 127.0.0.1:9000;
server unix:/run/php/php7.0-fpm.sock;
}
#Redirect from 80 to 443
server {
listen 80;
server_name example.sn.mynetname.net;
return 301 https://$host$request_uri;
}
# HTTPS
server {
listen 443 ssl;
server_name example.sn.mynetname.net;
ssl_certificate /etc/letsencrypt/live/example.sn.mynetname.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.sn.mynetname.net/privkey.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security max-age=15552001;
add_header Cache-Control "public, max-age=7200";
# Add headers to serve security related headers
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header "X-Download-Options" "noopen";
add_header "X-Permitted-Cross-Domain-Policies" "none";
root /var/www/;
rewrite ^/.well-known/carddav /remote.php/carddav/ permanent;
rewrite ^/.well-known/caldav /remote.php/caldav/ permanent;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
location ~ /.well-known {
allow all;
}
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
location ~ ^/(?:\.htaccess|data|config|db_structure\.xml|README){
deny all;
}
location ~ ^/(build|tests|config|lib|3rdparty|templates|data)/ {
deny all;
}
location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
deny all;
}
location ~ \.php(?:$|/) {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param HTTPS on;
fastcgi_param modHeadersAvailable true; #Avoid sending the security headers twice
fastcgi_pass php-handler;
fastcgi_intercept_errors on;
}
}
Конечно, если вам нужна совместимость со старыми версиями Java, Windows XP и тому подобным, придется разрешить некоторые потенциально небезопасные протоколы.
Автоматизируем обновление сертификата
Проверяем обновление сертификата с ключом --dry-run, который имитирует обновление, но ничего не меняет в реальности:
sudo certbot-auto renew --dry-run
При запуске этой команды certbot свяжется с серверами EFF и попытается обновить свою версию, если это возможно, а затем и сертификаты. Причем не только на все доступные домены. Очень удобно. Если срок смены сертификата не подошел, то ничего не произойдет, и скрипт об этом сообщит.
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/example.sn.mynetname.net.conf
-------------------------------------------------------------------------------
Cert not yet due for renewal
The following certs are not due for renewal yet:
/etc/letsencrypt/live/example.sn.mynetname.net/fullchain.pem (skipped)
No renewals were attempted.
Теперь можно добавить регулярный запуск скрипта crontab:
sudo crontab -e
Внутрь добавляем регулярную задачу по обновлению сертификатов и их перезаливке в nginx:
30 2 * * 1 /usr/local/sbin/certbot-auto renew >> /var/log/le-renew.log
35 2 * * 1 /etc/init.d/nginx reload
Активируем наш сайт:
sudo ln -s /etc/nginx/sites-available/418402b5554f.sn.mynetname.net /etc/nginx/sites-enabled/
Установка Owncloud
Есть несколько вариантов, но наиболее предпочтительным в большинстве случаев является установка из репозитория. Пусть у пакетного менеджера голова болит по поводу обновлений. Главное, не забывать делать backup перед накатыванием новых пакетов. Иногда бывают неприятные сюрпризы. Для начала необходимо добавить GPG-ключ:
wget -nv https://download.owncloud.org/download/repositories/stable/Ubuntu_16.04/Release.key -O Release.key
sudo apt-key add - < Release.key
После этого добавляем репозиторий и устанавливаем пакет owncloud-files. Обычный пакет owncloud притянет по зависимости еще и Apache, а он нам не нужен.
sudo sh -c "echo 'deb http://download.owncloud.org/download/repositories/stable/Ubuntu_16.04/ /' > /etc/apt/sources.list.d/owncloud.list"
sudo apt-get update
sudo apt-get install owncloud-files
В результате, в /var/www/owncloud у вас развернется все необходимое. Так как Nginx считает корневым каталог /var/www, то доступ к сервису будет выглядеть примерно так: example.com/owncloud
Настраиваем MariaDB
Так как инсталляция у нас маленькая, то в тонкости оптимизации мы вдаваться не будем. Поэтому разворачиваем с более или менее дефолтным конфигом. Username и password подставьте те, которые будет использовать owncloud для доступа к своей базе данных.
sudo mysql -uroot -p
create database owncloud;
create user username@localhost identified by 'password';
grant all privileges on owncloud.* to username@localhost identified by 'password';
flush privileges;
exit;
Подключаем внешнее хранилище
Как я уже говорил раньше, мне кажется хорошей идеей разделять виртуальную машину с самой логикой сервиса и хранилище, куда будут падать синхронизированные данные. Здесь вы уже можете поступить по своему разумению. Можно не делать ничего, и тогда дефолтным хранилищем будет /var/www/owncloud/data. Можно поступить как я и создать каталог /mnt/data, куда через fstab будет монтироваться внешний том. Это может быть SSD/HDD, он может лежать локально, а может находиться на NAS-storage в этой же локальной сети. Не забудьте только протестировать скорость полученного гибрида. Это потенциально узкое место. В моем домашнем варианте это samba-сервер на хост-машине, кто-то может предпочесть NFS.
Дополнительное удобство такой гибридной конструкции — легкость переезда на более быстрые или емкие варианты при необходимости. Достаточно остановить сервисы и залить на новый подключаемый том все файлы из старого /mnt/data, после чего изменить точку монтирования в fstab и перезапустить сервис вновь. Вдруг вы решите перенести данные со старого HDD на SSD RAID?
Кэширование
Важный момент. Без memory caching owncloud может работать ощутимо задумчивее. Причем он непременно напомнит вам об этом на странице администратора. Выбор способа кэширования зависит от архитектуры системы. С рекомендациями от разработчиков вы можете ознакомиться тут. Если коротко, то для личного использования и небольших инсталляций рекомендуется использовать только APCu. Для малых организаций, при установке на один сервер — APCu для локального кэширования и Redis для file locking. Для установки на кластер в большой организации: Redis для всего, кроме локального кэширования.
Разработчики считают APCu наиболее быстрым вариантом для локального кэша. Если хватает оперативной памяти, то лучше использовать APCu для локального кэширования и Redis для file locking. Если памяти недостаточно, то рекомендуется использовать Redis и для того и другого.
В нашем варианте мы будем использовать только APCu. Установим соответствующий модуль для php:
sudo apt-get install php-apcu
Теперь будет достаточно просто добавить их в конфигурационный файл owncloud — config.php:
'memcache.local' => '\OC\Memcache\APCu',
Первый запуск нашего детища
Перезагружаем машину на всякий случай, чтобы перезапустить все сервисы. Заходим на example.com/owncloud и внимательно
*Тысяча слонов
Но Достабль уже не слушал. Он указал на несколько прислоненных к стене дощечек.
— Что это такое? — спросил он.
— А это моя идея, — сказал Зильберкит. — Мы подумали, было бы проявлением… э-э… делового чутья, — он явно смаковал эти слова, как непривычное, но изысканное лакомство, — рассказывать людям о новых движущихся картинках, которые мы здесь производим.
Достабль подобрал одну из дощечек и, держа ее в вытянутой руке, осмотрел критическим оком. На ней значилось:
На будуюсчей ниделе мы пакажем
«ПЕЛИАС И МЕЛИСАНДРА»
Рамантическая Трогедия в 2 частях
Спасибо за внимание
— Угу, — произнес он без всякого выражения.
— Разве плохо? — глухо выговорил раздавленный Зильберкит. — Ну, это, ведь тут есть все, что необходимо знать зрителям.
— Разреши, — сказал Достабль, беря со стола Зильберкита кусочек мела.
Некоторое время он что-то торопливо царапал на обороте доски, а потом позволил прочитать написанное:
БОГИ И ЛЮДИ СКАЗАЛИ ЭТАМУ НИ БЫВАТЬ НО ОНИ НИЧИГО НИ ХАТЕЛИ СЛУШАТЬ
«ПЕЛИАС И МЕЛИСАНДРА»,
Истерия Запретной Люпви
Страсть Пабеждаит Прасранство и Время!
Тебя Натрясут
При Участии 1000 сланов!
Виктор и Зильберкит читали текст с настороженным вниманием. Так изучают обеденное меню на чужом языке. А язык и впрямь был чужим. Но что самое скверное, на вид он был прежним, родным.
— Ну, не знаю… — осторожно высказался Зильберкит. — Собственно говоря… Что уж там такого запретного… Э-э… Все это основано на реальной истории, только имена изменены. Я полагал, что картина будет полезна, так сказать, подрастающему поколению. Герои, извольте видеть, так никогда и не встретились — вот ведь в чем трагедия. Все это, э-э… очень-очень грустно. — Он посмотрел на дощечку. — Хотя, с другой стороны, в этом несомненно что-то есть. Э-э… — Он явно был чем-то обеспокоен. — Но я, по правде сказать, не помню никаких слонов. — Голос его прозвучал крайне виновато. — В день кликов я был на работе целый день, но совершенно не помню тысячи слонов, хотя наверняка заметил бы их.
Достабль сверлил его немигающим взором. Откуда взялись слоны, он и сам не знал, однако каждое новое мыслительное усилие одаривало его очередным, весьма определенным представлением о том, как следует производить картины. Тысяча слонов — для начала это совсем неплохо.
Спасибо всем дочитавшим до конца эту простыню. Мне хотелось описать максимально полно все детали, чтобы не приходилось рыться по разным, часто противоречивым источникам. Я не исключаю, что мог где-то допустить опечатки или неточности, хотя и проверил все дважды. Буду очень благодарен тыканью носом в ошибки.
UPD
Как мне правильно указали — надо переходить на Nextcloud, куда сбежали все разработчики. Я упустил этот момент в силу того, что уже довольно давно сижу на этой системе.
UPD2
Со мной связался пользователь grozaman и указал на некоторые неоптимальные настройки nginx, связанные со стойкостью шифрования и другими нюансами. Хороший дополнительный мануал можно взять здесь:Настройка Nextcloud на базе NGINX
UPD3
Мне уже несколько раз указали на то, что certbot/letsencrypt лежит в репозиториях и нет смысла тащить его отдельно. Для Ubuntu это:
sudo apt-get install letsencrypt
UPD4
Исправил ошибку с дефолтным webroot и доработал конфигурационный файл.
Комментарии (88)
metro2030
25.10.2016 12:05Почему не поменяете в конфиге nginx путь на root /var/www/owncloud/;, чтобы не надо было вбивать example.com/owncloud?
Сам использую в учебе, считаю Owncloud — невероятно удобным решением. У меня используется Caddy в качестве Web-сервера: он сам получает LE сертификаты, а также поддерживает http2 из коробки.
Meklon
25.10.2016 12:06Можно и так. Просто у меня корневой домен обычно на что-то еще может указывать. Привычка.
metro2030
25.10.2016 12:07Тогда нет вопросов=)
У меня на субдомене cloud.example.com, поэтому и использовал прямое указание.Meklon
25.10.2016 12:09Вот, кстати, до сих пор не понимаю логику выбора между service.example.com и example.com/service
marliotto
25.10.2016 13:10+2Плюсы service.example.com
— Свой набор кук, но могут быть и общие с example.com
— В верстке можно указывать путь "/" на главную страницу сервиса. В случае с example.com/service, нужно контролировать, чтобы не попасть на главную example.com
serafims
25.10.2016 12:26А есть ли какой-то ресурс, где можно было бы узнать о том, насколько успешно работает owncloud на конкретном железе под конкретными нагрузками?
Чтобы хотя бы примерно сориентироваться по железу для такого вот сервера на небольшую компанию…Meklon
25.10.2016 12:32Можно у них спросить. Вообще они декларировали тысячи пользователей и терабайты данных. Но, вероятно, потребуется нетривиальная архитектура и поиск узких мест.
vadek
01.11.2016 10:19+1В подобных сервисах узкое место — дисковая система. Учитывая, что OwnCloud выкладывает файлы в нативном виде (не в базу данных или в один файл), нагрузка на файловую систему (за счет мелких файлов) лишь усугубит эту проблему. Потому хороший рейд или даже отдельная полка с дисками не помешает. Кроме этого, присутствует запись в базу данных — ее со временем нужно будет тюнить и, возможно, защищать кластерным решением (как для отказоустойчивости, так и для скорости записи-чтения).
ErshoFF
25.10.2016 12:27У меня owncloud в контейнере docker, образы доступны.
Из плюсов — стабильность, нет оверхеда на виртуализацию целой вирт.машины, не упираюсь в объем диска виртуальной машины, обновление проходят более предсказуемо.
Минусов не обнаружил.vadek
01.11.2016 10:22Минус — слабый клиент. При большом количестве файлов он просто безбожно ест ресурсы рабочей станции, пересматривая метаданные файлов :(
ErshoFF
01.11.2016 12:34Это было бы минусом если бы другой клиент в этих же условиях (ОС+железо) не начинал тормозить при большом количестве файлов.
vadek
01.11.2016 12:52Клиенты некоторых других бекапных систем умеют работать с трекинговой системой, которая отслеживает изменяемые файлы в пределах файловой системы и записывает эти изменяемые файлы в журнал. После начала сессии резервного копирования клиент берет список измененных файлов из журнала и по этому списку начинает свою работу. Поинтересуйтесь.
ErshoFF
01.11.2016 13:08Спасибо за направление поисков.
Только что попробовал создать файл в папке, которая синхронизируется в клауд.
Файл не стал дожидаться сессии и тут же синхронизировался.
По значку в трее и файлу на сервере он действительно синхронизировался прямо вот сейчас.
На первый (да и на второй) взгляд этого достаточно для ежедневной работы (в клауде ~200гб, клауд в контейнере докера).Meklon
01.11.2016 14:44Там иногда странная фигня творится только, когда работаешь прямо в каталоге синхронизации и быстро переименовываешь/пересохраняешь файлы. Бывают конфликты на соседних машинах. Но редко.
ErshoFF
01.11.2016 14:48+1Каждому инструменту своё использование.
Для конкурентного доступа используются другие средства, поинтересуйтесь.
oldbie
25.10.2016 12:32Позвольте поинтересоваться, а вы не щупали nextcloud? Как человек с опытом использования что думаете об этой всей ситуации?
chelaxe
25.10.2016 12:39+1Перешел на него и в организации тоже перешли на него. Все отлично проблем нет. Советую.
DaemonGloom
25.10.2016 13:54+1Сам на него перешёл и организацию перевёл. Работает хорошо. Старые клиенты немедленного обновления и перенастройки не требуют, пользователи даже не заметят изменения серверной части (кроме других логотипов и иконок).
Сам переход выполняется без проблем, все настройки и данные сохраняются.
darken99
25.10.2016 12:35+1А можно не напрягаться и поднять в Docker
docker-compose.ymlfe: image: nginx:stable-alpine restart: always volumes: - ./nginx.conf:/etc/nginx/nginx.conf:ro ports: - 80:80 links: - be volumes_from: - be be: image: owncloud:fpm restart: always volumes: - /mnt/hdd/opt/owncloud:/var/www/htmlMeklon
25.10.2016 12:56+1Я дикий человек. Docker не использовал. KVM с полной изоляцией мне привычнее.
Googolplex
25.10.2016 13:04+1А почему owncloud а не nextcloud? Насколько я помню, в nextcloud ушла большая часть разработчиков owncloud, и сам он позиционируется как более свободная альтернатива.
Meklon
25.10.2016 13:09Я пропустил этот момент. Ситуация схожа с OpenOffice vs. LibreOffice? Я вижу, что owncloud движется в сторону Enterprise-услуг. В принципе, нормальная модель монетизации. Я обязательно посмотрю. Просто у меня уже все два года как развернуто. Перенос — дело гадкое. Надо понять полученные от этого плюшки.
custos
25.10.2016 13:26Сейчас миграция от обновления ничем не отличается, недавно мигрировал с 9.1 на 10.0.1, всё прошло гладко.
mecanism
25.10.2016 13:10+3nextcloud позволяет подключать внешние ресурсы из админки. без заморочек с mnt и cifs. Я имею в виду некоммерческие версии. Буквально 2 недели назад внедряли в конторе.
Имелось уже созданное хранилище документов samba и AD.
Сначала пробовали owncloud. Но вылезли те самые проблемы с подключением шар пользователей к аккаунтам в owncloud.
Поставили nextcloud. Добавили плагин для авторизации пользователей AD. под админом подключили общее хранилище (самба), в котором пользователи, естественно, имеют различные разрешения на доступ к содержимому (Изначально шара настроена так что пользователи видят только тот контент для которого у них есть соответствующие разрешения).
потратили целых 75 рублей и купили приложение для ios (приложение owncloud — показало себя лучше чем nextcloud. последний начинает безбожно вылетать, если ему что-то не нравится. При этом первый прекрасно работает с сервером nextcloud. Эдакая прямая совместимость...)
Из плюсов — не нужно заводить пользователей, или разрешать им самостоятельную регистрацию — все импортируется ид AD.
Из минусов — пользователи AD не могут сами подключать себе собственные удаленные хранилища (это скорее недоработка чем баг, но неприятно), хотя локальные пользователи nextcloud могут.solalex
25.10.2016 15:47подскажите, в nextcloud есть плагины для работы онлайн нескольких пользователей с таблицами?
mecanism
25.10.2016 16:04Есть Collabora Online connector и LibreOffice Online для создания и редактирования.
но эти плагины я не подключал, поэтому не могу сказать как они будут работать…
RZimin
25.10.2016 17:44А там коннектор в режиме реального времени, или же за синхронностью того, что импортнулось и что сейчас актуального в AD надо следить ручками?
SchmeL
25.10.2016 14:43Есть несколько вариантов, но наиболее предпочтительным в большинстве случаев является установка из репозитория. Пусть у пакетного менеджера голова болит по поводу обновлений.
Такой подход конкретно для owncloud работает не особо. А именно в пакетах очень часто забивают на обновления. Owncloud это веб приложение, и как WP можно обновлять из админки (в новых версиях так), один раз обновив его так вручную — словил не работающее хранилище при апгрейде пакетов (по сути был downgrade), теперь обновляю исключительно из админки и устанавливаю Ownclod без использования пакетного менеджера.Meklon
25.10.2016 15:09Странно. Если честно, ни разу вручную не обновлял за два года, полет нормальный. Стабильная ветка. Сами разработчики вроде пакеты рекомендуют для Linux.
Loki3000
01.11.2016 00:11+1Хуже того, был сравнительно недавно случай, когда в репозиторий выложили кривой релиз. Привычно обновился и все попадало. Я тогда, неожиданно для себя, вдруг присоединился к разработке Owncloud. Почти две недели вылавливал и правил всякие косяки. И только через эти две недели, когда у меня уже все стабильно работало, в репозитории появилась исправленная версия. Был бы я чуть более далек от веб-разработки — две недели сосал бы лапу. Так что теперь обновления Owncloud только ручками — нет у меня к ним доверия…
vconst
25.10.2016 14:57А почему энжиникс, а не апач?
Meklon
25.10.2016 15:11Для меня он в данной задаче выглядит проще в настройке и привычнее. Где-то мелькали тесты о более быстрой работе с owncloud. А так, конечно, это субъективное предпочтение. Не настаиваю. Привел именно реальный кейс, который работает.
Revertis
25.10.2016 15:17+2Потому, что апач давненько уже просто не нужен. Энджинкс легковеснее, скоростнее, не тратит кучу ресурсов на проверку .htaccess в каждой папке при запросе каких-то файлов и так далее…
Кроме того, как уже выше писали, надо ставить Nextcloud. Туда ушли почти все, кто разрабатывал OwnCloud, включая изначального разработчика. У них более открытая политика, не будет закрытых компонентов. Скоро выпустят 11-ю версию с обновлённым каталогом дополнительных приложений и кучей других вкусностей.
OwnCloud погряз в бюрократии, лишился разработчиков и теперь будет только в догоняющей роли.Meklon
25.10.2016 15:22Я это упустил. Не до того было. Есть хороший мануал по миграции с owncloud 9.1? У меня просто это продакшен с парой сотней гигабайт данных.
Revertis
25.10.2016 17:27Ну, данные ваши никуда не денутся в процессе миграции. Вот, например, пост о миграции: http://blog.jospoortvliet.com/2016/06/migrating-to-nextcloud-9.html
Можно смигрироваться на Nextcloud 9.1, потом уже проапгрейдиться. Думаю, так будет меньше волнительных моментов.
StalkerJS
25.10.2016 15:05Вот, кстати, при установке owncloud'а ниасилил подключить шару, которая была на виндовом сервере. Была какая-то моему бедному опыту и скудным знаниями линухи непонятная проблема с правами доступа.
BurlakovSG
25.10.2016 15:05Подскажите, пожалуйста, есть домен example.com, он привязан к статическому IP, как сделать чтобы example.com отрабатывал в одном docker контейнере, а cloud.example.com в другом контейнере? Или так нельзя сделать?
RZimin
25.10.2016 17:47Как вариант — nginx на хосте (или же опять в своем контейнере) в роли реверс прокси.
akubintsev
25.10.2016 16:40Где-то полгода назад тоже перешел на Owncloud. Очень доволен.
По своему опыту могу заметить, что php очень желательно ставить версии >= 7.0, прирост скорости в веб-клиенте в раза 2 точно по отношению к 5.6.
В статье немного не хватает пункта про организацию бекапа, впрочем об этом расписано и в официальной документации.Meklon
25.10.2016 16:48Я решил, что совсем будет огромный объем. Тем более, речь об установке в первую очередь.
Revertis
25.10.2016 18:52Бэкапить можно скриптиком базу, а кроме этого папку /data от самого own/nextcloud'а с помощью Syncthing на другой комп/сервак.
Meklon
25.10.2016 18:55У меня это проще. Виртуальная машина. Снапшоты.
TheShestov
26.10.2016 12:46Можно поинтересоваться? Гипервизор чьих будет? :)
Meklon
26.10.2016 13:09Debian wheezy, KVM. Управляю virt-manager'ом.
TheShestov
26.10.2016 13:21Просто чего интересовался то: я просто знаю, что хранение «бекапов путем снапшотов» с VMware или Hyper-V — противопоказано доктором. А вот как обстоят дела с Debian wheezy не знаю. И что подразумевается там под понятием «снапшот» тоже не знаю. Ну, вообщем тем, кто прочтет — главное, чтобы не превращали снапшоты в бекапы на вышеуказанных мною HV :)
akubintsev
26.10.2016 11:46В общем да, к этому и сводится суть описанного в документации.
Я воткнул старенький хард на 500гб в сервачок и ежедневно rsync-аю /data + дампаю БД.
ro00t
25.10.2016 17:04А что за путь /.well-known ?! У меня при попытке запустить certbot-auto выдает:
The directory '/home/owncloud/.cache/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
The directory '/home/owncloud/.cache/pip' or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
Запускаю с -H:
Invalid response from http://*****/.well-known/acme-challenge/NMTDCgEEnPup_YVaDGDd7fBi62RxG089701N8HxRPGo
И далее ругается что нет такого файла и каталога.Meklon
30.10.2016 11:30Проверь, пожалуйста с другим webroot. Судя по всему, я указал неверный дефолтный путь. В 16.04 он /var/www/html.
x4uDaK
25.10.2016 17:04Спасибо за статью, как раз собираюсь поднять Own(Next?)Cloud на своем мини-сервачке(Cubieboard2).
Что по ресурсам, какая скорость в локалке? Думаю, потянет ли 1GHz arm процессор и 1Гб оперативки всю эту красоту или оставить все как есть и работать с файлами по samba.akubintsev
25.10.2016 18:13Пробовал на Cubietruck. Тяжеловато ему было, но работало кое-как. Главное в веб-клиент не лазить к фоткам, миниатюры делать очень ресурсоёмко.
Когда я понял, что Owncloud не игрушка, а вполне нормальное приложение, то продал кубик и купил «кубик» побольше — HP Microserver Gen8
Inerren
25.10.2016 17:39Обычный StartSSL и другие сертификационные центры не станут с вами работать, если вы не владеете 2 уровнем.
Только на днях получил сертивикат у StartSSL для домена третьего уровня у no-ip.com (конкретно у меня домен вида example.ddns.net).
А статья действительно очень подробна. Спасибо.
den_admin
25.10.2016 20:32В комментариях достаточно много хвалили own/next cloud, а что можете сказать про seafile? С первого взгляда мне показался очень приятным.
wmlex
26.10.2016 00:19+1Если не нужна синхронизация контактов и календаря, то однозначно лучше! Особенно это заметно при синхронизации кучи маленьких файлов. На виртуалке (ovz) c 512 Mb RAM OwnCloud встает колом а Seafile даже не вспотеет. :)
ReanGD
26.10.2016 13:41Может посоветуете, если нужны контакты и календарь, то лучше всё же OwnCloud или заморочиться и настроить seafile + выделенный caldav сервер (radicale например)
wmlex
26.10.2016 14:01К сожалению посоветовать Вам ничего не могу, так как не использовал функции синхронизации календаря и контактов в OwnCloud. Рассматривал его только в качестве облачного файлового хранилища.
Sergey78
28.10.2016 13:26Благодаря комментариям тут, установил попробовать.
К сожалению возможности seafile по хранению версий файлов ведут к главному недостатку (для меня) — свой формат хранения данных. Т.е. просто сделать симлинк на каталог на сервере в котором уже есть нужные данные не получится. В этом плане nextcloud (я его использовал) удобнее, можно через external storage подключить нужную папку. И в случае если «все упало», можно просто подключить диск и забрать свои файлы. Ну или когда с данными работают несколько приложений. У меня в nextcloud подключена файлопомойка куда в частности торренты скачиваются. С seafile насколько я понял этого не выйдет.
Поскольку вы уже смотрели seafile, видимо в курсе этого. Комментарий для тех, кто выбирает.Meklon
28.10.2016 13:52Я не подключал подобным образом внешние хранилища к нему. А как он их индексирует в этом случае? Там же все плюшки связаны с метаданными, комментариями, правами на доступ и версионированием. То есть далеко от samba/NFS/ftp файлопомойки.
Sergey78
28.10.2016 13:56Собственно об этом и комментарий :)
К моему сожалению там нет варианта отключить версионирование для данной библиотеки и хранить данные как есть. Т.е. отключить то можно, но хранит он все равно по своему.
Это не хорошо и не плохо, это просто особенность seafile.
rhamdeew
26.10.2016 00:35Вот это я понимаю вдохновляющая статья! ownCloud я не поставил, но зато наконец руки дошли настроить автоматическое получение Let's Encrypt сертификатов и попробовать в работе docker-compose.
AlterMax
26.10.2016 13:47А как ownCloud (Nextcloud) относятся к большим файлам — десятки гигабайт? Есть ли проблемы с их удалением и очисткой свободного места на хранилище?
Я просто использую в подобных случаях Seafile и там все хорошо, кроме этого момента, при хранении нескольких версий больших файлов очистка свободного места доставляет некоторые неудобства…wmlex
26.10.2016 14:04А какие именно неудобства при удалении больших файлов у Вас возникали?
AlterMax
26.10.2016 14:11Не уверен уместно ли здесь это обсуждать, в принципе я подробно описал проблему на форуме Seafile вот здесь https://forum.seafile.com/t/garbage-collector-cant-release-space-if-deleted-file-have-a-big-size/904
eisaev
26.10.2016 19:38+1«certbot-auto» качался отдельно по какой-то определённой причине или исторически? В Ubuntu 16.04 точно есть пакет letsencrypt. Да и: «Until May 2016, Certbot was named simply letsencrypt or letsencrypt-auto, depending on install method.»
Meklon
26.10.2016 19:39Упустил момент. Но он все равно обновляется как скрипт через pip до последней версии. Спасибо, в любом случае.
kerberos464
26.10.2016 23:12+1спасибо за статью!
небольшой коммент: после того, как я всё настроил согласно статье, не удавалось зааплоадить любой файл более 5 мб.
чтобы это исправить, дописал в конфиг nginx'а /etc/nginx/nginx.conf в секцию http {} следующую строчку:
client_max_body_size 1024m;
(сам в линуксах и прочих энджинэксах не силён, поэтому решение было найдено на просторах интернета)
Lordbl4
01.11.2016 11:47один из вариантов решения — поправить значения в php.ini:
upload_max_filesize — максимальный размер закачиваемого файла
post_max_size — максимальный допустимый размер POST-данных
оба этих значения изменить например на 16g (для заливки файлов до 16 гигабайт через веб-морду)
ещё варианты описаны в официальном мане
Meklon
01.11.2016 14:45php.ini разве пойдет, если работаем с php-fpm?
Lordbl4
01.11.2016 20:00+1для php-fpm php.ini будет лежать по умолчанию в /etc/php/7.0/fpm/php.ini
для апача
php -i | grep php.ini Configuration File (php.ini) Path => /etc/php/7.0/cli Loaded Configuration File => /etc/php/7.0/cli/php.ini
Исходя из функционала php-fpm — не вижу препятствий для работы php.ini
В общем, способов реализации несколько и они зависят от того, как и на чём будет запущено облако. Для единственной машины с owncloud/nextcloud внутри подойдёт и глобальная политика размера загружаемых файлов, а если на сервере крутится ещё и несколько веб-проектов с использованием php — то лучше не трогать глобальный конфиг и использовать например .htaccess.
Ещё php-fpm позволяет запускать разные воркеры с разными php.ini, но это уже ненужные заморочки ;)
Lordbl4
01.11.2016 14:15Как мне правильно указали — надо переходить на Nextcloud, куда сбежали все разработчики. Я упустил этот момент в силу того, что уже довольно давно сижу на этой системе.
ну тогда ждёмс новую статью по установе Nextcloud на nginx :)Meklon
01.11.2016 14:45Та же фигня. Я пишу статью по миграции. Отличия минимальны — можно пользоваться этим мануалом. Я уже перенес все.
Meklon
Кстати, был бы рад услышать об использовании в продакшене. У меня очень удачный опыт интеграции owncloud для нужд научной лаборатории. Особенно актуально, когда есть коллеги из других центров с которыми некого нужно обмениваться тяжелыми данными. При этом все плюсы контроля доступа к каталогам и версионирования.