UNpatching di massa

In seguito a un problema sorto dopo un patching di massa di un Solaris10, dove un comando ha cessato di funzionare correttamente, ho deciso di ricorrere alla rimozione delle patch che interessano il binario in questione: si tratta di cfgadm, che semplicemente ha deciso di piantarsi quando lanciato; non muore nemmeno con un kill -9

In /var/sadm/patch ho i riferimenti per il ripristino dei files unpatched.
Vediamo a chi appartiene cfgadm:

pkgchk -l -p `which cfgadm`

mi ritorna un:

Referenced by the following packages:
SUNWcsu


Bene, la mia strategia è di verificare quali patches tra quelle presenti in /var/sadm/patch hanno partecipato alla modifica dell'installato del pacchetto SUNWcsu.
E di conseguenza rimuoverle. Un reboot, la speranza che la macchina "venga su".
Andiamo con ordine. E' necessario uno script, e qui ci si diverte:
Tipo questo:

root@ubigasmmg1->cd /var/sadm/patch
root@ubigasmmg1->for i in `showrev -p|grep SUNWcsu|/usr/xpg4/bin/awk '{print $2}'`
> do
> if [[ `ls -l|awk '{print $9}' |grep $i` ]]; then
> echo $i
> fi
> done

La prima riga apre il for sul risultato di un grep del pacchetto SUNWcsu ripulito con awk. Il particolare di usare quella versione specifica di awk viene dal fatto che il solito /usr/bin/awk aveva dei problemi nel trattare la lista generata da questa catena di pipe, sporcandola.
All'interno del for è necessario inserire la condizione che $i sia presente nella dir attuale; questo perchè, ovviamente, la lista generata nella riga prima è diversa da quella presente in /var/sadm/patch.
Il resto è di semplice comprensione e ne risulta:

125417-04
125500-01
125502-01
125550-01
126146-01
126148-01
126257-04
127112-03
127727-01
127758-01
127877-01
127921-01
127969-01


Ora si può rilanciare lo stesso script con il comando patchrm al posto dell 'echo.
Ha funzionato mica male, ora cfgadm non rimane più appeso senza speranza. Non resta che rileggermi uno a uno i README delle patch rimosse e cercare di capire dove salta fuori l'inghippo

IPMP Link-Based

Ho appena configurato IPMP su una macchina particolare:
si tratta di un Solaris 10u4 x86_64 virtualizzata su un BladeCenter a tre lame quad-opteron, tre nodi di un cluster Vmware ESX Infrastructure 3.0.2
Una LUN raid5 di 1 Terabyte è mappata raw direttamente da uno dei moduli di un Totalstorage DS4700; essa ospiterà un'istanza Oracle che farà da archivio referti.

Questa VM è dotata di due NIC attestate su due set di NIC fisiche diverse per ridondanza.
Si tratta di due Gigabit Ethernet Intel emulate (su Solaris 10 x86_64 è virtualizzata al posto di pcn e vmxnet), ed essendo che il loro driver supporta la modalità Link-Based di IPMP, e che odio la sintassi di configurazione e lo spreco di IP a cui è soggetto la configurazione Probe-Based, decido di usarla.

Configurare la gestione Link Based è di una facilità e pulizia allarmante:

root@ubigasmmg1->cat /etc/hostname.e1000g0
ubigasmmg1 group mmg up
root@ubigasmmg1->cat /etc/hostname.e1000g1
group mmg up
root@ubigasmmg1->svcadm restart physical

Fatto, pronto e funzionante.

Proviamolo:

root@ubigasmmg1->ifconfig -a
e1000g0: flags=1000843 mtu 1500 index 2
inet 172.21.200.175 netmask ffffff00 broadcast 172.21.200.255
groupname mmg
ether 0:50:56:b9:2a:7c
e1000g1: flags=1000843 mtu 1500 index 3
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
groupname mmg
ether 0:50:56:b9:64:b1

Simuliamo un problema sulla iface e1000g0:

root@ubigasmmg1->if_mpadm -d e1000g0

E verifichiamo:

root@ubigasmmg1->ifconfig -a
e1000g0: flags=89000842 mtu 0 index 2
inet 0.0.0.0 netmask 0
groupname mmg
ether 0:50:56:b9:2a:7c
e1000g1: flags=1000843 mtu 1500 index 3
inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255
groupname mmg
ether 0:50:56:b9:64:b1
e1000g1:1: flags=1000843 mtu 1500 index 3
inet 172.21.200.175 netmask ffffff00 broadcast 172.21.200.255

i logs:

Nov 30 02:31:22 ubigasmmg1 in.mpathd[607]: [ID 832587 daemon.error] Successfully failed over from NIC e1000g0 to NIC e1000g1

Ripristiniamo:
root@ubigasmmg1->if_mpadm -r e1000g0

ifconfig dice che tutto è tornato alla situazione iniziale con l'unico IP in uso attestato su e1000g0 (questo ovviamente in accordo al fatto che l'opzione FAILBACK è settata a YES in /etc/default/mpathd). Failback eseguito:

Nov 30 02:33:49 ubigasmmg1 in.mpathd[607]: [ID 620804 daemon.error] Successfully failed back to NIC e1000g0
Nov 30 02:34:19 ubigasmmg1 in.mpathd[607]: [ID 975029 daemon.error] No test address configured on interface e1000g0; disabling probe-based failure detection on it

Quest'ultima riga è significativa di una configurazione Link-based.
Ora vediamo come va. Un problema di cui ho letto è ad esempio il fatto che se uno switch non direttamente connesso al server dovesse cadere, IPMP non se ne accorge, essendo le ICMP request disabilitate non essendo utilizzata la modalità Probe-based. Nell'utilizzarlo è necessario tenere conto di ciò. Inoltre non tutte le NIC sono supportate, comprese alcune molto utilizzate.