PME è una (vecchia?) estensione per Mrtg.
Abbreviato, ciò di cui avevo bisogno in questo momento. Usavo Mrtg già tempo fa, e ne ho apprezzato le qualità nel monitoraggio di alcuni paratri via snmp sui Cisco.
Questa estensione, opportunamente modificata e adattata alle mie esigenze mi da la possibilità di sfruttare lo stupendo e familiare Mrtg per collezionare sottoforma di grafico l'utilizzo di cpu e memoria (per il momento) di alcune macchine.
In questo modo riesco a farmi un'idea del carico di lavoro durante la giornata e la settimana su diversi sistemi, per farmi un'idea dell'andazzo. So che mi sarà utile qual'ora incontrerò ancora problemi di "operazioni che mi siedono il 4800" (frase idiomatica che sharo col mio DBA di fiducia), quasi sempre dovute a anomalie sistemiche del tipo F (fornitore del software applicativo che ogni tanto fa danni scavando nei files di configurazione e operando modifiche del tipo:
$parametro=/dev/random
Naturalmente senza avvertire. Tant'è che la prima verifica che faccio quando si verificano problemi sinistri è digitare un:
pippo# last -20|grep $fornitore
Torniamo a noi; lancio i demoni a manina per verificare la bontà delle modifiche e dei files .cfg
C'è bisogno di uno script che lancia tutte le instanze del demone al riavvio della macchina.
root@ubigbck1# pgrep -lf mrtg
23164 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg ubigdbitc1-scan.cfg
21609 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg ubigdblis1-mem.cfg
21781 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg ubigdbitc1-mem.cfg
21336 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg unisio04-cpu.cfg
22103 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg unigen07-mem.cfg
6045 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg /bck/scripts/mrtg/ubigdblis1-cpu.cf
6498 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg ubigdbitc1-cpu.cfg
10540 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg ubigasbak1-cpu.cfg
21913 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg unigen05-mem.cfg
23078 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg ubigdblis1-dstatks.cfg
5969 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg /bck/scripts/mrtg/unigen02-cpu.cfg
21886 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg unigen02-mem.cfg
22188 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg unisio04-mem.cfg
6439 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg unigen05-cpu.cfg
6362 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg unigen07-cpu.cfg
23095 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg ubigdblis1-dstatwb.cfg
22933 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg ubigdblis1-scan.cfg
23221 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg unigen05-scan.cfg
23211 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg unigen07-scan.cfg
23380 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg ubigdbasmmg1-mem.cfg
23290 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg ubigdbasmmg1-cpu.cfg
23191 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg unigen02-scan.cfg
10818 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg ubigasbak1-scan.cfg
10689 /usr/bin/perl -w /usr/local/mrtg-2/bin/mrtg ubigasbak1-mem.cfg
Eccoli, redirigiamo quello che ci serve:
root@ubigbck1# echo "case \$1 in" >/etc/init.d/mrtgd
root@ubigbck1# echo "start)" >>/etc/init.d/mrtgd
root@ubigbck1# cd /bck/scripts/mrtg
root@ubigbck1# pgrep -lf bin/mrtg|grep ^[0-9]|awk '{print $4,$5}' >> /etc/init.d/mrtgd
root@ubigbck1# pgrep -lf bin/mrtg|grep ^' '|awk '{print $4,$5}' >> /etc/init.d/mrtgd
root@ubigbck1# echo ";;" >>/etc/init.d/mrtgd
root@ubigbck1# echo "stop)" >>/etc/init.d/mrtgd
root@ubigbck1# echo "pkill mrtgd" >>/etc/init.d/mrtgd
root@ubigbck1# echo ";;" >>/etc/init.d/mrtgd
root@ubigbck1# echo "*)" >>/etc/init.d/mrtgd
root@ubigbck1# echo "echo 'What'Ya Dueng?'" >>/etc/init.d/mrtgd
root@ubigbck1# echo ";;" >>/etc/init.d/mrtgd
root@ubigbck1# echo "esac" >>/etc/init.d/mrtgd
non dimentichiamo:
root@ubigbck1# chmod +x /etc/init.d/mrtgd
root@ubigbck1# ln -s /etc/init.d/mrtgd /etc/rc3.d/S99mrtgd
root@ubigbck1# ln -s /etc/init.d/mrtgd /etc/rcS.d/S99mrtgd
A posto!
sabato 30 giugno 2007
venerdì 29 giugno 2007
Arrivano i rinforzi
Gran giorno , oggi!
I nostri CED non vantano un massiccio numero di macchine SUN.
Considerando che sono anche l'unico sistemista unix in tutta la struttura, e che i sistemi Midrange che abbiamo sono trattati alla stregua di "mostri", l'arrivo di oggi ha qualcosa di speciale per tutti, e particolarmente piacevole per me.
Abbiamo appena finito di scaricare dal bilico due Fire E6900, due StorageTek Midrange 6540 e una Fire v245.
Andranno a creare il nuovo cluster, naturalmente Sun Cluster (o Solaris Cluster, ultimo cambio di nome del settore marketing che non ha di meglio da fare che creare confusione).
Appena ho tempo qualche foto
I nostri CED non vantano un massiccio numero di macchine SUN.
Considerando che sono anche l'unico sistemista unix in tutta la struttura, e che i sistemi Midrange che abbiamo sono trattati alla stregua di "mostri", l'arrivo di oggi ha qualcosa di speciale per tutti, e particolarmente piacevole per me.
Abbiamo appena finito di scaricare dal bilico due Fire E6900, due StorageTek Midrange 6540 e una Fire v245.
Andranno a creare il nuovo cluster, naturalmente Sun Cluster (o Solaris Cluster, ultimo cambio di nome del settore marketing che non ha di meglio da fare che creare confusione).
Appena ho tempo qualche foto
domenica 24 giugno 2007
Quanto sei pieno, filesystem? Un controllo per il riempimento via mail
Avendo bisogno di uno script che segnalasse il riempimento dei filesystems con un controllo abbastanza frequente ho realizzato il seguente script. In genere non amo prelevare dai vari rispettabili siti ( vedi BigAdmin ) scripts già fatti. Preferisco di gran lunga cercare di fare tutto da me per affinare la mia misera capacità nell'arte dello scripting e perchè poi so dove mettere le mani quando devo cambiare qualcosa, migliorare o aggiungere. In genere metto sempre un'anno di produzione ( i miei scripts me li porto dietro quando "migro" ) e un numero di versione per ricordarmi cosa ho di fronte sui vari servers dove utilizzo i miei accrocchi.
Il seguente ha queste caratteristiche
#!/usr/bin/bash
# 2007 Torchia Alessandro
# v0.6b
HOSTNAME=`hostname`
PC=90;
#FS=`df -F ufs -h|awk '{print$6}'|grep -v Moun`
df -F ufs -h|awk '{print$6}'|grep -v Moun|grep -n / > /tmp/fstable
PERCENT=`df -F ufs -h|awk '{print$5}'|grep %`
AA=0;
for i in $PERCENT
do
let AA+=1;
a=`cat /tmp/fstable|grep ^$AA`
a2=`echo $a|sed s/..:/''/|sed s/.:/''/`
#a3=`echo $a2|sed s/\//'_'/`
a3=`echo $a2|sed s/'\/'/'_'/`
PERCENTX=`echo $i|sed s/'%'/''/`;
if [ $PERCENTX -gt $PC ]; then
if [ ! `grep $PERCENTX /tmp/fswarn$a3` ];then
mailx -s "Filesystem $a2 sul server $HOSTNAME, è al $i" root <<> /tmp/fswarn$a3
fi
fi
done
Ah naturalmente va in crontab, tipo:
0,10,20,30,40,50 * * * * /bck/scripts/fullcontrol > /dev/null 2>&1
Se chi legge ha idee come migliorarne l'implementazione, beh, non chiedo di meglio, c'è sempre e molto da imparare
Il seguente ha queste caratteristiche
- Segnala il riempimento da sopra il 90% di utilizzo, personalizzabile tramite variabile apposita
- Manda una mail a ogni incremento o decremento di punto percentuale, non 5000. Quindi se si è ricevuta una mail che segnala un utilizzo del 92% tre ore fa, il 92% è l'utilizzo attuale
- Al momento il riempimento del filesystem che contiene /var e di conseguenza lo spool di Sendmail significa l'impossibilità per il demone di inviare mails di segnalazione
- Non è il massimo :), ma in rete ce ne sono sicuramente tanti altri
#!/usr/bin/bash
# 2007 Torchia Alessandro
# v0.6b
HOSTNAME=`hostname`
PC=90;
#FS=`df -F ufs -h|awk '{print$6}'|grep -v Moun`
df -F ufs -h|awk '{print$6}'|grep -v Moun|grep -n / > /tmp/fstable
PERCENT=`df -F ufs -h|awk '{print$5}'|grep %`
AA=0;
for i in $PERCENT
do
let AA+=1;
a=`cat /tmp/fstable|grep ^$AA`
a2=`echo $a|sed s/..:/''/|sed s/.:/''/`
#a3=`echo $a2|sed s/\//'_'/`
a3=`echo $a2|sed s/'\/'/'_'/`
PERCENTX=`echo $i|sed s/'%'/''/`;
if [ $PERCENTX -gt $PC ]; then
if [ ! `grep $PERCENTX /tmp/fswarn$a3` ];then
mailx -s "Filesystem $a2 sul server $HOSTNAME, è al $i" root <<> /tmp/fswarn$a3
fi
fi
done
Ah naturalmente va in crontab, tipo:
0,10,20,30,40,50 * * * * /bck/scripts/fullcontrol > /dev/null 2>&1
Se chi legge ha idee come migliorarne l'implementazione, beh, non chiedo di meglio, c'è sempre e molto da imparare
sabato 23 giugno 2007
Da Torino a Trento in festa
Con stasera inizia il weekend. Questo in particolare è speciale.In primo luogo è un week-end che io e la mia compagna amiamo definire "lungo", infatti staremo a Torino, la nostra città, dove siamo soliti tornare tutti i venerdì dopo la settimana lavorativa.
Infatti il mio lavoro mi ha portato per l'attuale impiego a diventare un trasfertista, per l'esattezza sono consulente Unix a Trento, presso una pubblica ammininistrazione.
Come accennavo sopra questo fine settimana è speciale. Domenica è la festa di Torino: il 24 giugno è San Giovanni, patrono della romanica Augusta Taurinorum, quindi... tutti a invadere Murazzi e Piazza Vittorio per l'appuntamento con i fuochi d'artificio.
Inoltre, e da qui il ponte di lunedi, martedi è la festa di Trento, San Vigilio.
WoW!
W San Vigilio, farò un pensiero per lui quando martedì mi starò godendo l'ultimo giorno nella mia città!
venerdì 22 giugno 2007
SVM fa 0+1 o 1+0?
Capiamoci bene qualcosa!
Questo è un'arcano che prima o poi chiunque si pone.
Anche a me è successo tempo fa, che c'è di meglio di annotarlo sul mio blog?
Fortunatamente qualcuno ci spiega come funziona qui:
http://blogs.sun.com/andresblog/entry/raid_0_1_vs_raid
Il succo del discorso sta in:
So, does SVM do RAID 0+1 or RAID 1+0? The answer is, "Yes." So it gives you a choice between the two? The answer is "No."
So, in a nutshell, SVM provides a RAID 0+1 style administrative interface but effectively implements RAID 1+0 functionality. Administrators get the best of each type, the relatively simple administration of RAID 0+1 plus the greater resilience of RAID 1+0 in the case of multiple device failures.
Questo per i profani vuol dire che, se si hanno due concatenazioni di quattro dischi, messe in mirror con SDS/SVM, il metadevice sopravviverà alla "morte" di quattro dei dischi. Con un paio di spares siete in una cassaforte di ottima fattura... e al costo dei soli dischi, senza ricorrere a nessun accrocchio in hardware.
Cosa? C'è ZFS adesso? Si, ma questa è un'altra storia...
UPDATE
Mi ero ripromesso di linkare da qualche parte una pagina che tratta l'argomento di questo post, ed eccolo qui:
http://chrismiles.info/unix/sun/dsraid10.txt
Questo è un'arcano che prima o poi chiunque si pone.
Anche a me è successo tempo fa, che c'è di meglio di annotarlo sul mio blog?
Fortunatamente qualcuno ci spiega come funziona qui:
http://blogs.sun.com/andresblog/entry/raid_0_1_vs_raid
Il succo del discorso sta in:
So, does SVM do RAID 0+1 or RAID 1+0? The answer is, "Yes." So it gives you a choice between the two? The answer is "No."
So, in a nutshell, SVM provides a RAID 0+1 style administrative interface but effectively implements RAID 1+0 functionality. Administrators get the best of each type, the relatively simple administration of RAID 0+1 plus the greater resilience of RAID 1+0 in the case of multiple device failures.
Questo per i profani vuol dire che, se si hanno due concatenazioni di quattro dischi, messe in mirror con SDS/SVM, il metadevice sopravviverà alla "morte" di quattro dei dischi. Con un paio di spares siete in una cassaforte di ottima fattura... e al costo dei soli dischi, senza ricorrere a nessun accrocchio in hardware.
Cosa? C'è ZFS adesso? Si, ma questa è un'altra storia...
UPDATE
Mi ero ripromesso di linkare da qualche parte una pagina che tratta l'argomento di questo post, ed eccolo qui:
http://chrismiles.info/unix/sun/dsraid10.txt
DMP, AP, MPXIO e chi più ne ha...
Veritas Volume Manager è licenziato gratuitamente e in automatico sul glorioso Photon ( StorEdge A5200).
Si da il caso io ne abbia uno in produzione connesso tramite due SOCAL ad una antica Enterprise 3500 (robe di due UltraSPARC II 400mhz, per la serie una Ultra10 ce la fa prima e più silenziosamente).
Il mio predecessore ha quindi pensato di gestire i 22 dischi FC inseriti nel Photon tramite questo gestore di volumi, e con DMP, il gestore multipathing per failover e distribuzione del carico di Veritas, parte della Storage Foundation. Tutto su Solaris 9 09/05 ben patchato.
Dopo una lunga serie di problemi e fastidi che questa macchina è riuscita a darci nel tempo, è venuto all'attenzione di qualcuno il fatto che Vxvm era il gestore di volumi sul server, questo in contrasto con le "policy aziendali" che volevano che il compito fosse svolto da SDS.
A me il compito di ovviare all' "inconveniente" (che a mio giudizio così sconveniente non era, ma...). Iniziando col deincapsulare i dischi di boot e via via /var /app e tutto ciò che risiedeva sui 6 dischi interni al server... ho fatto il tutto durante un down programmato.
Mancava lo storage array. Decisi di rinviare e sperare che qualcuno dimenticasse.
Per convenzione, i backups del db (che è ciò che risiedeva nel dg datadg residente sul
Photon) sono compito dei DBA, quindi i filesystem su cui risiedono i datafiles, solitamente montati in /dati , io semplicemente, non li backuppo (e nemmeno gli darei un senso farlo, fosse anche con uno snapshot, vedi fssnap).
Morale della favola, saltano due dischi del raid5 del volume vxvm, e non c'è verso per cui riesca a recuperare il filesystem. Qui urge un filesystem nuovo e pulito e relativo backup dei DBAs! Ma ecco la notizia: per qualche motivo, i backups di questo db non sono mai stati fatti, anzi, si era deciso di non farli... come al solito senza dire nulla al sottoscritto!
Perfetto!
Si fa tutto da capo e da zero; viene pianificato il modo migliore per ricostruire il db. Per fortuna è possibile, costa tempo ma è già un miracolo che sia possibile.
Distruggo i volumi, e come richiesto, colgo l'occasione per rimuovere il Veritas e mettere sotto DiskSuite i dischi sul Photon.
Mi viene richiesto di ridondare ancora di più il filesystem dedicato al db, a costo dello spazio disponibile; opto per fare due Simple raid0 in mirror che SDS dovrebbe trattare come un raid1+0 (in accordo a un documento tecnico trovato tempo fa in rete e che appena ritrovo posterò).
Niente di meglio. Ci aggiungo due spare e via:
d100 -m d101 d102 1
d101 8 1 c2t1d0s0 \
1 c2t2d0s0 \
1 c2t3d0s0 \
1 c2t4d0s0 \
1 c2t7d0s0 \
1 c2t8d0s0 \
1 c2t9d0s0 \
1 c2t10d0s0 -h hsp001
d102 8 1 c2t16d0s0 \
1 c2t17d0s0 \
1 c2t18d0s0 \
1 c2t19d0s0 \
1 c2t20d0s0 \
1 c2t22d0s0 \
1 c2t24d0s0 \
1 c2t25d0s0 -h hsp002
Manca solo la gestione del multipathing.
Ora che ho tolto DMP (che tra l'altro, secondo l'assistenza era il possibile motivo di un'altro problema che mi assillava di tanto in tanto dove il loop mi andava OFFLINE e ONLINE causando un desync che magari c'entra anche qualcosa col disastro sul filesystem che sto rifacendo), opto per mpxio, il driver di Solaris dedicato al multipathing (integrato in Solaris10 , anche detto StorEdge Traffic Manager o simili e disponibile da installare per Solaris 9.
Configuro tutto, ma niente; allora mi rileggo le note; tutto molto plausibile (il non funzionamento). Le SOCAL non sono supportate da questo driver. Devo ripiegare sul vecchio, buggato, triste Alternate Pathing (AP2.3).
eh no! nemmeno lui va, la versione di Solaris in uso (9), e la macchina in questione non ne permettono l'uso... mi rimane... un bel nulla!
Niente da fare.
Alla fine si opta per: nessun multipathing (giustificato dalla possibilità di avere resilienza, in quanto le prestazioni su questa macchina non sono un must), e "speriamo" che tenga, in attesa che arrivino i Blades che ospiteranno i servizi residenti su questa macchina.
La morale di questa storia è: leggi due volte le release notes, non fidarti del tecnico che al telefono ti dice che puoi mettere mpxio, e successivamente AP, perchè tanto nemmeno lui ha letto le Release Notes e sta dando le cose per scontato quasi quanto te.
Si da il caso io ne abbia uno in produzione connesso tramite due SOCAL ad una antica Enterprise 3500 (robe di due UltraSPARC II 400mhz, per la serie una Ultra10 ce la fa prima e più silenziosamente).
Il mio predecessore ha quindi pensato di gestire i 22 dischi FC inseriti nel Photon tramite questo gestore di volumi, e con DMP, il gestore multipathing per failover e distribuzione del carico di Veritas, parte della Storage Foundation. Tutto su Solaris 9 09/05 ben patchato.
Dopo una lunga serie di problemi e fastidi che questa macchina è riuscita a darci nel tempo, è venuto all'attenzione di qualcuno il fatto che Vxvm era il gestore di volumi sul server, questo in contrasto con le "policy aziendali" che volevano che il compito fosse svolto da SDS.
A me il compito di ovviare all' "inconveniente" (che a mio giudizio così sconveniente non era, ma...). Iniziando col deincapsulare i dischi di boot e via via /var /app e tutto ciò che risiedeva sui 6 dischi interni al server... ho fatto il tutto durante un down programmato.
Mancava lo storage array. Decisi di rinviare e sperare che qualcuno dimenticasse.
Per convenzione, i backups del db (che è ciò che risiedeva nel dg datadg residente sul
Photon) sono compito dei DBA, quindi i filesystem su cui risiedono i datafiles, solitamente montati in /dati , io semplicemente, non li backuppo (e nemmeno gli darei un senso farlo, fosse anche con uno snapshot, vedi fssnap).
Morale della favola, saltano due dischi del raid5 del volume vxvm, e non c'è verso per cui riesca a recuperare il filesystem. Qui urge un filesystem nuovo e pulito e relativo backup dei DBAs! Ma ecco la notizia: per qualche motivo, i backups di questo db non sono mai stati fatti, anzi, si era deciso di non farli... come al solito senza dire nulla al sottoscritto!
Perfetto!
Si fa tutto da capo e da zero; viene pianificato il modo migliore per ricostruire il db. Per fortuna è possibile, costa tempo ma è già un miracolo che sia possibile.
Distruggo i volumi, e come richiesto, colgo l'occasione per rimuovere il Veritas e mettere sotto DiskSuite i dischi sul Photon.
Mi viene richiesto di ridondare ancora di più il filesystem dedicato al db, a costo dello spazio disponibile; opto per fare due Simple raid0 in mirror che SDS dovrebbe trattare come un raid1+0 (in accordo a un documento tecnico trovato tempo fa in rete e che appena ritrovo posterò).
Niente di meglio. Ci aggiungo due spare e via:
d100 -m d101 d102 1
d101 8 1 c2t1d0s0 \
1 c2t2d0s0 \
1 c2t3d0s0 \
1 c2t4d0s0 \
1 c2t7d0s0 \
1 c2t8d0s0 \
1 c2t9d0s0 \
1 c2t10d0s0 -h hsp001
d102 8 1 c2t16d0s0 \
1 c2t17d0s0 \
1 c2t18d0s0 \
1 c2t19d0s0 \
1 c2t20d0s0 \
1 c2t22d0s0 \
1 c2t24d0s0 \
1 c2t25d0s0 -h hsp002
Manca solo la gestione del multipathing.
Ora che ho tolto DMP (che tra l'altro, secondo l'assistenza era il possibile motivo di un'altro problema che mi assillava di tanto in tanto dove il loop mi andava OFFLINE e ONLINE causando un desync che magari c'entra anche qualcosa col disastro sul filesystem che sto rifacendo), opto per mpxio, il driver di Solaris dedicato al multipathing (integrato in Solaris10 , anche detto StorEdge Traffic Manager o simili e disponibile da installare per Solaris 9.
Configuro tutto, ma niente; allora mi rileggo le note; tutto molto plausibile (il non funzionamento). Le SOCAL non sono supportate da questo driver. Devo ripiegare sul vecchio, buggato, triste Alternate Pathing (AP2.3).
eh no! nemmeno lui va, la versione di Solaris in uso (9), e la macchina in questione non ne permettono l'uso... mi rimane... un bel nulla!
Niente da fare.
Alla fine si opta per: nessun multipathing (giustificato dalla possibilità di avere resilienza, in quanto le prestazioni su questa macchina non sono un must), e "speriamo" che tenga, in attesa che arrivino i Blades che ospiteranno i servizi residenti su questa macchina.
La morale di questa storia è: leggi due volte le release notes, non fidarti del tecnico che al telefono ti dice che puoi mettere mpxio, e successivamente AP, perchè tanto nemmeno lui ha letto le Release Notes e sta dando le cose per scontato quasi quanto te.
T3+ e comandi di servizio
La solita chiamata quasi mensile; se hai due dozzine di StorEdge T3 o T3 Plus sparsi per i CED, capita abbastanza spesso di dover cambiare le batterie.
I T3 sono degli ottimi array raid HW, niente di eclatante ma fanno il loro lavoro, sono piuttosto semplici da usare e finchè non cominciano a fare le bizze, sono amici dell'amministratore di sistema.
Hanno anche la pessima abitudine, anzi tutti i Vendor ce l'hanno, di esistere con migliaia di versioni del loro sistema operativo, e come detto sopra in due versioni, delle quali la Plus è una revisione agli steroidi del fratello anziano T3 "liscio".
Tempo fa abbiamo rimpiazzato uno degli alimentatori (tutta la parte, non solo la batteria) su uno dei T3+ .
Ho poi ricevuto dal tecnico di servizio la procedura di reset del warranty date.
Un semplice:
T32:/:<1>.id write busage u1pcu2 0
Ieri, nuovo giorno, nuova batteria. Il comando già lo conoscevo; per sicurezza un cat syslog sull'array mi ha confermato quanto sopra.
Vado per darlo e ricevo un bel "Command not found".
Dopo diverse telefonate si risolve l'arcano. Il T3 di sopra è una versione 2.x.
Nuovo giorno, nuova batteria, nuova release del firmware, nuove funzioni ... nuovo command set.
I comandi che non trovi sono stati nascosti e imprigionati nei firmware 3.x (almeno nel mio 3.2.3); per liberarli è necessario il comando:
T44:/:<1> sun
Non correte a provarlo, vi chiederà una password che no, non sono autorizzato a darvi, che credo sia standard (anzi no son certo) e che è riservata ai cosiddetti "Field Engeneer" autorizzati da Sun Microsystem.
Dopo aver inserito questo comando troverete tutti gli altri che non vedete più nelle nuove releases del firmware dei T3/T3+
Si supponeva al telefono col tecnico che la procedura di update potrebbe essere stata automatizzata. Pensandoci io credo che i progettisti abbiano deciso di togliere dalle mani di clienti macellai gli strumenti per fare danni. Peccato che questo tolga a tutti la possibilità di gestire i propri array regolarmente acquistati.
Per la serie, no Support Contract, no Party
I T3 sono degli ottimi array raid HW, niente di eclatante ma fanno il loro lavoro, sono piuttosto semplici da usare e finchè non cominciano a fare le bizze, sono amici dell'amministratore di sistema.
Hanno anche la pessima abitudine, anzi tutti i Vendor ce l'hanno, di esistere con migliaia di versioni del loro sistema operativo, e come detto sopra in due versioni, delle quali la Plus è una revisione agli steroidi del fratello anziano T3 "liscio".
Tempo fa abbiamo rimpiazzato uno degli alimentatori (tutta la parte, non solo la batteria) su uno dei T3+ .
Ho poi ricevuto dal tecnico di servizio la procedura di reset del warranty date.
Un semplice:
T32:/:<1>.id write busage u1pcu2 0
Ieri, nuovo giorno, nuova batteria. Il comando già lo conoscevo; per sicurezza un cat syslog sull'array mi ha confermato quanto sopra.
Vado per darlo e ricevo un bel "Command not found".
Dopo diverse telefonate si risolve l'arcano. Il T3 di sopra è una versione 2.x.
Nuovo giorno, nuova batteria, nuova release del firmware, nuove funzioni ... nuovo command set.
I comandi che non trovi sono stati nascosti e imprigionati nei firmware 3.x (almeno nel mio 3.2.3); per liberarli è necessario il comando:
T44:/:<1> sun
Non correte a provarlo, vi chiederà una password che no, non sono autorizzato a darvi, che credo sia standard (anzi no son certo) e che è riservata ai cosiddetti "Field Engeneer" autorizzati da Sun Microsystem.
Dopo aver inserito questo comando troverete tutti gli altri che non vedete più nelle nuove releases del firmware dei T3/T3+
Si supponeva al telefono col tecnico che la procedura di update potrebbe essere stata automatizzata. Pensandoci io credo che i progettisti abbiano deciso di togliere dalle mani di clienti macellai gli strumenti per fare danni. Peccato che questo tolga a tutti la possibilità di gestire i propri array regolarmente acquistati.
Per la serie, no Support Contract, no Party
openldap bug in cambio password
Su uno dei Fire 4800 abbiamo un'applicativo che utilizza una directory openldap per la gestione delle utenze. Se ho ben capito replica su una tablespace Oracle le utenze e utilizza questa replica nel caso il demone slapd non fosse disponibile.
L'utilizzo di openldap pare dovuto a un decisamente buono incremento prestazionale rispetto all'utilizzo del db.
Ora, dopo un aggiornamento dell'applicativo interessato (un accrocchio di jboss tomcat e oracle), la versione di openldap in uso da 3 anni, una 2.1.25 ha cominciato a dare problemi.
Dopo un periodo di debug, kilometri di logs letti, dovrei avere stabilito l'origine del problema. Si tratterebbe di un bug documentato, dove un cambio password eseguito dall'applicativo causerebbe una corruzione del db (un BerkeleyDB 4.2.52 pacchettizzato SunFreeware). Unico modo di recuperare la directory era un ripristino da backup dei files del db o uno slapadd da precedente slapcat, quindi da un .ldif
Stamattina, vinta la guerra burocratica che tutto rende difficile, ho messo in produzione l'ultima stabile di openldap, la 2.3.32, sistemato il file di configurazione slapd.conf , che a distanza di anni ha introdotto un paio di cambi sintattici (attrs==attributes e simili).
La procedura di migrazione è stata alquanto indolore e semplice, inoltre ho, come sempre, optato per un aggiornamento con installazione in parallelo di binari e database nuovo, in modo da poter tornare indietro in una manciata di secondi al verificarsi di problemi imprevisti (che ci sono sempre soprattutto quando hai una macchina che è in produzione e centinaia di utenti che aprono chiamate a /dev/random anche abbastanza imbufaliti.
I tests di creazione utente e cambio password sembrano essere andati a buon fine; dopo 6 ore che il nuovo demone lavora tutto sembra ok.
In un prossimo post la procedura di aggiornamento.
L'utilizzo di openldap pare dovuto a un decisamente buono incremento prestazionale rispetto all'utilizzo del db.
Ora, dopo un aggiornamento dell'applicativo interessato (un accrocchio di jboss tomcat e oracle), la versione di openldap in uso da 3 anni, una 2.1.25 ha cominciato a dare problemi.
Dopo un periodo di debug, kilometri di logs letti, dovrei avere stabilito l'origine del problema. Si tratterebbe di un bug documentato, dove un cambio password eseguito dall'applicativo causerebbe una corruzione del db (un BerkeleyDB 4.2.52 pacchettizzato SunFreeware). Unico modo di recuperare la directory era un ripristino da backup dei files del db o uno slapadd da precedente slapcat, quindi da un .ldif
Stamattina, vinta la guerra burocratica che tutto rende difficile, ho messo in produzione l'ultima stabile di openldap, la 2.3.32, sistemato il file di configurazione slapd.conf , che a distanza di anni ha introdotto un paio di cambi sintattici (attrs==attributes e simili).
La procedura di migrazione è stata alquanto indolore e semplice, inoltre ho, come sempre, optato per un aggiornamento con installazione in parallelo di binari e database nuovo, in modo da poter tornare indietro in una manciata di secondi al verificarsi di problemi imprevisti (che ci sono sempre soprattutto quando hai una macchina che è in produzione e centinaia di utenti che aprono chiamate a /dev/random anche abbastanza imbufaliti.
I tests di creazione utente e cambio password sembrano essere andati a buon fine; dopo 6 ore che il nuovo demone lavora tutto sembra ok.
In un prossimo post la procedura di aggiornamento.
Iscriviti a:
Post (Atom)
