Correzione di errori nello scheduling di comandi mediante cron in Debian

Luglio 23rd, 2010 glycerin

 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

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

Posted in Debian, Linux, News | No Comments »

Recording di una Shell Session

Giugno 18th, 2010 glycerin

Un comando per il recording di una sessione di Shell è “script” che viene in aiuto soprattutto se si vuole provare e/o ricordare ciò che si è fatto. In particolare per uno script bash una sintassi è:

script -c ./script_bash.sh log.sessione

dove log.sessione è semplicemente il nome file sul quale memorizzare le varie azioni.

P.S.: Una forma più furba di nominare il file di log, soprattutto per lavori su più server è:

script -c ./script_bash.sh log_`cat /etc/hostname`_`date +”%d%m%Y_%H%M%S”`

Technorati Tags: bash, script, shell recording

Posted in Debian, Linux, News | No Comments »

[OT] Breve descrizione della mia attuale occupazione .. il lavoro più brutto al mondo

Giugno 10th, 2010 glycerin

 Powered by Max Banner Ads 

Lo so .. è OT ma quando l’ho letta ho pensato che questa sarebbe da stampare e da incorniciare per cui la allego al mio blog.
Al terzo paragrafo estenderei la tipologia di prodotto per un unico vendor molto conosciuto a tutti i vendor commerciali o meno che producono un prodotto informatico ….
I miei complimenti all’autore.
Ringrazio il carissimo amico che mi ha fatto conoscere questa fantastica descrizione.

Buona lettura …

Il lavoro più brutto al mondo
Faccio un lavoro in cui devi essere sempre disponibilie
perché i sistemi devono funzionare 24 ore su 24 per 365
giorni all’anno; a ferragosto non trovi l’idraulico ma trovi
me (se trovi l’idraulico, costa molto più di me).

Posted in News | No Comments »

“System Services update required” al boot di un server PE R710

Giugno 9th, 2010 glycerin

Provando a far fare un upgrade dei firmware di una R710 Dell serie PowerEdge mi è capitata la scritta in oggetto al boot della macchina e, di fatto, mi era impossibile entrare nel menu dei “System Services“, di solito premendo il tasto F10.
Ovviamente mi sono affidato a un buon motore di ricerca per cercare di capire la segnalazione e finalmente ne è uscito fuori un documento della DELL riguardante i “Dell Unified Server Configurator (USC)” che in soldoni contiene le info per ripristinare il tutto. L’unico problema che ho incontrato è alla voce sul tool da scaricare dall’FTP alla sezione LifecycleController  della Dell. Alla fine ho optato per la release “USC_1.3.0_Rep_Pack_A00.usc” che tra l’altro dava una data di aggiornamento recente.
In soldoni, come spiegato ben bene nel documento ho uploadato il file con estensione usc via iDRAC direttamente sul server per poi farlo ripartire una volta che l’upload ha dato esito positivo. Una volta restartata la macchina ho seguito il consiglio di upgradare via System Services i rimanenti firmware anche se l’upgrade del BIOS dalla release 1.0.4 alla 2.0.13 non è stato possibile per errore nelle signature di un file con estensione efi; cosa appurata dopo vari restart.

P.S.: Piccolo aggiornamento
Ho riprovato la procedura di upgrade del BIOS via “System Services“. In pratica nel pannello di scelta di opzioni degli aggiornamenti possibili vi era soltanto l’upgrade del BIOS e stavolta tutto è proceduto correttamente. Finalmente sulla R710 vi è installato la versione 2.0.13 del BIOS. Piccolo inconveniente rispetto alla R610 sulla quale non sono stati riscontrati problemi di questo tipo.

Technorati Tags: DELL, R710, F10, USC

Posted in Linux, News | No Comments »

Ripristino della funzionalità della iDRAC

Giugno 3rd, 2010 glycerin

Avevamo visto come abilitare la remote console via iDRAC, passiamo ora al suo ripristino.

Via racadm vengono alterati i seguenti valori per ripristinarli ai valori di default (ovviamente tutte queste operazioni vengono fatte con un’utenza remota che non sto qui a specificare):

racadm config -g cfgSerial -o cfgSerialConsoleEnable 0
racadm config -g cfgIpmiSol -o cfgIpmiSolBaudRate 115200

Eventualmente lanciare un racreset ….
racadm racreset

Sulla macchina sulla quale è stata abilitata la remote console via iDRAC viene disabilitato il “Console Redirection After Boot”:
omconfig chassis biossetup attribute=crab setting=disabled

Controllare mediante un omreport chassis biossetup.

Infine nel file inittab della stessa vengono commentate le seguenti entry:

##for serial console
#7:2345:respawn:/sbin/getty 57600 hvc0
#8:23:respawn:/sbin/getty 57600 tty1

Far ripartire la macchina e controllare che il comportamento del “viewer” corrisponda ai comportamenti di default, ovvero possibilità di login e suo controllo.

Technorati Tags: drac, racadm, remote console

Posted in Debian, Linux, News, Virtualizzazione | No Comments »

Replicazione MySQL tra una LENNY e una ETCH Debian ed Error_code: 1105

Maggio 17th, 2010 glycerin

Mi è capitato di dover configurare una replicazione tra un server Debian Lenny e un altro ETCH sempre Debian e dover affrontare una problematica che descrivo di sguito.
Una volta realizzata la replicazione compare, nel daemon.log, una segnalazione che implica il dover skippare l’errore lato mysql per far sì che la replicazione tra i due host continui.
In pratica nel my.cnf viene aggiunta la seguente riga:

# inserito lo slave-skip-errors per rimediare alla incompatibilita tra
la versione 5.0.51 e la 5.0.32
slave-skip-errors=1105
#

che permette alla replicazione di andare avanti.
Sul daemon.log compare di continuo la riga allegata in basso e in ogni caso l’aggiungere questo parametro può essere considerata soltanto una soluzione tampone. Anche perchè nella casistica 1105 rientrano tutti gli errori classificati come unknown (http://dev.mysql.com/doc/refman/5.0/en/error-messages-server.html#error_er_unknown_error)

In ogni caso è bene leggere le warning presenti sul sito MySQL:
http://dev.mysql.com/doc/refman/5.0/en/replication-options-slave.html#option_mysqld_slave-skip-errors

Segnalazione del daemon.log:
May 17 18:11:10 host mysqld[27024]: 100517 18:11:10 [ERROR] Slave: According to the master’s version (’5.0.32-Debian_7etch11-log’), it is probable that master suffers from this bug: http://bugs.mysql.com/bug.php?id=24432 and thus replicating the current binary log event may make the slave’s data become different from the master’s data. To take no risk, slave refuses to replicate this event and stops. We recommend that all updates be stopped on the master and slave, that the data of both be manually synchronized, that master’s binary logs be deleted, that master be upgraded to a version at least equal to ’5.0.38′. Then replication can be restarted. Error_code: 1105

Technorati Tags: mysql, Error_code: 1105, daemon, lenny, etch

Posted in Debian, Linux, News, Security, mysql | No Comments »

iDrac 6 Debian Xen based e Serial Console Redirection

Maggio 13th, 2010 glycerin

Ecco i passi seguiti per poter abilitare la redirection della Serial Console via iDRAC 6. La procedura è stata testata su di una DELL R610 con installata una Debian Lenny e Xen Hyperviser 3.2-1. Lo scopo è di poter avere maggiori informazioni nei casi di crash del kernel.

Come primo step ho installato le “dellomsa” che mi permettono anche di intervenire sui settaggi del BIOS via shell, o in alternativa gli stessi passi è possibile farli entrando nel menu del BIOS al riavvio della macchina.

Di seguito i valori alterati, con i relativi comandi:

host:~# omconfig chassis biossetup attribute=extserial setting=rad
host:~# omconfig chassis biossetup attribute=fbr setting=57600
host:~# omconfig chassis biossetup attribute=serialcom setting=com2
host:~# omconfig chassis biossetup attribute=crab setting=enabled

Se i comandi sono andati a buon fine dovrebbe comparire in output il seguente feedback:”BIOS setup configured successfully. Change will take effect after the next reboot.“

Successivamente sono state anche modificate le seguenti righe sulla DRAC per abilitare la Serial Console.

racadm config -g cfgSerial -o cfgSerialBaudRate 57600
racadm config -g cfgSerial -o cfgSerialConsoleEnable 1
racadm config -g cfgSerial -o cfgSerialHistorySize 8192
racadm config -g cfgIpmiSol -o cfgIpmiSolBaudRate 57600

Invece per quanto riguarda la parte di avvio della macchina, e in particolare GRUB le righe da modificare all’interno di menu.lst sono le seguenti.

Aggiunta delle seguenti righe prima della parte evidenziata come “### BEGIN AUTOMAGIC KERNELS LIST“

serial –unit=0 –speed=57600 –word=8 –parity=no –stop=1
terminal –timeout=10 serial console

Mentre per le opzioni di avvio di Xen e della relativa release del kernel:

kernel                /boot/xen-3.2-1-i386.gz dom0_mem=1024m com2=57600,8n1 console=com2,vga
module                /boot/vmlinuz-2.6.26-2-xen-686 root=/dev/sda5 ro console=tty0 console=hvc0

Infine nel file inittab vengono aggiunte le seguenti entry:

#for serial console
7:2345:respawn:/sbin/getty 57600 hvc0
8:23:respawn:/sbin/getty 57600 tty1

Una volta fatte le modifiche sopra riportate si fa ripartire la macchina. Nel frattempo ci si logga via SSH sulla iDRAC della macchina da monitorare via Serial Console e ci si connette alla console appena impostata mediante un semplice comando:

console -h com2

Se tutto è andato per il verso giusto dovrebbe comparire l’output che è anche visibile attraverso il viewer proprio della iDRAC e permettere così la gestione intera della macchina.

N.B.:Per non essere buttati fuori dalla console per inattività è preferibile mettere un qualunque processo in esecuzione come ad esempio un semplice top.

Posted in Debian, Linux, News, Virtualizzazione | 1 Comment »

SVN: una seconda implementazione del post-commit per progetti web

Maggio 7th, 2010 glycerin

Una seconda implementazione dello script di post-commit è stata implementata causa bug trovati successivamente e quindi sono stato costretto a rivedere anche lo script per facilitare il bug-fixing.

Di seguito lo script nelle sue varie parti:

#!/bin/sh

if [ -e /var/tmp/svn.mail.01.$$$ ]; then
    rm -f /var/tmp/svn.mail.01.$$$
fi

In quest’ultimo caso sono stati inseriti dei codici di controllo al fine di controllare che la procedura vada a buon fine.
Quale ad esempio la parte inerente l’error_code. Tutte queste parti possono essere disattivate in un secondo tempo, insieme all’invio della mail.

Technorati Tags: svn, svnlook, subversion

Posted in Debian, Linux, News, Website | No Comments »

SVN: una prima implementazione del post-commit per progetti web

Aprile 30th, 2010 glycerin

Nel dover gestire dei progetti web utilizzando SVN (SubVersion) è utile abilitare un hook (il post-commit in particolare) che faccia un update del progetto web e in particolare della copia che sarà visibile via HTTP formulando la URL del progetto.
Un primo script è il seguente che in sostanza fa un update per ogni commit del repository.

host:~$ cat /var/local/projectsvn/hooks/post-commit
#!/bin/sh
/usr/bin/svn update /var/www/htdocs/projectsvn/htdocs –username user –password password

Un altro script, che io preferisco, invece si occupa di fare l’update delle singole directory che vengono aggiornate mediante la utility svnlook ed è il seguente:

host:~$ cat /var/local/projectsvn/hooks/post-commit
#!/bin/sh
/usr/bin/svnlook dirs-changed /var/local/projectsvn| /usr/bin/awk ‘{print “/var/www/htdocs/projectsvn/htdocs/”$1}’ |/usr/bin/xargs /usr/bin/svn up -N –username user –password password

dove la directory /var/local/projectsvn sarebbe il repository del progetto, mentre la directory /var/www/htdocs/projectsvn/htdocs/ sarebbe la directory della cosiddetta working copy. In soldoni non viene fatto l’update ricorsivo del progetto ma solo delle singole directory che restituisce la parte /usr/bin/svnlook dirs-changed /var/local/projectsvn.

In ultimo può essere comodo controllare che lo script sia funzionante magari implementando anche l’invio di una mail. Come ad esempio con il seguente script:

#Invio mail
AUTHOR=`/usr/bin/svnlook author    /var/local/bakecasvn`;

if [ -e /var/tmp/svn.mail.01.$$$ ]; then
        rm -f /var/tmp/svn.mail.01.$$$
fi
#END Invio mail

Technorati Tags: svn, svnlook, subversion

Posted in Debian, Linux, News, Website | No Comments »

XEN: migrazione COLD di una VM da un dom0 verso un altro

Aprile 28th, 2010 glycerin

Una metodologia di migrazione di una VM (creata utilizzando lvm2) da un dom0 a un altro è quella cosiddetta COLD, ovvero con lo stopping della VM. In linea generale perchè la versione LIVE comporta avere uno storage condiviso, ma a dire la verità non  ho ancora avuto esperienze in merito. Spero quanto prima di provarlo.
Passiamo agli step che ho seguito per questa metodologia.

Come primo step si crea un “logical volume” sulla macchina che dovrà ricevere la VM che verrà migrata (sia per la parte disco che per la swap)

lvcreate –addtag srv_2_vol-vm_da_migrare -L20G -n vm_da_migrare-disk srv_2_vol
lvcreate –addtag srv_2_vol-vm_da_migrare -L1G -n vm_da_migrare-swap srv_2_vol

Successivamente si copia in “scp” il file di configurazione che andrà poi modificato:

srv_1:/etc/xen# scp -p vm_da_migrare.cfg root@xxx.xxx.xxx.xxx:/etc/xen/

Vengono modificate le parti inerenti il disco all’interno della configurazione della VM, visto che il volume ha un riferimento diverso.

Una volta completate le fasi iniziali si stoppa la VM sulla macchina dalla quale migrare (xm destroy vm_da_migrare) e via dd e ssh migrare bit a bit il contenuto del logical volume vm_da_migrare-disk congelato a quell’istante.

dd if=/dev/srv_1_vol/vm_da_migrare-disk | ssh -2 -o “Compressionlevel 1″ root@xxx.xxx.xxx.xxx “dd of=/dev/srv_2_vol/vm_da_migrare-disk bs=100M”
srv_1:/etc/xen# dd if=/dev/srv_1_vol/vm_da_migrare-disk | ssh -2 -o “Compressionlevel 1″ root@xxx.xxx.xxx.xxx “dd of=/dev/srv_2_vol/vm_da_migrare-disk bs=100M”
root@xxx.xxx.xxx.xxx’s password:
41943040+0 records in
41943040+0 records out
21474836480 bytes (21 GB) copied, 589.536 s, 36.4 MB/s
0+655801 records in
0+655801 records out
21474836480 bytes (21 GB) copied, 585.855 s, 36.7 MB/s

Sulla VM viene risistemato il gateway in interfaces e l’eventuale firewall visto che cambia il dom0 e che quindi avrà un IP diverso.

Sul SERVER_DAL_QUALE_MIGRARE disabilitare le VM spostate per il loro avvio al boot (tolto il link in /etc/xen/auto/)

Sus SERVER_SUL_QUALE_MIGRARE invece abilitare l’avvio della VM al reboot (link in /etc/xen/auto/)

Technorati Tags: xen, lvm2, dd, ssh, migrazione, dom0

Posted in Debian, Linux, News | No Comments »