Solaris 11 Express OUT!! Upgrade da snv_145

alex@sunbox:~$ ssh oper@depot
Password:
Last login: Thu Nov 18 11:14:52 2010 from sunbox.sanluigi
Oracle Corporation SunOS 5.11 snv_151a November 2010
oper@filebox:~$ head -1 /etc/release
Oracle Solaris 11 Express snv_151a X86

E' uscito, con una marea di aspettative, installato ora! E' una snv_151 upgradabile dal "vecchio" Opensolaris b134/b134b.
In realta' si puo' passare a questa release ufficiale anche da versioni successive. Personalmente ho upgradato da una 145. E' sufficiente forzare l'image-update.

pkg image-update -v -f --be-name sx11_151 --accept

La v e' verbose, f forza l'upgrade anche se l'incorporation non matcha, be-name gli da un nome decente e accept e' una novita': serve ad accettare la licenza d'uso, senza il comando stampa a schermo la licenza ed esce.

Occhio a eventuale upgrade da openindiana oi_147:
ho letto di problemi con il versioning dello zpool; in pratica sx11 non lo riconosce e chiede "giustamente" di fare un bel blowup

Ho appena aggiornato il fileserver cifs, che arriva da una Opensolaris 2009.6 upgrade dopo upgrade ... icap, vscan, cifs e i due zpool raid1 sembrano funzionare, vediamo se reggono allo stress della giornata.

Ora stiamo a vedere che combina Oracle col piu' bel sistema operativo a disposizione ...

Compilare IllumOS

Tante cose successe dopo l'acquisizione Oracle di Sun.
Sicuramente c'è da gioire perchè si spera in un grande Solaris 11 che sarà di nuovo il più moderno e "VENDUTO" sistema operativo unix Enterprise.

Per quanto riguarda Opensolaris e l'open source, invece, solo schiaffi:
Opensolaris è morto!!

Il progetto fork IllumOS ne vuole prendere il posto. Ecco le istruzioni per compilare i nuovi bits:

http://www.illumos.org/projects/illumos-gate/wiki/How_To_Build_Illumos

Mirroring rootvg su aix

Aggiungere hdisk1 al Volume Group:

# extendvg rootvg hdisk1

Dire a lvm di fare un mirror:

# mirrorvg rootvg
0516-1804 chvg: The quorum change takes effect immediately.
0516-1126 mirrorvg: rootvg successfully mirrored, user should perform
bosboot of system to initialize boot records. Then, user must modify
bootlist to include: hdisk0 hdisk1.

Aggiungere il nuovo disco a quelli bootabili:

# bootlist -m normal hdisk0 hdisk1

Installare il necessario per bootare il nuovo mirror:

# bosboot -ad hdisk0
# bosboot -ad hdisk1

Voila, les jeux sont faites:

#lspv
hdisk0 003639ba5bd2ab8f rootvg active
hdisk1 005fd68c35102992 rootvg active

Globaldevices su LOFI

Ora Sun Cluster permette di utilizzare un device LOFI per il Global Device Namespace.
E' sufficiente creare un file con mkfile (di almeno 100 Mb) e passarlo a lofiadm.
Con scinstall in typical mode viene poi richiesto se si vuole usare un LOFS come globaldevice.

Pressochè inutile ... direte ... si, se non si pensa di dover mettere Sun Cluster su una macchina già con Solaris preinstallato senza spazio su disco per creare una slice da dedicare al Global Device Namespace.

Info 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...

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/

Sun cluster 3.2: Non-Storage Topology e Interconnect Singolo

Leggendo la Student Guide di Sun Cluster Administration (ogni tanto mi porto avanti con lo studio per la certificazione), nel capitolo riguardante le topologie possibili scopro la Non-Storage Topology. In pratica, è una configurazione senza shared-storage, possibile solo con Sun Cluster 3.2 . Infatti, da come la sapevo io, uno storage condiviso è mandatorio per formare il cluster e soprattutto per il quorum device. Naturalmente con questa topologia è necessario utilizzare un altro tipo di quorum, ad esempio il nuovo quorum server, che può stare su una terza macchina e servire da voting device per N clusters.

Inoltre, testando oggi la nuova update 2 di Sun Cluster, noto la possibilità di avere un solo cluster interconnect, cosa che prima non era fattibile, nè poteva essere in alcun modo definita.

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

Wireless iface su linux (ACX111): note d'installazione

E' un sacco di tempo, ormai, che connetto i miei pc, che stanno in camera, al router in soggiorno, via wireless. Mi affido con successo a Dlink con chip Atheros e driver madwifi.
Per il nuovo arrivato ho a disposizione due schede pci: una Belkin/Broadcom e una U.S Robotics con chip Texas Instrument.

Opto per la seconda, e procedo con l'installazione. Questa macchina ha su una debian installata da chiavetta con una ISO netinstall (mi piace fare da zero, scegliere e installare subito roba relativamente aggiornata.
Dopo il reboot, il nuovo pc, routato via ethernet su internet da un'altro pc come soluzione temporanea, ha bisogno di essere indipendente e avere la sua wireless.

Su debian procedo all'incirca così: nella repository ci sono i sorgenti del driver acx. Quindi li tiro giù assieme a module-assistant e agli headers del kernel per la versione attualmente in uso.

apt-get install module-assistant acx100-source

Lancio il tool, che si occupa di automatizzare quello che un tempo si faceva a manina; scompattare, compilare per benino e crearmi il pacchetto .deb da installare.
Ne risulta un acx100-2.6.26-1-686_20070101-3+2.6.26-13_i386.deb da installare via dpkg.

cd /fw/acx111_1.2.1.34
cp * /lib/firmware
modprobe acx

Fatto. Vediamo che dicono i logs:

Feb 7 10:45:52 debian kernel: [29017.574442] acx: compiled to use 32bit I/O access. I/O timing issues might occur, such as non-working firmware upload. Report them
Feb 7 10:45:52 debian kernel: [29017.589967] acx: need to load firmware for acx111 chipset with radio ID 16, please provide via firmware hotplug:
Feb 7 10:45:52 debian kernel: [29017.589971] acx: either one file only (ombined firmware image file, radio-specific) or two files (radio-less base image file *plus* separate adio-specific extension file)
Feb 7 10:45:52 debian kernel: [29017.590080] requesting firmware image 'tiacx111c16'
Feb 7 10:45:52 debian kernel: [29017.590106] firmware: requesting tiacx111c16
Feb 7 10:45:53 debian kernel: [29018.378579] acx: === chipset TNETW1130, radio type 0x16 (Radia), form factor 0x01 ((mini-)PCI / CardBus), EEPROM version 0x05: uploaded firmware 'Rev 1.2.1.34' ===

Sono contenti. Caricata e funzionante. iwconfig parla di una interfaccia wlan0, che è proprio lei!

Veritas Cluster: aggiungere un nodo e un pò di teoria

Installare Veritas cluster su un secondo o terzo nodo è molto semplice.
E' sufficiente fare un'installazione manuale del software o usare i tools.
E' possibile lanciare l'installer principale di Storage Foundation HA; a me piace usare rsh durante l'installazione (anche di Sun Cluster e il CRS di Oracle), e poi disabilitarlo successivamente.
Cosa da fare presto o tardi è aggiungere /opt/VRTS/bin al $PATH

# ./installer -rsh

Scegliere 1 e poi l'installazione senza configurazione.
Alternativa è installare i pacchetti a mano (parlo di Solaris in questo caso):

# pkgadd -d . VRTSjacs
# pkgadd -d . VRTSjacsd
# pkgadd -d . VRTSjacsj
# pkgadd -d . VRTSjacsm
# pkgadd -d . VRTSjacsu

In questo secondo caso bisogna aggiungere la licenza d'uso che sia essa demo o permanente:

vxlicinst -k XXXX-XXXX-XXXX-XXXX-XXXX-XXX

da verificare con vxlicrep|more.

Una volta terminata l'operazione è possibile passare alla configurazione del nuovo nodo e alla modifica di alcuni files sul/sui nodo/i preesistente/i.

Prima cosa da fare è disporre la comunicazione tra i nodi. di questo compito si occupano LLT e GAB.
Ma cosa sono:
LLT è l'infrastruttura di interconnessione tra i nodi, comprendente le interfacce adibite a questo compito, che è bene siano almeno due per nodo. La gestione delle NIC e dei media di interconnessione avviene in modo trasparente, il traffico viene bilanciato sugli interconnects disponibili; nel caso un'interconnessione venga a mancare vengono usate le altre.
GAB si occupa e si tratta proprio della comunicazione tra i nodi, ovvero dell'heartbeat necessario ai nodi per "sentire" la presenza degli altri. Inoltre tutti gli scambi di informazioni riguardanti cambi di configurazione o failures in qualunque punto del cluster avvengono grazie a GAB. Lui comunica con HAD, il motore del cluster presente sui nodi e intermediario tra i gestori di risorse e LLT/GAB.

I files da editare sono:
/etc/llthosts /etc/llttab /etc/gabtab

Nel nostro cluster, basato su Solaris10 e composto di due nodi aventi una interfaccia pubblica e due di interconnessione tra i nodi dovremo ritrovarci con questi contenuti:

Su entrambi i nodi, qui c'è la lista dei nodi con davanti un numero progressivo

# cat /etc/llthosts
0 sunbox1
1 sunbox2

Sul nodo già attivo, avete questo (a meno che non avete attivato LLT e GAB quando avete installato). Le direttive LLT che vedete di seguito dicono
set-node vuole il nome del nodo in questione
set-cluster vuole l'identificativo numerico del cluster

root@sunbox1 / # cat /etc/llttab
set-node sunbox1
set-cluster 1
link hme1 /dev/hme:1 - ether - -
link hme2 /dev/hme:2 - ether -

Sul secondo e nuovo nodo creerete un file coerente con quanto visto sopra, premurandovi di mettere il nome del nodo su cui siete in set-node. Le ultime due righe identificano le interconnessioni 1 e 2 assegnandogli le NIC

root@sunbox2 / # cat /etc/llttab
set-node sunbox2
set-cluster 1
link hme1 /dev/hme:1 - ether - -
link hme2 /dev/hme:2 - ether - -

Questo file contiene l'eseguibile gabconfig. Il parametro -n specifica il nuovo numero di nodi che formano il cluster

# cat /etc/gabtab
/sbin/gabconfig -c -n2

Sul nuovo nodo è necessario digitare il comando:

#/sbin/gabconfig -c

per rendere effettiva la configurazione. Ora verificatela con:

root@sunbox1 / # gabconfig -a
GAB Port Memberships
===============================================================
Port a gen 2f0a01 membership 01
Port a gen 2f0a01 jeopardy ;1
Port h gen 2f0a04 membership 01
Port h gen 2f0a04 jeopardy ;1

Un output molto simile significa che ci siete!!

Ora che l'interconnessione è presente, bisogna aggiungere al cluster il nodo passandogli la configurazione, dal nodo preesistente:

#haconf -makerw
#hasys -add sunbox2
#hastop -sys sunbox2
#rcp /etc/VRTSvcs/conf/config/main.cf sunbox2:/etc/VRTSvcs/conf/
config/

Sul nuovo nodo digitate:

#hastart

per avviarlo

E poi rendete di nuovo read-only la configurazione:

# haconf -dump -makero

Questo modesto how-to è pubblicato su AreaNetworking e visibile qui

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

LAOP: Php e Oracle su Linux

Smanettando con Oracle ho deciso di interfacciarmici con un linguaggio che già conosco e col quale ho realizzato qualche piccola applicazioncina, solitamente usando come backend mySQL.

L'installazione di Oracle su Debian 32bit, e successivo patching alla 10.2.0.4 è stato abbastanza painless. Ho scelto Oracle Database Enterprise Edition, anzichè Oracle XE, per il quale sono forniti binari pacchettizati deb; più che altro per uniformità con la versione che mi ritrovo in ambienti di produzione al lavoro. Tempo fa, lo avevo installato su un HP con Gentoo 64bit e fu dura; questa volta invece tutto liscio.
E' stato sufficiente esportare il display e lanciare la GUI d'installazione con un unico parametro:

#./runInstaller -ignoreSysPrereqs

Questo permette di poter installare senza che venga eseguito il check di sistema operativo e versione; infatti, se non è tra gli OSes supportati, l'OUI (Oracle Universal Installer) esce e quitta.
Per il patching da 10.2.0.1 a 10.2.0.4 è sufficiente fare la stessa cosa descritta qui sopra. Naturalmente ho omesso alcuni passi di preparazione dell'installazione tra cui la creazione dell'utente e l'impostazione dell'ambiente.

Per Apache e Php basta il solito apt-get install. Dopodichè consiglio di verificare che tutto funzioni mettendo il file index.php in /var/www con i contenuti che seguono:

phpinfo():
?>

Manca solo interfacciare PHP a Oracle. Per questo mi son rifatto a una procedura veloce e pulita, descritta sul sito morse.nl

In breve:

#apt-get install php5-dev php-pear

Il secondo fornisce il comando pecl da usare per installare l'estensione Oracle oci8. E' sufficiente passargli la $ORACLE_HOME quando verrà richiesto il PATH dove risiede l'Instantclient. Quest'ultimo sarebbe da installare precedentemente ai pacchetti qui sopra, nel caso la parte server di Oracle risiedesse su un'altro sistema.

Una piccola modifica ancora

#echo "extension=oci8.so" >> /etc/php5/apache2/php.ini

e siamo a posto. Restartando Apache e accedendo di nuovo alla index.php creata prima, è possibile vedere i riferimenti all'estensione oci8.

Questa è una delle possibili configurazioni per poter utilizzare un db Oracle come backend per PHP. Per altre possibilità e un mucchio di informazioni utili in 195 pagine, ci si può rifare al pdf:

The Underground PHP and Oracle Manual