Correzione di errori nello scheduling di comandi mediante cron in Debian

luglio 23rd, 2010 glycerin

 Correzione di errori nello scheduling di comandi mediante cron in Debian
 Powered by Max Banner Ads 

Per noi amministratori risulta necessario settare dei cron, ovvero comandi ripetuti a specifici orari e/o giorni, che generalmente possono corrispondere a degli script in bash.

Una cosa che a volte mi capita è di dover settare un nuovo cron all’interno di /etc/cron.d e accorgermmi dopo di un errore nel setting di questo cron.
La cosa risulta evidente andando a controllare il relativo log (in /var/log/cron.log) e notare delle segnalazioni di questo tipo:

Jul 22 12:51:01 host_test /usr/sbin/cron[6663]: (*system*cron_modificato) RELOAD (/etc/cron.d/cron_modificato)
Jul 22 12:51:01 host_test cron[6663]: Error: bad minute; while reading /etc/cron.d/cron_modificato

La difficoltà che ho sempre riscontrato non è di dover sistemare l’errore, dovuto magari a un copia e incolla sbagliato. Perchè anche se corretto l’indomani mattina, in genere, ho l’amara sorpresa di vedere che il cron non ha fatto il suo dovere.
Un workaround che ho trovato e testato è un procedimento un pò laborioso che comporta la perdita di almeno 4 minuti fra i vari step necessari.

Di seguito gli step seguiti:
1. Spostare il cron dalla directory /etc/cron.d in altra directory e controllare in /var/log/cron.log il normale lavoro del daemon.

2. Ricollocare il cron in /etc/cron.d, come era in origine e ricontrollare in /var/log/cron.log il normale lavoro del daemon.

3. Inserire una riga “dummy” utile soltanto al RELOAD del cron come ad esempio la seguente

27 6 * * * user #dummy row per il controllo del successivo RELOAD

ovviamente l’orario deve essere posto a un valore diverso dall’attuale altrimenti il comando verrebbe lanciato anche se l’uso del “#” dovrebbe evitare complicazioni.

Se tutto è corretto dovremmo trovare nel cron.log la seguente riga…

Jul 23 10:42:01 host_test /usr/sbin/cron[6663]: (*system*cron_modificato) RELOAD (/etc/cron.d/cron_modificato)

4. Si cancella la riga “dummy” inserita e si controlla sempre nel cron.log il successivo RELOAD

Jul 23 10:44:01 host_test /usr/sbin/cron[6663]: (*system*cron_modificato) RELOAD (/etc/cron.d/cron_modificato)

La procedura è abbastanza lunga e doverlo fare su varie macchine comporta perdere del tempo, ma finora dalle prove fatte non ho trovato altri workaround.
Ovviamente apprezzerò moltissimo suggerimenti migliorativi.

Technorati Tags: cron, /etc/cron.d, log

 Correzione di errori nello scheduling di comandi mediante cron in Debian
share save 171 16 Correzione di errori nello scheduling di comandi mediante cron in Debian

Posted in Debian, Linux, News | No Comments »

Riconoscere i sistemi remoti con la tecnica del Fingerprinting utilizzando i Log del Firewall

agosto 7th, 2009 glycerin

L’articolo del SANS institute mette in mostra una prima tecnica per capire, con un margine di errore non piccolo, che tipo di sistema è stato utilizzato per raggiungere la nostra macchina che stiamo monitorando o proteggendo. Il tutto si basa sul TTL, che è facilmente modificabile, ed è per questo che direi che la tecnica può essere considerata un primo approccio ma non la soluzione a come determinare il tipo di OS del sistema remoto.

Link: https://blogs.sans.org/computer-forensics/2009/08/06/fingerprinting-systems-with-firewall-logs/

 Riconoscere i sistemi remoti con la tecnica del Fingerprinting utilizzando i Log del Firewall

share save 171 16 Riconoscere i sistemi remoti con la tecnica del Fingerprinting utilizzando i Log del Firewall

Posted in News, Security | No Comments »