Questa è l'ultima parte dell'articolo, ecco l'inizio
L'ultima volta ho scritto su come implementare il monitoraggio dei dispositivi, ora parleremo della gestione. Nelle discussioni con i 'tecnici' da parte del Cliente, mi imbatto spesso in una percezione limitata delle possibilità di questi piccoli dispositivi (con risorse di memoria e prestazioni basse); molti pensano che 'il massimo che ci servirà è inviare reboot, per qualcosa di più serio — invieremo una squadra'.
Ma la pratica dimostra che non è proprio così. Ecco un breve elenco di compiti tipici frequenti:
- Diagnostica di rete e risoluzione dei problemi. Dietro la porta ethernet del vostro router di solito 'vive' un altro dispositivo, con un suo indirizzo ip interno. A volte, può (deve) essere 'pingato'. O gestione del tunnel — se sul router, che funziona tramite un modem 3G, improvvisamente non si alza il tunnel, ma vediamo il router stesso.
- Manutenzione di sistema. Aggiornamento del firmware, upgrade di script di servizio.
- Equilibrista. Potrebbe essere definito come 'deviazioni', ma il concetto di 'equilibrista', come citato, «capacità dell'artista circense di mantenere l'equilibrio in una posizione instabile del corpo» — si adatta meglio. Situazioni simili si presentano a causa delle limitazioni di bilancio del cliente. Di seguito ho riportato un paio di esempi, ma poiché non hanno diretta attinenza con il tema della narrazione, li ho collocati in note.
Monitoraggio Wi-FiNegli ultimi cinque anni, questa è stata una tematica alla moda principalmente tra le reti di vendita al dettaglio federali. Passeggiando lentamente nei reparti, il tuo cellulare con Wi-Fi attivato, nel tentativo di 'attaccarsi' a qualche rete, invia regolarmente pacchetti Probe Request, che possono essere analizzati per contare la frequenza delle tue visite a questo negozio, le percorrenze che fai e così via. Successivamente, i dati vengono raccolti, analizzati, vengono generate mappe termiche e i manager utilizzano queste immagini per ottenere finanziamenti dalla direzione o dagli investitori. Ma, nel frattempo... 'non ci sono soldi, ma andate avanti...', e il risultato (reale) deve già essere mostrato, torna la vecchia e buona canzone 'Sì-sì, poi certo installeremo i sistemi e tutto quello che desiderate, ma ora dobbiamo mostrare il risultato al Cliente! A proposito, abbiamo dimenticato di dire che il Cliente ha autorizzato a collegare la nostra attrezzatura al suo hotspot tramite Wi-Fi, ma su base comune, proprio come se fossimo clienti ospiti'. Così ci tocca realizzare router-equilibristi — vengono attivati vari sottinterfacce Wi-Fi, una delle quali si collega all'hotspot e l'altra monitora l'ambiente circostante, scaricando freneticamente il risultato del tcpdump su se stesso, quindi il contenuto del file viene impacchettato in un archivio e, rischiando di soffocare da 'eccesso di cibo', cerca di scaricare il contenuto su un server FTP. Non è sorprendente che il router-equilibrista spesso 'cada' e debba essere 'rianimato' a distanza.
RadiusQui la situazione si può descrivere in modo più semplice con l'affermazione del cliente: «Vogliamo una rete decentralizzata di hotspot, che funzionino su dispositivi il cui modello non è noto in anticipo, attraverso canali che non conosciamo ancora. Ah, abbiamo dimenticato di dire che non vogliamo solo mostrare pubblicità ai clienti, ma anche analizzare tutto intorno al luogo di installazione dell'hotspot. No, al momento non sappiamo il motivo, ma troveremo una soluzione, non preoccupatevi, siamo stati in grado di concepire questa idea»
E non bisogna dimenticare che, a causa di molte circostanze inizialmente imprevedibili, la gestione deve avvenire in condizioni non standard, quando non possiamo connetterci direttamente al router tramite IP: porta e dobbiamo semplicemente aspettare un'attività da parte sua. Se ci astraiamo, il dialogo tra il server e il router può essere rappresentato così:
- Router: ciao. Io sono il router tale e quale, ci sono compiti per me?
- Server: router tale registrato, sei vivo. Ecco il compito: mostrami il risultato del comando ifconfig?
- Router: ciao. sono il router tale, l'ultima volta mi hai chiesto di mostrare il risultato di ifconfig, eccolo. Hai qualche compito per me?
- Server: router tale registrato, sei vivo. Non ci sono compiti per te.
La domanda più interessante: in che modo un router remoto può inviare una certa quantità di informazioni? Nella parte precedente ho descritto che sul router, a causa delle limitazioni delle risorse, c'è solo un wget 'tagliato' che funziona solo tramite GET e nient'altro, non ci sono né client FTP né curl. In effetti, abbiamo bisogno di un modo universale, indipendentemente dalle specificità della versione. Ho optato per l'uso di wget. Più precisamente, non è che 'ho optato' — semplicemente non avevo altre scelte 🙂
Una nota preliminareLa mia soluzione di gestione è funzionale, non eccessivamente limitata e sono sicuro — storta, anche se soddisfa la maggior parte dei miei clienti. Come si potrebbe fare in modo più appropriato — scrivere una piccola utilità che invia dati binari tramite POST sulla porta 80. Includerla (l'utilità) nel pacchetto firmware del router e poi interagirvi attraverso bash. Ma la realtà è che: a) dobbiamo fare in fretta b) forse dobbiamo fare tutto sull'attuale 'zoo di router' c) 'non nuocere!' — se il router funziona e svolge altre attività, cerca di apportare modifiche che non influenzino la funzionalità esistente.
Passiamo all'implementazione. Supponiamo che il tuo cliente voglia riavviare il router da zabbix in modo semplice e immediato, 'con un clic del mouse'. Oggi iniziamo a descrivere l'implementazione con zabbix.
Nel menu 'Amministrazione' -> 'Script' aggiungiamo un nuovo script. Lo chiamiamo 'Reboot', come comando scriviamo 'php /usr/share/zabbix/reboot.php {HOST.HOST}'
Successivamente: Menu 'Monitoraggio' -> 'Ultimi dati' -> 'Clic destro sul nodo di rete desiderato'. Questo sarà l'aspetto del menu dopo aver aggiunto lo script.
Di conseguenza, posizioniamo lo script reboot.php nella directory /usr/share/zabbix (potrebbe essere diversa per te, io utilizzo la directory principale di zabbix).
Nota di sicurezzaPer una spiegazione visiva nello script utilizzo solo l'id del router, ma non uso la password. Nella versione operativa non è consigliato farlo! Perché l'ho fatto: perché resta una grande domanda — dove memorizzare le password per i router? Nello stesso Zabbix nei "dati di inventario"? Pratica controversa. Come alternativa: limitare l'accesso esterno al file reboot.php
File reboot.php
set_charset("utf8");
// "Inviamo" il comando reboot modificando il campo task nella tabella users. Nel campo task è possibile inviare qualsiasi comando.
$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();
?>In sostanza è tutto. Rimane aperta la questione "come ottenere il risultato dell'esecuzione del comando dal dispositivo". Consideriamo il compito con l'esempio del comando ifconfig. Ecco un comando che possiamo inviare al dispositivo:
message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt, dove:
message=`ifconfig` — alla variabile $message assegniamo il risultato dell'output del comando ifconfig
wget " — il nostro script a.php, che registra i router e riceve messaggi da essi
u=user&p=password!&m=$message — le credenziali e il valore della variabile di query m — assegna il contenuto della variabile $message
-O /tmp/out.txt — l'output nel file /tmp/out.txt non ci è necessario in questo caso, ma se non specifichiamo questo parametro, wget non funziona
Perché questo funziona malePerché rappresenta una potenziale falla di sicurezza. L'errore più innocuo che può verificarsi è se nell'output del tuo comando, ad esempio, appare il simbolo "&". Pertanto, è necessario filtrare tutto ciò che viene inviato dai router e tutto ciò che arriva al server. Sì, mi vergogno, davvero. A mia discolpa posso solo dire — che l'intero articolo è dedicato a come gestire router con firmware non definito in anticipo, con canali di comunicazione non definiti in anticipo.
E ho fatto anche un passo verso il futuro: finora non ho capito come utilizzare gli strumenti standard di Zabbix per riflettere i risultati (ad esempio, il risultato dell'esecuzione del comando) che arrivano al server.
Ricordo che tutti i sorgenti possono essere prelevati dal repository Git all'indirizzo:
Fonte: habr.com
