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.

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.