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

L’inventore di Cygwin meriterebbe una statua in ogni piazza, non è la prima volta che lo affermo ma non sarà di certo l’ultima.

Una delle innumerevoli features utilissime di questo fantastico software è il server X, indispensabile se lavorate su server GNU/Linux o Unix per poter utilizzare applicazioni che hanno una interfaccia grafica o richiedono un server grafico.
Qualcuno pensa che “il sistemista che non deve chiedere mai” può vivere di sola command line, in realtà però molti software enterprise ormai possono essere installati solo tramite installer grafici, pertanto un server X è ormai parte del corredo di sopravvivenza di qualsiasi sistemista.

L’installazione è estremamente semplice, scaricare dal sito https://www.cygwin.com/ l’ultima versione del setup di cygwin per l’architettura che preferite (x86 o x64), piazzatelo in una directory (es c:\cygwin\setup) e  lanciatelo.

1) Proseguite nei primi passi dove selezionare l’origine dei pacchetti (suggerisco “Install from Internet” se avete la possibilità di connettervi a web mediante protocollo http o ftp)
2) Selezionate la root di cygwin (es c:\cygwin)
3) Confermare la directory che conterrà i package scaricati (es c:\cygwin\setup)
4) Infine inserite l’eventuale proxy necessario per raggiungere il repository dei pacchetti di installazione e selezionate un mirror a piacimento.

Dopo avere scaricato l’elenco aggiornato dei package vi verrà mostrata la schermata riassuntiva dei pacchetti da installare, nell’angolo superiore sinistro troverete un’area di testo dove potete ricercare specifici pacchetti, quelli che dovrete installare per avere un server X funzionante sono:

• xorg-server
• xinit
• xorg-docs

Cercate ciascuno di questi e selezionateli per l’installazione cliccando sulla label “Skip”

Cliccate su Avanti per proseguire nel wizard, la schemata successiva mostrerà i pacchetti che saranno installati come dipendenze dei tra selezionati.

Installazione terminata

A questo punto tra i programmi installati dovrebbero essere comparsi il gruppo Cygwin-X contenente il collegamento per lanciare il server X (XWin Server), se provate a lanciarlo comparirà nel systray l’icona del server X avviato in background e si aprirà un terminale grafico (xterm).
Personalmente trovo questa cosa piuttosto noiosa, per eliminare l’apertura di xterm all’avvio del server X basta creare nella home del proprio utente il file nascosto .startxwinrc, per farlo aprite un terminale di cygwin e digitate “touch .startxwinrc”.

Un’altra cosa imho molto comoda è avviare il server X immediatamente al boot (o al login di del proprio utente), per farlo basta creare un collegamento nella folder Esecuzione automatica (per chi utilizza Windows 8 si trova sotto %AppData%\Microsoft\Windows\Start Menu\Programs\Startup) che lanci questo comando:

<ROOT DI CYGWIN>\bin\run.exe -p /usr/X11R6/bin XWin -multiwindow -clipboard -silent-dup-error

Prima di testare il nostro fiammante server X occorre un ultimo semplice passaggio, dobbiamo esportare la variabile DISPLAY, per farlo possiamo lanciare il comando “export DISPLAY=:0.0″ oppure modificare il file .bash_profile presente nella home del nostro utente (per fare in modo che la variabile venga esportata automaticamente all’apertura del terminale, ricordatevi di chiudere e riaprire il terminale stesso) inserendo in coda DISPLAY=:0.0

Finalmente ci siamo, provate a connettervi mediante ssh ad un server avendo l’accortezza di aggiungere l’opzione -X (oppure -Y se volete abilitare il forward trustato) e lanciate una qualsiasi applicazione grafica (es xeyes)

Bingo!

Lavorando su macchine GNU/Linux 9 volte su 10 ci si trova ad avere a che fare con la bash, e in molti casi diventa essenzialmente scavare nella history per recuperare comandi già lanciati o dimenticati risparmiando così parecchio tempo.

La history è conservata nella home di ciascun utente nel file nascosto .bash_history e per visualizzarne il contenuti è sufficiente lanciare il comando history, eventualmente greppando qualsiasi cosa possa servire:

In realtà questo modo di interrogare la history è spesso molto macchinoso e lento, può essere utile per documentare o per farsi un’idea su una serie di comandi lanciati in serie, ma per un uso “on the fly” della history è poco utile.

Esiste un altro modo molto più veloce e immediato che ho notato pochi conoscono (almeno all’interno della mia cerchia di colleghi, clienti e collaboratori), ovvero lo shortcut CTRL+R.

Usando questa veloce scorciatoia si abilita una ricerca inversa nella history, digitando il comando lanciato la bash precompila il resto utilizzando il record più recente della history che comincia con quanto è stato digitato, se occorre recuperare un comando più vecchio che inizia nello stesso modo basta premere di nuovo CTRL+R per passare ai precedenti.

Se invece preferite eliminare i record presenti nella history (perchè ad esempio contengono password o informazioni critiche che non dovrebbero essere visibili da altri utenti) potete cancellare il file ~/.bash_history oppure più elegantemente lanciare il comando “history -c”

May the bash be with you!