Dette er den afsluttende del af artiklen, her er starten
Sidst skrev jeg om, hvordan jeg implementerede enhedsovervågning, nu skal det handle om styring. I diskussioner med 'teknikere' fra bestilleren støder jeg ofte på en begrænset opfattelse af mulighederne for sådanne små enheder (med begrænsede hukommelsesressourcer og ydeevne); mange mener, at 'det maksimale, vi har brug for, er at sende en genstart, til noget mere alvorligt - sender vi et team'.
Men erfaring viser, at dette ikke helt er tilfældet. Her er en lille liste over ofte typiske opgaver:
- Netværksdiagnostik og fejlfinding. Bag ethernetporten på din router lever der normalt et andet apparat, som har sin egen interne ip-adresse. Nogle gange kan det være nødvendigt at 'pinge' det. Eller tunnelstyring - hvis tunnelen på routeren, der kører via 3G-modem, pludselig ikke kan oprettes, men selve routeren er vi i stand til at se.
- Systemvedligeholdelse. Opdatering af firmware, opgradering af service-scripts.
- Ekvilibrisme. Dette kunne kaldes 'afvigelser', men begrebet 'ekvilibrisme' er mere passende, som jeg citerer, “evnen hos en cirkusartist til at opretholde balancen i en ustabil kropsposition” — passer bedre. Sådanne situationer opstår på grund af bestillerens begrænsede budget. Jeg har nævnt et par eksempler nedenfor, men da de ikke direkte relaterer til emnet, har jeg taget dem ud i noter.
Wi-Fi overvågningDet seneste modefænomen i de sidste fem år er hovedsageligt blandt de føderale detailhandelsnetværk. Du slentrer langsomt rundt i butikkerne, mens din mobil med Wi-Fi tændt forsøger at 'klæbe' sig til et eller andet netværk og regelmæssigt sender Probe Request-pakker, som kan analyseres med det formål at tælle, hvor ofte du besøger denne butik, hvilke ruter du går, og så videre. Herefter indsamles dataene, analyseres, tegnes varmekort, og cheferne får penge fra ledelsen eller investorerne for disse visualiseringer. Men indtil da... 'Der er ingen penge, men hold ud...', og resultatet (det reelle) skal allerede vises, så den gamle gode sang bliver aktiveret: 'Ja, ja, senere vil vi selvfølgelig opsætte dit udstyr og alt hvad I ønsker, men lige nu skal vi vise resultater til kunden! Forresten, vi glemte at sige, at kunden har tilladt os at forbinde vores udstyr til hans hotspot via Wi-Fi, men på generel basis, bare som om vi var gæstekunder.' Så man ender med at lave routere, der er akrobater — flere WiFi-undergrænseflader aktiveres, hvoraf en forbinder til hotspot'et, og den anden overvåger omgivelserne, hurtigt uploader tcpdump-resultatet, pakker filens indhold i et arkiv og risikerer at 'eksplodere' af 'overædning', mens den forsøger at sende indholdet til FTP-serveren. Det er ikke overraskende, at akrobat-routeren ofte 'går ned' og skal 'genoplivets' på afstand.
RadiusHer kan situationen beskrives mere enkelt med kundens udsagn: "Vi vil have et decentralt netværk af hotspots, der fungerer på udstyr, hvis model ikke er kendt på forhånd, gennem kanaler, men hvilke ved vi endnu ikke. Åh, vi glemte at nævne, at vi ikke blot vil vise reklamer til kunderne, men også analysere alt omkring installationsstedet for hotspot'et. Nej, vi ved endnu ikke hvorfor, men vi finder på noget, det er der ingen tvivl om, vi kunne jo finde på denne idé."
Og man må ikke glemme, at på grund af en masse uforudsigelige omstændigheder skal styringen foregå under ikke-standardiserede forhold, hvor vi ikke kan forbinde til routeren direkte via IP: port og er nødt til blot at vente på aktivitet fra den. Hvis vi abstraherer, kan dialogen mellem serveren og routeren præsenteres således:
- Router: hej. jeg er routeren, er der nogen opgaver til mig?
- Server: router sådan, jeg har registreret dig, så du er i live. Her er opgaven: vis mig resultatet af kommandoen ifconfig?
- Router: hej. jeg er router sådan, sidste gang bad du om at vise resultatet af ifconfig, her er det. Er der opgaver til mig?
- Server: router sådan, jeg har registreret dig, så du er i live. Der er ingen opgaver til dig.
Det mest interessante spørgsmål: hvordan kan en fjernrouter sende et bestemt volumen information? I den tidligere del beskrev jeg, at routeren kun har et "forkortet" wget på grund af begrænsede ressourcer, som kun fungerer via GET og ikke mere, der er ingen ftp-klient eller curl. Mere præcist, vi har brug for en universel metode, uafhængigt af image-konfigurationens særpræg. Jeg stoppede ved at bruge wget. Nærmere bestemt, hvordan jeg "stoppede" — jeg havde simpelthen ikke noget valg 🙂
En hurtig bemærkningMin løsning til styring fungerer, er ikke alt for begrænset, og jeg er sikker på — den er skæv, selvom den tilfredsstiller de fleste af mine kunder. Hvordan man RIGTIGT kunne gøre det — skrive et lille værktøj, der sender binære data via POST på port 80. Inkludere dét (værktøjet) i routerens firmware og derefter tilgå det via bash. Men virkeligheden er sådan, at: a) vi skal hurtigt b) vi skal muligvis gøre alt på den eksisterende "zoo af routere" c) "ikke skade!" — hvis routeren fungerer og udfører andre opgaver, prøv at foretage ændringer, som ikke påvirker den eksisterende funktionalitet.
Lad os gå videre til implementeringen. Lad os sige, at din kunde vil genstarte routeren fra zabbix let og uanstrengt, "med et klik med musen". I dag begynder vi beskrivelsen af implementeringen med zabbix.
I menuen "Administration" -> "Scripts" tilføjer vi et nyt script. Vi kalder det "Reboot", og som kommando skriver vi "php /usr/share/zabbix/reboot.php {HOST.HOST}"
Dernæst: Menuen "Overvågning" -> "Seneste data" -> "Højreklik på den ønskede netværksenhed". Sådan vil menuen se ud efter tilføjelsen af scriptet.
Scripts reboot.php placeres i kataloget /usr/share/zabbix (for dig kan det være et andet, jeg bruger zabbix's rodmappe).
Bemærkning for sikkerhedFor clarity in the script explanation, I use only the router ID but do not use a password. This is not recommended in the working version! Why I did this: because a big question is where to store passwords for routers? In Zabbix in the 'inventory data'? Controversial practice. As an option: restrict external access to the reboot.php file itself.
File reboot.php
set_charset("utf8");
// "Send" the reboot command by changing the task field of the users table. Any command can be sent in the task field.
$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();
?>That's all. The question remains open: 'how to receive the result of the command execution from the device'. Let’s consider the task using the ifconfig command as an example. You can send the following command to the device:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, hvor:
message=`ifconfig` — we assign the output of the ifconfig command to the variable $message
wget " — our script a.php, which registers the routers and receives messages from them
u=user&p=password!&m=$message — credentials and the request variable m value assigns the contents of the variable $message
-O /tmp/out.txt — output to the file /tmp/out.txt is not needed in our case, but if this parameter is not specified, wget does not work
Why does this work poorly?Because this is a potential security hole. The most harmless mistake that can happen is if, for example, there is a symbol "&" in the output of your command. Therefore, you need to filter everything sent from the routers and everything that comes to the server. Yes, I’m ashamed, really. In my defense, I can only write that the entire article is dedicated to how to manage routers with undefined firmware and undefined communication channels.
Og så et skridt mod fremtiden: jeg har endnu ikke fundet ud af, hvordan jeg med standardfunktioner i Zabbix kan vise de resultater (for eksempel udførelsen af en kommando), der kommer ind på serveren.
Husk, at alle kildefiler kan hentes fra Git-repositoriet på adressen:
Kilde: habr.com
