Omada Software Controller v LXC kontejneru na Proxmoxu s Debianem 13

Domácí síť mám postavenou na zařízeních TP-Link Omada: switch SG2210XMP-M2 a dva přístupové body Wi-Fi 7 EAP773. Doteď běžela každá zvlášť v režimu standalone, takže každé zařízení mělo vlastní webové rozhraní a vlastní nastavení. Abych je mohl spravovat z jednoho místa, nainstaloval jsem bezplatný Omada Software Controller do LXC kontejneru na domácím serveru s Proxmoxem. Kontejner běží na Debianu 13, i když ho TP-Link zatím oficiálně neuvádí. Popíšu, proč jsem zvolil právě tuhle cestu a na co si dát pozor.

Výchozí stav a cíl

Doma mi běží server s Proxmox VE 9.2, na kterém už jsou dva LXC kontejnery s Debianem 13: webový server s Drupalem a Nextcloud. Postup jejich vzniku jsem popsal v článku Webový server na Proxmoxu v LXC kontejneru. Server běží nonstop a volné RAM má kolem 6–7 GB.

Cílem bylo:

  • spravovat switch a obě AP z jednoho rozhraní,
  • připravit základ pro oddělení IP kamer do vlastní VLAN,
  • aktualizovat firmware zařízení z jednoho místa,
  • nic měsíčně neplatit a nekupovat hardware navíc.

Jaký controller zvolit

Omada nabízí tři varianty správy. Porovnal jsem je takto:

VariantaVýhodyNevýhody
Hardwarový controller (OC200 a vyšší)samostatné zařízení, nic se neinstalujejednorázový výdaj, další krabička v rozvaděči
Omada Central Essentials (cloud, zdarma)bez instalacezávislost na cloudu a účtu TP-Link, omezené funkce, správa sítě mimo domov
Omada Software Controllerzdarma, všechny funkce, data zůstávají domapotřebuje server, kde poběží

Server už doma běží, takže volba byla jasná: softwarový controller.

Schéma: Omada Software Controller v LXC kontejneru na Proxmoxu spravuje switch a přístupové body, zálohuje se na NAS a cloud je vypnutý

Proč LXC kontejner, a ne virtuální stroj

Původně jsem zvažoval plnohodnotný virtuální stroj. Hlavní důvod byl, že ho můžu vypnout, když ho nepotřebuju, a že se na hostitele nebude instalovat Java ani databáze. Obojí ale splňuje i LXC kontejner:

  • vypnutí: vypnutý kontejner nezabírá RAM ani CPU, stejně jako vypnutá VM,
  • oddělení: Java, MongoDB i controller se instalují dovnitř kontejneru, na hostitele se nic nepřidá a smazáním kontejneru zmizí i všechny balíčky,
  • nároky: kontejner potřebuje zhruba 1,5–2 GB RAM, VM by chtěla 3–4 GB,
  • AVX: MongoDB od verze 5 vyžaduje instrukce AVX. Kontejner vidí CPU hostitele přímo, u VM je potřeba nastavit typ procesoru na host.

Důležité je i zjištění, jak často se controller vlastně používá. Síť ke svému běhu controller nepotřebuje. Switch a AP si po převzetí drží konfiguraci samy a Wi-Fi i VLAN fungují dál, i když controller vypnu. Intenzivně se používá jen při nastavování, potom občas při změnách a aktualizacích firmwaru. Nechávám ho přesto běžet trvale, protože dělá automatické zálohy konfigurace a sbírá statistiky.

Debian 13, i když ho TP-Link neuvádí

Podle oficiálního návodu TP-Link controller podporuje Ubuntu do verze 24.04 a Debian do verze 12. Ostatní kontejnery mám na Debianu 13 a chtěl jsem mít všechny stejně, aby se jednotně aktualizovaly. Debian 13 funguje, jen je potřeba počítat se dvěma rozdíly:

  • Java: Debian 13 už nemá v základních balíčcích Javu 17. Controller od verze 5.15.20 vyžaduje 64bitovou Javu 17 nebo novější, takže jsem použil OpenJDK 21.
  • MongoDB: tady jsem narazil na dvě nečekané pasti (jádro Proxmoxu a podpis repozitáře). Jejich řešení jsem rozepsal v samostatném článku MongoDB 8 nestartuje na Proxmoxu s jádrem 7.0.

Postup instalace

1. Kontrola CPU a šablona

Na hostiteli Proxmoxu jsem nejdřív ověřil podporu AVX a stáhl aktuální šablonu Debianu 13:

grep -m1 -o 'avx2\?' /proc/cpuinfo
pveam update
pveam available --section system | grep debian-13

2. Vytvoření kontejneru

Kontejner má 2 jádra, 3 GB RAM, 20 GB disk, pevnou IP adresu v LAN, běží bez oprávnění na hostitele (unprivileged) a spouští se po startu serveru. Zástupné hodnoty si nahraďte svými:

pct create CT_ID local:vztmpl/debian-13-standard_13.6-1_amd64.tar.zst \
  --hostname NAZEV_KONTEJNERU --cores 2 --memory 3072 --swap 512 \
  --rootfs local-lvm:20 \
  --net0 name=eth0,bridge=vmbr0,ip=192.0.2.20/24,gw=192.0.2.1 \
  --nameserver 192.0.2.1 --unprivileged 1 --features nesting=1 \
  --onboot 1 --password
pct start CT_ID

Proxmox při vytváření vypsal varování, že součet velikostí všech disků přesahuje kapacitu thin poolu. Nejde o chybu. Thin disky se plní postupně, takže to funguje, dokud skutečná obsazenost nedojde ke 100 %. Stačí ji občas zkontrolovat.

3. Java 21, JSVC a časové pásmo

Uvnitř kontejneru (pct enter CT_ID):

apt update && apt full-upgrade -y
timedatectl set-timezone Europe/Prague
apt install -y curl gnupg openjdk-21-jre-headless jsvc
java -version

Příkaz jsvc -help hlásí „Cannot locate Java Home“. Nevadí to, cestu k Javě mu předá controller při startu.

4. MongoDB

Controller potřebuje MongoDB ve verzi 4.4 až 8. Nakonec jsem použil MongoDB 7.0 instalovanou ručně z oficiálního repozitáře. Proč ne osmička a proč ručně, popisuji v navazujícím článku. Systémovou službu mongod jsem po ověření, že databáze startuje, zastavil. Controller si totiž spouští vlastní instanci MongoDB se svými daty.

5. Snapshot a instalace controlleru

Před instalací jsem udělal snapshot kontejneru, abych se mohl kdykoli vrátit:

pct snapshot CT_ID pred_omada_RRRRMMDD

Balíček .deb jsem stáhl z oficiální stránky ke stažení (TP-Link ho nově jmenuje „Omada Network Application“) a nainstaloval:

curl -fLo omada.deb "ODKAZ_NA_BALICEK_DEB"
dpkg -i omada.deb
tpeap status

Instalátor vypíše dvě upozornění: „Cannot locate Java Home“ a „JSVC is less than 1.1.0“. Obě jsou neškodná, instalace i start proběhnou v pořádku. První start trvá několik minut. Pak je controller dostupný v prohlížeči přes HTTPS na adrese kontejneru. Certifikát je vlastní, takže prohlížeč zobrazí varování.

6. Průvodce prvním nastavením

V průvodci jsem nastavil název, zemi, časové pásmo a lokální účet správce se silným heslem. Cloudový přístup přes TP-Link ID jsem vypnul, controller je dostupný jen z domácí sítě a ven ho nevystavuji. Přidání zařízení a nastavení Wi-Fi jsem v průvodci přeskočil. Převzetí AP totiž maže jejich nastavení a chtěl jsem ho udělat řízeně, viz Adopce Omada AP bez výpadku Wi-Fi.

Výsledek

Controller běží v LXC kontejneru s Debianem 13, Javou 21 a MongoDB 7.0. Spotřebuje zhruba 2 GB RAM a pod jeho správou jsou switch i oba přístupové body. Kontejner je zařazený do zálohovací úlohy Proxmoxu a controller si sám jednou týdně zálohuje konfiguraci. Podrobnosti o zálohách a aktualizacích popisuji v článku Aktualizace a zálohování Omada controlleru.

Shrnutí

  • Pro domácnost se serverem je Omada Software Controller nejlepší volba: zdarma, se všemi funkcemi a bez závislosti na cloudu.
  • LXC kontejner stačí. Jde vypnout, nic neinstaluje na hostitele a je úspornější než VM.
  • Debian 13 funguje, jen s Javou 21 místo 17 a s jinak řešenou MongoDB.
  • Controller není pro běh sítě nutný, ale hodí se kvůli zálohám, statistikám a jednotné správě.

Na tento článek navazují řešení problému s MongoDB 8, převzetí přístupových bodů bez výpadku Wi-Fi a VLAN pro IP kamery s MikroTikem a Omadou.