gemlog/public/uk/radicle-multi-network-seed-deployment.gmi
2026-02-11 20:09:06 +02:00

292 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 в мульти-мережному середовищі
> Цього разу, мені захотілось організувати персональний сервер, щоб не залежати від наявних публічних сідів. Нижче наведено приклад з налаштування персонального (Selective) вузла, орієнтованого на мережі Yggdrasil, Mycelium і Tor.
Radicle - це платформа децентралізованого хостингу Git, що працює на базі технологій BitTorrent/DHT. Роль сіда (англ. seed) в цьому випадку аналогічна класичним торентам і полягає в поширенні вузлом завантажених на нього даних. Різниця сіда в мережі Radicle, полягає лише в тому, що вузол тут окремо бере на себе й роль трекера.
Окремо про клієнтське використання цього програмного забезпечення вже було описано в матеріалі:
=> 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`.
```
Як бачимо, файл конфігурації ще не існує і менеджер пропонує виконати команду `rad auth`. Після введення команди, відповідаємо на питання конфігуратора. Для серверного вузла - особисто я не вказую пароль, щоб потім не вказувати його в systemd змінною середовища (не бачу у цьому необхідності, адже це всього лише ресід мого віддалено-підписаного облікового запису)
Також, на цьому етапі важливо визначитись з політикою сідування (seedingPolicy)
=> https://radicle.xyz/guides/seeder#seeding-policies Radicle Seeder Guide: Seeding policies
Поточну політику вузла (якщо файл конфігурації було створено раніше) можна дізнатися командою:
``` bash
rad config get node.seedingPolicy
```
Нижче розглянемо дві базові.
### Дозвільна політика (Permissive)
Лояльний режим роботи вузла. Він автоматично приймає будь-які поширення з інших вузлів, тим само найкраще підтримує мережу Radicle. Утім, такий спосіб вимагає чимало дискового простору і може тягнути за собою не бажані наслідки, зокрема юридичного характеру: адже будь-хто зможе розмістити на вашому сервері будь що.
Обираючи цей тип, політика встановлюється наступним чином:
``` config.json
"node": {
"seedingPolicy": {
"default": "allow",
"scope": "all"
}
}
```
При виявленні не бажаного вмісту, при такому способі сідування, видалити окремий вузол можна командою:
``` bash
rad block rad:z9DV738hJpCa6aQXqvQC4SjaZvsi
```
### Вибіркова політика (Selective)
Дана конфігурація вузла (що також є стандартною) вимагатиме від його адміністратора ведення "білого списку" клієнтських вузлів, від яких надходитимуть запити на сідування їх репозиторіїв. Прикладом такого вузла є `seed.radicle.xyz`, куди на відміну від `seed.radicle.xyz` та `iris.radicle.xyz` - ніхто не зможе надіслати свої дані.
Цей тип є оптимальним для організацій та приватних осіб, які бажають забезпечити хорошу конективність для своїх репозиторіїв (наприклад, не маючи достатньо ресурсів сервера для підтримки усієї мережі Radicle) і не бути залежними від інших учасників мережі.
Кейс `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", "myc.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 буде підключено через наявний мережний інтерфейс "напряму". Для підтримки сідів в мережі Tor - потрібно окремо вказати налаштування відповідного проксі:
```
"node": {
"onion": {
"mode": "proxy",
"address": "[::1]:9150"
}
}
```
* стандартний порт `9050` замінено на `9150` (сучасна імплементація Arti на Rust)
* також, на моєму сервері використовується IPv6, для IPv4 це буде хост `127.0.0.1` (за умови локального розташування роутера)
Про налаштування підключення Arti через Yggdrasil, написано тут:
=> 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, але цю тему я поки не копав, бо вузлів вище - цілком вистачає для синхронізації з глобальною мережею Radicle. Але додам деякі посилання по темі на майбутнє (хоча думаю що проксі налаштовується по аналогії з ключем `onion` тільки це буде `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 (не цікавився)
## Запуск вузла
Для запуску і контролю процесом, використовується сервіс 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