gabcicala » Open Source

Correzione di errori nello scheduling di comandi mediante cron in Debian

glycerin — Fri, 23 Jul 2010 15:13:59 +0000

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

No related posts.

Articoli correlati elaborati dal plugin Yet Another Related Posts.

Recording di una Shell Session

glycerin — Fri, 18 Jun 2010 17:15:15 +0000

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

No related posts.

Articoli correlati elaborati dal plugin Yet Another Related Posts.

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

glycerin — Wed, 09 Jun 2010 11:14:55 +0000

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

No related posts.

Articoli correlati elaborati dal plugin Yet Another Related Posts.

Ripristino della funzionalità della iDRAC

glycerin — Thu, 03 Jun 2010 12:41:50 +0000

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

No related posts.

Articoli correlati elaborati dal plugin Yet Another Related Posts.

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

glycerin — Mon, 17 May 2010 16:18:00 +0000

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

No related posts.

Articoli correlati elaborati dal plugin Yet Another Related Posts.

iDrac 6 Debian Xen based e Serial Console Redirection

glycerin — Thu, 13 May 2010 16:41:35 +0000

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.

No related posts.

Articoli correlati elaborati dal plugin Yet Another Related Posts.

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

glycerin — Fri, 07 May 2010 16:20:49 +0000

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

#cd /var/www/htdocs/projectsvn/htdocs
#/usr/bin/svnlook dirs-changed /var/local/projectsvn |/usr/bin/xargs /usr/bin/svn up -N {} –username user –password password >> /var/tmp/svn.mail.01.$$$
#error_code=`/bin/echo “$?”`
#/bin/echo “Error_code: $error_code” >> /var/tmp/svn.mail.01.$$$
#if [ "$error_code" != 0 ]; then
# /bin/echo “[Error] ERROR on $LINENO” >> /var/tmp/svn.mail.01.$$$
# #exit 1
#fi

### update su directory
##/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
#cd /var/www/htdocs/projectsvn/htdocs
#/usr/bin/svnlook dirs-changed /var/local/projectsvn| /usr/bin/xargs /usr/bin/svn up -N –username user –password password >> /var/tmp/svn.mail.01.$$$
#error_code=`/bin/echo “$?”`
#/bin/echo “Error_code: $error_code” >> /var/tmp/svn.mail.01.$$$
#if [ "$error_code" != 0 ]; then
# /bin/echo “[Error] ERROR on $LINENO” >> /var/tmp/svn.mail.01.$$$
# #exit 1
#fi
### END update su directory

### update su singolo file
/usr/bin/svnlook changed /var/local/projectsvn| /bin/sed “s/^….//” | /usr/bin/awk ‘{print “/var/www/htdocs/projectsvn/htdocs/”$1}’ |/usr/bin/xargs /usr/bin/svn up –username user –password password >> /var/tmp/svn.mail.01.$$$
error_code=`/bin/echo “$?”`
/bin/echo “Error_code: $error_code” >> /var/tmp/svn.mail.01.$$$
if [ "$error_code" != 0 ]; then
/bin/echo “[Error] ERROR on $LINENO” >> /var/tmp/svn.mail.01.$$$
#exit 1
fi
### END update su singolo file

/bin/echo “—————————————————-” >> /var/tmp/svn.mail.01.$$$

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

echo “Upgrade to revision by $AUTHOR” >> /var/tmp/svn.mail.01.$$$
/usr/bin/svnlook changed /var/local/projectsvn >> /var/tmp/svn.mail.01.$$$

mail -s “Projectsvn update from $AUTHOR” user@dominio.it -a “From: svn update ” -a “Return-Path: userfrom@dominio.it” < /var/tmp/svn.mail.01.$$$

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

No related posts.

Articoli correlati elaborati dal plugin Yet Another Related Posts.

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

glycerin — Fri, 30 Apr 2010 16:28:45 +0000

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`;

echo “Upgrade to revision by $AUTHOR” >> /var/tmp/svn.mail.01.$$$
/usr/bin/svnlook changed /var/local/projectsvn >> /var/tmp/svn.mail.01.$$$

mail -s “Projectsvn update from $AUTHOR” user@dominio.it -a “From: svn update ” -a “Return-Path: userfrom@dominio.it” < /var/tmp/svn.mail.01.$$$

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

Technorati Tags: svn, svnlook, subversion

No related posts.

Articoli correlati elaborati dal plugin Yet Another Related Posts.

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

glycerin — Wed, 28 Apr 2010 14:59:00 +0000

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

No related posts.

Articoli correlati elaborati dal plugin Yet Another Related Posts.

XEN: timer stops running after dom0 reboot & save/restore

glycerin — Thu, 22 Apr 2010 17:01:46 +0000

Una nota abbastanza stonata ogni volta che si restarta il dom0 di una macchina adibita alla virtualizzazione.
Finora, dalla mia esperienza, mi è sempre stato necessario operare un destroy della macchina virtuale (VM) per po ritirarla su con un “xm create“. Il motivo è presto detto. Ogni volta che si ha un boot della macchina fisica la VM entra nello state “save” di XEN per poi essere ripristinata non appena la macchina fisica è su.

Se invece nella configurazione della VM viene inserito il campo extra del seguente tipo:

extra = ‘clocksource=jiffies’

e, insieme a questo far sì che il clock delle VM sia indipendente dalla dom0 con il parametro

xen.independent_wallclock=1

in /etc/sysctl.conf (sia per la VM che per la dom0).

Al riavvio ho notato che la VM ritorna ad avere un time coerente con la dom0, e in generale con l’ntp server configurato. Ovviamente questo presuppone che vi sia il daemon ntpd operativo.
Se altri hanno avuto esperienze simili alla mia mi farebbe piacere avere news sul workaround adoperato.

Technorati Tags: XEN, jiffies, clocksource, independent_wallclock

No related posts.

Articoli correlati elaborati dal plugin Yet Another Related Posts.