Создаем личное файловое облако легко и просто (и дешево)

А сегодня мы с вами быстро и решительно легко и просто поднимем свое личное файловое облако типа Google Drive или Яндекс.Диск, а если повезет, то еще и очень дешево.

Зачем? Ну, например, потому что не хотим зависеть от корпораций с их кабальными лицензионными соглашениями и сменой условий задним числом. Или потому что нам хочется приватности. Или просто потому что можем. А бонусом на нашем сервере вы потом сможете еще установить VPN или прокси для доступа к запрещенным сайтам, или поднять простенький веб-сайтик.

В наше время, благодаря развитому инструментарию, такому как docker и snap, установить и настроить все что нужно можно очень быстро всего лишь несколькими командами. Disclaimer: для опытных пользователей это статья покажется очень простой, банальной и очевидной. Однако причиной, побудившей меня ее написать, была именно просьба тут на Хабре сделать максимально простой и детальный мануал для тех, кто вообще ничего не понимает в системном администрировании. Я специально будут рассказывать все максимально подробно и пошагово, чтобы даже люди без большого опыта системного администрирования смогли все повторить.

Поехали

Первым делом, нам нужен сервер под это дело. Shared hosting нам не подходит, dedicated server - оверкилл и очень дорого, поэтому нам нужен VDS/VPS. Поскольку цель всего затеянного - хранить данные, много данных, самый распространенный вариант “SSD VDS” нам не подходит, и нужно найти то, что обычно называется “HDD VPS” или “Storage VDS”. Гуглим и выбираем то что надо исходя из своих потребностей и размеров кошелька. Я уже много лет пользуюсь одним классным украино-американским хостером, который предлагает HDD VPS в дата-центре в Болгарии за смешные деньги, а именно 1 евро в месяц за сервер с 100 гигабайт дискового пространства, 3 евро в месяц за сервер с  500 гигабайтами, и т.д. Обычно чем больше вы покупаете пространство на диске, тем больше вы получаете ОЗУ и процессорных ядер, поэтому сразу говорю, что брать машину с 512 RAM мегабайт памяти я не рекомендую.

Регистрируемся у хостера, заполняем все необходимые данные, и, наконец, заказываем услугу, выбирая сервер/тариф который нам хочется. Обычно при этом еще задается вопрос, какую ОС установить на сервер. Как известно, лучший дистрибутив Linux - это тот, который использует ваш Linux-гуру, поэтому выбирайте Debian самой свежей версии, которая есть - все дальнейшие инструкции будут приведены именно для Debian. Если Debian в списке нет (чему я очень сильно удивлюсь), то можно выбрать Ubuntu, там будет почти все то же самое. 

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

Для подключения к серверу нам нужен SSH-клиент. Если вы линуксоид, или у вас установлен WSL (Windows Subsystem for Linux), то просто используйте команду ‘ssh’. Если вы приверженец Windows, скачайте PuTTy.

Подключаемся к серверу по его IP-адресу:

$ ssh root@xx.xx.xx.xx (где root - это имя пользователя, а xx.xx.xx.xx это IP)

Сразу же меняем пароль суперпользователя с хостерского на свой свежепридуманный:

$ passwd

Обновим установленный в системе софт до свежих версий и установим несколько пакетов, которые нам пригодятся:

$ apt update
$ apt upgrade
$ apt install nano curl git

nano - это простой текстовый редактор, как по мне, самый дружелюбный к начинающим пользователям благодаря постоянно присутствующим там на экране подсказкам по его комбинациям клавиш, curl - утилитка для скачивания файлов и ывполнения HTTP-запросов, она может пригодиться нам чуть позже, git - клиент Git, мы им скачаем нужные файлы с гитхаба.
Если вы совсем неопытный пользователь, можете также установить пакет mc - это классический двухпанельный файловый менеджер типа виндового Far Manager (или более олдовых Norton Commander и DOS Navigator) для более удобных прогулок по файловой системе.

Создадим учетную запись обычного пользователя (не root) и зададим ему пароль:

$ adduser user
$ passwd user

После этого немного укрепим безопасность нашей системы - запретим логиниться пользователю root: сначала надо будет зайти под учетной записью обычного пользователя, а уже потом командой ‘su -’ при необходимости эскалировать права.

Делаем

$ nano /etc/ssh/sshd_config

и там меняем параметр PermitRootLogin на

PermitRootLogin no 

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

Теперь давайте немного поколдуем над файловой системой.

Сначала выполним команду mount и найдем, как называется наш основной диск, на котором находится корневой системный раздел:

$ df -h

Filesystem      Size  Used Avail Use% Mounted on
udev            473M     0  473M   0% /dev
tmpfs            98M  788K   97M   1% /run
/dev/vda1       300G  130G  170G  44% /
tmpfs           489M     0  489M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock

Как видим, наш диск зовется /dev/vda1. По умолчанию Linux резервирует на каждом диске определенное место “на всякий случай” для пользователя root, чтобы, например, при полном исчерпании свободного пространства, сервисы не начали падать из-за невозможности писать логи и по-прежнему была возможность залогиниться и все исправить. Нюанс в том, что по умолчанию это место задается в % от общего объема, а поскольку диск у нас довольно большой, то не стоит заниматься расточительством, 1% более чем достаточно:

$ tune2fs -m1 /dev/vda1

HDD VPS обычно предназначены именно для хранения данных, а не для работы каких-либо тяжелых сервисов, поэтому характеристики у них бывают нередко скромные. Часто можно встретить виртуальные машины с 1 гигбайтом или даже 512 мегабайтами оперативной памяти, что в наше время и для наших целей, прямо скажем, очень мало. Первым делом, проверим, сколько у нас вообще памяти, и главное, есть ли swap (раздел подкачки).

$ free

               total        used        free      shared  buff/cache   available
Mem:          999824      255160       87040         668      657624      612536
Swap:         262140      148092      114048

Если в последней строчке вы видите нули, то это тревожный звоночек: памяти мало, свопа нет, и в дальнейшем есть риск наткнуться на серьезные проблемы из-за этого. Сейчас мы все исправим.

$ fallocate -l 1G /swapfile
$ chmod 600 /swapfile
$ mkswap /swapfile
$ swapon /swapfile

- этот набор команд создаст на диске swap-файл размером в 1 гигабайт и начнет использовать его в системе.

Чтобы не надо было делать swapon после каждой перезагрузки, добавим новую строчку в /etc/fstab:

/swapfile swap swap defaults 0 0

Все, с диском и памятью закончили, теперь переходим к более интересным делам.

Использовать нешифрованный HTTP в наше время очень неблагоразумно, а для HTTPS нам нужны сертификаты, которые не получится получить без доменного имени. Соответственно, нам нужен домен.

Не буду изобретать велосипед, а просто процитирую фрагмент из недавней отличной статьи:

Нам потребуется доменное имя для сервера, чтобы на нём беспроблемно работал TLS (HTTPS). Вы можете либо купить домен и привязать его к IP-адресу вашего VPS, либо использовать какой-либо бесплатный сервис, предоставляющий доменные имена. В последнем случае, родительский домен вашего домена должен быть внесён в список публичных суффиксов доменов. Иначе могут возникнуть проблемы с выпуском сертификата через Let's Encrypt - упрётся в разрешённое число выпущенных сертификатов для родительского домена за какой-то период времени. В этом руководстве мы воспользуемся бесплатным сервисом freemyip.com, который даёт домен пользователю даже без регистрации.

Зайдите на страницу https://freemyip.com/.

Выберите красивое доменное имя и заберите его.

Сохраните куда-нибудь ссылку, которую получите.

Запустите следующую команду на вашем сервере: curl 'ССЫЛКА', где ССЫЛКА - та самая ссылка, которую вы получили на предыдущем шаге. Обратите внимание: нужно не забыть взять ссылку в одиночные кавычки!

Проверка: проверьте ваш домен ping-ом, он должен указывать на IP-адрес вашего VPS. Если это не так, то попробуйте подождать несколько минут и попробовать снова.

Я лично пользовался сервисом https://www.dynu.com/, там все очень просто: зарегистрировались, нажали DDNS Services -> Add -> выбрали красивый домен -> задали IP-адрес своего сервера. Всё.

Настало время самого важного.

Мы будем устанавливать NextCloud. Из альтернатив могу назвать еще Seafile и FileRun, но NextCloud мне попался под руку раньше, поэтому я буду использовать его.

Инструкция по ручной установке NextCloud довольно страшная: нужно установить Apache, PHP, PostgreSQL/MariaDB, Redis, создать таблицы, сделать еще кучу всего, и не сойти с ума.

Официальное руководство предлагает для простоты использовать snap-пакет, и первый вариант статьи описывал установку именно этим образом. Вы читаете обновленную и дополненную версию этой статьи, и мы будем использовать Docker. Причин несколько: во-первых, как выяснилось, Docker-образы как раз-таки созданы и поддерживаются самими разработчиками Nextcloud (не смотря на то что на сайте с документацией они не упомянуты), во-вторых snap-пакет имеет несколько проблем (например, срач в логах ошибками apparmor), в-третьих snap-пакет включает в себя веб-сервер Apache, а при установке в Docker есть возможность использовать nginx+php-fpm, и по моим наблюдениям на слабых серверах эта связка работает гораздо отзывчивее.

Устанавливаем docker:

$ apt install docker.io docker-compose

Скачиваем файлы docker-compose для Nextcloud из Git и переходим в директорию, которая относится к установке NextCloud с Nginx+PHP-FPM+PostgreSQL.

$ git clone https://github.com/nextcloud/docker.git
$ cd docker/.examples/docker-compose/with-nginx-proxy/postgres/fpm/

Теперь надо внести пару изменений.
В файле db.env нужно задать пароль для базы данных (база данных доступна только внутри контейнера, но давайте приучать себя к хорошим практикам и придумаем сложный пароль):

$ nano db.env
POSTGRES_PASSWORD=MySecretPassword

В docker-compose надо задать доменное имя, на котором вы поднимаете сервис и е-майл, на который Let'sEncrypt будет слать вам сообщения если захочет сообщить что-то важное:

$ nano docker-compose.yml
VIRTUAL_HOST=yourhost.domain.com
LETSENCRYPT_HOST=yourhost.domain.com
LETSENCRYPT_EMAIL=youremail@yourmail.com

После этого запускаем установку:

$  docker-compose up -d

Это может занять некоторое время, терпеливо ждем. Когда команда завершит свое выполнение, я рекомендую перед следущими шагами подождать еще несколько минут, чтобы отработали все фоновые процессы.
Всё! NextCloud установлен. Просто, правда?

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

COMPOSE_HTTP_TIMEOUT=300 docker-compose up -d

Потом вспоминаем доменное имя, которое мы зарегистрировали ранее, пусть, например, это будет 'habrdrive.mywire.org'.

Заходим браузером на него: https://habrdrive.mywire.org
Откроется веб-интерфейс NextCloud с мастером установки, где кликаем на “Next”/”Далее” и немного ждем, пока он делает все необходимое под капотом.
Если у вас очень медленный сервер, то на этом этапе веб-морда может упасть с ошибкой "504 Gateway timeout" - ничего страшного, процесс все равно идет, подождите несколько минут и обновите страницу.
NextCloud может предложить вам установить дополнительные расширения (“приложения), но если у вас слабенький сервер (гигабайт памяти или меньше), то лучше вежливо отказаться, если что, доустановите потом.

В Docker-контейнере NextCloud уже настроен cron (планировщик задач), и там уже стоит задание для автоматического обновления NextCloud - периодически при логине через браузер вы будете видеть веселые уведомления о том, что он обновился до новой версии. Кроме того, при установке таким образом, NextCloud сам сходит за сертификатом Let's Encrypt, установит его, и добавит в планировщик задачу, которая автоматически будет обновлять сертификат каждые несколько месяцев

На всякий случай, если понадобится: все ваши данные будут лежать в volumes Docker'а, которые обычно можно найти в /var/lib/docker/volumes/.

После этого можно лазить по веб-интерфейсу NextCloud, изучать настройки.
Чтобы создать новые пользовательские аккаунты, для себя, для друзей, для родственников, для кота, и т.д., нужно перейти в пункт “Пользователи” в админской менюшке, и дальше разберетесь. Да, для пользователей можно задавать квоты (максимально допустимый объем занятого пространства) :)

В целом, NextCloud даже без дополнительных расширений умеет всё, что полагается уметь файловому облаку: можно создавать папки, заливать и скачивать файлы, шарить файлы и папки между пользователями в пределах облака и даже на весь Интернет, и много чего другого. Есть “Корзина” для удаленных файлов, есть журнал событий - короче говоря, все как у людей.

Интерфейс интуитивно понятный:

Меню выбора приложений (1): в верхнем левом углу, там торчат все “Приложения” NextCloud, но если вы ничего дополнительно не устанавливали, то как минимум там будут “Файлы” и “События”. 

Поле «Информация о приложениях» (2): расположено на левой боковой панели и содержит пункты, связанные с выбранным вами приложением. Например, когда открыты «Файлы», там есть специальный набор фильтров для быстрого поиска, например, файлы которыми вы поделились с вами, и файлы, которыми вы поделились с другими, и т.д.

Панель навигации (4). классические “хлебные крошки” (breadcrumbs), показывающие, насколько глубоко вы забрались по папкам и позволяющие оттуда вылезти.

Кнопка «Создать» (5): расположенная на панели навигации кнопка «Создать» позволяет создавать новые файлы, новые папки или загружать файлы. Можно и без нее, просто перетащить drag-n-drop’ом файл или диру в браузер.

Поле поиска (6): поиск по тому, что у вас есть в хранилище.

Меню настроек (9): нажмите на изображение своего профиля, расположенное справа от поля поиска, чтобы открыть раскрывающееся меню настроек. На странице настроек представлены следующие настройки и функции:

• Ссылки для скачивания десктопных и мобильных приложений

• Управление паролями

• Настройки имени, электронной почты и изображения профиля

• Управление “подключенными” (залогиненными) браузерами и устройствами

• Настройки языка интерфейса

• Управление уведомлениями

• Информация о версии Nextcloud

У NextCloud есть десктопный клиент для синхронизации под Windows, MacOS и Linux, есть очень удобные мобильные клиенты для Android и iOS. Найти все это дело можно на их официальном сайте: https://nextcloud.com/clients/ 

После установки клиента он первым делом спросит у вас адрес сервера - введите свое доменное имя. Дальше пользовательские логин/пароль, и дело сделано:

Некоторые пользователи натыкаются на странный баг при использовании мобильных клиентов, что после логина в приложении при нажатии на кнопку "Grant access" ничего не происходит, вообще ничего. В этом случае, залогиниться можно другим образом: в веб-интерфейсе войдя под нашим пользователем, идем в Настройки -> Безопасность, и там внизу около кнопки "Создать пароль приложения" вводим какое-нибудь имя (например, Android) и кликаем на эту кнопку. Далее выбираем "Показать QR-код для мобильных приложений", сканируем его камерой на телефоне - открывается клиент NextCloud и сразу сам без проблем логинится.

Кроме того, с NextCloud можно работать любым WebDAV-клиентом. Например, подобный функционал нередко используется во всевозможных менеджерах паролей, утилитах для бэкапов, и т.д. Чтобы получить ссылку для webdav-соединения, при открытом окошке “Файлы” ткните на “Настройки” слева снизу (да, вот это немного неочевидно), и она будет там:

Шифрование

Если вы немного параноик (в наше время это нормально), то NextCloud поддерживает шифрование на стороне сервера. Перед его включением следует иметь в виду, что: 1) отключить его обратно через веб-интерфейс не получится (но все еще можно через глубины консоли) 2) В зашифрованном виде файлы занимают примерно на 30% больше, чем в нешифрованном, ну и тормозить при заливке-скачивании оно может больше, если на сервере слабый процессор и много пользователей.

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

Ключи шифрования хранятся в следующих каталогах:
./data/<user>/files_encryption
./data/files_encryption

Для включения шифрования, сначала идем в меню "Приложения", находим там Default Encryption module и включаем его:

Потом идем в Настройки - Параметры сервера - Безопасность, находим там "Шифрование на стороне сервера" и тоже его включаем

Детали реализации можно прочитать вот здесь и вот здесь.

Более надежным вариантом будет шифрование всего дискового раздела с данными, но это уже совсем другая и гораздо более сложная история. Гугл в помощь.

Оптимизации

Если у вас на сервере 1 гигабайт памяти, то все еще неплохо, а вот если у вас только 512 мегабайт, то NextCloud будет работать как говно неторопливо. Очень неторопливо. Настолько неторопливо, что лучше вообще избегать ставить его на машины с 512 мегабайтами памяти. Да, мы добавили swap, потому что без swap’а на системах с 512 мегабайтами он тупо не работает - процесс базы данных периодически тупо прибивается системным out-of-memory-killer’ом и все с грохотом падает. С активным свопом такого не происходит, но поскольку диск у нас HDD, то работает все это дело иногда довольно медленно, вплоть до того, что когда вы после долгого бездействия открываете веб-морду NextCloud или мобильное приложение, первые одна-две попытки соединиться отваливаются по таймауту, что, само собой, не очень приятно, и с этим надо что-то делать. 

Так что если вы настолько отчаянны, что у вас 512mb-виртуалка, то сейчас я расскажу несколько трюков, которые помогут сделать чтобы все было не так больно (но больно все равно будет).

В первую очередь, есть смысл отключить все ненужные плагины. Откройте страницу "Приложения" из меню пользователя-администратора, внимательно пройдитесь по всему списку, и выключите всё, что вам не нужно в данный момент - в случае чего, всегда можно будет потом включить обратно.

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

Проверяем, не включено ли оно уже - обычно не включено

$ cat /sys/module/zswap/parameters/enabled
N

Если видим N, то делаем

$ echo Y | tee /sys/module/zswap/parameters/enabled
$ echo z3fold | tee /sys/module/zswap/parameters/zpool

и потом добавляем те же самые строчки в /etc/rc.local чтобы оно сразу включалось после перезагрузки:

#!/bin/bash
echo Y | tee /sys/module/zswap/parameters/enabled
echo z3fold | tee /sys/module/zswap/parameters/zpool
exit 0

Если у вас свежая версия Debian, то этого файла может и не быть, тогда после того, как он создан, нужно будет еще выполнить пару действий, чтобы команды из него автоматически выполнились:

$ chmod +x /etc/rc.local
$ systemctl daemon-reload
$ systemctl start rc-local

Существует и другой, более “правильный” способ активации zswap еще на этапе загрузки системы через параметры ядра, но не будем переусложнять, оно и так нормально работает.

Еще в /etc/systemd/journald.conf можно выставить опцию

Storage=persistent

и после этого перезапустить journald командой

$ systemctl restart systemd-journald

чтобы SystemD скидывал логи на диск, а не хранил их в памяти.

Ну и наконец на случай совсем безысходности: можно установить NextCloud с использованием SQLite вместо Postgres/MariaDB. SQLite - встраиваемая база данных. MariaDB-демон с пустой базой занимает в памяти примерно 50 мегабайт, Postgres немного поменьше, но в любом случае, и если в системе не будет запущен отдельный процесс сервера СУБД, то потребление памяти будет ощутимо ниже. Обратной стороной медали будет то, что в SQLite при любых транзакциях база блокируется целиком, в результате чего при больших нагрузках оно может тормозить даже сильнее чем MariaDB или PostrgeSQL при нехватке памяти. Разработчики NextCloud предписывают использовать SQLite только для тестов или "очень небольших инсталляций" и избегать его, если у вас множество пользователей или вы любите синхронизировать кучи файлов, однако если вы действительно планируете использовать облако только в режиме "раз в неделю переслать жене файл с билетами", то такой вариант может подойти и работать вполне сносно.
К сожалению, готового docker-compose-файла для варианта nginx+php-fpm+letsencrypt но SQLite не существует, но его можно легко сделать самому: отредактируйте docker-compose.yml следущим образом:

В разделе "services" удалите весь пункт "db"
В разделе "app" - "environment": удалите строку POSTGRES_HOST=db
Удалите строки с "env_file: db.env"
Удалите из этого файла вообще все строки, где упоминается "db" или POSTGRES :)

После такого редактирования после установки NextCloud и будет использовать SQLite, о чем сообщит вам предупреждением при открытии мастера инсталляции.

К сожалению, даже с этими всеми оптимизациями, на виртуалках с 512 мегабайтами NextCloud хоть и не падает, но все равно работает неповоротливо, поэтому даже и не думайте ставить его на low-end VPS, и если у вас на сервере меньше гигабайта памяти, то лучше присмотритесь к варианту с только WebDAV/SFTP (например, SFTPGo). Но настройка подобного - уже совсем другая история :)