Установка nextcloud на домашний сервер через docker с ssh-туннелем до VPS для удалённого доступа.

Задача: установка nextcloud на домашний локальный сервер через docker compose с установкой ssh-туннелем до VPS для доступа к nextcloud из интернета.

Шаги:

1) Создать docker compose файл

2) Установить нужные docker контейнеры

3) Проверить что все работает локально

4) Создать поддомен для удалённого доступа

5) Настроить nginx на удаленном сервере

6) Получаем SSL-сертификат

7) Открыть нужные порты на VPS

8) Создаем ssh-туннель

9) Написать службу systemd которая будет поддерживать постоянный ssh-туннель до сервера

Реализация:

1) Создать docker compose файл

mkdir -p ~/nextcloud && cd ~/nextcloud
vim docker-compose.yml

docker-compose.yml:

version: '3.7' 

services: 
 db: 
   image: mariadb 
   command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW 
   restart: always 
   volumes: 
     - db:/var/lib/mysql 
   environment: 
     - MYSQL_ROOT_PASSWORD=yourRootPassword 
     - MYSQL_PASSWORD=yourUserPassword 
     - MYSQL_DATABASE=nextcloud 
     - MYSQL_USER=nextcloud 

 app: 
   image: nextcloud 
   ports: 
     - 8082:80 
   links: 
     - db 
   volumes: 
     - nextcloud:/var/www/html 
   restart: always 
   environment: 
     - MYSQL_PASSWORD=yourUserPassword 
     - MYSQL_DATABASE=nextcloud 
     - MYSQL_USER=nextcloud 
     - MYSQL_HOST=db 

volumes: 
 db: 
 nextcloud:

Не забыть поменять yourRootPassword, yourUserPassword.

2) Установить нужные docker контейнеры

docker-compose up -d

3) Проверить что все работает локально

Заходим на http://[ip-локального-сервера]:8082 и убеждаемся, что все работает на локально.

4) Создать поддомен для удалённого доступа

Нужно создать DNS-запись у регистратора домена. Пусть это будет nextcloud.bernd32.xyz. В cloudflare это делается так: cloudflare.com -> DNS -> Add record -> name: nextcloud -> ip: [ip_сервера] -> type: A

5) Настроить nginx на удаленном сервере

sudoedit /etc/nginx/sites-available/nextcloud.bernd32.xyz

Файл должен выглядеть примерно так:

server {
       #listen [::]:80;
       server_name nextcloud.bernd32.xyz;
       access_log /var/log/nginx/nextcloud/access.log;

   location / {
       proxy_pass http://localhost:8084;
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
   }

Создаем симлинк конфига:

sudo ln -s /etc/nginx/sites-available/nextcloud.bernd32.xyz /etc/nginx/sites-enabled/

6) Получаем SSL-сертификат

sudo certbot --nginx -d nextcloud.bernd32.xyz
sudo systemctl reload nginx

7) Открыть нужные порты на VPS

sudo ufw allow 8082
sudo ufw allow 8084

8) Создаем ssh-туннель

/usr/bin/ssh -i <путь/до/ssh/ключа> -p 53333 -R 8084:localhost:8082 root@<VPS-IP> -NTC  -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes

Заходим на https://nextcloud.bernd32.xyz и убеждаемся что все работает.

9) Написать службу systemd которая будет поддерживать постоянный ssh-туннель до сервера

sudo vim /etc/systemd/system/nextcloud-ssh-tunnel.service
[Unit]
Description=Persistent SSH Tunnel for nextcloud  
After=network.target
 
[Service]
Restart=on-failure
RestartSec=5
ExecStart=/usr/bin/ssh -i <путь/до/ssh/ключа> -p 53333 -R 8084:localhost:8082 root@<VPS-IP> -NTC  -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes
 
[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl start nextcloud-ssh-tunnel.service
sudo systemctl enable nextcloud-ssh-tunnel.service

В случае возникновения ошибки “Bad Request Your browser sent a request that this server could not understand. Apache/2.4.57 (Debian) Server at 172.19.0.3 Port 80” можно попробовать отредачить конфигурационный файл nextcloud в контейнере:

docker cp id_контейнера:/var/www/html/config/config.php ./config.php
vim ./config.php

Добавляем туда:

'trusted_proxies' => ['172.19.0.3', 'YOUR_VPS_IP'], //  172.19.0.3 внутренний айпи докера
'overwriteprotocol' => 'https',
'overwritehost' => 'nextcloud.bernd32.xyz',
'overwritecondaddr' => '^YOUR_VPS_IP$', // VPS IP

После копируем файл обратно в контейнер:

docker cp ./config.php app:/var/www/html/config/config.php

В случае возникновения каких-то проблемы логи смотреть через команду

docker logs -f айди_контейнера

Конфигурация goaccess на nginx-сервере.

Итак, стоит задача настроить анализатор логов nginx-сервера goaccess таким образом, чтобы оно отображало статистику в реальном времени (для этого будем использовать веб-сокеты). Статистика должна быть доступна по адресу https://website1.example.com/goaccess

Далее – создать systemd-юниты для автоматизации процесса. Дополнительные задачи: настроить goaccess для второго сайта на том же сервере (https://website2.example.com/goaccess). Два процесса goaccess должны работать параллельно (для этого будем использовать встроенные опции именованных каналов межпроцессного взаимодействия, указание на путь хранения базы данных программой goaccess, а также укажем другой порт). Также установить ограничений по ip-адресам для доступа к панели статистики второго сайта (с помощью конфигурации nginx).

Предположим, что goaccess уже установлен. Нам нужно просматривать статистику по логам /var/log/nginx/website1/access.log по адресу https://website1.example.com/goaccess/main.html. HTML-страница со статистикой для https://website1.example.com будет храниться здесь: /var/www/goaccess/website1. Далее нам потребуется настроить nginx. Для этого в конфиге сайта (/etc/nginx/sites-available/website1) нужно добавить две локации: stats и ws:

location /stats/ {
alias /var/www/goaccess/website1/;
try_files $uri $uri/ =404;
}

вкратце, этот блок конфигурации Nginx настроен на обработку запросов, начинающихся с “/stats/”. Он сопоставляет эти запросы с локальным каталогом на сервере и пытается предоставить запрашиваемый файл или каталог, возвращаясь к ошибке 404, если таковой не существует.

Далее нужно настроить веб-сокет:

location /ws/ {

# порт не должен блокироваться фаерволом
proxy_pass http://localhost:7890/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
}

Релоадим конфигурацию nginx:

sudo systemctl reload nginx

этот блок перенаправляет http-реквесты с https://website1.example.com/ws на http://localhost:7890 и устанавливает необходимые заголовки для работы с веб-сокетами. 

Запуск команды для проверки что все работает: 

goaccess /var/log/nginx/website1/access.log -o /var/www/goaccess/website1/main.html --real-time-html --port=7890 --log-format=COMBINED --ws-url=wss://eiensora.bernd32.xyz/ws/:443

Порт 443 предполагает, что у нас настроено https.

Заходим https://website1.example.com/goaccess/main.html и смотрим. Если все ок, то добавим systemd-юнит: 

vim /etc/systemd/system/goaccess_website1.service:

[Unit]
Description=GoAccess Live Log Analyzer for website1


[Service]
Type=simple
ExecStart=goaccess /var/log/nginx/website1/access.log \
-o /var/www/goaccess/website1/main.html \
--real-time-html \
--port=7890 \
--log-format=COMBINED \
--ws-url=wss://website1.example.com/ws/:443
ExecStop=/bin/kill ${MAINPID}
PrivateTmp=false
RestartSec=1800
User=root
Group=root
Restart=always

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl start goaccess_website1
sudo systemctl enable goaccess_website1

Для одного сайта всё должно работать ок. Если нужно мониторить несколько разных логов (скажем, от разных сайтов, которые находятся на одном сервере) одновременно на разных адресах. То есть нам нужно запустить каким-то образом запустить два параллельных процесса goaccess. Сделать это можно, если

– запускать каждый процессор goaccess на разных портах –port.

– Различные каналы (FIFO) –fifo-in=/path/in.1 –fifo-out=/path/out.1.

– Если вы используете хранилище на диске, вам понадобится другой путь, по которому хранятся файлы БД –db-path=/path/instance1/.

Нужно изменить предыдущий юнит и добавить новые опции

–fifo-in=/tmp/es.in \
–fifo-out=/tmp/es.out \
–db-path=/var/lib/goaccess/

[Unit]
Description=GoAccess Live Log Analyzer for website1


[Service]
Type=simple
ExecStart=goaccess /var/log/nginx/website1/access.log \
-o /var/www/goaccess/website1/main.html \
--real-time-html \
--port=7890 \
--log-format=COMBINED \
--ws-url=wss://website1.example.com/ws/:443 \

--fifo-in=/tmp/site1.in \
--fifo-out=/tmp/site1.out \
--db-path=/var/lib/goaccess/website1
ExecStop=/bin/kill ${MAINPID}
PrivateTmp=false
RestartSec=1800
User=root
Group=root
Restart=always

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl start goaccess_website1
sudo systemctl enable goaccess_website1

Значения fifo и db-path можно выбрать какие-угодно.

Далее, добавить второй юнит для статистики второго сайта, в котором будет другой порт, другое значение параметров –db-path, –fifo-in и –fifo-out:

vim /etc/systemd/system/goaccess_website2.service:

[Unit]
Description=GoAccess Live Log Analyzer for website2

[Service]
Type=simple
ExecStart=goaccess /var/log/nginx/website2/access.log \
-o /var/www/goaccess/website2/main.html \
--real-time-html --port=7891 \
--log-format=COMBINED \
--ws-url=wss://website1.example.com/ws/:443 \
--fifo-in=/tmp/site2.in \
--fifo-out=/tmp/site2.out \
--db-path=/var/lib/goaccess/website2/
ExecStop=/bin/kill ${MAINPID}
PrivateTmp=false
RestartSec=1800
User=root
Group=root
Restart=always

[Install]
WantedBy=multi-user.target

Также не забыть добавить в конфиг /etc/nginx/sites-available/website2:

location /stats/ {
alias /var/www/goaccess/website2/;
try_files $uri $uri/ =404;

#даем доступ к статистике только локальной подсетке и одному внешнему айпи
allow 44.51.220.3;
allow 192.168.1.0/24;
deny all;
}
location /ws/ {

# порт должен отличаться от созданного первого юнита
proxy_pass http://localhost:7891/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
}
sudo systemctl daemon-reload
sudo systemctl start goaccess_website2
sudo systemctl enable goaccess_website2

Теперь панели просмотра goaccess разных сайтов будут доступны одновременно по двум адресам:

https://website1.example.com/goaccess/main.html

https://website2.example.com/goaccess/main.html

Создание своего стримингового сервиса музыки Navidrome

Недавно мне в руки, почти бесплатно, попал вот такой почти что карманный бесшумный маленький терабайтный сервер, Lenovo ThinkCentre.

Думая, что с ним сделать такого интересного, решил, что неплохого было бы создать свой self-hosted аналог сервиса для потокового вещания музыки (что-то типа Spotify или Apple Music).  Первым делом я, конечно же, накатил Linux Debian в качестве ОС для будущего сервера.  В качестве бекенда для музыкального сервера выбор пал на проект Navidrome, из-за его простоты. Процесс установки Navidrome действительно настолько простой, насколько это вообще возможно.

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

План:  в качестве бекенда для стримингового сервиса будем использовать navidrome из-за его простоты и надежности. Установим navidrome на локальный сервер с debian linux, протестируем, что все нормально работает в локальной сети. Далее настраиваем возможность работы сервера за пределами локальной сети. Для этого будем использовать VPS с nginx в качестве реверс-прокси. Установим ssh-туннель с VPS и настроим nginx чтобы он обратно проксировал данные на наш локальный сервер с Navidrome.

Что потребуется: локальный сервер с linux-дистрибутивом, vps-сервер на linux со статическим ip-адресом, и, опционально, с доменом.

Реализация:

    ставим ffmpeg и удостоверяемся, что система обновлена:

    sudo apt update
    sudo apt upgrade
    sudo apt install ffmpeg

    создаем нужные директории:

    sudo install -d -o <юзер> -g <группа> /opt/navidrome
    sudo install -d -o <юзер> -g <группа> /var/lib/navidrome

    Заходим на страницу релизов (https://github.com/navidrome/navidrome/releases) navidrome и скачиваем и устанавливаем последнюю версию:

    wget https://github.com/navidrome/navidrome/releases/download/v0.XX.0/navidrome_0.XX.0_Linux_x86_64.tar.gz -O Navidrome.tar.gz
    sudo tar -xvzf Navidrome.tar.gz -C /opt/navidrome/
    sudo chown -R <юзер>:<группа> /opt/navidrome

    Создаем конфигурационный файл navidrome.toml в рабочей директории /var/lib/navidrome и вбиваем туда путь до директории музыкальной библиотеки, которая будет стримиться:

    MusicFolder = "/home/MusicLib"

    Создаем юнит systemd. Для этого создаем файл navidrome.service в директории /etc/systemd/system/с таким содержанием:

    [Unit]
    Description=Navidrome Music Server and Streamer compatible with Subsonic/Airsonic
    After=remote-fs.target network.target
    AssertPathExists=/var/lib/navidrome
    
    [Install]
    WantedBy=multi-user.target
    
    [Service]
    User=<user>
    Group=<group>
    Type=simple
    ExecStart=/opt/navidrome/navidrome --configfile "/var/lib/navidrome/navidrome.toml"
    WorkingDirectory=/var/lib/navidrome
    TimeoutStopSec=20
    KillMode=process
    Restart=on-failure
    
    # See https://www.freedesktop.org/software/systemd/man/systemd.exec.html
    DevicePolicy=closed
    NoNewPrivileges=yes
    PrivateTmp=yes
    PrivateUsers=yes
    ProtectControlGroups=yes
    ProtectKernelModules=yes
    ProtectKernelTunables=yes
    RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
    RestrictNamespaces=yes
    RestrictRealtime=yes
    SystemCallFilter=~@clock @debug @module @mount @obsolete @reboot @setuid @swap
    ReadWritePaths=/var/lib/navidrome

     

    Запускаем только что созданный сервис:

    sudo systemctl daemon-reload
    sudo systemctl start navidrome.service
    sudo systemctl status navidrome.service
    
    sudo systemctl enable navidrome.service

     

    Заходим на http://localhost:4533 и проверяем, что все нормально работает. Если с сервера зайти посмотреть не удается, то это можно сделать с другого компьютера, если он в одной локальной сети, но localhost нужно будет поменять локальный ip сервера.

    Готово! Теперь у нас есть собственный стриминговый сервис with blackjack and hookers, но есть одно большое НО: работать все будет только в рамках локальной сети. Итак, теперь наша задача сделать так, чтобы сервис был доступен из Интернета. Сразу скажу, что у меня динамический IP и исходить я буду из этого. Вариантов решения этой задачи несколько, но учитывая то, что у меня есть работающая VPS-ка с веб-сервером nginx, статическим IP и доменом, то самым идеальным вариантом для меня стало бы пробросить порты посредством ssh, создав безопасный туннель передачи данных между удаленным VPS и нашим локальным сервером. Дальше нужно будет настроить nginx на удаленном vps чтобы он обратно проксировал данные на наш локальный сервер с Navidrome. Отмечу, что это самый секьюрный вариант, а так же самый удобный в пользовании: в конечном итоге нам остается только зайти на наш домен (например, music.example.com) и пользоваться, с поддержкой SSL. Если нет VPS-ки, то этот вариант будет не самым быстрым. Отмечу вкратце, что нужно сделать:

    1. Приобретаем VPS-ку.
    2. Приобретаем домен.
    3. Настраиваем nginx и ssh доступ через ключ
    4. Регистрируемся в Cloudflare и привязываем туда домен.
    5. Получаем бесплатный SSL-сертификат

    Как все это сделать можно посмотреть в других гайдах (например, здесь).

    Итак, если VPS с настроенным nginx есть, то можем продолжать. В качестве примера будут следующие вводные параметры (взятые “от балды”):

    Внешний IP-адрес VPS: 237.37.96.248

    Порт ssh: 44633

    Домен (а так же URL), на котором будет доступен Navidrome: music.mydomain.com

    Итак, устанавливаем на локальном сервере с Navidrome ssh-туннель из порта 16059 на нашем vps до порта 4533 локального сервера:

     ssh -p 44633 -R 16059:localhost:4533 user@237.37.96.248 -N

    Создаем отдельный конфигурационный файл для music.mydomain.com в nginx такого содержания:

    server {
    listen 80;
    server_name music.mydomain.com;
    location / {
    proxy_pass http://localhost:16059;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    }
    }

    Здесь мы говорим nginx принимать запросы по адресу music.mydomain.com и переводить их на порт 16059 локалхоста нашего vps, который в свою очередь через туннель передается на наш локальный сервер с установленным Navidrome.

    Теперь, если мы зайдем по адресу music.mydomain.com, то все должно работать. Остался добавить небольшой штрих – подключить ssl-сертификаты. Я предпочитаю это делать через удобнейшую утилиту certbot:

    certbot --nginx -d music.mydomain.com

    Итоговый результат будет выглядеть как-то так на компьютере:

    Navidrome

    На смартфоне можно использовать любое приложение поддерживающее Subsonic API, я предпочитаю Ultrasonic.

    Есть еще один важный момент. Дело в том, что ssh-туннель, установленный выше способом, очень просто, но в то же время неудобен: соединение будет время от времени падать, и нужно будет переподключиться самостоятельно. Можно решить эту проблему несколькими способами (например утилитой autossh), но на мой взгляд лучше всего создать службу systemd, которая будет всегда поддерживать туннельное соединение. Способ авторизации в данном случае только через ключи безопасности.

    Для этого нужно создать файл службы

    sudo vim /etc/systemd/system/ssh-tunnel-persistent.service
    Примерно такого содержания:
    [Unit]
    Description=Persistent SSH Tunnel to from port 9092 on this server to port 9090 on external server (for encrypted traffic)
    After=network.target
    
    [Service]
    Restart=on-failure
    RestartSec=5
    ExecStart=/usr/bin/ssh -i <путь/до/приватного/ключа/ssh> -p 44633-R 16059:localhost:4533 user@237.37.96.248 -NTC -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes
    
    [Install]
    WantedBy=multi-user.target
    Данная конфигурация службы systemd используется для настройки постоянного SSH-туннеля. Этот туннель предназначен для передачи зашифрованного трафика и обеспечивает сохранение активности туннеля и его автоматический перезапуск в случае сбоя. Далее, нужно ввести в терминале:
    sudo /usr/bin/ssh -i <путь/до/приватного/ключа/ssh> -p 44633-R 16059:localhost:4533 user@237.37.96.248 -NTC -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes
    После этого подключение можно будет сразу прервать. Дело в том, что SSH хранит известные ключи хоста и связанные с ними отпечатки пальцев в конфигурационном файле для каждого пользователя, а так как эта служба systemd выполняет команду из-под пользователя root, то у системы для него нет записей в known_hosts.
    Осталось лишь включить и запустить созданную службу:
    sudo systemctl daemon-reload
    sudo systemctl enable ssh-tunnel-persistent.service
    sudo systemctl start ssh-tunnel-persistent.service