Nuovo numero di Linux&C. disponibile in edicola a Torino

settembre 23rd, 2010 glycerin

Beh .. come non segnalare l’uscita del nuovo numero di Linux&C. in edicola, il numero 71. Argomenti molto interessanti in discussione, come sempre. La mia curiosità è rivolta particolarmente verso la trattazione di Asterisk e una descrizione pratica dell’utilizzo di HIPHOP per migliorare le prestazioni di un sito web e l’intervista a Stefano Zacchiroli attuale Debian Project Leader……..

Buona lettura
Technorati Tags: Linux&C, asterisk, hiphop

 Nuovo numero di Linux&C. disponibile in edicola a Torino
share save 171 16 Nuovo numero di Linux&C. disponibile in edicola a Torino

Posted in Debian, Linux, News | No Comments »

Anche gli sviluppatori del kernel Linux a volte sbagliano

settembre 19th, 2010 glycerin

Leggendo la nuova, che poi nuova non è, vulnerabilità riguardante il kernel Linux su “H security” non ho potuto fare a meno di pensare ciò. Se effettivamente la cosa risulta come raccontato nell’articolo in questione l’unica cosa che posso aggiungere è che sbagliare è umano. Lo so che per chi ha in ambiente di produzione una potenziale vulnerabilità di questo tipo la cosa non risulta facile da digerire ma così è ……

A quanto detto da Ben Hawkes la vulnerabilità venne scoperta e chiusa nel 2007 ma poi nel 2008, inspiegabilmente, la patch venne rimossa riaprendo la vulnerabilità che permette di guadagnare i permessi di root per mezzo di un exploit che si può tranquillamente scaricare e testare. Il problema riguarda i sistemi a 64 bit nella compatibility mode a 32 bit; in soldoni il livello di emulazione a 32 bit non discrimina se la “call” è all’interno della Syscall table o meno. Su seclists.org è stato pubblicato un veloce workaround per limitare i danni fino a quando non si potrà aggiornare il kernel vulnerabile.
Technorati Tags: linux, kernel, exploit, seclist.org

 Anche gli sviluppatori del kernel Linux a volte sbagliano

share save 171 16 Anche gli sviluppatori del kernel Linux a volte sbagliano

Posted in Linux, News, Security | No Comments »

Correzione di errori nello scheduling di comandi mediante cron in Debian

luglio 23rd, 2010 glycerin

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 »

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

 Recording di una Shell Session
share save 171 16 Recording di una Shell Session

Posted in Debian, Linux, 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

 System Services update required al boot di un server PE R710

share save 171 16 System Services update required al boot di un server PE R710

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

 Ripristino della funzionalità della iDRAC
share save 171 16 Ripristino della funzionalità della iDRAC

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

 Replicazione MySQL tra una LENNY e una ETCH Debian ed Error code: 1105
share save 171 16 Replicazione MySQL tra una LENNY e una ETCH Debian ed Error code: 1105

Posted in Debian, Linux, mysql, News, Security | 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.

 iDrac 6 Debian Xen based e Serial Console Redirection
share save 171 16 iDrac 6 Debian Xen based e Serial Console Redirection

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

#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 <userfrom@dominio.it>” -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

 SVN: una seconda implementazione del post commit per progetti web
share save 171 16 SVN: una seconda implementazione del post commit per progetti web

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

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 <userfrom@dominio.it>” -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

 SVN: una prima implementazione del post commit per progetti web
share save 171 16 SVN: una prima implementazione del post commit per progetti web

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