Spesso si sente ripetere in modo un po’ banale che la condizione necessaria per un backup consistente è il test di restore, io di solito considero necessarie queste condizioni:

• il backup deve essere fatto (…)
• va effettuato un test di restore periodico
• il backup deve essere schdulato e automatico (non deve dipendere da azioni manuali)
• il backup deve inviare notifiche su eventuali anomalie occorse durante la schedulazione

Quest’ultimo aspetto ahimè è spesso ignorato, oppure ci si affida a notifiche inviate a prescindere senza distinguere l’effettivo esito del processo (troppe informazioni che inevitabilmente comportano la mancata rilevazione di un problema).

Questa la premessa, come ho già avuto modo di dire mi capita spesso di sguazzare tra vecchi ruderi informatici sparsi per i datacenter più insospettabili, di recente mi è capitato di mettere le mani su un server MS SQL (brrr…) 2000 (brrr²….) con piani di manutenzione disastrati e backup in uno stato di completo abbandono.
Come solo i vecchi sistemisti ricorderanno MS SQL 2000 richiede ufficialmente l’utilizzo di Exchange (brrrr³…) per inviare notifiche email sull’esito dei maintenance plan, un autentico furto a mano armata…

Come alternativa propongo questa semplice soluzione che non comporta alcuno stravolgimento architetturale ed è applicabile anche a versioni più recenti del database MS (che per fortuna hanno colmato questa lacuna con apposite procedure).

Prosegui con la lettura »

Durante qualche scorribanda sistemistica potrebbe capitare anche voi di trovarvi nella spiacevole condizione di non riuscire a installare un semplice package rpm su una delle distribuzioni GNU/Linux derivate da RedHat.

A me è capitato di recente mentre mi accingevo ad installare l’agente EMC² Networker su un server presso un cliente, il triste errore è il seguente:

Controllando meglio il server (fresco fresco di installazione e quindi non ancora sotto monitoraggio) mi sono accorto che il volume montato in /var risultava completamente saturo, motivo per cui il package manager non è riuscito ad aggiornare il database locale.

Anche dopo aver esteso il volume però il risultato non ha accennato a migliorare, sintomo che doveva essere successo qualcosa di spiacevole al suddetto database rpm. Vista la situazione non è rimasto altro da fare che cancellarlo…

…e ricostruirlo mediante il comando “rpm –rebuilddb”, al termine del quale l’installazione del package si concluso con esito splendido splendente.

Generalmente preferisco non usare troppe estensioni sui miei browser (principalmente Firefox e Chrome) per non ritrovarmi i browser “seduti” oppure per rendere un eventuali disinstallazione e reinstallazione snella e veloce (guardacaso mi è successo pochi giorni fa dopo l’ennesimo upgrade di Firefox).

Une estensione di Firefox a cui però non riesco proprio a rinunciare è MM3 Proxy switch, che come suggerisce il nome serve ad attivare, disattivare o cambiare impostazioni del proxy in modo pratico e veloce.
Esistono parecchie altre estensioni che fanno tutto questo, ma tra tutte quelle che ho provato questa mi è sempre sembrata la più leggera e semplice da usare, riassumendo: un click per attivare il proxy, un click per disattivare il proxy, una dropdown per selezionare i vari profili e un file di configurazione semplice da editare al volo.

Essendo una estensione di Firefox utilizza la stessa sintassi per definire le eventuali esclusioni di indirizzi, sottoreti, hostname o domini, se doveste avere dubbi trovate una veloce guida a questo link.

Come dicevo poco sopra la sintassi della configurazione è decisamente semplice, ogni profilo è delimitato da parentesi quadre, è possibile definire un proxy differente a seconda del protocollo utilizzato (http, ftp, ssl o socks) oppure per tutti i protocolli (all) e infine definire le esclusioni (noProxy).

[Proxy1
  all=10.0.0.1:8080
  noProxy=127.0.0.1, 10.0.0.0/8, 81.82.83.0/24, dominio.tld, ced.azienda.local
  clear=cache
]
[Proxy2
  http=10.0.0.2:3128
  http=10.0.0.2:3128
  ftp=10.0.0.3:80
  noProxy=127.0.0.1, 10.0.0.0/8, 81.82.83.0/24, dominio.tld, ced.azienda.local
  clear=cache 
]
[SocksSSH
   socks=127.0.0.1:777
   config:network.proxy.socks_remote_dns=true
   noProxy=127.0.0.1, 192.168.0.0/24, domain.external.local
   clear=cache
]

Ottimo software imho, l’unica miglioria possibile potrebbe essere quella di aggiungere una direttiva di configurazione che permetta di lanciare uno script al cambio di profilo, pensiamo ad esempio all’avvio di una connessione ssh che incapsuli il traffico del proxy (via http o socks, vedi ad esempio il profilo SocksSSH di esempio con proxy socks in ascolto sulla porta 777) .

Trovandomi spesso a lavorare con vecchi catorci non è infrequente che abbia a che fare con vecchi database Oracle 9i a cui puntalmente manca storage (o quantomeno non avanza mai…).
Spesso poi si tratta di database che girano in modalità no archivelog (e non sia mai che si modifichi una virgola di un servizio che funziona, nemmeno quando può migliorare sensibilmente la vita e la manutenibilità del servizio… :\ ) e su cui l’unica forma di backup è la classica export omnicomprensiva (tanto poi in caso di disastro c’è sempre il dba pirla che ricostruisce tutto e importa il dump…).

A questo aggiungete che solo da Oracle 10g è possibile effettuare export compresse mediante data pump, ecco quindi che si rende necessario adottare i cosidetti “accrocchi con gli stecchini e nastro adesivo”, insomma una sorta di puntata di MacGyver in salsa Oracle…

Ecco quindi la soluzione, utilizzare il buon vecchio mknod per creare una pipe in cui infilare l’output del dump, redirigendo l’output su gzip, redirigendo l’output dello stesso su filesystem sottoforma di file compresso.
Detto così sembra complicato, in realtà si tratta del solito gioco di scatole cinesi e redirezioni di output (non di uno stream di testo ma di binari, la sostanza non cambia), quello che mi sono sempre chiesto è perchè Oracle non abbia mai rilasciato un piccolo aggiornamento per fare quello che qualsiasi server unix like può fare dalla notte dei tempi… e Mr Ellison non mi venga a dire che gli mancano le risorse…

Ovviamente il suddetto script bash funziona esclusivamente su GNU/Linux o sistemi operativi unix like, se usate Oracle su Windows non vi resta che cospargevi il capo di cenere, attaccarvi al tram e urlare in curva :D

export ORACLE_SID=<SID DATABASE>
dstr=$(date '+%Y%m%d-%H%M%S')
exp_dir=<DIRECTORY DESTINAZIONE EXPORT>
pfile=$exp_dir/p$dstr
dmptempl=$exp_dir/${ORACLE_SID}_
dmpfile=${dmptempl}$dstr.dmp.gz
logfile=${dmptempl}$dstr.log

$(which mknod) $pfile p
cat $pfile | $(which gzip) -6 -c > $dmpfile &
exp <UTENTE>/<PASSWORD> file=$pfile full=y direct=y consistent=y \
recordlength=65535 buffer=20000000 log=$logfile statistics=none
rm -f $pfile

Lavorando con WebSEAL su un virtualhost junction mi è recentemente capitato di avere qualche disguido, nello specifico si è trattato di un virtualhost junction ad accesso riservato dove l’applicazione di backend in single sign-on catturava lo UID dell’utente (passato tramite variabile IV_USER) e lo utilizzava per attività di vario genere.
Abbiamo osservato una anomalia quando l’utente effettuava la login inserendo degli spazi in coda allo username (es “utente   ” anzichè “utente”), mentre WebSEAL lo autenticava correttamente l’applicazione di backend generava una serie di eccezioni che si manifestavano con un loop continuo di richieste http.

Verificando l’anomalia ho provato a riprodurla su un ambiente di sviluppo, ricreando il virtualhost junction nello stesso modo e associando all’oggetto l’acl per forzare la login (all_auth).

In questo caso ho utilizzato come risorsa di backend un banalissimo webserver php dove ho piazzata una semplicissima pagina (headers.php) che estraesse le variabili passate da WebSEAL (-c all), in particolare la variabile IV_USER:

<?php
$user = $_SERVER['HTTP_IV_USER'];
$groups = $_SERVER['HTTP_IV_GROUPS'];
$userl = $_SERVER['HTTP_IV_USERL'];
$creds = $_SERVER['HTTP_IV_CREDS'];
?>
<ul>
<li>iv_user: <?php echo $user ?></li>
<li>iv_groups: <?php echo $groups ?></li>
<li>iv_user_l: <?php echo $userl ?></li>
<li>iv_creds: <?php echo $creds ?></li>
</ul>

Il risultato di una login con spazi in coda allo username è stato il seguente.

GOTCHA!
Verificando sull’infocenter IBM ho trovato una technote che descrive proprio il problema in questione (anche se riferito ad un problema sul componente di integrazione SSO ETAI, che nel caso specifico non stavo utilizzando).
La soluzione consiste nel creare il virtualhost junction configurando gli headers con encoding “UTF8 Binary” anzichè “UTF8 URI Encoded” (parametro -e utf8_bin)

Una volta effettuata questa piccola modifica il risultato è stato il seguente e il problema si è risolto.