Конфигурация 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

How to upload a file directly from Dolphin file manager

How to upload an image file to 0x0.st file hosting:

Just create 0x0upload.desktop file with the following content:

[Desktop Entry] 
Type=Service 
MimeType=image/*; 
Actions=UploadTo0x0st; 
X-KDE-Priority=TopLevel 
X-KDE-StartupNotify=false 

[Desktop Action UploadTo0x0st] 
Icon=cloud-upload 
Name=Upload to 0x0.st 
Exec=konsole -e bash -c "curl -F'file=@%u' http://0x0.st; read -p 'Press Enter to close'"


Save the file in
/usr/share/kio/servicemenus, restart Dolphin (killall dolphin) and it’s done.

Result:

How to upload a file to remote server via scp:

Create a desktop file:

[Desktop Entry]
Type=Service
MimeType=all/allfiles;
Actions=UploadToVPS;
X-KDE-Priority=TopLevel
X-KDE-StartupNotify=true

[Desktop Action UploadToVPS]
Icon=cloud-upload
Name=Upload to VPS
Exec=konsole -e bash -c "scp -P <port> -i /home/user/.ssh/id_rsa '%u' user@<server-ip>:/home/user/
Uploads && echo 'File %u was uploaded to /home/user/Uploads' || echo 'Upload failed'; read -p 'Pre
ss Enter to close';"

 

Создание своего стримингового сервиса музыки 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

    Zankyou no Terror

    Zankyou no Terror is a glaring example of an anime gone wrong. The plot is mediocre, pretentious, and at times, so ridiculous that it’s unintentionally humorous. It embodies the essence of cringe and juvenile pathos in a manner that is hard to digest.

    While the graphical execution is commendable, offering stellar animations and visuals, the OST is awful (at least to my taste).

    The story and its characters don’t warrant any deep analysis, much like assessing a child’s gibberish (which it is). Injecting mythological references and ridiculous attempts to make the plot look “deep” – all this leaves only an impression of puzzlement and Spanish shame.

    By comparison, Code Geass, another show designed for the edgy schoolboy demographic, reigns supreme. It manages to sustain a level of storytelling elements that Zankyou no Terror lacks sorely.

    One might speculate that the creators intended to pander to Western audiences in a bid for popularity or increased viewership. Unfortunately, their efforts fell dreadfully short.