22 apr 2009

Google App Engine


Lotus Notes Sucks!



Odio Lotus Notes: ogni tanto è necessario ribadirlo. Sembra un client di posta scritto in Access. E scritto decisamente male (visto che Access mi piace)!
Non c'è nulla al suo posto, nulla come ci si aspetta, i pulsanti e le voci dei menù sembrano sparati sullo schermo con il mitra, le operazioni basilari o non funzionano, oppure sono ultra complicate, utilizzarlo quotidianamente è un inferno. Insomma cara IBM, la gente con la posta ci lavora, non ci deve mica giocare!

Sono perfettamente al corrente che Lotus non è solo un client di posta ma un ambiente di esecuzione di applicativi distribuiti. L'idea era bella ed innovativa. L'implementazione, un disastro. Argh!

Gmail!



Le alternative ci sono - e sono numerose - ma se parliamo solamente di posta, secondo la mia semplice ma autorevole opinione mi sembra quasi che Google, con la sua Gmail, sia l'unica azienda ad aver capito per davvero a che cosa serve l'E-Mail!
Una webmail più comoda di un vero client? Sembra impossibile, ma pare proprio che quei furbacchioni ci siano riusciti: la grafica è spartana ma leggera e funzionale, e la comodità di utilizzo supera oltre ogni aspettativa.
Bello raggruppare i messaggi in conversazioni (inbox e outbox, bye bye!) e perchè organizzare i messaggi in strutture gerarchiche? Basta con cartelle e sottocartelle: il Web 2.0, così come il mondo, funziona ad etichette.


Privacy?
Una volta si diceva che le memorie di massa erano lo specchio dell'anima, e che per conoscere davvero una persona si doveva guardare il suo hard disk. Oggi ci siamo aggiornati e per conoscere a fondo una persona basterebbe sbirciare il profilo tracciato - e custodito con cura - da Google. Facciamo pure finta di ignorare ogni aspetto legato alla privacy, ma non dimentichiamoci che sarà necessario fare una bella riflessione anche su ciò: di questo ne parleremo in un prossimo disco.

Google Apps for Business
Un po' per provocazione, visto che non ne posso più di Lotus, ed un po'... perché mi sembra un'idea interessante, ho proposto di buttare via tutto e passare a Google Apps for Business. Se l'ha fatto la Regione Veneto, possiamo farlo anche noi: basta server mail in casa, basta hardware, software, firewall, sistemi di accesso remoto, licenze, rbl, antivirus che non si aggiorna, antispam che combina casino, dischi che si riempiono, basta consulenti esterni per ogni minimo problema! Basta anche con VMWare, anche se in fondo alla fine cominciava a piacermi!

Google fornisce numerosi servizi a pagamento per le aziende: si parte da dei semplici filtri da applicare ad una infrastruttura già esistente, fino alla completa casella di posta mantenuta remotamente presso i datacenter di Google.

I prezzi? Molto competitivi. Una protezione di base da applicare al proprio sistema esistente costa 3 $ annui a casella, e si arriva fino ai 40 $ annui per una casella completa, gestita ed amministrata dai migliori sistemisti della terra, e di ben 25GB tutti schiaffati nei sistemi segreti sparsi in giro per il pianeta.

Inoltre con Google Apps for Business vengono messe a disposizione delle API per gestire gli utenti via software: agganciarsi ad un sistema di Identity Management esistente non poteva essere più semplice!

Ovviamente la mia proposta non ha avuto successo (uhm non ancora): il Computer sulla Nuvola non è ben visto, viene inteso principalmente come una perdita di controllo sui propri sistemi informativi. Ed il fatto di non sapere con precisione a chi sono in mano i propri segreti non fa certo piacere.

Forse oggi è ancora troppo presto, si deve valutare meglio quali saranno gli impatti sulla privacy, ma la direzione che seguiremo tutti in un prossimo futuro sembra essere delineata!

Google App Engine
Causa brutto tempo - e, probabilmente, causa mix letale di Anima Nera e prosecco la sera prima - la scorsa domenica non me la sono sentito di spritzettare fino a tarda notte, come succede invece abitualmente. Ho pensato quindi di sfruttare questo insolito ritaglio di tempo per dare finalmente uno sguardo al Google App Engine SDK che avevo installato, e mai provato, tempo addietro.

Sul fronte programmazione, non ci trovo molto di nuovo: tutto quello che avevo imparato sullo sviluppo Web anni fa si applica ancora, e ciò mi rallegra molto. Il Web server deve essere un Apache personalizzato, configurato con grande cura, e configurabile con semplicità tramite file di configurazione caricabili dallo sviluppatore. Il linguaggio di programmazione predefinito è Python, anche se di recente è possibile sviluppare anche in Java. I framework supportati sono numerosi, tra cui mi è saltato all'occhio Pylons che avevo già indicato come possibile oggetto di studio qualche post fa.

Il database messo a disposizione non è relazionale, ma ad oggetti, ma si interroga comunque oltre che con i propri metodi nativi, anche con la normale sintassi SQL (mi ricorda tanto InterSystems Ensemble che funziona allo stesso modo. Beh magari tutti i database ad oggetti funzionano allo stesso modo, chissà!).

Spero di scrivere presto qualche applicativo funzionante!

Conclusione!
Cosa mi ha colpito di Google App Engine?

Le applicazioni scritte per l'engine di Google dispongono di una autenticazione integrata, e chi dispone di un account Gmail per aziende può limitare l'accesso agli applicativi agli utenti della propria azienda.

La conclusione è che quando saremo pronti per spostare le nostre caselle di posta sulla nuvola, saremo pronti per spostare anche tutti i nostri applicativi sulla nuvola.

Non è davvero una rivoluzione da poco!

Conclusione 2.
Lotus Notes è ancora al suo posto. And it still sucks!

19 apr 2009

Conficker

Mentre molte aziende sono state colpite in maniera massiccia dall'infezione del worm Conficker, nella mia realtà il problema è passato quasi del tutto inosservato: d'altra parte i requisiti di sicurezza per evitare il propagarsi di un'infezione di questo tipo sono decisamente di base, e dovrebbe far riflettere il fatto che molte aziende che trattano dati personali o sensibili non siano state adeguatamente preparate ad una tale evenienza.

In ogni caso, è bene non abbassare la guardia, visto che il Conficker è un worm che non perdona alcuna leggerezza!
Per tutte le informazioni relative al worm vedere questo articolo: "Considerazioni per un efficace contenimento dell'infezione Conficker.B".

Uno dei problemi principali consiste nell'individuare quali siano le macchine infette. Fortunatamente sono disponibili numerosi tool di scansione della rete in grado di rilevare eventuali sistemi infetti (vedere Conficker Remote Scanners), tra i quali è presente anche nmap.
La sintassi per controllare una macchina od una rete remota è la seguente:
nmap -PN -T4 -p139,445 -n -v --script smb-check-vulns,smb-os-discovery --script-args safe=1 [targetnetworks]
Bisogna comunque tenere in considerazione il fatto che molti pc potrebbero essere spenti od essere collegati alla rete solo saltuariamente, e purtroppo avere un inventario esatti di tutti i pc che "mancano all'appello" non è sempre facile. Ho pensato quindi di far girare saltuariamente il seguente script su di un domain controller:
@echo off
for /f "tokens=4 delims=: " %%a in ('netstat -na^|find "ESTABLISHED"') do (
nmap -PN -T4 -p139,445 etc. %%a >> scan_%%a
)
Questo script estrae tutti gli indirizzi IP che hanno una connessione correntemente aperta con il domain controller, ed effettua una scansione remota sugli indirizzi rilevati.

Certo il rischio è quello di effettuare numerose scansioni allo stesso indirizzo IP, ed il rischio è che alcune connessioni possano venire allegramente ignorate (meglio un windump piuttosto di un netstat, se non vogliamo farci sfuggire nulla). Naturalmente se sarà necessario, sono pronto a modificare lo script per renderlo più funzionale!

Ah un po' di informazioni sul comando for si trovano a questa pagina http://www.ss64.com/nt/for.html.

6 apr 2009

Drupal: Integrazione con Active Directory

Drupal dispone di alcuni moduli per l'integrazione con LDAP:
  1. ldapauth: permette agli utenti di autenticarsi su dei server LDAP
  2. ldapgroups: permette di utilizzare i gruppi LDAP come ruoli di Drupal
  3. ldapdata: permette l'accesso in lettura/scrittura ad un server LDAP

I moduli di cui ho bisogno sono ldapauth e ldapgroups.

La procedura di installazione di un nuovo modulo è molto semplice: si scarica il modulo, lo si estrae nella cartella modules, si lancia la scansione dei nuovi moduli collegandosi all'indirizzo http://mysite/update.php e lo si attiva dalla pagina http://mysite/admin/build/modules .

La configurazione di LDAP Authentication per Active Directory è la seguente:

  • Nome: inserire il nome del proprio dominio
  • LDAP Server: inserire il nome del PDC
  • Porta: 389 (funziona anche con il protocollo sicuro? è da provare!)
  • Base DNs: inserire la OU dove si trovano gli utenti, ad esempio OU=Utenti,DC=dominio,DC=dom
  • UserName attribute: sAMAccountName
  • DN for non-anonymous search: inserire un utente che ha privilegi di lettura del dominio, nel formato username@dominio.dom
  • inserire la password di questo utente

La configurazione di LDAP Grouops, se si vogliono utilizzare i gruppi di Active Directory, è la seguente:

  • spuntare la casella "Groups are specified by LDAP attributes"
  • il nome dell'attributo da inserire è memberOf

Se tutto va a buon fine, da questo momento in poi è possibile definire i permessi di ogni gruppo di Active Directory all'interno di drupal.