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:
| Varianta | Výhody | Nevýhody |
|---|---|---|
| Hardwarový controller (OC200 a vyšší) | samostatné zařízení, nic se neinstaluje | jednorázový výdaj, další krabička v rozvaděči |
| Omada Central Essentials (cloud, zdarma) | bez instalace | závislost na cloudu a účtu TP-Link, omezené funkce, správa sítě mimo domov |
| Omada Software Controller | zdarma, všechny funkce, data zůstávají doma | potřebuje server, kde poběží |
Server už doma běží, takže volba byla jasná: softwarový controller.

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-132. 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_IDProxmox 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 -versionPří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_RRRRMMDDBalíč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 statusInstalá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.