Toto je závěrečná část článku, zde je začátek
Minule jsem psal o tom, jak jsem implementoval monitoring zařízení, teď se budeme bavit o managementu. Při diskusích s „techniky“ ze strany Zákazníka se často setkávám s omezeným vnímáním možností takto malých zařízení (s nízkými paměťovými prostředky a výkonem), mnozí se domnívají, že „maximálně, co potřebujeme, je poslat restart , na něco vážnějšího - vyšleme brigádu“ .
Praxe ale ukazuje, že to není tak úplně pravda. Zde je malý seznam běžných typických úkolů:
- Diagnostika sítě a řešení problémů. Za ethernetovým portem vašeho routeru obvykle „žije“ další kus železa, který má svou vnitřní IP adresu. Někdy může (mělo by) být „pingnut“. Nebo správa tunelu – pokud se tunel náhle nezvedne na routeru pracujícím přes 3G modem, ale vidíme router samotný.
- Systémová služba. Aktualizace firmwaru, aktualizace servisních skriptů.
- Ekvilibristika. Dalo by se to nazvat „perverzemi“, ale pojem „provazochodec“ jako, cituji, "schopnost cirkusového umělce udržet rovnováhu v nestabilní poloze těla" - lépe sedí. Takové situace vznikají z důvodu omezeného rozpočtu zákazníka. Níže jsem uvedl pár příkladů, ale od nesouvisí přímo s tématem příběhu, uvádím je do poznámek
wifi monitoringMódní téma posledních pěti let hlavně mezi federálními obchodními řetězci. Pomalu se procházíte po obchodních parketech a váš mobilní telefon se zapnutou Wi-Fi ve snaze „přilepit“ se k nějakému vláknu sítě pravidelně odesílá pakety Probe Request, které lze analyzovat a vypočítat za vás : jak často do tohoto obchodu chodíte, po jakých trajektoriích chodíte a podobně. Dále se data sbírají, analyzují, kreslí tepelné mapy a manažeři za takové obrázky „vyklepávají“ peníze od managementu nebo investorů. Mezitím .... „peníze nejsou, ale vydrž...“, a výsledek (reálný) by se už měl ukázat, stará dobrá písnička „Ano, ano, pak samozřejmě dodáme cisco a co chcete, ale teď musíme zákazníkovi ukázat výsledek! Mimochodem, zapomněli říct, že zákazník povolil připojení našeho zařízení k jeho hotspotu přes Wi-Fi, ale obecně, stejně jako bychom byli hostujícími klienty. A teď musíte udělat ekvilibristické routery – zvedne se několik WiFi podrozhraní, z nichž jedno se přichytí k hotspotu a druhé monitoruje prostředí, zběsile do sebe stahuje výsledek tcpdump, pak zabalí obsah souboru do archivu a riskuje, že zemře z "přejídání" při pokusu vyplivnout obsah na ftp server. Není divu, že se ekvilibristický router často „rozbije“ a musí se nějak vzdáleně „oživit“.
PoloměrZde je jednodušší popsat situaci něčím takovým, jako je toto prohlášení zákazníka: „Chceme decentralizovanou síť hotspotů, která by fungovala na zařízeních, jejichž model není předem znám, prostřednictvím kanálů, ale která ještě neznáme. Oh, zapomněli jsme říct, že chceme nejen zobrazovat reklamy zákazníkům, ale také analyzovat vše kolem instalačního webu hotspotu. Ne, zatím nevíme proč, ale přijdeme na to, neváhejte, dokázali jsme to vymyslet."
A nesmíme zapomenout, že kvůli spoustě předem nejistých okolností musí být správa prováděna v nestandardních podmínkách, kdy se nemůžeme připojit k routeru přímo přes ip: port a jsme nuceni jednoduše čekat, až se objeví aktivita z to. Pokud abstrahujeme, pak dialog mezi serverem a routerem může být reprezentován takto:
- Směrovač: Ahoj. Jsem takový a takový router, jsou pro mě nějaké úkoly?
- Server: takový a takový router, zaregistroval jsem tě, že žiješ. Zde je výzva: ukažte mi výstup příkazu ifconfig?
- Směrovač: Ahoj. Jsem takový a takový router, minule jsi chtěl ukázat výsledek ifconfig, tady to je. Jsou pro mě úkoly?
- Server: takový a takový router, zaregistroval jsem tě, že žiješ. Nejsou pro vás žádné úkoly.
Nejzajímavější otázka zní: jak může vzdálený router odeslat určité množství informací? V minulém díle jsem popsal, že router má z důvodu omezených zdrojů pouze “odebraný” wget, který funguje pouze přes GET a nic jiného, není tam žádný ftp klient ani curl. Přesněji řečeno, potřebujeme univerzální způsob, bez ohledu na vlastnosti obrazové sestavy. Rozhodl jsem se používat wget. Přesněji řečeno, jak „zastaveno“ - prostě jsem neměl na výběr 🙂
Okamžitá rezervaceMoje řešení pro správu funguje, není příliš omezené a jsem si jistý, že je pokřivené, i když většině mých zákazníků vyhovuje. Jak by to bylo možné udělat moudře - napište malou utilitu, která posílá binární data přes POST přes 80. port. Zahrňte jej (utilitu) do firmwaru routeru a pro přístup k němu použijte bash. Realita je ale taková, že: a) je potřeba rychle b) asi je potřeba udělat vše na stávající "zoo routerů" c) "neškodit!" - pokud router funguje a provádí jiné úkoly, pokuste se provést změny, které neovlivní stávající funkčnost.
Přejděme k realizaci. Řekněme, že váš zákazník chce od zabbix restartovat router snadno a přirozeně pomocí „kliknutí myší“. Dnes začneme s popisem implementace se zabbixem.
V menu "Administrace" -> "Skripty" přidejte nový skript. Říkáme tomu "Reboot", jako příkaz napíšeme "php /usr/share/zabbix/reboot.php {HOST.HOST}"
Dále: Menu "Monitorování" -> "Nejnovější data" -> "Klikněte pravým tlačítkem myši na požadovaný hostitel". Takto bude menu vypadat po přidání skriptu.
Podle toho umístíme skript reboot.php do adresáře /usr/share/zabbix (u vás to může být jiné, já používám kořenový adresář zabbixa).
Bezpečnostní upozorněníPro srozumitelnost vysvětlení ve skriptu používám pouze id routeru, ale nepoužívám heslo. V pracovní verzi se to nedoporučuje! Proč jsem to udělal: protože velkou otázkou je, kam uložit hesla pro routery? V samotném zabbixe v "inventáři"? Protichůdná praxe. Jako možnost: omezit externí přístup k samotnému souboru reboot.php
soubor reboot.php
<?php
// присваиваем параметры с консоли переменным
$user = $argv[1];
// ВНИМАНИЕ. Вот здесь в целях безопасности все-таки прописывать пароль устройства! Но для демонстрации мы будем обращаться к базе данных без использования пароля.
//$password = $argv[2];
$conn=new mysqli("localhost","db_user","db_password","db_name");
if (mysqli_connect_errno()) {
exit();
}
$conn->set_charset("utf8");
// "Отправляем" команду reboot за счет изменения поля task таблицы users. В поле task можно отправлять любую команду.
$sql_users=$conn->prepare("UPDATE users SET task='reboot' WHERE id=? AND status='active';");
$sql_users->bind_param('s', $user);
$sql_users->execute();
$sql_users->close();
?>Vlastně všechno. Otázka „jak získat výsledek provedení příkazu ze strany zařízení“ zůstává otevřená. Zvažme úlohu pomocí příkazu ifconfig jako příklad. Do zařízení lze odeslat následující příkaz:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, kde:
message=`ifconfig` - do proměnné $message přiřadíme výsledek výstupu příkazu ifconfig
wget" - náš skript a.php, který registruje routery a přijímá od nich zprávy
u=uživatel&p=heslo!&m=$zpráva - přihlašovací údaje a hodnotu proměnné dotazu m - přiřadí obsah proměnné $message
-O /tmp/out.txt - v tomto případě nepotřebujeme výstup do souboru /tmp/out.txt, ale pokud tento parametr není zadán, wget nefunguje
Proč to funguje špatněProtože je to potenciální bezpečnostní díra. nejnebezpečnější chybou, která se může stát, je, pokud výstup vašeho příkazu například obsahuje symbol "&". Proto je nutné filtrovat vše, co se posílá z routerů a vše, co přichází na server. Jo, stydím se, opravdu. Na svou obranu mohu jen napsat, že celý článek je věnován tomu, jak spravovat routery s nedefinovaným firmwarem, s nedefinovanými komunikačními kanály.
No, dotkl jsem se budoucnosti: zatím jsem nepřišel na to, jak reflektovat výsledky (například výsledek provedení příkazu), které přicházejí na server pomocí standardních nástrojů zabbix.
Připomínám, že všechny zdroje lze převzít z úložiště Git na adrese:
Zdroj: www.habr.com