основний, найкорисніший сервіс в домашній мережі — owncloud — крутиться в контейнері на старенькому сервері навіть без віртуалізації (і це не головна проблема!); до цього часу він (тьху-тьху-тьху) працює надійно, як годинник — але ж ми знаємо, що рано чи пізно щось та й трапиться. тож давно визріває думка: треба перенести контейнер на віртуалку в proxmox на іншому, трішки надійнішому сервері v2 (план а), або… повністю перейти на nextcloud як сервіс yunohost на тому ж сервері v2 (план б). звідси — бажання випробувати для початку yunohost, бо давно задивляюся на нього.
зміст
- підготовка
- встановлення yunohost на debian
- масштабування розділів lvm наживо
- продовження налаштування yunohost
- перші враження
- висновки
підготовка
маю колись для чогось створену віртуальну машину (озу 4 гб, системний накопичувач 32 гб), що «лежить» без діла на proxmox, — використаю її для випроби yunohost. веб-консоль proxmox — міняю hostname, щоби уникнути пізніших проблем з перейменуванням:
> sudo hostnamectl set-hostname yuno
> sudo vi /etc/hosts
# ----- >8 -----
127.0.0.1 localhost
127.0.1.1 yuno.lan yuno
# ----- 8< -----
перевіряю, що ip статична і за dns править локальний шлюз:
> sudo vi /etc/network/interfaces
# ----- >8 -----
# магія…
# ----- 8< -----
перезавантажую. далі — ssh і поновлення системи (бо не пригадую вже, коли ця vm створювалась, і з чого…); спершу — поновлюю вже встановлену версію:
> cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
> cat /etc/debian_version
10.13
> sudo apt-mark showhold
# порожньо — це добре
> sudo apt update
> sudo apt upgrade
> sudo apt full-upgrade
> sudo apt --purge autoremove
> sudo systemctl reboot
після перезавантаження — додаю посилання на репозиторії 11-ї версії (bullseye), і закоментовую все для встановленої десятки (buster):
> sudo vi /etc/apt/sources.list
# ----- >8 -----
# debian 11 upgrade (2023-11-28) /ti
# main repo
deb http://deb.debian.org/debian/ bullseye main contrib non-free
deb-src http://deb.debian.org/debian bullseye main contrib non-free
# security repo
deb http://security.debian.org/debian-security bullseye-security main contrib non-free
deb-src http://security.debian.org/debian-security bullseye-security main contrib non-free
# updates repo
deb http://deb.debian.org/debian/ bullseye-updates main contrib non-free
deb-src http://deb.debian.org/debian/ bullseye-updates main contrib non-free
# backports repo
deb http://deb.debian.org/debian/ bullseye-backports main contrib non-free
deb-src http://deb.debian.org/debian/ bullseye-backports main contrib non-free
# ----- 8< -----
> sudo apt update
мета цього apt update — переконатися, що нові репозиторії доступні, списки завантажуються. все гаразд — роблю мінімальне поновлення; ризик мінімальний, бо на vm нічого не крутиться, якщо щось поламається — просто підніму нову vm (на машинці з «живими» сервісами я б нестямно бекапив і висирав цеглу на кожне питання менеджера пакунків):
> sudo apt upgrade --without-new-pkgs
далі — повне поновлення і перезавантаження в нову версію:
> sudo apt full-upgrade
> sudo systemctl reboot
знову ssh, перевіряю:
> cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
> cat /etc/debian_version
11.8
встановлення yunohost на debian
можна було завантажити образ системи з yunohost, але коли вже ж я мав «зайву» віртуальну машину — хотілося спробувати мережеве встановлення. отже, пробую (найперше треба встановити curl, бо debian «з коробки» його не має):
> sudo -i
> apt install curl
> curl https://install.yunohost.org | bash
деякий час інсталятор робить свою магію, періодично запитуючи щось… і врешті-решт пропонує відкрити веб-консоль у веб-оглядачі для продовження налаштування. на жаль, я забув перевірити розподіл системного накопичувача, і yunohost попереджає мене, що 6 гб для системного розділу — надто мало для нього.
масштабування розділів lvm наживо
доведеться ще трішки пошаманити з lvm: зменшити завеликий розділ під /home і віддати зекономлене під /. на щастя, для розбивки використано lvm (завжди так робіть!), і корінь треба збільшити, а не зменшити — тож можна втнути штуку й спробувати зробити це наживо (без перезавантаження, і без відмонтування кореня) — що може піти не так?
не робіть цього вдома без нагляду дорослих (мені можна: я вже робив багато разів, на реальних vm з сервісами, по роботі).
найперше — роблю зняток віртуалки в proxmox. далі — це важливо! — знадобиться init 1 (тиць), і підключення ssh перерветься; тому потрібен фізичний доступ до консолі, а у випадку з віртуальною машиною — доступ до емуляції консолі в гіпервізорі (веб-консоль proxmox); ще раз: не робіть ось цього по мережі (а на ubuntu та подібних — ще й перевірте завчасу, чи доступний профіль root!):
> sudo init 1
доведеться залогінитися знову, причому лише як root! перевіряю конфігурацію та розміри розділів (з виводу показую вибірково лише важливе):
> lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
...
└─sda5 LVM2_member LVM2 001 dRwWT7-aOhr-oTkW-j4HF-DdM4-aEZy-kAMego
├─docker--vg-root ext4 1.0 3ae786fa-a2d6-446d-ab2c-8c5ac92475c0 3.5G 37% /
└─docker--vg-home ext4 1.0 ffaab9e4-82bb-4a64-a977-1bbc7399f917 19.8G 0% /home
lsblk (і df) використовує нотацію логічних розділів /dev/mapper/<vg>-<lv>, а утиліти lvm — трохи більш наочну /dev/<vg>/<lv> (обидві, насправді, створюють посилання на третю нотацію: /dev/dm-N, але вона не гарантує персистентного найменування через ребути, тому її не варто використовувати в маніпуляціях); корисно одразу встановити собі відповідність між назвами:
> lvdisplay | grep "Path"
...
LV Path /dev/docker-vg/root # /dev/mapper/docker--vg-root
LV Path /dev/docker-vg/home # /dev/mapper/docker--vg-home
збираю інформацію перед зменшенням /dev/docker-vg/home (вибірково):
# детальна інформація про логічний розділ /dev/docker-vg/home
> lvdisplay /dev/docker-vg/home
--- Logical volume ---
LV Path /dev/docker-vg/home
LV Name home
VG Name docker-vg
LV Size <21.43 GiB
Current LE 5485
# детальна інформація про групу docker-vg
> vgdisplay
--- Volume group ---
VG Name docker-vg
Format lvm2
VG Status resizable
VG Size <31.52 GiB
PE Size 4.00 MiB
Total PE 8069
Alloc PE / Size 8056 / <31.47 GiB
Free PE / Size 13 / 52.00 MiB
# чи не відкрито якісь файли в /home?
> lsof /dev/docker-vg/home
якщо вивід lsof порожній — все гаразд: «пацієнт» під наркозом, можна починати операцію.
# відмонтувати розділ під /home
> umount /dev/docker-vg/home
# перевірити на помилки
> e2fsck /dev/docker-vg/home
# зменшити розмір логічного розділу (і файлової системи) до 1 гб
lvreduce --resizefs --size 1G /dev/docker-vg/home
# змонтувати зменшений /home
mount /dev/docker-vg/home
скільки фізичних «ділянок» (physical extent) вивільнилося для кореня (було 13 / 52 мб)?
> vgdisplay docker-vg | grep "Free"
Free PE / Size 5242 / <20.48 GiB
тепер можна збільшити кореневий розділ /dev/docker-vg/root «на льоту» (без відмонтування):
> lvextend --resizefs -l +100%FREE /dev/docker-vg/root
перевірка:
> lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
└─sda5 LVM2_member LVM2 001 dRwWT7-aOhr-oTkW-j4HF-DdM4-aEZy-kAMego
├─docker--vg-root ext4 1.0 3ae786fa-a2d6-446d-ab2c-8c5ac92475c0 22.8G 8% /
└─docker--vg-home ext4 1.0 ffaab9e4-82bb-4a64-a977-1bbc7399f917 792.7M 0% /home
легко й просто? це тому, що lvm, і не треба було зменшувати корінь. можна повертатися до нормального рівня виконання, закривати «фізичну» консоль (веб-консоль proxmox) і знову підключатися по ssh:
> init 5
продовження налаштування yunohost
повертаюсь до веб-інтерфейсу yunohost і перезапускаю майстер налаштування після встановлення. найважливіше тут рішення — доменне ім’я; для випроби я вказав yuno.malynka.duckdns.org, бо malynka «прив’язана» до публічного ip домашнього шлюза, і хотілося одразу спробувати налаштувати traefik (крутиться в контейнері на іншому сервері) для переадресації, але… поки що забракло клямки (про це згодом), тож згодом довелося міняти на yunohost.local для випробування суто в локальній мережі.
після цього маю встановлений тестовий yunohost з доступом виключно в локальній мережі через адресу https://yunohost.local; віртуальна машинка дуже «тісненька», тож сервер придатний лише для випроби.
на одному з етапів встановлення, скрипт з install.yunohost.org запитував дозволу відредагувати конфігурацію сервера ssh, щоби root’ом не можна було підключитися; я погодився (бо це правильно), але… після цього виявилося, що не лише root, але й усі інші профілі, налаштовані до встановлення yunohost, втратили досту через ssh! це фіча, яка водночас є вадою, якщо встановлювати yuno на вже підготовлену систему (а не розгортати з образу): по-перше, нас про це не попереджали (йшлося лише про root’а!), а по-друге, а ну ж як щось пішло не так під час додавання адміністратора yunohost (за замовчуванням: admin), — можна лишитися без дистанційного доступу до машини. тож найперше — перевіряю, що там пороблено в /etc/ssh/sshd_config (знову через веб-консоль proxmox):
> sudo vi /etc/ssh/sshd_config
# ----->8-----
# This configuration has been automatically generated
# by YunoHost
...
PermitRootLogin no
...
AllowGroups ssh.main sftp.main ssh.app sftp.app admins root
...
# root login is allowed on local networks
Match Address 192.168.0.0/16,10.0.0.0/8,172.16.0.0/12,169.254.0.0/16,fe80::/10,df99:/8
PermitRootLogin yes
# -----8<-----
отже, ssh для root’а закритий не зовсім, а загальний доступ обмежений групами. здавалося б, додати свій профіль (створений до встановлення yunohost) до однієї з перелічених груп — і буде щастя? так, але ні… не працює з групами ssh.main чи admin, але спрацювало з ssh.app; не розбирався, чому саме так. отже:
> sudo usermod -a -G ssh.app tivasyk
можна закривати веб-консоль proxmox, підключитися затишненько по ssh і роздивлятися далі.
перші враження
yunohost — не готовий «з коробки» сервер (і не операційна система, попри те, що пише на сайті), а система адміністрування веб-сервісів для самохостингу. встановлений yuno потребує встановлення сервісів — веб-додатків, що будуть доступні за спільною для всіх адресою (в моєму випадку лише локально: https://yunohost.local). з додатками проблемки:
- їх багато… але далеко не всі вони навіть на позір виглядають потрібними (ну, але то я);
- деякі мені не вдалося встановити: мікро-блогінговий рушій pico;
- деякі — встановив, але вони не працюють: додаток для обліку фінансів ihatemoney (зазирнув до /var/www/ihatemoney, це люті python’івські хащі);
- інші — встановив і спробував: забавки 20euros, 243 та hextris.
жодного сенсу тримати ці забавки на власному сервері я не бачу (хто заважає грати деінде?) спроба встановити nextcloud теж поки що не вдалася… тому що забракло місця під /var: схоже, всі сервіси «живуть» у /var/www; знову цей момент «якби ж знаття!» — адже замість віддавати все звільнене з-під /home місце під корінь, можна було забрати частину під /var… але поїзд пішов, і тепер доведеться додавати віртуальний диск спеціально для цього… проблема в тім, що yuno ніяк не попереджає, скільки місця й де знадобиться тому чи іншому додатку, — хіба що я щось пропустив.
і прочитаю ж мабуть таки документацію.
висновки
головне питання: чи мені потрібен yunohost для наступної реінкарнації домашнього сервера?
позитивні враження:
- єдиний логін (sso) до всіх веб-сервісів, налаштований і працює «з коробки», хоч і з особливостями (локальні профілі);
- автомагічне управління сертифікатами tls (ще називаєте їх ssl?) «з коробки» — хоча я не випробував поки що;
- веб-сервер (nginx) і поштовий сервер (postfix) налаштовані «з коробки»;
- дуже обмежені налаштування, але ті, що є — доступні й притомно коментовані.
що спиняє:
- в дійсності — дуже обмежений набір інструментів для власне підтримки (maintenance) системи: сподівання на те, що все просто працює як слід;
- yunohost спрощує до нуля встановлення й налаштування сервісів з набору, але ускладнює їх підтримку, вельми ускладнює додаткове налаштування (див. проблему з дисковим простором під nextcloud) і встановлення чогось не з каталога;
- сервіси «крутяться» безпоседеньо на машині (в ідеалі — віртуальній), не в контейнерах; для мене це здоровенний мінус, тому що контейнери docker чи podman — це найпростіша форма infrastructure as code, що є добре з будь-якої точки зору, а yuhonost — це продовження класичного підходу (вищі затрати, вищі ризики).
чи не найпомітніша особливість, щодо котрої я не був певен, чи писати її до плюсів чи мінусів: yunohost — це менеджер веб-сервісів (не сервера!); доступні налаштування сервера не просто обмежені, а мінімальні, — практично вся підтримка власне сервера робиться все-одно в командному рядку: диски, мережа, поновлення системи, керування системними сервісами тощо. водночас, yuhonost — це додатковий рівень складнощів у випадку будь-яких негараздів, потенційно зі своїми проблемами.
тож наразі відповідь на «головне питання» — ні, yunohost мені не потрібен, а потрібно
- мігрувати мої контейнери на сервер v2;
- замінити traefik на caddy;
- переналаштувати до пуття сховище даних;
- налаштувати резервне копіювання (і відновлення).