Sun User Group su Areanetworking!!

Sono felice di annunciare l'apertura del Sun User Group di Areanetworking.
Al momento consiste di una mailing list per comunicazioni amministrative, richieste di aiuto tecnico, proposte di incontro/attività, scambio di informazioni su training e certificazioni.

Tra gli obiettivi finali del SUG, quello di farsi riconoscere da Sun Microsystem come gruppo ufficiale e magari ottenere qualche privilegio per gli iscritti negli acquisti e nell'adesione a manifestazioni organizzate da Sun.

Per ora puoi iscriverti scrivendo a alessandro.torchia@areanetworking.it o federico.lagni@areanetworking.it

La pagina dedicata sul sito Areanetworking
La mailing list è sug@ml.areanetworking.it , potete iscrivervi anche nella maniera classica, usando i comandi via mail (vedi manuale di Mailman)

Ricordo che già esiste un Cisco User Group di AreaNetworking riconosciuto e ufficiale che conta circa 440 membri (forse il più grande in Italia?) con una mailing list moderata e con un discreto traffico. E' cug@ml.areanetworking.it, archivio consultabile qui. Inoltre vi è una mailinglist dedicati ai certificandi CCIE
Pagina d'informazione qui

Quale Virtualbox?Lla versione brandizzata, of course

Ho provato Virtualbox: dopo che mi sono arreso nel cercare l'ennesima patch per Vmware server per l'ennesimo kernel linux; come al solito i moduli non si compilano e una volta a settimana, cambiata versione di vmware o di kernel, bisogna ricercare da zero una qualche patch ... ma @#@¼#!

Lo trovo nella repository Debian come Virtualbox-OSE, la versione pura e opensource, amica di Dio e conforme ai dettami open e alle linee guida source ... tutto molto bello ... peccato che la mia virtual machine con 16 dischi non ci può bootare!! Infatti, dopo 10000 tentativi di bootare una virtualmachine preconfezionata da Sun, scopro che i controllers aggiuntivi (non l'IDE a due canali di default con i suoi 4 devices massimi), siano essi SATA o SCSI Lsi o BusLogic, non sono supportati. Sono attivabili ma al boot un errore blocca tutto. La cosa naturalmente è non/maldocumentata in puro stile Linux.

Allora, visto che c'è, ripiego sulla versione Black-Voodoo del software di virtualizzazione, brandizzato Sun: Sun Virtualbox.

Identico, versione 2.2.4, ma con controllers aggiuntivi funzionanti ... evviva!
Tralasciando il fatto che da qualche parte ho letto che è uscita la versione 3.0 di Virtualbox ma da nessuna parte ne trovo menzione sui siti Sun e virtualbox.org, booto felice la mia Vmachine con tutti i suo dischi sata. Da ricordare in futuro...

Internet Relay Chat Solaris

Circa un paio d'anni fa, ho registrato su Azzurra, il canale #solaris . Un pò colto da un eccesso di entusiasmo, un pò perchè questo canale su quel network manca, e anche perchè mi interessava creare un canale di discussione in italiano per sistemisti italiani che prediligono i sistemi Sun e Solaris.

Su questo canale si incontrano circa 7-8 persone, quasi tutti lavoratori informatici, che lavorano su Solaris esclusivamente o in buona parte.

Certo, sarebbe bello vedere più gente, perchè so che i sistemisti specializzati su queste tecnologie in Italia sono un discreto numero, tra cui alcuni molto in gamba.
Il canale è dedicato a tutto ciò che ruota intorno a Sun, in primis Solaris, è aperto a discussioni su argomenti d'attualità sul tema in oggetto e anche a richieste di aiuto e consigli per risoluzione di problemi e per implementazioni che magari qualcuno già conosce.
Anche Opensolaris e derivati sono benvenuti, sebbene il canale ha come focus la distribuzione Sun del sistema operativo, che in questo momento è Solaris 10 (e da cui deriva il codice sorgente rilasciato come open), e dei prodotti Sun o meno che vi girano sopra. Per quanto riguarda l'hardware, il discorso è diverso, e sebbene i sistemi marchiati Sun Microsystems con architettura SPARC siano la configurazione "of choice", qualsiasi sistema classificabile server SPARC o x86/x64, supportato o meno, può essere incluso in una discussione.

Il canale #solaris è accessibile cliccando qui se avete un client IRC installato oppure via web qui inserendo un nickname e #solaris come channel.

SMI e EFI label

Per cambiare la label di un disco è necessario usare il comando format in modalità enhanced.

# format -e
format> label
[0] SMI Label
[1] EFI Label
Specify Label type[0]:

Quando ci si trova a rifare una macchina con relativo storage connesso potrebbe tornare utile. Ad esempio con Veritas Volume Manager è fondamentale labellizare correttamente il disco per poter utilizzare un formato in particolare durante la sua inizializzazione.
Da ricordare che la EFI label è il default che viene usato per dischi da 1 Terabyte in su.
Da ricordare anche che dischi con label EFI non sono compatibili in Diskgroups vxvm CDS, Cross-Platform Data Sharing, che è il formato che li rende importabili su qualsiasi piattaforma e OS per cui è disponibile VxVM.

Cheatsheets

Esattamente qui una serie di cheatsheet per avere a portata di mano i comandi per fare un sacco di cose.

Grazie a http://www.datadisk.co.uk/

Netinstalling Solaris Vs. Linux "Broken" NFSd

La fiera delle stranezze che l'implementazione NFS di linux riesce a metter su ogni volta, è incredibile.
Questa volta, installando da rete Solaris 10 U6 ... al momento di montare via NFS il cdrom, l'installer fallisce, verificando i logs sull'install server Debian, mi trovo un:

Feb 24 23:53:39 debian mountd[8682]: Unauthorized access by NFS client 192.168.5.11.
Feb 24 23:53:39 debian mountd[8682]: Blocked attempt of 192.168.5.11 to mount /extra/media

Mmhh ... comincio a giocare senza troppa convinzione col file /etc/exports ... mmh; l'unica cosa che rimane è invariata è l'asterisco che indica che tutti gli hosts hanno permesso di montare l'export:

/srv/sol/Boot *(sync,ro,no_root_squash,all_squash,insecure)
/srv/media *(sync,ro,no_root_squash,all_squash,insecure)

Allora mi ricordo di aver letto qualcosa durante le passate ricerche alle prese con altri problemi legati a nfsd su linux. E cambio così:

/srv/sol/Boot 192.168.5.0/255.255.255.0(sync,ro,no_root_squash,all_squash,insecure)
/srv/media 192.168.5.0/255.255.255.0(sync,ro,no_root_squash,all_squash,insecure)

Funziona!!
E i log confermano:

Feb 25 00:01:18 debian mountd[8758]: NFS mount of /extra/media attempted from 192.168.5.11
Feb 25 00:01:29 debian mountd[8758]: /extra/media has been mounted by 192.168.5.11

Pazzesco ... segno qui da ricordare anche questa scocciatura

HTC Touch Diamond e il cavetto USB/miniUSB

Ho un HTC Touch Diamond come cellulare. Non è che ne sia particolarmente fiero, nel complesso non mi piace quanto mi sono piaciuti i precedenti telefoni, tutti Nokia, che ho avuto. Ma tant'è, per un pò tengo questo.

Recentemente ho perso il cavetto USB. Questo telefonoha un cavetto USB con un capo dotato di una interfaccia USb standard e l'altro di un connettore simile a un mini-USB ... simile.

Questo cavetto serve sia per la connettività col PC (Mass Storage/Active Syc), sia, collegandolo all'alimentatore, per caricare il telefono in modo tradizionale.

Cercando per negozi cavetto o caricatore ho avuto poca fortuna; ho trovato parecchi modelli non originali per HTC Touch e Tytn, che utilizzano una interfaccia mini-USB standard, a differenza del mio.

Oggi entro in un negozio e il proprietario mi rifila un caricatore che dice "E' lui! E' perfetto!"; mi faccio convincere ad acquistarlo a 10 euro ... ho risolto il problema ... sto telefono era li spento nel cassetto da una ventina di giorni. Arrivo a casa e ... orrore ... mi ha FOTTUTO!!! Il tizio del negozio mi ha rapinato 10 euro, il cavo ha interfaccia mini-USB, come quella che ho visto ovunque ... ho come una sensazione di essere stato preso per il culo, e mi chiedo come mai.

E' la disperazione che mi convince a fare l'assurdo. Lo infilo nella presa di corrente e provo a infilare la mini-USB nel cellulare ... ENTRA ... ODDIO ... il tasto circolare comincia a lampeggiare lentamente ... ODDIO ... significa "Mi sto caricando!! Grazie capo, ero proprio a secco" ... WOW!!!

Morale della favola:
HTC Touch Diamond ha un'interfaccia non standard, simile a una interfaccia mini-USB, in realtà E' UNA MINI-USB, e sebbene la forma sia diversa, il connettore calza a perfezione, il pinout è identico e il telefono funziona sia nella ricarica che nella connessione via USB a un computer. E' fantastico.

Se perdete il cavetto, perchè, come me, avete il cervelletto che perde ticks e attende un'aggiornamento del firmware come ogni benedetto server Sun che si rispetti, è sufficiente rimpiazzarlo con un qualsiasi cavetto USB-miniUSB. Se perdete anche il caricatore da presa, allora un qualsiasi caricatore per HTC Touch non originale (questi sono però un pezzo unico, il cavetto è attaccato al caricatore) fa al caso vostro.

Maledetto initiator ID aka "Scsi initiator ID is now 6"!!

Rifacendo un cluster con un vecchio JBOD scsi come shared storage, sono incorso in un conflitto di target ID nella catena scsi tra lo storage sharato e i due nodi.

In questo tipo di configurazione, uno dei due nodi va configurato ad hoc, agendo su alcuni parametri in OBP, in modo da evitare appunto conflitti.

Questo passaggio l'ho fatto già diverse volte, non tantissime, visto che per lo più capita di lavorare su devices fiber-channel, ma abbastanza da essere routine.

Si tratta di agire sulla variabile scsi-initiator-id di un nodo, portando il valore dal default (7) a 6, e poi inserire uno script in nvramrc, abilitandone l'uso mettendo a true use-nvramrc?. Questo in spiccioli aggira il conflitto tra gli HBA dei due nodi dandogli ID diversi, e poi al caricamento di Solaris, risetta in modo trasparente l'ID. Fatto.

Booto. Parte. Uno sfacelo. Decine di errori con molto poco senso, che tutto dicono, tranne quello che è ovvio (vabbè, l'ho esagerata, il loro senso lo hanno).

C'è da dire, che avevo già installato Solaris10 via flar sui nodi, e anche Sun Cluster che era in installmode, in attesa che designassi una DID come quorum.

Dopo un pò di riavvii stressanti e di set-defaults di OBP e rifacimento dei settaggi di cui sopra, mi illumino. Booto un solo nodo, lo booto -xvsr e osservo:
manca la dichiarazione "Scsi initiator ID is now 6". Viene bypassato, il trucco non viene implementato.

Disabilito il parsing di nvramrc settando a false "use-nvramrc?".
Ribooto ... nulla.
STOP-A brutale! Spengo lo storage. Do un reset-all. Ribooto.
Lo vedo: "Scsi initiator ID is now 6" !!
Poweroff ... accendo il JBOD ... accendo il nodo ... boot -v
Pare andare. Accendo l'altro nodo ... TUTTO OK!!!
Riabilito use-nvramrc? . Riavvio i nodi, tutto va.

Morale della favola:
le modifiche vanno implementate a storage spento (magari prima di installare Solaris, ma non è mandatorio come ho letto in alcuni documenti sull'argomento).
Dopo le modifiche è bene dare un reset-all. Provare che la configurazione venga usata. Spegnere e riavviare a storage acceso. Avviare l'altro nodo per avere conferma.

SCSI Jbod in Sun Cluster

Si può definire questa guida un "cult" di Sun Cluster:

http://docs.sun.com/app/docs/doc/819-2995?l=en&q=sun+cluster+scsi_initiator_id&a=load

Ogni volta che vado a cercarla temo che possa essere stata rimossa. Descrive tra le altre cose come cablare un jbod scsi fisicamente e come settare OBP per far funzionare correttamente la catena scsi tra due nodi e uno o due vecchi storage scsi.

Base10/16 e jumpstarting solaris da linux troubles

Jumpstart da rete, da ambiente misto, server Linux che installa un sistema Solaris 10 su SPARC. Sto rifacendo il clusterino di casa. Come sempre rinfresco i passi da eseguire scorrendo la guida che ho scritto qualche anno fa. Sta qui .

Tutto bene. Finchè non c'è da linkare inetboot con ln -s nominandolo coll'esadecimale del IP della macchina bersaglio.

Qui mi impanico come al solito ... non riesco mai a ricordare come si fà.
Ma alla fine ci arrivo.
Ecco:

Prendi IP, convertilo in forma binaria e da lì a esadecimale!! Ora so dove cercare quando dovrò rifarlo e mi sarò dimenticato; se non entra non entra disse Siffredi in qualche suo film (almeno presumo, mi pare una battuta abbastanza scontata).

Stavolta ho dovuto anche improvvisare passando a obp il kernel da caricare; pareva non essere in grado di trovarlo. Quindi /platform/sun4v/kernel/unix
Probabilmente un effetto collaterale di nfsv4? Indagherò.

Indagato:
apt-get install nfs-user-server

rimuove l'implementazione kernel-nfs e installa quella userspace. Ci avevo preso, era un problema legato a incompatibilità tra nfs4 Solaris e Linux a quanto pare. Basta riavviare il processo dall'inizio e questo va avanti trovandosi il kernel da caricare.

Altra cosa. Se si usa il Network Manager su Linux, è bene disattivarlo o configurarlo perchè l'interfaccia che serve i dati abbia indirizzamento statico per evitare scherzi tipo che tiri giù l'interfaccia.

Altro simpatico problema:

svc.configd: smf(5) database integrity check of:

/etc/svc/repository.db

failed. The database might be damaged or a media error might have
prevented it from being verified.  Additional information useful to
your service provider is in:

/etc/svc/volatile/db_errors

The system will not be able to boot until you have restored a working
database.  svc.startd(1M) will provide a sulogin(1M) prompt for recovery
purposes.  The command:

/lib/svc/bin/restore_repository

Bla,Bla Bla ... il problema riguarda le opzioni di esportazione dei filesystems in /etc/exports.
La soluzione è esportare così:

/sol/Boot *(insecure,sync,ro,no_root_squash)
/vcdrom *(insecure,sync,ro,no_root_squash)

Ora dovrebbe andare.

Una descrizione di molti altri fastidiosi problemi incontrati in questo tipo d'installazione e relativa soluzione si trova qui

Snoop, Tcpdump e l'AND

Per catturare del traffico ci sono vari tools; da CLI i più conosciuti sono senza dubbio Snoop e Tcpdump. Mentre il primo è incluso in Solaris e sviluppato da Sun, Tcpdump è un progetto open source e disponibile per essere compilato sui più disparati sistemi operativi.

In genere io uso Snoop, lo conosco abbastanza bene ed è disponibile subito e di default su qualsiasi release di Solaris.

Su Linux, però, non c'è ... quindi se non c'è già, mi aggiusto con tcpdump.
I due tools hano molte similarità, almeno per quanto riguarda logica, sintassi e per la definizione di porzioni specifiche del flusso di pacchetti da catturare tramite espressioni.

Oggi, mi son bloccato su un particolare:

dovendo catturare il traffico proveniente da 192.168.2.1 e destinato alla porta 514, con Snoop avrei digitato:

# snoop -d ce2 ip src 192.168.2.1 port 514

Quindi vado deciso, controllo che tcpdump sia installato e:

# tcpdump -i ce2 ip src 192.168.2.1 port 514
tcpdump: syntax error

Mmh ... chiedo in IRC, nei canali che frequento; la soluzione sta com'è ovvio, nella sintassi:
avevo già notato che ip src e port usate una alla volta funzionavano, inoltre sapevo e mi sono sincerato guardando il man, che fossero keyword esistenti;
comunque ... Tcpdump, a differenza di Snoop, vuole l'AND, quindi:

# tcpdump -i ce2 ip src 192.168.2.1 and port 514

Funziona.
Snoop, comunque, accetta l'and, sebbene lo sottintenda se non specificato.
Da ricordare. Risolto.

Escapare caratteri speciali su Blogger

Nel post precedente dovevo digitare <<EOF ma non ci riuscivo. Veniva interpretato come tag errato. Dopo un breve ricerca ho trovato come fare l'escape di alcuni caratteri:

< diventa &lt;
> diventa &gt;
© diventa &copy;
& diventa &amp;
" diventa &quot;

Riassunti qua sopra. Grazie all'autore di Anilinux per il tip leggibile qui su Anilinux

Mount e l'opzione size

Una opzione di mount e' size. Questa option dipende dal filesystem in uso. Su Solaris, ad esempio, non e' disponibile con UFS, ma e' usabile con TMPFS. Offre quindi la possibilita' di decidere a boot-time la dimensione del tmpfs

Cosi':

# mount -F tmpfs -o size=1g swap /tmp

Oppure permanente:

# cat /etc/vfstab
swap - /tmp tmpfs - yes size=Xg

Files in uso ma rimossi: trovarli

Ringrazio Massimo per questa segnalazione che annoto di seguito qui pronto per essere trovato quando mi serve:

In questo post (http://wikis.sun.com/display/BigAdmin/Checking+for+Deleted+Files+Held+Open+in+UFS+File+Systems) in fondo c'è un commento dove si suggerisce di usare il "find" per scovare processi che hanno files aperti ma cancellati.

Il comando è:

find /proc/*/fd -type f -links 0 -exec ls -l {} \;

Lo segnalo giusto come elemento di analisi in più per quelle situazioni "simili" già capitate in passato.

Rimuovere shared QFS

Un QFS shared su una LUN mappata dall'array a 4 hosts.
Rimuovere due hosts.
Oltre all'editing del file hosts.xxx sulle macchine rimanenti per eliminare i riferimenti a quelle da rimuovere è fondamentale:
* smontare il filesystem
* lanciare samsharefs -Ru
* samd config
* stoppare il qfs sulle macchine rimosse
* rinominare files hosts.xxx e mcf sulle macchine rimosse
* importante ... nel file inittab delle macchine rimosse, c'è una entry che riguarda il QFS che causa il respawn del demone sam-fsd, questa va COMMENTATA!! In caso contrario, nonostante lo stop dei demoni tramite script presente /etc/init.d/ le macchine continueranno a inviare richieste a quella che è conosciuta come l'ultimo host server del filesystem shared; di per sè non causa nulla di male saltare questo passo, ma non è pulito e, non si sa mai, potrebbe causare o essere concausa di problemi
* sulle macchine rimanenti samd config restituisce un errore che seppur non bloccante, fa ben capire che non ha del tutto digerito i cambiamenti; infatti, parla di qualche problema con le macchien eliminate. Questo viene fixato da un reboot, potrebbe esserci altra soluzione ma non la conosco
* Rimuovere le entries del filesystem qfs dal file /etc/vfstab delle macchine rimosse
* Last but not least: switchare il server da una macchina all'altra per assicurarsi che tutto funzioni a dovere.

lofs delirium

Un amico mi chiama sottoponendomi un problema che sta avendo.
Riguarda un'immagine iso montata sotto Solaris, che non si comporta come dovrebbe o ... come lui vorrebbe.
Dice di aver creato il lofs con lofiadm e di averlo montato con successo. Al momento di accedere al mountpoint, però, riceve un:

cd /mnt2
-bash: cd: /mnt2: Not a directory

mmh.
Allora si parte con le domande di rito:
Fai un ls -la di /mnt2:
ls -la /mnt2
brw------- 1 root sys 144, 1 mag 18 21:19 /mnt2

Mmmhh, un block device file. Qualcosa non quadra. Sarebbe necessario capire cosa ha fatto durante la procedura di creazione del loFS e del successivo mount.

Niente history... ma dopo qualche smanettamento infruttuoso m'illumino:
Smonto il filesystem e distruggo il device file; notando che /mnt2 non è una directory ma un device file, sono convinto che abbia montato il device specificando a mount non che si tratta di un'immagine iso, ma appunto di un lofs ... che si può assimilare a distrazione o più probabilmente al fatto di conoscere la procedura, essersi distratto e non aver ben capito cosa si stia facendo. Quindi mount l'ha montato come quello che è, ragionando correttamente (almeno lui).

Ora da vuoto, rifaccio tutto:
creo il device con lofiadm, /dev/lofi/1 , poi creo la dir /mnt2, e lo monto:
mount -F hsfs /dev/lofi/1 /mnt2

df -h|grep lofi
/dev/lofi/1 450M 450M 0K 100% /mnt2

cd /mnt2
ls
sparc worm x64

Perfetto. Funziona.
Il problema è riproducibile, dopo aver creato il lofs desiderato, montandolo cosi:

mount -F lofs /dev/lofi/1 /mnt2

e verificando che /mnt2 è un block device file e non il mountpoint sotto il quale si voleva montare la iso.
Distrazione o errato ragionamento.
Morale;
Montando un loFS, bisogna specificare il tipo di FS al quale esso fa riferimento, e non definendolo come loFS, quando si usa l'opzione -F di mount.

Struttura lo script, Debugga lo script

Pare banale saperlo, ma ci sono volte in cui diventa di fondamentale importanza per sistemare uno script usare gli strumenti giusti.

Ad esempio quando lo script ha dimensioni medio-grandi e gli errori non balzano subito all'occhio.

A me capita di scrivere i miei scripts bash ( si, uso bash, nessuno è perfetto, ed è una delle cose che mi porto dietro da Linux e che non ho mai corretto con un po di sana Korn o C shell, vabbè) di getto, dopo aver gettato una base un minimo strutturata, fondamentale perchè lo script abbia senso e magari sia customizzabile/espandibile in futuro, tiro giù il codice di botto senza preoccuparmi di testare riga per riga e facendo un sacco di errori di sintassi. Questo mi permette di concentrarmi sulla forma e struttura, e di renderlo "usabile successivamente, a lavoro finito. Stare attento a sintassi e piccolezze mi distrae e mi fa perdere l'attenzione allo scrivere qualcosa di davvero funzionale.

Poi viene la correzione assieme al test. E gli errori sintattici non si contano, in genere dimentico i ; o le $ davanti alle variabili, do nomi assurdi alle stesse variabili o cicco per l'ennesima volta la struttura dei cicli, in ultimo dimentico i fi alla fine degli if/else, per non parlare di parentesi o apici.

Una cosa molto utile in questi casi è l'uso delle opzioni di bash -xv direttamente al prompt con un:
# bash -xv script.sh

oppure all'interno dello script passandolo alla dichiarazione della shell in prima riga:
#!/usr/bin/bash -xv

Il risultato è a dir poco eclatante.

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

Cambiare l'ID di un controller

Preparo un cluster due nodi, Solaris10, Sun cluster 3.2, un bunch di risorse e il RACche installerà il DBA.
Pasticciando con l'initiator-scsi (si, è uno StorEdge Scsi Jbod abbastanza vetusto a fare da shared disk container), mi ritrovo alla fine con c1 come controller connesso al Jbod sul primo nodo e c2 sul secondo.

Mode Ricerca ON

Trovo una risposta molto sintetica ma di inestimabile valore, ed è nientemeno che D. Dhunam a darla sui forums di Sun:

You might try renaming the links in /dev/cfg to how you want, then deleting the /dev links for the c1 and c2 devices, then doing a reconfiguration reboot.

Mode Ricerca OFF
Presto fatto:
cd /dev/cfg
ls -l
lrwxrwxrwx 1 root root 40 Jul 31 14:14 c2 -> ../../devices/pci@1f,0/pci@1/scsi@4:scsi
lrwxrwxrwx 1 root root 53 Jul 31 14:14 c1 -> ../../devices/pci@1f,0/pci@1/pci@2/SUNW,isptwo@4:scsi

mv c1 c3
mv c2 c1
rm -rf /dev/rdsk/c2*
rm -rf /dev/dsk/c2*
reboot -- -rv

Funziona!
Andiamo avanti con l'installazione