gemlog/public/uk/radicle-multi-network-seed-deployment.gmi
2026-02-12 06:16:12 +02:00

298 lines
No EOL
17 KiB
Text
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Розгортання сіда Radicle в мульти-мережному середовищі
> Давно планував організувати автономний сервер Radicle, щоб не залежати від наявних публічних сідів. Нижче наведено приклад мого налаштування персонального (Selective) сід-вузла, орієнтованого в першу чергу на мережі Yggdrasil, Mycelium і Tor.
Radicle - це платформа децентралізованого хостингу Git, що працює на базі пірингової технології Gossip. У цьому випадку, роль сіда (англ. seed) подібна класичним торентам і так само полягає в поширенні вузлом завантажених на нього даних.
Окремо про клієнтське використання цього програмного забезпечення вже було описано в матеріалі:
=> radicle-is-decentralized-p2p-git-dvcs.gmi Radicle: децентралізований P2P хостинг Git/DVCS
## Підготовка системи
Спочатку, створюється системний користувач з обмеженими правами:
``` bash
useradd -mr radicle
```
* `m` - створення домашньої теки (для зберігання даних профілю)
* `r` - системний користувач (для використання сервісом systemd)
Встановлення бінарних `rad`, `radicle-node` і `git-remote-rad` відбувається до теки глобального простору `/usr/local/bin`, куди буде надалі звертатись системний сервіс (інакше можливі проблеми з правами на запуск)
## Конфігурація вузла
Якщо запуск вузла Radicle відбувався раніше, то в домашній теці користувача вже буде автоматично створено стандартний файл конфігурації. Дізнатись шлях до нього можна командою:
``` bash
$ rad self --config
/home/radicle/.radicle/config.json
```
Якщо запуск (в рамках гайду) раніше ще не здійснювався, і оскільки це серверний вузол, краще заздалегідь створити актуальну версію файлу через CLI до запуску. Для цього потрібно авторизуватись від створеного раніше користувача:
``` bash
su radicle
$ rad self --config
✗ Error: Radicle profile not found in '/home/radicle/.radicle'.
✗ Hint: To setup your radicle profile, run `rad auth`.
```
Як бачимо, файл конфігурації ще не існує і менеджер пропонує виконати команду:
``` bash
rad auth
```
Після введення команди, відповідаємо на питання конфігуратора. Для серверного вузла - особисто я не вказую пароль, щоб потім не вказувати його в systemd змінною середовища (не бачу у цьому необхідності, адже це всього лише ресід мого віддалено-підписаного облікового запису)
Також, на цьому етапі важливо визначитись з політикою сідування (seedingPolicy)
=> https://radicle.xyz/guides/seeder#seeding-policies Radicle Seeder Guide: Seeding policies
Поточну політику (якщо файл конфігурації було створено раніше) можна дізнатися командою:
``` bash
rad config get node.seedingPolicy
```
Нижче розглянемо дві базові.
### Дозвільна політика (Permissive policy)
Лояльний режим роботи вузла. Він автоматично приймає будь-які поширення з інших вузлів, тим само найкраще підтримує глобальну мережу Radicle. Утім, такий спосіб вимагає чимало дискового простору і може тягнути за собою не бажані наслідки, зокрема юридичного характеру: адже будь-хто зможе розмістити на вашому сервері будь що.
Обираючи цей тип, політика встановлюється наступним чином:
``` config.json
"node": {
"seedingPolicy": {
"default": "allow",
"scope": "all"
}
}
```
При виявленні не бажаного вмісту, заблокувати окремий вузол можна командою:
``` bash
rad block rad:z9DV738hJpCa6aQXqvQC4SjaZvsi
```
### Вибіркова політика (Selective policy)
Дана конфігурація вузла (що також є стандартною) вимагатиме від його адміністратора обліку "білого списку" клієнтських вузлів, від яких надходитимуть запити на сідування їх репозиторіїв. Прикладом такого вузла є `seed.radicle.xyz`, куди на відміну від `seed.radicle.xyz` та `iris.radicle.xyz` - ніхто не зможе надіслати свої дані.
Цей тип є оптимальним для організацій та приватних осіб, які бажають забезпечити хорошу конективність для своїх репозиторіїв (наприклад, не маючи достатньо ресурсів сервера для підтримки усієї мережі в форматі Permissive) та/або не бути залежними від онлайну інших учасників мережі.
Кейс `seedingPolicy` у цьому випадку, матиме наступний вигляд:
``` config.json
"node": {
"seedingPolicy": {
"default": "block"
}
}
```
Тим не менше, якщо ви помітили цікавий проєкт, що не входить до "білого списку" додати виключення можна командою:
``` bash
rad seed rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5
```
І навпаки, видалити зі списку зберігання і роздач:
``` bash
rad unseed rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5
```
### Приклад мого файлу конфігурації
Після ініціації засобами CLI, можна продовжити керування цією ж утилітою (див. `rad --help`) але мені простіше буде відкрити файл конфігурації та відтюнити в ньому деякі моменти вручну, зокрема:
``` config.json
"node": {
"alias": "YGGverse",
"listen": [
"[202:68d0:f0d5:b88d:1d1a:555e:2f6b:3148]:8776",
"[505:6847:c778:61a1:5c6d:e802:d291:8191]:8776"
],
"externalAddresses": [
"[202:68d0:f0d5:b88d:1d1a:555e:2f6b:3148]:8776", "ygg.ua.srv:8776",
"[505:6847:c778:61a1:5c6d:e802:d291:8191]:8776", "myc.ua.srv:8776"
],
"seedingPolicy": {
"default": "block"
}
}
```
* як бачимо, я "роздаю" на мережі Yggdrasil та Mycelium, а також використовую вибіркову політику "Selective", адже мій вузол має обмежені ресурси та певні юридичні вимоги
Оскільки вхід на вузол орієнтований в першу чергу на оверлейні мережі а також має виключно такий інтерфейс, додав до списку один відомий мені сід Yggdrasil:
``` config.json
"preferredSeeds": [
"z6MkrLMMsiPWUcNPHcRajuMi9mDfYckSoJyPwwnknocNYPm7@irisradizskwweumpydlj4oammoshkxxjur3ztcmo7cou5emc6s5lfid.onion:8776",
"z6Mkmqogy2qEM2ummccUthFEaaHvyYmYBYh3dbe9W4ebScxo@rosarad5bxgdlgjnzzjygnsxrwxmoaj4vn7xinlstwglxvyt64jlnhyd.onion:8776",
"z6MkocYY4dgMjo2YeUEwQ4BP4AotL7MyovzJCPiEuzkjg127@[202:f094:502b:1b03:9e0:2c3d:bc8b:428b]:8776"
]
```
* роутер Tor у мене працює також через Yggdrasil, тому я не дуже залежу від сідів саме цієї мережі, але додав на випадок, якщо сіди Tor будуть не доступні (і навпаки)
=> https://yggdrasil-network.github.io/services.html#radicle-nodes Перевірити актуальні сіди Yggdrasil
Таким чином, сід Yggdrasil буде підключено через наявний IPv6 інтерфейс "напряму". Для підтримки вказаних вище сідів мережі Tor - потрібно окремо вказати налаштування відповідного проксі:
```
"node": {
"onion": {
"mode": "proxy",
"address": "[::1]:9150"
}
}
```
* стандартний порт `9050` замінено на `9150` (сучасна імплементація Arti на Rust)
* на моєму сервері для роутера Tor використовується локалхост IPv6, для IPv4 - це буде хост `127.0.0.1` (за умови локального розташування роутера)
Про мій сетап Arti, детальніше написано тут:
=> arti-onion-router-with-tor-connection-over-yggdrasil.gmi Встановлення Onion-роутера Arti з підключенням до мережі Tor через Yggdrasil
Щодо налаштування вхідного трафіку (hidden service) від пірів з мережі Tor, можна почитати окремо:
=> https://radicle.xyz/guides/user#setting-up-a-tor-onion-service-for-radicle Radicle User Guide: Setting up a Tor Onion Service for Radicle
В мене ще крутиться роутер I2P, але цю тему я поки не копав, бо вузлів вище - цілком вистачає для синхронізації з глобальною мережею. Але додам деякі посилання по темі на майбутнє:
=> https://radicle.zulipchat.com/#narrow/channel/369274-General/topic/i2p.20and.20other.20overlay.20networks.20support Тема на Zulip Chat
=> https://app.radicle.xyz/nodes/seed.radicle.xyz/rad%3Az371PVmDHdjJucejRoRYJcDEvD5pp/patches/18e6ec1dd5e87e39223ceade8e016107937ab1c3 Add docs for I2P use in addition to Tor
Офіційний гайд стосовно гібридної конфігурації мереж:
=> https://radicle.xyz/guides/user#configuring-radicle-in-mixed-mode Radicle User Guide: Configuring Radicle in Mixed Mode
## Фаєрвол
Якщо у вас використовується виключно Tor або I2P - відкривати порти не потрібно!
В інших випадках (на базі оверлеїв класичного стеку) дивимось потрібні нам IP інтерфейсів:
``` bash
ifconfig
```
Після чого додаємо записи `iptables`, особисто я надаю перевагу `ufw`:
``` bash
ufw allow from 0200::/7 to 202:68d0:f0d5:b88d:1d1a:555e:2f6b:3148 port 8776 comment 'radicle'
ufw allow from 0400::/7 to 505:6847:c778:61a1:5c6d:e802:d291:8191 port 8776 comment 'radicle'
```
* мій сервер працюватиме тільки на дві мережі: Mycelium та Yggdrasil; у вас це може бути й Інтернет IP, або ж дозвільне правило типу `ufw allow 8776`
* у прикладі я свідомо не вказую фільтрацію по TCP, адже технічно торенти можуть працювати також в контексті UDP (реалізацією сокетів Radicle ще не цікавився)
## Запуск вузла
Для запуску і контролю процесом, використовується сервіс systemd, для цього створімо новий юніт:
``` /etc/systemd/system/radicle.service
[Unit]
Description=Radicle Node
After=network.target network-online.target
Requires=network-online.target
[Service]
# використовується IPv6, оскільки я пускаю вузол в мережах Mycelium та Yggdrasil
ExecStart=/usr/local/bin/radicle-node --listen [::]:8776 --force
KillMode=process
Restart=always
RestartSec=3
# Базові параметри жорсткого підсилення.
# Для докладнішої інформації див. `systemd-analyze security`
PrivateTmp=true
ProtectSystem=strict
NoNewPrivileges=true
MemoryDenyWriteExecute=true
# Якщо ваш ключ Radicle захищено фразою-паролем,
# потрібно встановити змінну середовища `RAD_PASSPHRASE` зі значенням фрази-пароля,
# вказаної під час `rad auth`
#Environment=RAD_PASSPHRASE=snickerdoodle
# Запуск від створеного раніше користувача
User=radicle
Group=radicle
# Журнали, опціонально:
# * розмістити в `/var/log` попередньо створивши теку та надавши відповідні дозволи
# * закоментувати або вказати як `null`
StandardOutput=file:///home/radicle/debug.log
StandardError=file:///home/radicle/error.log
[Install]
WantedBy=multi-user.target
```
=> https://app.radicle.xyz/nodes/iris.radicle.xyz/rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5/tree/systemd/system/radicle-node.service Приклад systemd в офіційному репозиторії
### Керування системним сервісом
Автоматично запускати вузол Radicle при старті системи:
``` bash
systemctl enable radicle
```
Запуск (або перезапуск) якщо служба активна:
``` bash
systemctl restart radicle
```
Перевірка статусу:
``` bash
systemctl status radicle
```
При змінах конфігурації системного сервісу, перед запуском, потрібно застосувати зміни:
``` bash
systemctl daemon-reload
```
## Резервні копії
Для "повного бекапу" достатньо створити архів з підтримкою прав файлової системи `.tar.gz` для теки `/home/radicle/.radicle`. Але якщо ви не хочете тягати туди-сюди великі об'єми даних (що й так поширені між іншими вузлами) рекомендую здійснити резервні копії саме ключів, які знаходяться у теці `/home/radicle/.radicle/keys`.
## Публікація
Подібно оверлейним мережам, якщо ваш вузол Radicle підключено щонайменше до одного сіда - його рано чи пізно зможуть побачити інші учасники пірингової мережі. Переконатись у цьому можна виконавши команду на стороні клієнтського піра:
``` bash
rad sync status
```
Утім, якщо треба опублікувати реквізити вузла у різних каталогах, або потрібно пріоритезувати синхронізацію змін саме до нашого сіду під час виконання `git push`, тоді на клієнтській машині додається рядок з параметрами так званого "preferred" підключення у форматі `DID@IP:PORT`. Якщо хост і порт ми вказували під час оголошення мережного інтерфейсу, то тримати `DID` можна командою:
```
$ rad self
Alias YGGverse
DID did:key:z6Mkvky2mnSYCTUMKRdAUoZXBXLLKtnWEkWeYQcGjjnmobAU
...
```
* де `z6Mkvky2mnSYCTUMKRdAUoZXBXLLKtnWEkWeYQcGjjnmobAU` - без префіксу `did:key:`
Отже, на клієнтському вузлі додаю два нові рядки з реквізитами нашого сід-вузла (який згідно конфігурації слухає з'єднання на `[::]:8776`)
``` config.json
"preferredSeeds": [
"z6Mkvky2mnSYCTUMKRdAUoZXBXLLKtnWEkWeYQcGjjnmobAU@[202:68d0:f0d5:b88d:1d1a:555e:2f6b:3148]:8776",
"z6Mkvky2mnSYCTUMKRdAUoZXBXLLKtnWEkWeYQcGjjnmobAU@[505:6847:c778:61a1:5c6d:e802:d291:8191]:8776"
]
```
Якщо є налаштовані приховані сервіси Tor або тунелі I2P, вони додаються по аналогії.
## Посилання
=> https://radicle.xyz/guides/seeder Radicle Seeder Guide