syslog-ng e NOOP

[ZeroUno]

Salve.

Ho un syslog server (non gestito da me) a cui invio dei log con syslog-ng dalle mie macchine.

Avrei bisogno che periodicamente il syslog-ng invii tipo un noop per farlo funzionare tipo da keep-alive, senza fargli loggare niente.

Però non sono riuscito a trovare nessuna impostazione.


Qualcuno sa qualcosa?

[notsafe]

se è questo che ti serve (immagino che tu stia usando una sessione tcp e non udp)

keep-alive()- yes or no - Available for tcp() only; specifies whether connections should be closed upon the receipt of a SIGHUP signal.

[ZeroUno]

Si, l'ho provato, ma questo non fa quello che serve a me.
Questo semplicemente determina cosa fare in caso di "kill -SIGHUP" e serve più che altro per i syslog server.
In pratica se un server ha parecchie connessioni e do kill -SIGHUP per rileggere la configurazione, non disconnette i client che stanno trasmettendo se keep-alive è yes. Se è no si comporta come uno stop/start, in pratica, uccidendo tutti i client.

Sul mio client ho provato a metterlo sia in source sia in destination e dando kill -SIGHUP in entrambi i casi tcpdump mi dice

14:24:09.980531 IP 172.18.96.71.49896 > 150.54.9.226.9006: F 1:1(0) ack 1 win 46 <nop,nop,timestamp 2041806355 583697943>
14:24:09.981777 IP 150.54.9.226.9006 > 172.18.96.71.49896: F 1:1(0) ack 2 win 46 <nop,nop,timestamp 583762188 2041806355>
14:24:09.981810 IP 172.18.96.71.49896 > 150.54.9.226.9006: . ack 2 win 46 <nop,nop,timestamp 2041806356 583762188>
14:24:10.146069 IP 172.18.96.71.38252 > 150.54.9.226.9006: S 1212503744:1212503744(0) win 5840 <mss 1460,sackOK,timestamp 2041806520 0,nop,wscale 7>
14:24:10.146729 IP 150.54.9.226.9006 > 172.18.96.71.38252: S 2425753700:2425753700(0) ack 1212503745 win 5792 <mss 1460,sackOK,timestamp 583762229 2041806520,nop,wscale 7>


E comunque bisogna dare kill -SIGHUP manualmente, mentre io voglio che faccia da solo.




edit:
di suo sembrerebbe che syslog-ng già farebbe un invio ogni 5 minuti

13:06:45.400451 IP 150.54.9.226.9006 > 172.18.96.71.56673: . ack 10145 win 501 <nop,nop,timestamp 582601040 2036861691>
13:06:45.400472 IP 172.18.96.71.56673 > 150.54.9.226.9006: . ack 1 win 58 <nop,nop,timestamp 2037161695 581553722>
13:11:45.399664 IP 150.54.9.226.9006 > 172.18.96.71.56673: . ack 10145 win 501 <nop,nop,timestamp 582676040 2037161695>
13:11:45.399733 IP 172.18.96.71.56673 > 150.54.9.226.9006: . ack 1 win 58 <nop,nop,timestamp 2037461699 581553722>
13:16:45.398708 IP 150.54.9.226.9006 > 172.18.96.71.56673: . ack 10145 win 501 <nop,nop,timestamp 582751040 2037461699>
13:16:45.398735 IP 172.18.96.71.56673 > 150.54.9.226.9006: . ack 1 win 58 <nop,nop,timestamp 2037761704 581553722>

Ma non c'è nessun invio; quando c'è un invio si ha
13:22:21.336499 IP 172.18.96.71.56673 > 150.54.9.226.9006: P 10145:10315(170) ack 1 win 58 <nop,nop,timestamp 2038097648 581553722>
13:22:21.337356 IP 150.54.9.226.9006 > 172.18.96.71.56673: . ack 10315 win 501 <nop,nop,timestamp 582835025 2038097648>
che non c'è sopra

[masalapianta]

il protocollo syslog non prevede comandi noop (che attenzione, non hanno una funzione di keep alive, ma servono all'applicativo client per vedere se il server è vivo e se risponde in tempi accettabili); se però ti serve semplicemente un invio di dati a layer 7, che però non venga loggato dal server (a che scopo?), ti basta conoscere ad esempio una facility che non viene loggata ed utilizzare un cronjob con logger (loggando su quella facility ovviamente).

[notsafe]

il protocollo syslog non prevede comandi noop (che attenzione, non hanno una funzione di keep alive, ma servono all'applicativo client per vedere se il server è vivo e se risponde in tempi accettabili); se però ti serve semplicemente un invio di dati a layer 7, che però non venga loggato dal server (a che scopo?), ti basta conoscere ad esempio una facility che non viene loggata ed utilizzare un cronjob con logger (loggando su quella facility ovviamente).

ed effettivamente non ho capito lo scopo di tutto questo.
comunque si può fare tranquillamente anche usando un filtro match (impostando il syslog server in modo tale da scartare entry con quel determinato match)

[masalapianta]

comunque si può fare tranquillamente anche usando un filtro match (impostando il syslog server in modo tale da scartare entry con quel determinato match)

si, ci sono tanti modi per farlo oltre ad utilizzare una facility non loggata (con match() come hai fatto notare, oppure usando program() o message(), ecc..); ma avendo specificato che il log server non lo gestisce lui (senza contare che potrebbe non utilizzare syslog-ng), ho pensato fosse meglio una soluzione che non comportasse modifiche al server; inoltre il filtro match a livello computazionale è molto più pesante di uno sulla facility (difatti, laddove possibile, è sempre meglio preferire quest'ultimo)

[ZeroUno]

Intanto vi dico la necessità reale.

Il syslog-ng invia gli auth e authpriv (in pratica il /var/log/secure), quindi accessi ssh e comandi su

Tra il client e il server c'è un firewall (anzi, ben più di uno credo; come minimo sono 3 più un dnat, ma facciamo finta che sia uno solo).
Questo firewall ha impostato un DROP su timeout; cioè se una connessione è stabilità ma non fa traffico per un paio di giorni, questa viene droppata (attenzione, non killata o resettata... né il client né il server se ne accorgono e quindi rimane pending su ambo le macchine).
Per cui: se nessuno fa accesso ssh per un po' di tempo allora non si genera traffico; se non si genera traffico la connessione viene droppata.
Come workaround attuale (fino a che non avevamo capito il problema), il syslog server mi fornisce una lista di macchine che non ha loggato per 24 ore, e su queste viene manualmente restatato syslog-ng.
Dopo aver capito il problema abbiamo messo temporaneamente come workaround un comando in cron, che invia sulla facility auth un "--MARK--" che dice al firewall che la connessione funge.
L'altra soluzione che sto mettendo, è quella di mettere in cron un kill -HUP in crontab. Questo chiude la connessione e ne apre una nuova.

[masalapianta]

Tra il client e il server c'è un firewall (anzi, ben più di uno credo; come minimo sono 3 più un dnat, ma facciamo finta che sia uno solo).
Questo firewall ha impostato un DROP su timeout; cioè se una connessione è stabilità ma non fa traffico per un paio di giorni, questa viene droppata (attenzione, non killata o resettata... né il client né il server se ne accorgono e quindi rimane pending su ambo le macchine).

strano, non credo il firewall valuti l'idle sui dati nel layer 7 dei pacchetti, quindi o hai impostato /proc/sys/net/ipv4/tcp_keepalive_* a pene di segugio, oppure qualche folle ha deciso di progettare un log collector, che deve loggare i dati di autenticazione per rispondere a determinati requisiti di legge, per lavorare su udp (orrore); il che significa che i dati possono andar persi e che, oltre ad andare in giro in chiaro, non c'è mutua autenticazione tra client e server.

Per cui: se nessuno fa accesso ssh per un po' di tempo allora non si genera traffico; se non si genera traffico la connessione viene droppata.
Come workaround attuale (fino a che non avevamo capito il problema), il syslog server mi fornisce una lista di macchine che non ha loggato per 24 ore, e su queste viene manualmente restatato syslog-ng.
Dopo aver capito il problema abbiamo messo temporaneamente come workaround un comando in cron, che invia sulla facility auth un "--MARK--" che dice al firewall che la connessione funge.
L'altra soluzione che sto mettendo, è quella di mettere in cron un kill -HUP in crontab. Questo chiude la connessione e ne apre una nuova.

non vedo altre strade, a parte queste e quelle suggerite sopra

[ZeroUno]

non vedo altre strade, a parte queste e quelle suggerite sopra

Io invece ho rianalizzato completamente la mia analisi di cui sopra, e l'ho trovata completamente sballata.

Una premessa per capire un po' meglio la problematica.

Il fatto è che io gestisco le macchine che devono connettersi al syslog server, mentre chi gestisce il syslog server lo gestisce un gruppo che non conosco personalmente, solo qualche scambio di email.

La cosa credo che sia nata dal momento della prima configurazione del syslog che, non essendo ancora a puntino, non loggava correttamente o non loggava affatto. Poi la configurazione è stata aggiustata.
Tuttavia il gruppo del syslog server, monitorizzando i log raccolti, ci invia giornalmente l'elenco delle macchine che il giorno precedente non hanno effettuato log.
Pensando che questa sia una anomalia dovuta proprio ad un problema che il firewall troncava le connessioni per inattività (cosa effettivamente successa per altri servizi), o che non loggasse perchè non funzionasse il syslog, era entrata in procedura ormai che dell'elenco giornalmente inviato si facesse il restart del servizio syslog-ng, cosa che apparentemente risolveva il problema e difatti il giorno dopo la macchina non ricompariva nell'elenco perchè aveva loggato.

Non essendo io personalmente a fare i restart del syslog-ng non gli ho dato tanto peso (ero solo in copia nelle email). Ma dal momento che la gestione la faccio io, ho deciso che una analisi ed una soluzione va fatta.


Finita la premessa, mi sono messo a riconsiderare i dati secondo i quali avevo tirato fuori la diagnosi precedente e la ricerca della possibile soluzione.
Riconsiderati ancora i dati in mio possesso, ho pensato che invece sia il syslog-ng sia il firewall stanno funzionando correttamente, e non è vero che la connessione viene troncata o bloccata o che.
La macchina non invia log perchè semplicemente non ha log da inviare. Infatti il syslog-ng è configurato per inviare le connessioni ssh e i su. E se non ci si logga è normale che non viene inviato nessun log.
Il motivo per cui il restart del syslog-ng risolveva il problema? semplice... per restartarlo bisogna entrare in ssh; se entro in ssh si produce e viene inviato log.
La soluzione che avevo pensato, di mettere un kill -HUP in crontab, il quale avrebbe chiuso e riaperto la connessione, non avrebbe risolto niente.
La soluzione di inviare un MARK funziona ma non è bella.
Se non viene loggato niente per anche un mese, la connessione non può cadere perchè syslog-ng invia un pacchetto vuoto ogni 5 minuti (v. tcpdump precedente, mal interpretato).

Di conseguenza la soluzione finale qual'è?...
nessuna! il syslog funziona già correttamente così com'è.

Dal momento che l'analisi precedente l'ho fatta io ed è stata accettata come vera da tutti, e la soluzione del MARK l'ho proposta io e sembra essere stata accettata dal gruppo syslog server, aspetterò un po' prima di dire la vera verità. Per ora ho detto che non implemento la soluzione per tutto l'ambiente (per ora è solo su una macchina) con la spiegazione che "al momento sono impegnato in altre cose più importante " (che tra l'altro è verissimo ).

Ciao
01