Šī ir raksta beigu daļa, šeit ir sākums
Iepriekšējo reizi rakstīju par to, kā ieviesu ierīču uzraudzību, tagad runāsim par pārvaldību. Sarunās ar “tehniķiem” no Klienta puses bieži sastopos ar ierobežotu priekšstatu par tik mazu ierīču iespējām (ar zemiem atmiņas resursiem un veiktspēju), daudzi uzskata, ka “visvairāk mums ir jānosūta reboot, lai kaut ko vairāk nopietni, mēs nosūtīsim komandu”.
Taču prakse rāda, ka tā nav gluži taisnība. Šeit ir neliels parasto tipisko uzdevumu saraksts:
- Tīkla diagnostika un problēmu novēršana. Aiz jūsu maršrutētāja Ethernet porta parasti atrodas cita aparatūra, kurai ir sava iekšējā IP adrese. Dažreiz jūs varat (vajadzētu) to "ping". Vai tuneļa pārvaldība - ja tunelis pēkšņi nepaceļas uz maršrutētāja, kas darbojas caur 3G modemu, bet mēs varam redzēt pašu rūteri.
- Sistēmas uzturēšana. Programmaparatūras atjauninājums, servisa skripta jauninājums.
- Līdzsvarošanas akts. To varētu saukt par "perversiju", bet jēdziens "ekvilibrists" kā, es citēju, "Cirka mākslinieka spēja saglabāt līdzsvaru nestabilā ķermeņa stāvoklī" - labāk der. Šādas situācijas rodas klienta ierobežotā budžeta dēļ. Zemāk es minēju pāris piemērus, bet... Tie nav tieši saistīti ar stāsta tēmu, ieliku piezīmēs
Wi-Fi uzraudzībaModes tēma pēdējo piecu gadu laikā, galvenokārt starp federālajām mazumtirdzniecības ķēdēm. Jūs nesteidzīgi staigājat pa tirdzniecības stāviem, un jūsu mobilais tālrunis ar ieslēgtu Wi-Fi, mēģinot “pieķerties” kādam tīkla pavedienam, regulāri izsūta Probe Request paketes, kuras var analizēt, lai aprēķinātu tu: cik bieži tu nāk uz šo veikalu, kādu iemeslu dēļ tu ej pa trajektorijām utt. Pēc tam tiek apkopoti, analizēti dati, sastādītas siltuma kartes, un vadītāji par šādām bildēm “izspiež” naudu no vadības vai investoriem. Nu pagaidām.... “nav naudas, bet turaties...”, un rezultāts (īsts) jau jārāda, sākas vecā labā dziesma: “Jā, jā, tad protams mēs uzstādīs cis un visu ko vēlies, bet tagad jāparāda Klientam rezultāts! Starp citu, mēs aizmirsām pateikt, ka Klients atļāva mums pieslēgt mūsu aprīkojumu savam karstajam punktam, izmantojot Wi-Fi, bet vispārīgi tā, it kā mēs būtu viesklienti. Un tāpēc mums ir jātaisa balansējošie maršrutētāji - tiek pacelti vairāki WiFi apakšinterfeisi, no kuriem viens pieķeras karstajam punktam, bet otrs uzrauga vidi, izmisīgi augšupielādē tcpdump rezultātu, pēc tam iepako faila saturu arhīvā un riskē. mirstot no “pārēšanās”, mēģina izspļaut FTP servera saturu. Nav pārsteidzoši, ka balansējošais maršrutētājs bieži “sabojājas” un kaut kā ir “jāatdzīvina” attālināti.
rādiussSituāciju ir vieglāk aprakstīt ar kaut ko līdzīgu šim klientam: "Mēs vēlamies decentralizētu karsto punktu tīklu, kas darbotos ar iekārtām, kuru modelis nav iepriekš zināms, izmantojot kanālus, bet kurus mēs vēl nezinām. Ak, mēs aizmirsām pateikt, mēs ne tikai vēlamies klientiem rādīt reklāmu, bet arī analizēt visu, kas atrodas ap vietu, kur ir uzstādīts tīklājs. Nē, mēs vēl nezinām, kāpēc, bet mēs to izdomāsim, nešaubieties, mēs varējām nākt klajā ar šo ideju.
Un nedrīkst aizmirst, ka daudzu iepriekš nezināmu apstākļu dēļ kontrole ir jāveic nestandarta apstākļos, kad nevaram pieslēgties maršrutētājam tieši caur IP: portu un esam spiesti vienkārši gaidīt darbību no tā. Ja mēs abstrahējamies, dialogu starp serveri un maršrutētāju var attēlot šādi:
- Maršrutētāju: Sveiki. Esmu tāds un tāds rūteris, vai man ir kādi uzdevumi?
- Serveris: rūteris tāds un tāds, es tevi reģistrēju, ka esi dzīvs. Šis ir izaicinājums: parādīt man komandas ifconfig rezultātu?
- Maršrutētāju: Sveiki. Esmu tāds un tāds rūteris, pēdējo reizi prasīji parādīt ifconfig rezultātu, lūk. Vai man ir kādi uzdevumi?
- Serveris: rūteris tāds un tāds, es tevi reģistrēju, ka esi dzīvs. Jums nav nekādu uzdevumu.
Interesantākais jautājums: kā attālais maršrutētājs var nosūtīt noteiktu informācijas daudzumu? Pēdējā daļā es aprakstīju, ka ierobežoto resursu dēļ maršrutētājam ir tikai “noņemts” wget, kas darbojas tikai caur GET un neko citu; nav FTP klienta vai curl. Precīzāk, mums ir nepieciešama universāla metode, neatkarīgi no attēla montāžas iezīmēm. Es izvēlējos izmantot wget. Precīzāk, kā es "apstājos" - man vienkārši nebija izvēles :)
Tikai atrunaMans pārvaldības risinājums darbojas, nav ļoti ierobežots, un esmu pārliecināts, ka tas ir greizs, pat ja tas ir piemērots lielākajai daļai manu klientu. Kā jūs to varētu izdarīt gudri - uzrakstiet nelielu utilītu, kas nosūta POST bināros datus caur portu 80. Iekļaujiet to (utilītu) maršrutētāja programmaparatūrā un piekļūstiet tai, izmantojot bash. Bet realitāte ir tāda, ka: a) mums ir ātri b) mums, iespējams, jādara viss esošajam "maršrutētāju zoodārzam" c) "nekaitēt!" — ja maršrutētājs strādā un veic citus uzdevumus, mēģiniet veikt izmaiņas, kas neietekmēs esošo funkcionalitāti.
Pāriesim pie īstenošanas. Pieņemsim, ka jūsu klients vēlas viegli un dabiski pārstartēt maršrutētāju no zabbix, noklikšķinot uz peles. Šodien mēs sāksim aprakstīt ieviešanu ar Zabbix.
Izvēlnē "Administrēšana" -> "Skripti" pievienojiet jaunu skriptu. Mēs to saucam par “Reboot”, ievadiet “php /usr/share/zabbix/reboot.php {HOST.HOST}” kā komandu.
Nākamais: Izvēlne “Uzraudzība” -> “Jaunākie dati” -> “Ar peles labo pogu noklikšķiniet uz vajadzīgā tīkla mezgla”. Šādi izvēlne izskatīsies pēc skripta pievienošanas.
Attiecīgi mēs ievietojām skriptu reboot.php direktorijā /usr/share/zabbix (jūsējais var atšķirties, es izmantoju zabbixa saknes direktoriju).
Drošības atrunaLai skaidrojums būtu skaidrāks skriptā, es izmantoju tikai maršrutētāja ID, bet neizmantoju paroli. Ražošanas versijā to darīt nav ieteicams! Kāpēc es to izdarīju: jo lielais jautājums ir, kur glabāt maršrutētāju paroles? Pašā zabbixe sadaļā “inventāra dati”? Pretrunīga prakse. Alternatīvi: ierobežojiet ārējo piekļuvi pašam reboot.php failam
Fails 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();
?>Tas ir viss. Jautājums paliek atklāts: "kā iegūt komandas izpildes rezultātu no ierīces." Apskatīsim uzdevumu, kā piemēru izmantojot komandu ifconfig. Šo komandu var nosūtīt uz ierīci:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, kur:
message=`ifconfig` — mēs piešķiram komandas ifconfig izvades rezultātu mainīgajam $message
wget " — mūsu a.php skripts, kas reģistrē maršrutētājus un saņem no tiem ziņojumus
u=lietotājs&p=parole!&m=$ziņa — akreditācijas dati un pieprasījuma mainīgā m vērtība — piešķir mainīgā $message saturu
-O /tmp/out.txt — šajā gadījumā mums nav nepieciešama izvade failā /tmp/out.txt, bet, ja šis parametrs nav norādīts, wget nedarbojas
Kāpēc tas nedarbojas?Jo tas ir potenciāls drošības caurums. Visnekaitīgākā kļūda, kas var notikt, ir, piemēram, ja komandas izvadē ir rakstzīme “&”. Tāpēc ir jāfiltrē gan viss, kas tiek sūtīts no maršrutētājiem, gan viss, kas nonāk serverī. Jā, man ir kauns, tiešām. Savā aizstāvībā varu tikai rakstīt, ka viss raksts ir veltīts tam, kā pārvaldīt maršrutētājus ar iepriekš definētu programmaparatūru un sakaru kanāliem, kas nav iepriekš definēti.
Nu, sākums nākotnei: es vēl neesmu izdomājis, kā izmantot standarta zabbix rīkus, lai atspoguļotu serverī nonākušos rezultātus (piemēram, komandas izpildes rezultātu).
Atgādinu, ka visus avotus var iegūt no Git repozitorija:
Avots: www.habr.com