Ciao Nino, Si ci avevo pensato ma avevo un dubbio circa l'utilizzo di snmp e la sua configurazione.
La situazione è questa: Ci sono n nodi collegati lungo tutto il lungo mare ogni 3 nodi c'è un'adsl da 4 Mb ed infino c'è un server a pochi chilometri con un adsl dedicata che fa solo monitoring e log dei nodi e del traffico (meshboard/freeradius). Con questo voglio dire che i nodi non sono in lan con il server, quindi è possibile utilizzare snmp su questo scenario senza installare VPN? Se si avreste qualche doc che spieghi come configurare nodi e server? P.S. La rete al mare sta riuscuotendo un notevole succcesso, dunque per ringraziare la comunità del supporto sarei ben felice di mettere un link a ninux sul sito dell'associazione. Ciao Il giorno 24 luglio 2010 10.19, Nino <[email protected]> ha scritto: > Sembra il lavoro perfetto per le trap snmp. > Filippo, ci avevi pensato? > Se succede qualcosa al nodo, ti avverte immediatamente e a quel punto puoi > fare il poll snmp. > Ovviamente quello che non fanno e` rilevare la caduta completa di un nodo, > ma per esempio dovrebbero essere in grado di indicarti anche un calo di > tenzione dell`alomentazione etc... > Forse sarebbe la soluzione piu` standard per avvicinarsi al vero > monitoring. > Ciao > Nino > > Antonio Anselmi <[email protected]> ha scritto: > > >in questo caso credo che sul server ci sia una specie di "tolleranza", > >nel senso che se non ricevo beat per n- secondi di fila allora > >presumibilmente il nodo e' giu' (una specie di validity time alla > >olsr). Altrimenti, al primo beat perso il server potrebbe credere che > >il nodo sia a ramengo. > > > >Antonio > > > >Il 22 luglio 2010 16.53, Filippo Sallemi <[email protected]> ha scritto: > >> Per completezza, quello che dice Antonio è giusto, ma è utilie nella > >> situazione immediatamente successiva, ovvero inviare l'intero stato (o > altre > >> info) del nodo ad un entità centrale, per cui è necessario essere certi > che > >> arrivi e magari ricevere una risposta (robin update). > >> In generale io vedo come unica informazione del beat, il nodo che lo sta > >> mandando e nient'altro. > >> > >> ovviamente la parte server collezionerà una serie di pacchetti "beat" in > >> base ai quali saprà se il nodo c'è oppure no. > >> > >> Magari mi sbaglio ma a me pare cristallino. > >> > >> Ciao > >> > >> Il giorno 22 luglio 2010 16.47, Filippo Sallemi <[email protected]> ha > >> scritto: > >>> > >>> Sono daccordissimo con te Michele, non ho proprio voglia di reinventare > >>> l'acqua calda anche se in verità il programmino con il suo ciclo di > vita > >>> dovrebbe essere abbastanza facile da implementare e con pochi rischi di > >>> fallimento. > >>> > >>> In verità avrei voluto usare snmp per questo genere di cose ma non so > se > >>> in realtà è la scelta giusta. > >>> > >>> La scelta di UDP dipende da due fattori: > >>> > >>> Usare minor banda possibile; > >>> Non mi interessa se perdo qualche pacchetto, mi interessa solo dire > "hei > >>> ci sono" ogni tot secondi, dove tot è un numero veramente basso. > >>> > >>> Il software è pensato per una serie di applicazioni lato server e > >>> sicuramente non è sufficiente per fare monitoring dei nodi, ma > rappresenta > >>> un inizio... > >>> > >>> Filippo > >>> > >>> > >>> Il giorno 22 luglio 2010 16.42, Antonio Anselmi < > [email protected]> > >>> ha scritto: > >>>> > >>>> perche' non usare TCP? con UDP "spari e speri" che il beat arrivi a > >>>> destinazione, senza alcuna info sullo stato della connesiione > >>>> > >>>> Antonio > >>>> > >>>> Il 22 luglio 2010 14.45, Michele Favara Pedarsi <[email protected]> > >>>> ha scritto: > >>>> > Di heartbeat ce ne sono a iosa; da semplici script che pingano a > >>>> > soluzioni > >>>> > complesse. Cerca prima di sviluppare l'ennesima tecnologia > apposita... > >>>> > anche > >>>> > perche' stai facendo un sistema di monitoraggio, e come tale ha > bisogno > >>>> > di > >>>> > essere affidabile; se te lo fai da solo rischi di affidarti ad una > cosa > >>>> > che > >>>> > per essere affidabile deve prima fallire qualche volta per trovare i > >>>> > bug... > >>>> > a meno che non applichi i modelli di sviluppo piu' rigidi, con i > tempi > >>>> > che > >>>> > questi comportano... > >>>> > > >>>> > Una via di mezzo potrebbe essere quella di impiegare un qualsiasi > >>>> > socket > >>>> > server multithreaded generico gia' sviluppato - ie: esente da bachi > - a > >>>> > cui > >>>> > devi aggiungere solo quella pochissima logica che verifica l'arrivo > di > >>>> > un > >>>> > pacchetto ogni x secondi da y IP. > >>>> > > >>>> > ciao > >>>> > > >>>> > Michele > >>>> > > >>>> > > >>>> > > >>>> > Il giorno 22 luglio 2010 14.37, Filippo Sallemi <[email protected]> > ha > >>>> > scritto: > >>>> >> > >>>> >> Vi ringrazio per il supporto ragazzi, ed è tutto molto > interessante. > >>>> >> Il motivo per cui sto scrivendo questo piccolissimo software è > perchè > >>>> >> vorrei avere un heartbeat dei nodi da mandare ad un server, per il > >>>> >> solo > >>>> >> scopo di tenere sotto controllo lo stato dei nodi in tempo più > reale > >>>> >> possibile ma senza compromettere la banda. > >>>> >> > >>>> >> In verità penso che sia solo sufficiente mandare un beat al server > e > >>>> >> non > >>>> >> ricvere nulla nel caso specifico, ovviamente però potrei sbaglairmi > o > >>>> >> non > >>>> >> tenere conto di qualcosa che magari mi sfugge. > >>>> >> > >>>> >> So programmare in concorrenza, ma purtroppo la mia poca esperienza > di > >>>> >> concorrenza viene da mondo java universitario. > >>>> >> > >>>> >> Se pensate che quello che sto facendo sia inutile o interesante vi > >>>> >> prego > >>>> >> di farmelo sapere non voglio reinventare l'acqua calda. > >>>> >> > >>>> >> Ciao e grazie ancora > >>>> >> > >>>> >> Il giorno 22 luglio 2010 11.54, <[email protected]> ha scritto: > >>>> >>> > >>>> >>> Ciao. > >>>> >>> La rcvfrom e' una chiamata bloccante, quindi o usi la sottocitata > >>>> >>> select > >>>> >>> o entri nel fantastico mondo dei thread e della programmazione > >>>> >>> concorrente... > >>>> >>> > >>>> >>> Clauz > >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> On 07/22/2010 01:54 AM, ZioPRoTo (Saverio Proto) wrote: > >>>> >>> > Consiglio questa lettura: > >>>> >>> > http://beej.us/guide/bgnet/output/html/multipage/index.html > >>>> >>> > > >>>> >>> > nello specifico: > >>>> >>> > > >>>> >>> > > http://beej.us/guide/bgnet/output/html/multipage/advanced.html#select > >>>> >>> > > >>>> >>> > Saverio > >>>> >>> > > >>>> >>> > > >>>> >>> > Il 21 luglio 2010 19.05, Filippo Sallemi <[email protected]> > ha > >>>> >>> > scritto: > >>>> >>> >> Ciao ragazzi, > >>>> >>> >> sto giocherellando un po con C e stavo provando a scrivere un > >>>> >>> >> piccolo > >>>> >>> >> programma che manda pacchetti UDP ad un host solo che ho notato > >>>> >>> >> che la > >>>> >>> >> funzione rcvfrom resta bloccata finchè il server non manda una > >>>> >>> >> risposta > >>>> >>> >> anche vuota. > >>>> >>> >> > >>>> >>> >> Parte del codice esegue questo: > >>>> >>> >> > >>>> >>> >> read = sendto(sock, str, strlen(str), 0, (struct sockaddr > *)&addr, > >>>> >>> >> sizeof(addr)); > >>>> >>> >> if (read < 0) { > >>>> >>> >> perror("Request error"); > >>>> >>> >> return -1; > >>>> >>> >> } > >>>> >>> >> > >>>> >>> >> read = recvfrom(sock, buffer, MAXLINE, 0, NULL, NULL); > >>>> >>> >> if (read < 0) { > >>>> >>> >> perror("Read error"); > >>>> >>> >> return -1; > >>>> >>> >> } > >>>> >>> >> > >>>> >>> >> /** > >>>> >>> >> * Print results > >>>> >>> >> **/ > >>>> >>> >> if (read > 0) { > >>>> >>> >> buffer[read]=0; > >>>> >>> >> if (fputs(buffer, stdout) == EOF) { > >>>> >>> >> perror("fputs error"); > >>>> >>> >> return -1; > >>>> >>> >> } > >>>> >>> >> } > >>>> >>> >> > >>>> >>> >> Ho provato a usare le fnctl per impostare la socket in modo non > >>>> >>> >> bloccante ma > >>>> >>> >> ottengo solo l'uscita dal programma e nessun invio di > pacchetti. > >>>> >>> >> > >>>> >>> >> Adesso non è che mi importi tanto avere una risposta dal server > e > >>>> >>> >> potrei > >>>> >>> >> ovviare al problema eliminando la parte di codice dove aspetto > >>>> >>> >> risposta, ma > >>>> >>> >> la mia curiosità dal punto di vista didattico rimane. > >>>> >>> >> Qualcuno saprebbe illuminarmi in qualche modo? > >>>> >>> >> > >>>> >>> >> Grazie > >>>> >>> >> > >>>> >>> >> Ciao > >>>> >>> >> > >>>> >>> >> -- > >>>> >>> >> Filippo Sallemi > >>>> >>> >> > >>>> >>> >> _______________________________________________ > >>>> >>> >> Wireless mailing list > >>>> >>> >> [email protected] > >>>> >>> >> http://ml.ninux.org/mailman/listinfo/wireless > >>>> >>> >> > >>>> >>> >> > >>>> >>> > _______________________________________________ > >>>> >>> > Wireless mailing list > >>>> >>> > [email protected] > >>>> >>> > http://ml.ninux.org/mailman/listinfo/wireless > >>>> >>> > >>>> >>> _______________________________________________ > >>>> >>> Wireless mailing list > >>>> >>> [email protected] > >>>> >>> http://ml.ninux.org/mailman/listinfo/wireless > >>>> >> > >>>> >> > >>>> >> > >>>> >> -- > >>>> >> Filippo Sallemi > >>>> >> > >>>> >> _______________________________________________ > >>>> >> Wireless mailing list > >>>> >> [email protected] > >>>> >> http://ml.ninux.org/mailman/listinfo/wireless > >>>> >> > >>>> > > >>>> > > >>>> > _______________________________________________ > >>>> > Wireless mailing list > >>>> > [email protected] > >>>> > http://ml.ninux.org/mailman/listinfo/wireless > >>>> > > >>>> > > >>>> _______________________________________________ > >>>> Wireless mailing list > >>>> [email protected] > >>>> http://ml.ninux.org/mailman/listinfo/wireless > >>> > >>> > >>> > >>> -- > >>> Filippo Sallemi > >> > >> > >> > >> -- > >> Filippo Sallemi > >> > >_______________________________________________ > >Wireless mailing list > >[email protected] > >http://ml.ninux.org/mailman/listinfo/wireless > _______________________________________________ > Wireless mailing list > [email protected] > http://ml.ninux.org/mailman/listinfo/wireless > -- Filippo Sallemi
_______________________________________________ Wireless mailing list [email protected] http://ml.ninux.org/mailman/listinfo/wireless
