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.

Una delle operazioni fondamentali del setup di una nuova istanza WebSEAL consiste nel fare in modo che il prodotto protegga determinati oggetti mediante autenticazione (di vario genere, basic, form authentication o altro) e permetta l’accesso anonimo verso altri.

Apparentemente l’operazione è banale, si creano entità nello spazio oggetti di WebSEAL e si applicano differenti ACL in base alle proprie necessità.
Ad esempio si possono creare due ACL, una (all_view) per l’accesso anonimo e una (all_auth) per l’accesso autenticato (senza distinzioni di gruppi o utenti), ciascuna con i propri parametri di accesso.

Si sfoglia lo spazio oggetti di WebSEAL mediante il comando “object list” e una volta ottenuto il percorso esatto dell’oggetto desiderato (per esempio una transparent junction /wps che espone un portale WebSphere Portal) occorre collegare l’ACL all’oggetto mediante il comando “acl attach <object-name> <acl-name>”.

Con il comando “object show” si può verificare il dettaglio dell’oggetto e le acl ad esso associate (Attached ACL) oppure ereditare da un oggetto padre (Effective ACL).

Durante un nuovo setup però può capitare che l’effetto di questa operazione non sia quello voluto, insomma che le ACL non funzionino a dovere oppure che l’associazione tra l’oggetto e l’ACL non sia efficace.
In realtà questa eventualità è piuttosto remota (almeno io non ho mai osservato un comportamento simile sebbene siano anni che mi trovo a lavorare con questo prodotto IBM), è molto più probabile che vi siate dimenticati di settare un parametro fondamentale nel file di configurazione di WebSEAL.

Nel dettaglio potete osservare che la junction dell’esempio /wps ha valorizzato il parametro “Basic authentication mode” con “supply” (comando “server task <SERVER NAME> show <JUNCTION NAME>”)

Guardacaso nel file di configurazione di WebSEAL (percorso di default su GNU/Linux: /opt/pdweb/etc/webseald-<SERVER NAME>.conf ), sotto stanza “server” è presente il parametro “allow-unauth-ba-supply” che di default è valorizzato in modo tale da non permettere l’accesso anonimo a junction con flag BA attivo.

Una volta modificato il parametro inserendo come valore “yes” e riavviato WebSEAL (pdweb restart) la junction ad accesso anonimo risulterà rispondere correttamente.

Tempo fa ho promosso Duplicati al ruolo di mio software di riferimento per i piccoli backup personali, lo uso sul mio pc di casa, sul fedele ThinkPad lavorativo, sui pc di amici e famigliari.
E’ piccolo, leggero, semplice da usare, versatile e (cosa che non guasta mai) gratuito, insomma una manna.

Purtroppo qualche giorno fa il cliente da cui sto lavorando ha effettuato una revisione generale delle politiche di sicurezza limitando molte connessioni verso web, ciò mi ha causato diversi fastidi, non ultimo il blocco dei backup che effettuavo con frequenza giornaliera proprio con Duplicati, il tutto su un server esterno mediante protocollo sftp.
In casistiche come queste una delle possibili soluzioni consiste nell’utilizzare un proxy http (il quale ovviamente deve poter comunicare con il server sftp di destinazione), strumento che generalmente viene messo a disposizione in scenari di questo tipo.

Per fare in modo che Duplicati possa continuare a funzionare correttamente (senza modificare il backupset o il protocollo utilizzato) è necessario utilizzare la suite di Putty.
Aprite Putty e configurate un profilo che punti al vostro server sftp (utilizzando un hostname e una porta che siano raggiungibili dal proxy http che intendete usare) e utilizzi un proxy http.

Aprite le opzioni di Duplicati e configurate il client sftp puntando al binario di PSFTP

Create un backupset (o editatene uno esistente) checkando l’opzione “Use installed sftp program instead of the built-in SSH library”

Ora il backup dovrebbe funzionare correttamente utilizzando il profilo configurato con Putty e passando attraverso il server proxy configurato.

Se siete giunti a questo post pensando che tratti della nota distribuzione GNU/Linux Fedora mi spiace per voi, ma siete nel posto sbagliato.
Fedora Commons è un apprezzato progetto opensource per la creazione e gestione di librerie multimediali (almeno così è come me l’hanno venduto, ma sapete meglio di me che è sempre bene non fidarsi mai di commerciali e project manager…).

Durante il setup di una istanza di test dell’ultima versione disponsibile (3.7.1) sono incappato in un brutto errore, terminato il setup senza alcuna anomalia faccio partire l’istanza di Tomcat su cui è deployata l’applicazione e come risultato ottengo un catalina.out relativamente pulito e una tristissima homepage di amministrazione del servizio su cui campeggia una orribile errore 404 :(

In realtà nel catalina.out qualche problemino c’è proprio durante l’avvio dell’applicazione fedora.war (ma va?), così mi metto alla ricerca di dettagli nel log della suddetta in $FEDORA_HOME/server/logs/fedora.log, dove campeggia un gargantuesco errore di creazione di una delle tabelle (db MySQL nel mio caso).

Verificando sul db in effetti la creazione delle tabelle è ferma a quelle indicate nel log (ma va?) e le stesse sono prive di record.
Vista la banalità dell’errore (ma chi ha validato gli script di creazione del dbms?!?) ho corretto creando manualmente la tabella, poi cercando online ho trovato un gentile utente che suggerisce di definire sia come UNIQUE KEY che come PRIMARY KEY il campo rebuildDate usando la query:

CREATE TABLE fcrepoRebuildStatus (
  rebuildDate bigint NOT NULL,
  complete boolean NOT NULL,
  UNIQUE KEY rebuildDate (rebuildDate),
  PRIMARY KEY rebuildDate (rebuildDate)
);

Questa volta al riavvio tutto pare procedere per il meglio, se poi dovesse capitare che a forza di fare tentativi ed esperimenti fedora commons dovesse proprio incazzarsi non vi resta che lanciare l’apposito script di ricostruzione del database fedora-rebuild.sh (ricordatevi di definire le tre variabili d’ambiente sacre, JAVA_HOME, FEDORA_HOME e CATALINA_HOME).

Al termine potete godervi un fedora.log pulito e il servizio finalmente raggiungibile alla url http://server:9080/fedora/admin