See on artikli viimane osa, siin on algus
Viimati kirjutasin, kuidas seadmete monitooringut juurutasin, nüüd räägime juhtimisest. Aruteludes kliendipoolsete "tehnikutega" kohtan sageli piiratud arusaama selliste väikeste seadmete (madala mäluressursi ja jõudlusega) võimalustest, paljud usuvad, et "maksimaalne, mida me vajame, on saata taaskäivitus , millegi tõsisema jaoks - saadame brigaadi" .
Kuid praktika näitab, et see pole täiesti tõsi. Siin on väike loend tavalistest tüüpilistest ülesannetest:
- Võrgu diagnostika ja tõrkeotsing. Teie ruuteri Etherneti pordi taga elab tavaliselt veel üks rauatükk, millel on oma sisemine IP-aadress. Mõnikord võib (peaks) seda "pingida". Või tunnelihaldus - kui tunnel 3G-modemi kaudu töötaval ruuteril järsku ei tõuse, vaid näeme ruuterit ennast.
- Süsteemi teenus. Püsivara värskendus, teenindusskriptide uuendamine.
- Ekvilibristika. Seda võiks nimetada "perversioonideks", kuid mõiste "köielkõndija" nagu ma tsiteerin "tsirkuseartisti võime säilitada tasakaal ebastabiilses kehaasendis" - sobib paremini. Sellised olukorrad tekivad kliendi piiratud eelarve tõttu. Allpool tõin paar näidet, aga kuna need ei ole otseselt loo teemaga seotud, panin need märkmetesse
wifi jälgimineViimase viie aasta moekas teema, peamiselt föderaalsete jaekettide seas. Kõnnite aeglaselt mööda kauplemispõrandaid ja teie sisselülitatud WiFi-ga mobiiltelefon saadab võrgu mõne lõime külge "kleepumiseks" regulaarselt välja Probe Request pakette, mida saab teie eest arvutamiseks analüüsida. : kui tihti sa sellesse poodi tuled, mis trajektooridel kõnnid jne. Edasi kogutakse, analüüsitakse andmeid, koostatakse soojuskaarte ja juhid “koputavad” selliste piltide eest juhtkonnalt või investoritelt raha välja. Vahepeal .... “raha pole, aga pea vastu ...”, ja tulemust (päris) peaks juba näitama, vana hea laul “Jah, jah, siis loomulikult tarnime ciscosid ja mida iganes sa tahad, aga nüüd peame kliendile tulemust näitama! Muide, nad unustasid öelda, et Klient lubas meie seadmeid WiFi kaudu oma hotspotiga ühendada, kuid üldiselt, just nagu oleksime külaliskliendid. Ja nüüd tuleb teha ekvilibristid ruuterid - tõuseb mitu WiFi alamliidest, millest üks klammerdub hotspoti külge ja teine jälgib keskkonda, laadib meeletult endasse tcpdumpi tulemuse, siis pakib faili sisu arhiivi ja riskib surra "ülesöömise" tõttu, kui üritate sisu ftp-serverisse välja sülitada. Pole üllatav, et ekvilibristlik ruuter sageli "katki läheb" ja seda tuleb kuidagi eemalt "reanimeerida".
raadiusSiin on olukorda lihtsam kirjeldada sellise kliendi avaldusega: “Soovime detsentraliseeritud levialade võrgustikku, mis töötaks kanalite kaudu seadmetel, mille mudel pole ette teada, kuid milliseid me veel ei tea. Oh, me unustasime öelda, et me ei taha mitte ainult klientidele reklaame näidata, vaid ka analüüsida kõike leviala installisaidil. Ei, me ei tea veel, miks, aga me mõtleme selle välja, ärge kõhelge, me suutsime selle idee välja mõelda. ”
Ja me ei tohi unustada, et eelnevalt paljude ebakindlate asjaolude tõttu tuleb haldamine läbi viia ebastandardsetes tingimustes, mil me ei saa ruuteriga otse ip: pordi kaudu ühendust luua ja oleme sunnitud lihtsalt ootama, millal tegevus ilmub seda. Kui teeme abstraktse, saab serveri ja ruuteri dialoogi esitada järgmiselt:
- Ruuter: Tere. Olen selline ja selline ruuter, kas mulle on mingeid ülesandeid?
- Server: selline ja selline ruuter, registreerisin teile, et olete elus. Siin on väljakutse: näidata mulle käsu ifconfig väljundit?
- Ruuter: Tere. Ma olen selline ja selline ruuter, viimati palusid näidata ifconfigi tulemust, siin see on. Kas mulle on ülesandeid?
- Server: selline ja selline ruuter, registreerisin teile, et olete elus. Teie jaoks pole ülesandeid.
Kõige huvitavam küsimus on: kuidas saab kaugruuter saata teatud hulga teavet? Viimases osas kirjeldasin, et piiratud ressursside tõttu on ruuteril ainult “ribistatud” wget, mis töötab ainult läbi GET-i ja mitte midagi muud, ftp klienti ega curli pole. Täpsemalt vajame universaalset viisi, olenemata pildikoostu omadustest. Ma otsustasin kasutada wgetit. Täpsemalt, kuidas “peatus” - mul lihtsalt polnud valikut 🙂
Kohe broneeringMinu halduslahendus töötab, mitte väga piiratud, ja olen kindel, et see on viltu, isegi kui see sobib enamikule mu klientidest. Kuidas oleks võimalik seda targalt teha - kirjutage väike utiliit, mis saadab binaarandmeid POST-i kaudu läbi 80. pordi. Lisage see (utiliit) ruuteri püsivarasse ja kasutage sellele juurdepääsuks bashi. Kuid reaalsus on see, et: a) peate kiiresti b) peate tõenäoliselt tegema kõik olemasolevas "ruuterite loomaaias" c) "ära kahjusta!" - kui ruuter töötab ja täidab muid ülesandeid, proovige teha muudatusi, mis ei mõjuta olemasolevat funktsionaalsust.
Liigume edasi rakendamise juurde. Oletame, et teie klient soovib, et zabbix taaskäivitaks ruuteri lihtsalt ja loomulikult, „hiireklõpsuga”. Täna alustame rakenduse kirjeldust zabbixiga.
Menüüs "Administreerimine" -> "Skriptid" lisage uus skript. Nimetame seda "Reboot", käsuna kirjutame "php /usr/share/zabbix/reboot.php {HOST.HOST}".
Järgmiseks: Menüü "Jälgimine" -> "Viimased andmed" -> "Paremklõps soovitud hostil". Selline näeb menüü välja pärast skripti lisamist.
Vastavalt sellele panime skripti reboot.php kataloogi /usr/share/zabbix (teie puhul võib see erineda, mina kasutan zabbixa juurkataloogi).
Ohutustest loobumineSkripti selgituse huvides kasutan ainult ruuteri ID-d, kuid ei kasuta parooli. Tööversioonis pole see soovitatav! Miks ma seda tegin: kuna suur küsimus on, kuhu ruuterite paroole salvestada? Zabbixe'is endas "inventaris"? Vastuoluline praktika. Võimalusena: piirata välist juurdepääsu failile reboot.php endale
reboot.php faili
<?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();
?>Tegelikult kõike. Küsimus “kuidas saada seadme poolelt käsu täitmise tulemus” jääb lahtiseks. Vaatleme ülesannet, kasutades näitena käsku ifconfig. Seadmele saab saata järgmise käsu:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txtkus:
message=`ifconfig` - määrame käsu ifconfig väljundi tulemuse muutujale $message
wget " - meie a.php skript, mis registreerib ruuterid ja võtab neilt vastu sõnumeid
u=kasutaja&p=parool!&m=$sõnum - volikirjad ja päringumuutuja m väärtus - määrab $message muutuja sisu
-O /tmp/out.txt - me ei vaja sel juhul väljundit faili /tmp/out.txt, kuid kui seda parameetrit pole määratud, siis wget ei tööta
Miks see valesti töötabSest see on potentsiaalne turvaauk. kõige kahjutum viga, mis võib juhtuda, on see, kui teie käsu väljund sisaldab näiteks sümbolit "&". Seetõttu on vaja filtreerida kõik, mis ruuteritest saadetakse ja kõik, mis serverisse tuleb. Jah, mul on häbi, tõesti. Oma kaitseks võin ainult kirjutada, et kogu artikkel on pühendatud sellele, kuidas hallata määratlemata püsivara ja määratlemata sidekanalitega ruutereid.
Noh, ma puudutasin tulevikku: ma pole veel aru saanud, kuidas standardsete zabbixi tööriistade abil serverisse saabuvaid tulemusi (näiteks käsu täitmise tulemust) kajastada.
Tuletan teile meelde, et kõiki allikaid saab võtta Giti hoidlast aadressil:
Allikas: www.habr.com