Автоматическое переключение на bluetooth-наушники при их подключении в linux

Не совсем уверен почему, но после переустановки арча у меня начались какие-то небольшие проблемы с bluetooth-адаптером. Подозреваю, что проблема в кривых драйверах, хотя в прошлой версии арча все работало ок. В частности, после переустановки перестало автоматически переключаться на подключенные bluetooth-наушники. Кое-как решил эту проблему с помощью udev-правил. Напишу здесь как это делается, чтобы не забыть (думаю, мне это еще пригодится):

  • Узнать mac-адрес наушников командой bluetoothctl, затем devices
  • Подключить наушники и узнать какой sink они используют (pactl list short sinks). В моем случае это bluez_output.F8_4E_17_1E_76_1F.1
  • Создать bash-скрипт, который переключает звук на наушники:
#!/bin/bash

SINK="bluez_output.F8_4E_17_1E_76_1F.1"
pactl set-default-sink $SINK
# Move all audio streams to new sink
pactl list short sink-inputs | while read stream; do
  stream_id=$(echo $stream | cut '-d ' -f1)
  pactl move-sink-input $stream_id $SINK
done
exit 0
  • Делаем исполняемым sudo chmod +x auto-switch.sh
  • Создать udev-правило, которое будет запускать  скрипт как только bluetooth-устройство с указанным mac-адресом будет подключен к компьютеру:
    sudoedit /etc/udev/rules.d/10-bluetooth.rules:
ACTION=="add", SUBSYSTEM=="bluetooth", ATTRS{address}=="f8:4e:17:1e:76:1f", RUN+="/usr/local/bin/auto-swutch.sh"
  • Тестируем что все работает командами:

    sudo udevadm control –reload-rules

    sudo udevadm trigger

Установка katrain на (arch) linux с видеокартой AMD

KaTrain — это инструмент для анализа игр Го с обратной связью AI от движка KataGo.

Поэтому для начала нужно получить этот движок. Можно скачать уже скомпилированную версию с гитхаба, но лучше всего скомпилировать самому. Подробнее про это здесь: https://github.com/lightvector/KataGo/blob/master/Compiling.md

В моем случае (с RX5500XT)  это выглядело так:

 

sudo pacman -S opencl-clover-mesa 
sudo pacman -S opencl-icd-loader opencl-headers
git clone https://github.com/lightvector/KataGo.git
cd KataGo/cpp
cmake . -DUSE_BACKEND=OPENCL -DBUILD_DISTRIBUTED=1
make -j 6

Скомпилированный бинарник будет находиться в Katago/cpp под названием katago. Теперь нужно установить и настроить katrain. Это можно сделать через репозиторий AUR, но проще всего установить через pip:

pipx install katrain

Далее в настройках katrain (engine settings) указываем на скомпилированный бинарник katago.

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

git clone https://aur.archlinux.org/opencl-amd.git
makepkg -si

Далее перезагрузить компьютер.

Read more

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

    Guide on installing shadowsocks+v2ray server with traffic obfuscation (Cloudflare) over TLS in Debian 10

    English translation of my post, original version in Russian is here.

    Just a few words before we get started. You can skip this part if you want.

    Introduction.

    With internet regulation and censorship on the rise, states increasingly engaging in online surveillance, and state cyber-policing capabilities rapidly evolving globally, concerns about regulatory “chilling effects” online – the idea that laws, regulations, or state surveillance can deter people from exercising their freedoms or engaging in legal activities on the internet have taken on greater urgency and public importance [1]. Today, the most popular way to bypass Internet censorship are VPN services. However, they have quite significant drawbacks, which are completely or partially solved by setting up your own shadowsocks server. In this guide I will teach how to do it. 

    You can ask a reasonable question: why bother so much when there is a VPN services? So, to begin with, I will list the pros and cons of a VPN over a shadowsocks server:

    Pros of VPN services:

    The user does not need any technical knowledge and time-consuming configuration, just install a VPN client and use it. Setting up an SS server, especially with traffic obfuscation, requires some skills and knowledge that most users do not have.

    Cons:

    – VPN services can be slow, including the paid ones. I won’t even mention the free ones, as they are often extremely slow and may not provide adequate privacy protection. ISPs may intentionally throttle the speed of suspicious encrypted traffic originating from VPNs. This issue can be addressed by employing traffic obfuscation through basic TLS encryption, which appears legitimate to your ISP.

    – VPNs are not entirely secure. If someone is determined, they can find you relatively quickly: either the VPN service might hand over your information to authorities, or your ISP could track you using a so-called “correlation attack.” This is when an ISP compares the IP address a user utilizes to access certain online content or visit a restricted website with the IP addresses connected at that time, enabling the ISP to potentially identify an internet dissident’s real IP address. In this context, SS + v2ray + tls is a safer option for users residing in totalitarian countries like Russia or China. By the way, the Shadowsocks protocol and v2ray were developed by users in China.

    Besides speed and security, circumventing internet censorship and surveillance with SS+v2ray can be absolutely free! You just need to find a shareware virtual server (for example, Oracle Cloud, which has an unlimited trial period) and a free domain (such as a .tk domain provided by Freenom). However, using free services can be somewhat risky since you don’t have full ownership, and both the VPS and domain could be taken away from you at any moment.

     

    Steps to set up your SS server:

    – Getting a virtual server (VPS) running on Debian (you can use any distro you want, but in this tutorial I’m using Debian 10)

    – Getting a domain (you can go with any domain, Freenom’s .tk for example)

    – Signing up on Cloudflare and linking the domain there

    – Deploying the shadowsocks and a web server on the VPS

    – Getting a free SSL certificate and setting up traffic obfuscation

    – Setting up a client for windows/android/ios/linux.

    Let’s get started.

    Getting a virtual server (VPS)

    Any inexpensive virtual server provider will do. Oracle Cloud and Microsoft Azure are fine and they’re free too! (though, there is a limit on the amount of traffic). There is nothing complicated in getting a virtual server, just make sure that you are provided with a dedicated static IP address and have open ports 80, 443 and 22 (usually they are opened by default). You can also choose a suitable VPS from this list: https://bitcoin-vps.com/

    Getting a domain

    Get any domain you want, .tk domains are free (you can get one here: https://www.freenom.com)

    Signing up on Cloudflare and linking the domain (adding DNS records)

    As an example, let’s take the bernd32.xyz domain. To do this, in the cloudflare, specify the IP address of our SS server, one is just bernd32.xyz, the second is www.bernd32.xyz, click next.

    In this guide I’ll use one of my domains bernd32.xyz, replace with your own. We need to make two DNS records:

    1) “A” record with the name “www” and IP address of your VPS

    2) “A” record with the name “bernd32.xyz” and IP address of your VPS

    Next, click “Continue.” Afterward, Cloudflare will generate name servers that should be entered into the control panel of your domain registrar. If you obtained your free .tk domain from Freenom, the control panel page might look something like this:

    Wait for a few hours for the DNS records to update. In the meantime, let’s navigate to the Cloudflare Firewall settings and change the Security level to “Essentially Off”:

    Read more

    Быстрый, безопастный и бесплатный(*) shadowsocks+v2ray-сервер с обфускацией трафика через TLS

    English version is here.

    Преамбула.

    В свете нынешних событий в России, тема блокировок интернета стала актуальной, как никогда. На сегодняшний день самым популярным способом обхода блокировок являются VPN-сервисы. Однако они имеют довольно значительные недостатки, которые полностью или частично решаются поднятием своего собственного shadowsocks-сервера. В этом гайде я опишу, как это сделать.

    Сразу возникает резонный воппрос – а зачем так заморачиваться, когда есть VPN? Итак, для начала перечислю плюсы и минусы VPN перед shadowsocks-сервером:

    + От пользователя не требуется никаких технических знаний и траты времени на настройку – поставил ВПН и забыл. Настройка же SS-сервера, тем более с обфускацией трафика, требует некоторых умений и знаний, которых нет у большинства пользователей.

    – ВПН серверы работают медленно, даже платные. Про бесплатные вообще говорить не приходится – это просто дно, которым невозможно пользоваться на постоянной основе. Причины медленной скорости кроются в том, что российские провайдеры анализируют трафик и умышленно режут скорость подозрительного зашифрованного трафика. Всё это решается обфускацией трафика с помощью обычного TLS-шифрования, который для провайдера выглядит как легитимный.

    – VPN небезопасен для пользователя. При желании товарища майора, вас очень быстро найдут: либо вас сольёт сам ВПН-провайдер, либо вас вычислят с помощью т.н. атаки сравнений – это когда товарищ майор, имея пакет яровой и данные о трафике, а так же данные с серверов (что актуально для всего рунета) для того, чтобы найти злобного оппозиционера, который пишет плохие вещи про власть через впн, сравнивает, с какого айпи пользователь это писал и кто в этот момент времени подключался к айпи-адресу, с которого это писали, и вычисляет мамкиного копротивленца.  SS+v2ray+tls в этом плане гораздо безопаснее для пользователя, живущего в таких тоталитарных странах, как Россия и Китай, к примеру. Поэтому вполне естественно, что протокол shadowsocks и v2ray были созданы в КНР.

    – (*) Помимо скорости и безопасности, обход блокировок с помощью SS+v2ray может быть абсолютно бесплатным! Для этого нужно найти какой-нибудь условно-бесплатный виртуальный сервер (например Oracle Cloud) и бесплатный домен (например, .tk, который предоставляет freenom). О том, как получить бесплатную VPS-ку, можно почитать эту статью на Хабре, но есть одно но – свете последних событий Oracle не предоставляет услуги россиянам, поэтому просто так там зарегистрироваться не получится – только если у вас нет иностранной симки и иностранной банковской карты, с которой единоразово снимается 1 доллар в качестве проверки.

    – VPN провайдеры ограничивают трафик/количество устройств и как правило используют стоковый OpenVPN или немного модифицированный.

    Краткий план действий.

    Read more

    Хранение конфигурационных файлов на удалённом репозитории

    Задача: у нас есть два компьютера (ноутбук и ПК), в каждом из которых есть некие конфигурационные файлы (.vimrc, .zshrc, mpv.conf и т.п.). Нам нужно хранить эти файлы и синхронизировать с удалённым репозиторием, чтобы в любой момент их можно восстановить или развернуть на новой системе. Так как у нас два устройства, то их нужно как-то разграничить. Это можно сделать несколькими способами, самый удобный – это воспользоваться ветками – создать отдельную ветку для ПК и для ноутбука.

    Что потребуется: git, аккаунт на github или любой другой хостинговой платформе

    Реализация:

    Создадим репозиторий, назовём его my-configs

    Клонируем созданный репозиторий:

    git clone https://github.com/bernd32/my-configs.git
    
    cd /my-config

    Так как сейчас мы работаем с ПК, то создадим и перейдем в отельную ветку pc, где будут отдельно храниться конф. файлы ПК:

    git checkout -b pc

    Теперь нужно добавить нужные файлы. Чтобы не редактировать конфигурационные файлы по два раза (находящиеся в директории локального репозитория (далее – ДЛР), и находящиеся на своем непосредственном месте (чаще всего это  домашняя директория /~)), то создадим симлинки на эти файлы.

    К примеру, нам нужно синхронизировать .zshrc и .vimrc. Добавляем эти файлы в ДЛР

    mv ~/.vimrc ~/my-configs
    
    mv ~/.zshrc ~/my-configs

    Создаем симлинки этих файлов в то место, откуда они были перемещены:

    ln -s ~/my-configs/.vimrc ~/.vimrc
    
    ln -s ~/my-configs/.zshrc ~/.zshrc

    Пушим и коммитим файлы на удаленную ветку pc:

    git add .
    git commit -m "Initial PC config"
    git push -u origin pc

    Повторяем все те же действия на втором устройстве (в моем случае это ноутбук), но не забываем создать ветку laptop и пушить файлы в ветку laptop:

    git add .
    git commit -m "Initial laptop config"
    git push -u origin laptop

    Объединение общих конфигураций

    Если есть общие конфигурации на ПК и ноутбуке которые нужно расшарить между собой, то это можно сделать это путем слияния (merge). К примеру, мы внесли в ветке pc те изменение, которые должны быть применены также и к ветке laptop, замержить эти изменение можно таким образом:

    git checkout laptop
    git merge pc
    
    git push origin laptop

    Регулярная синхронизация

    Регулярное обновление каждой машины изменениями из удаленного репозитория и отправление (push) новых изменений совершается примерно такими  командами:

    Синхронизация с удаленной веткой:

    git pull origin <имя_ветки>

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

    git add .
    git commit -m "Update config files"
    
    git push origin <имя_ветки>