I pezzi di software per costruire il server di una piccola rete aziendale ci sono già tutti, gratuiti e stabili da almeno un anno. Samba serve file e stampanti ai client Windows; sendmail o Postfix instradano la posta; OpenLDAP 2.0, uscito ad agosto, tiene un’anagrafica utenti centralizzata via LDAPv3; ipchains filtra i pacchetti sul kernel 2.2; Squid fa da proxy e da cache HTTP; Apache pubblica un’intranet. Per una piccola impresa che vuole una rete locale funzionante, questi programmi sono dati per scontati. Il lavoro vero comincia dopo: farli stare insieme su una macchina sola, configurati in modo coerente, gestibili da chi non legge le pagine man per mestiere.

Contesto

Una rete da dieci o venti postazioni Windows ha bisogno di un insieme di servizi preciso: condivisione di file e stampanti, una casella di posta interna, una connessione a Internet condivisa con un minimo di filtraggio, l’autenticazione degli utenti in un punto solo, un backup che parta da solo la notte. Le soluzioni commerciali del momento — Windows NT Server con la sua suite BackOffice, oppure gli apparati dedicati — coprono questo insieme con licenze per server e per client (le Client Access License) che crescono con il numero di postazioni.

Sul versante libero, ogni funzione ha alle spalle un progetto collaudato. Samba 2.0, uscito a gennaio 1999, parla il protocollo SMB abbastanza bene da rimpiazzare un file server NT per la gran parte degli usi d’ufficio. sendmail gira dagli anni Ottanta; Postfix, scritto da Wietse Venema e pubblicato a dicembre 1998, offre un’alternativa con una configurazione più leggibile. Quale programma scegliere per ciascun servizio è la parte già risolta. Resta aperta la domanda di chi tiene allineati i dieci file di configurazione che ne escono, e di cosa succede quando uno va riscritto a mano dopo un aggiornamento.

Architettura

Il modo onesto di descrivere una macchina così è questo: un kernel Linux 2.2 e una manciata di demoni che nessuno ha progettato per parlarsi, tenuti insieme dalla configurazione.

Lo strato di rete parte dal filtraggio. Sul kernel 2.2 il filtro di pacchetto è ipchains, senza stato: ogni regola guarda il singolo pacchetto e non sa nulla della connessione a cui appartiene. La condivisione di un’unica linea esterna passa per il masquerading, cioè la riscrittura degli indirizzi sorgente — quello che oggi chiamiamo NAT di tipo source. Squid si mette davanti al traffico HTTP come proxy e cache: taglia la banda consumata da una piccola rete in modo misurabile, e dà un punto solo dove applicare le regole d’accesso.

L’autenticazione è dove si gioca davvero la coerenza. Senza una directory centrale, ogni servizio tiene il proprio elenco di utenti: gli account di sistema in /etc/passwd, gli utenti Samba in un file a parte, le caselle di posta da un’altra parte ancora. Con OpenLDAP 2.0 e il supporto LDAPv3 l’anagrafica sta in un posto solo e gli altri servizi la interrogano. Il guadagno è reale, ma ha un prezzo: ogni demone va istruito a interrogare la directory, e nel 2000 i meccanismi per farlo sono ancora acerbi e cambiano da un servizio all’altro.

La posta è la catena più lunga. Un agente di trasporto (sendmail o Postfix) riceve e instrada; un server POP3/IMAP consegna le caselle ai client; tra i due va infilato un livello di filtraggio antivirus, e il modo praticato è passare ogni messaggio per uno scanner esterno con uno script come AMaViS. Ogni anello è un programma a sé, con il suo formato di configurazione e il suo log.

Punto critico

La somma di componenti corretti non fa un sistema corretto. Quattro problemi concreti saltano fuori appena si prova a mettere insieme questi demoni.

Il primo è l’autenticazione condivisa. Far autenticare Samba, la posta e il proxy contro la stessa directory LDAP vuol dire configurare ogni demone in modo diverso, e nel 2000 il supporto è irregolare: alcuni leggono LDAP da soli, altri vanno mediati da PAM, altri ancora pretendono il proprio file. Un utente disattivato deve sparire da tutti i servizi in un colpo solo, altrimenti l’ho disattivato solo per finta.

Il secondo è la coerenza della configurazione. Dieci servizi vuol dire dieci file in dieci sintassi diverse, ciascuno con il suo formato e i suoi vincoli. Cambiare un indirizzo di rete o un nome di dominio li tocca quasi tutti. Senza uno strato che generi quei file da una descrizione unica, ogni modifica è un giro manuale che invita all’errore — e un errore in ipchains o nel masquerading lascia la rete esposta in silenzio.

Il terzo è l’aggiornamento. Aggiornare un singolo pacchetto può cambiargli il formato di configurazione e sovrascrivere i file modificati a mano. Su una macchina che regge dieci servizi, ogni aggiornamento è una regressione potenziale per tutti gli altri. Per questo questi sistemi, una volta che girano, non li tocca più nessuno — che è il modo peggiore di tenere in piedi la sicurezza.

Il quarto è la diagnosi. Quando la posta esterna non arriva, la causa può stare in una regola ipchains, nel masquerading, nel filtro antivirus che blocca senza dire nulla, nella configurazione del trasporto o nella directory LDAP che non risponde. Ogni anello ha il suo log, in un posto diverso, in un formato diverso. Senza un punto unico da cui osservare, la diagnosi diventa correlazione a mano.

Implicazioni

Per una piccola impresa, il valore di una macchina così sta tutto nello strato di integrazione, non nella raccolta dei pacchetti, che sono pubblici e documentati: la directory unica come fonte di verità per gli account, un generatore che produca i file di configurazione da una descrizione coerente, un posto solo dove leggere i log e lo stato. È lo strato che nessuno dei progetti a monte fornisce, perché ciascuno risolve bene il proprio problema e si ferma al proprio confine.

Questo cambia la natura del lavoro. Il software di rete è già scritto, collaudato e mantenuto da comunità più capaci di un singolo integratore. Quello che resta da fare è costruire e mantenere lo strato di coerenza sopra componenti che evolvono con i propri calendari. È lavoro di sistemi, e come tale va giudicato: da quanto resta corretto dopo il terzo aggiornamento, non da quanto è elegante il giorno dell’installazione. Una macchina che impacchetta proprio questo strato in un apparato unico è il B.O.S.S. (Business Open Source Server) descritto nell’insight di noze: https://www.noze.it/insights/boss-server/.

Limiti

Sul kernel 2.2 il filtro ipchains resta senza stato: la valutazione per connessione che semplificherebbe le regole del firewall arriverà con netfilter e la serie 2.4, ancora in sviluppo a fine 2000. La consegna POP3 in chiaro espone le credenziali sulla rete locale; per ora il rimedio pratico è confinarla alla LAN, dietro il filtro. E lo strato di integrazione di cui sopra ha un costo ricorrente che non sparisce: una macchina così è un impegno di manutenzione continuo, non un apparecchio da installare e dimenticare. Chi la propone a una piccola impresa deve dirlo apertamente.

https://www.openldap.org/software/roadmap.html https://www.samba.org/samba/history/samba-2.0.0.html https://www.postfix.org/ https://www.kernel.org/pub/linux/kernel/v2.2/ https://en.wikipedia.org/wiki/Ipchains https://www.squid-cache.org/

Immagine di copertina: Primo server di produzione di Google del 1999: schede madri di hardware commodity montate a vista con cavi esposti, esposte al… — foto di Carlo Nardone, CC BY-SA 2.0 — https://commons.wikimedia.org/wiki/File:Google’s_First_Production_Server_(1999)_-_Computer_History_Museum_(2007-11-10_23.05.32_by_Carlo_Nardone).jpg