AD Domain Controller fault CIFS log

Ieri c'è stato un major fault sul dominio qui dal cliente. A causa di uno switch critico (non ridondante) il domain controller è stato irreperibile per parecchio tempo.

Il fileserver Solaris (che è in join al dominio) e idmapd se ne sono accorti e hanno loggato regolarmente.

Ecco quando è andato giù ed è tornato su.

Feb 15 11:18:19 filebox idmapd[293]: [ID 696364 daemon.error] Degraded operation (Global Catalog servers not configured/discoverable). If you are running an SMB server in workgroup mode, or if you're not running an SMB server, then you can ignore this message

Feb 15 14:43:57 filebox idmapd[293]: [ID 643943 daemon.notice] Normal operation restored

Cisco IOS: scripting con Tcl

Mentre preparavo uno script perl per eseguire una serie di comandi da remoto sul mio Cisco, una ricerca su Google, mi porta a una scoperta molto interessante. Mi ha stupito, che, di ciò che segue, non ne ho mai sentito parola, ne da colleghi specializzati, ne durante lo studio sul programma CCNA, ne nei luoghi di discussione quali forums, irc chat ecc. IOS contiene un linguaggio di scripting: TCL, pronunciabile tickle. Non è certo il più famoso scripting language, ma c'è, ed è molto maturo. Basta, in enable mode, digitare tclsh: wallbox#tclsh wallbox(tcl)# e per uscire tclquit. E' disponibile dalle seguenti releases in poi nella versione 12.2 (25 della T) e 12.3 (2 della S). La CLI diventa ibrida ed è possibile quindi utilizzarla anche per digitare comandi IOS. Informazioni qui e qui

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/

Come fare: Connesione Xdmcp

Mi capita di volermi connettere a un desktop linux remoto per vari motivi. Odio VNC e simili, per il semplice fatto che non sono integrati o nativi del sistema. X ha già ciò che serve per realizzare una sessione remota; non tutti lo sanno ... e vedo in continuazione clienti che usano VNC ignari degli strumenti integrati nel proprio OS; addirittura sui servers!! Tutto ciò per poi magari aprire un xterm da CDE o Gnome e dare due comandi, cosa che potevano benissimo fare con ssh. tsclient è una GUI per connettersi a un host remoto e supporta vari protocolli tra cui RDP, VNC, ICA e il nostro amico XDMCP. Per "attivarne" il supporto basta installare i binari necessari. Su Debian servono i seguenti pacchetti:

RDP --> rdesktop VNC --> xvnc4viewer o uno dei molteplici cloni disponibili. ICA --> icaclient di cytrix (non in repository XDMCP --> xnest

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

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.

Protocollo DNS e le sue debolezze

Si è parlato molto della recente "scoperta" della grave vulnerabilità propria del protocollo DNS. Vulnerabilità causata da un problema di design e che quindi interessa molte, forse tutte le implementazioni software in circolazione.

E' stato trovato un workaround e le patches sono arrivate in tempi brevi; come al solito mi chiedo chi tra coloro che sono a rischio si è occupato di patchare.
Noi l'abbiamo fatto (tra l'altro grazie a questo ho scoperto cose che ignoravo) e la falla, diciamo, è stata tappata alla buona. La soluzione finale è, comunque, passare a DNSSEC, che per come è stato pensato, non può soffrire del problema del fratello protocollo più anziano.

Parlandone con la mia compagna, che è entrata in tempi recenti nel mondo lavorativo IT, mi ha chiesto di spiegarle, con un esempio, il problema.

E allora le ho risposto, che se ho ben capito io stesso, può immaginare questo:

"Il tuo conto BancoPosta al quale accedi quando hai bisogno di effettuare operazioni, potrebbe essere un bersaglio. Il problema che un attaccante può sfruttare nei DNS è l'avvelenamento della cache. Il nome del sito che normalmente viene risolto a 62.241.4.82, viene cambiato a un'altro dove risiede una copia contraffatta dello stesso. La vittima non se ne accorge facilmente, inoltre le pagine fasulle, hanno links che puntano a url familiari e corrette, a differenza dei siti di pishing, dove ci si accorge della truffa verificando i links e notando che puntano a indirizzi estranei e non conformi alle pagine originali che vorremmo visitare.
Quindi è possibile che non ci si accorga della truffa, o che ci si riesca troppo tardi."

Con un pò di fantasia si può pensare ad altri attacchi, quindi la situazione è piuttosto tesa, e le continue raccomandazioni a patchare ne sono prova.
Inoltre è uscito l'exploit, cosicchè, chi non è in grado di fabbricarsene uno, può sfruttare questo. E' contenuto in Metasploit, un tool per penetration testing, IDS e simili.

Qui una descrizione della vulnerabilità: http://www.kb.cert.org/vuls/id/800113

E la pagina dell'ISC, curatori di BIND, contenente l'advisory:

YOU ARE ADVISED TO INSTALL EITHER THE PATCHES, STAYING WITHIN YOUR MAJOR VERSION, (9.5.0-P1, 9.4.2-P1, 9.3.5-P1) OR THE NEW BETA RELEASES (9.5.1b1, 9.4.3b2) IMMEDIATELY.

The patches will have a noticeable impact on the performance of BIND caching resolvers with query rates at or above 10,000 queries per second. The beta releases include optimized code that will reduce the impact in performance to non-significant levels.

Trovate il resto qui: http://www.isc.org/sw/bind/bind-security.php

Cisco "do" it!

Molti non lo sanno.
Questo è un trick che mi ha passato l'amico Norsys di Areanetworking qualche anno fa.

Su un apparato Cisco con IOS, se non sbaglio (correggetemi non ho voglia di verificare) dalla versione 12 in sù, in qualsiasi modalità operativa ci si trovi, è possibile dare comandi che normalmente sono disponibili e si usano da altra modalità. E' sufficiente utilizzare il comando do.

Mi spiego, in "conf t", il comando show semplicemente non c'è, con do è possibile usarlo.
Osservate:

>en
#conf t
(config)#do show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

Router(config)#


OK? Comprìs? Eccezionale quando lo si scopre, il mondo cambia angolazione :)))

VPN e Desktop remoto; lusso!!

Con la capacità di banda delle connessioni, al giorno d'oggi ci si può "scialare" e offrirsi qualche lusso quando necessario.
Tipo una sessione X remota dalla macchina linux di casa alla workstation Solaris in ufficio?
VPN, rdesktop e magari tsclient sono ciò di cui si ha bisogno.
Per la vpn uso quasi esclusivamente vpnc che funziona egregiamente su qualsiasi sistema operativo; o almeno, io lo uso con successo su diversi flavours di Linux, FreeBSD 8, Solaris 10 e Solaris Express, sebbene questi ultimi due hanno necessitato di qualche ora di scervellamento.
xdmpc e tsclient sono anch'essi disponibili ovunque e laddove non è possibile averli, installare un server vnc è decente alternativa; la cosa carina di tsclient è che offre una gestione centralizzata con possibilità di salvare i profili per le connessioni desktop remoto coi protocolli xdmpc, vnc, rdp, rdp5.

Ultimamente, nei giorni in cui "telelavoro" da casa via vpn Trento-Torino, farcito di Alice 20 Mbit, produco egregiamente, fermandomi solo per pensare quanto il telelavoro in Italia sia un sogno per pochi, e quanti benefici darebbe utilizzarlo.

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.

Sono SCNA

Niente di speciale, si.
Mi aspettavo qualcosa di molto più difficile, invece o so bene la lezione, oppure...
Però è una soddisfazione non da poco, e come per la precedente SCSA c'è un che di fierezza.
Che è poi il motivo primo per cui ci si certifica (almeno spero sia così per tutti, non penserete mi ca di trovare lavoro o amenità simili solo perchè rispondete giusto a un test? Io non vi assumerei mai perchè siete SCSA o SCNA, tanto più ora che ho le certs in mano).

Ora credo che continuerò il terzetto di certs Solaris andando per la Certified Security Administrator, anche se le certificazioni Sun Cluster (ci sono le 3.2 adesso) sono sicuramente il mio fine ultimo in fatto di certificazioni; anche la soglia minima percentuale è leggermente più alta per quest'ultima.
A mio avviso, il punteggio per essere certificati Sun è scandalosamente basso, se comparato a certs quali quelle Cisco o simili: e questo sta alla base della svalutazione che faccio.

E' vero che ci sono profonde differenze: Sun è molto più pratica e ci vuole un minimo di esperienza reale per ottenere anche la più basica cert, tipo la SCSA (che comunque mette davanti a due esami), ma secondo me si dovrebbe alzare la soglia Passed di almeno 15 punti percentuali per tutte le certificazioni.

Mi prendo qualche tempo per pensarci...

Ah , era un 82%