La guida che leggerete è sicuramente particolare, quantomeno interessante e difficile da trovare in lingua italiana: questi i motivi per cui mi decido a scriverla.
L’architettura che andremo a realizzare è basata su Squid, il popolare proxy-cache server opensource, e vedremo come questo potentissimo amico riesce a dare il meglio di se e a stupire anche nelle architetture più complesse. L’obiettivo, infatti, è quello di installare un sistema di proxy-caching distribuito in parent-child configuration, integrando l’oggetto “child” con un antiviral engine proprietario come Symantec Scan Engine, e con un sistema di autenticazione ldap-based. Ma andiamo con ordine.

Overview: in che contesto ci muoviamo?

In strutture di rete complesse, solitamente è la network di DMZ (Demilitarized Zone) che si occupa di gestire i contatti tra l’intranet e l’esterno e viceversa. Le risorse disponibili in DMZ (solitamente server mail, webserver, server Dns, proxy server eccetera) devono essere separate dalla LAN per non comprometterne l’integrità. Ciò comporta l’impossibilità, da parte di un client di rete interna, di poter raggiungere un host fisico in DMZ o un servizio presente su di esso.

Se vogliamo implementare un servizio proxy-cache per velocizzare e controllare l’accesso ad internet dei nostri client, sarà indispensabile posizionare il server proxy su una delle macchine della DMZ. Come consentire, quindi, agli utenti della nostra rete di utilizzare il server proxy (che di base non raggiungerebbero direttamente) per poter accedere ad internet?

La risposta alla nostra domanda: Squid e la configurazione parent-child.

Una possibile soluzione è senza dubbio quella di effettuare due installazioni di Squid, una sull’host fisico della DMZ, e un’altra su un host fisico presente su una rete che faccia da trait d’union fra la nostra LAN e la zona demilitarizzata. Ovviamente solo per alcuni servizi e per alcuni protocolli.
Le due installazioni di Squid saranno in contatto fra di loro in una gerarchia che chiameremo “di padre-figlio” (da cui parent-child) per la quale l’installazione “padre” sarà quella che, fisicamente, mantiene il contatto con l’esterno e serve le pagine web, mentre l’installazione “figlio” sarà quella fisicamente raggiungibile dagli utenti della lan e alla quale essi inoltreranno le richieste.

Il “child Squid”, una volta ricevuta la richiesta dal client, controllerà sulla propria cache la presenza del dato. In caso di risposta positiva servirà la pagina in modalità “offline” all’utente, altrimenti inoltrerà la richiesta al “parent Squid”, il quale si comporterà alla medesima maniera: controllerà la presenza del dato sulla parent cache e, se la trova serve la pagina, altrimenti effettua materialmente la richiesta via internet e riceve la risposta dalla rete. Tale risposta verrà rispedita al child e servita all’utente finale.

Lo schema qui sotto potrebbe risultare esplicativo.

Squid Parent-Child Schema

Vediamo ora come configurare correttamente le due installazioni per ottenere l’effetto voluto.

Bookmark It

{[ = echo $pippo; = | .hilite( = php = ) ]}

Bookmark It

Mi trovo, proprio in questi giorni, a fare un sacco di ragionamenti sull’argomento e capire cosa va, cosa non va e che situazione si trova a fronteggiare uno come me che nell’ambiente non solo ci lavora, ma ci vuole investire per il proprio futuro.

Si è parlato molto in questo periodo dell’uscita della GPL 3 e onestamente ho letto editoriali non proprio entusiasti sull’argomento. Io la licenza non l’ho ancora letta e quindi evito di fare commenti fuoriluogo. Mi lascio andare ad una sola considerazione che, però, sento di potermi permettere perchè mi riguarda: ho ammirato molto Stallman fino a qualche anno fa; adesso quando parla lo trovo troppo lontano dalla realtà, magari anche solo dalla realtà che sento di vivere io che come tanti altri spalo guano dalla mattina alla sera e non me ne vado in giro a fare conferenze sull’etica open. Forse questo è un campanello d’allarme di qualcosa; forse è il motivo per cui io la GPL 3 non l’ho ancora letta.

Cmq il motivo di questo post è un altro. Faccio subito una affermazione importante:

Il movimento opensource e i prodotti che genera mi sembra siano entrati in una fase di maturità rilevante.

Gli faccio seguire una mia considerazione personale:

Mi sembra che le aziende che investono nell’IT e (da come dicono alcune) nell’opensource in Italia siano orientate a due modelli di business: da un lato le partnership con le grandi società inglesi o americane che sviluppano prodotti a pagamento (RedHat) o soluzioni (Alfresco, Zimbra) a basso costo, in modo da fornire un “pacchetto pronto” per il cliente; dall’altro il body-rental. Nessuno che investe sullo sviluppo di soluzioni integrate per il cliente.

E questa “propensione all’open” un po’ posticcia un cliente la percepisce. Fa peggio: è convinto che la scelta di migrare verso una piattaforma o un software open è legato soprattutto al fatto che è “gratis” (quanto mi incazzo quando sento questa parola non capite nemmeno!!!) e l’azienda risparmia. Ecco quello che rimane: l’opensource vince perchè è “gratis” non perchè è meglio.

Io ci ho pensato un po’ e mi è venuta una domanda, forse un po’ provocatoria, ma forse anche no. Magari scomoda, magari errata ma a cui forse è meglio rispondere subito.

E se fosse colpa nostra?

Sì, nostra nostra, di noi che l’opensource lo facciamo/installiamo/promuoviamo. Di noi che ci riempiano la bocca.
Io mi chiedo: ma non è che è la nostra immagine a far perdere l’intero mondo? L’immagine di di quei colleghi sistemisti/programmatori fissati che si lasciano crescere la barba per 13 anni, si lavano di media 2 volte al mese, si vestono col maglione largo del babbo e si comprano gli occhiali da nerd per sembrare, finalmente, un nerd (o Richard Stallman in alternativa).
L’immagine di quelle aziende che vanno in startup con tante buone promesse e poi appena incassano due lire e si ingrandiscono, si perdono, si tradiscono, smettono di puntare sulla qualità del proprio lavoro e cercano “sponde facili”, fanno il soldo col body-rental e proteggono la loro immagine con (massimo!!!) due commesse l’anno veramente interessanti, legate mani e piedi a partnership anche apprezzabili, ma che poi ti portano a scegliere il partner anche quando sai benissimo che non corrisponde esattamente alle esigenze del cliente.
L’immagine di tutti quegli attori delle community internazionali dell’opensource (e sono parecchi abbiate pazienza) che si sentono un po’ i depositari della “saggezza binaria” e si collocano in alto, “che la gente usi pure windows, che dia i soldi alla microsoft, io sì che sono un gran fico che non do una lira a nessuno”. Se oggi Linux si insinua appena nel mondo “desktop” e in quello “server” lotta (ad armi pari intendiamoci) con colossi come Sun, HP e anche Microsoft ci metterei, magari è anche e soprattutto colpa di chi dieci, quindici anni fa non ha ritenuto poi così necessario portare avanti un certo tipo di sviluppo meno “server” e più “easy”…e non mi dite che non era possibile, perchè basta guardare cosa ha fatto Apple.

Lo sapete qual’è il problema più grande dei prodotti opensource per quella che è la mia esperienza di sistemista linux? La non integrazione, il concetto di “pila” sempre preferito a quello di “piattaforma”. Non sto chiedendo una tecnicità venduta semplice, perchè poi è chiaro che sarebbe un farsi male e basta. Sto dicendo: aziende, investite nelle risorse in gamba che avete, non internatele per forza in consulenze-capestro di tre, quattro, sei anni in mega-aziende dell’IT italiano dove vanno a fare i luminari per quattro lire. Proponete soluzioni, fatele integrare dai vostri uomini, proponete piattaforme customizzate sul cliente, magari (perchè no?) anche aiutandosi con le partnership che sono una occasione di pluralità e non di unicità del prodotto che si può vendere.

Spendete dei soldi ora…scommettiamo che vi rientrano?

Open your mind!

Bookmark It