Tales from the Machine Room


Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Login/Register

A Man, A Plan, A Scam

Questa non e' tanto una storia quanto un rantolo, una geremiade, un cantico del purgatorio.

C'e' una divisione di $noisalviamoilmondopuntocom che chiameremo $noiguardiamolebellestelline. Che si occupa di.. hemmm... guardare le belle stelline... tale divisione gestisce 4 'posti di osservazione' i quali sono:

  1. solo 4
  2. in cima a montagne
  3. in cima a montagne nel mezzo del nulla
  4. in cima a montagne nel mezzo del nulla circondate da una recinzione

Essendo isolate dal resto del mondo ci sono solo pochi individui, ergo i problemi di sicurezza sono estremamente limitati, e le uniche connessioni di rete sono tramite rete telefonica, ponti radio o satellitare, quindi sono strettamente dial-up, con larghezza di banda imposta da condizioni esterne e quindi tutte le comunicazioni sono compresse.

Si capisce bene che i problemi di $noiguardiamolebellestelline sono molto diversi da quelli della rete globale di $noisalviamoilmondopuntocom, e si capisce anche perche' ad un certo punto si e' deciso che loro abbiano il loro reparto IT separato ed autonomo.

Entra in scena UL. Che, dopo aver "gestito" alcuni progetti per $noiguardiamolebellestelline, ha maturato un certo tipo di mentalita' ed una certa propensione per certi metodi e modalita' di lavoro. Di colpo si rende conto che la rete globale di $noisalviamoilmondopuntocom non e' gestita nello stesso modo! Eccolo iniziare una manovra di falciatura con lo scopo di portare l'intera rete sotto il suo controllo, con le stesse metodologie impiegate per $noiguardiamolebellestelline.

Cosi' siamo impelagati in questa "presentazione" per una nuova "proposta di aggiornamento e modifica della rete".

UL - yada yada yada, rete moderna, efficiente, sicura, yada yada uso delle ultime tecnologie wireless, gprs, umts, yada yada predilezione per soluzioni custom-made, yada yada yada, tool di configurazione yada yada...

Ed e' andato avanti cosi' per un paio d'ore circa... Alla fine, quando tutti stavano sbadigliando e guardando l'orologio, siamo arrivati alla parte 'commenti'.

TB - Allora, ci sono commenti?
IO - Non sarebbe meglio i commenti metterli per iscritto e mandarli alla mailing-list? Cosi' anche i non presenti possono contribuire.
UL - Ma sarebbe meglio avere una franca discussione face-to-face.
IO - Si, soprattutto perche' Aquila e' in ferie in questo momento vero?
TB - Be', se qualcuno ha qualche cosa da dire adesso ok, altrimenti andiamo di mail.

Cosi' ci siamo aggiornati. Dopo una bella nottata a ponzarci sopra ho messo insieme un documentino di risposta, che aggiungo qui' con qualche modifica (e qualche nome rimosso)...


Commenti riguardo la "proposta di aggiornamento della rete"

Secondo quello che si e' capito la proposta puo' essere divisa in 3 blocchi,
il primo e' quello piu' importante con le cose che effettivamente contano,
il secondo e' piu' che altro mere tecnicalita' non realmente importanti, 
l'ultimo e' il meno importante in assoluto.

Prima parte - struttura

Fondamentalmente la parte importante e correttamente analizzata si compone
di 3 idee di base:

1. i nostri 'hub' dovrebbero essere in datacenters dove ci sono UPS,
   connessioni di rete stabili ed il padrone di casa non puo' sbatterci
   fuori come e' successo al nostro centro di Seattle ultimamente.

Ora, questo e' esattamente quello che stiamo facendo. Amsterdam ha gia'
il firewall in una hosting farm, per Seattle ci stiamo lavorando, non ho
idea di come sia la situazione a Mosca ma devo supporre che si possa
arrangiare. Niente di nuovo quindi.

2. ci serve un'altro HUB nel pacifico.

Assolutamente vero e ci stiamo lavorando proprio adesso, parlando con i
possibili candidati a mantenerlo. Ci serve gente sul posto che possa
prenderne carico, non si puo' fare tutto da remoto e penso che non vogliamo
dare troppo controllo al personale delle server-farms.
Di nuovo niente di nuovo.

3. Ci serve piu' ridondanza.

Se uno degli hub e' inattivo (per qualsivoglia ragione), tutti i server
connessi dovrebbero passare sugli hub rimanenti con il minimo di intervento
manuale. Questo si puo' fare modificando il software di gestione del
firewall, si tratta di una modifica relativamente semplice ma da ripetere
per tutti i 320 server che sono in giro (!). Per questo motivo non lo abbiamo
ancora fatto a mano ed aspettavamo con ansia questo "tool" di
modifica che il nostro consulente dovrebbe essere sul punto di rilasciare.


Quindi, in totale, questa parte e' assolutamente corretta e non c'e'
niente di nuovo. Sono cose che sappiamo gia' e che stiamo gia' lavorando
per correggere o sistemare. Possibilmente dovremmo essere in condizione di
dichiararla chiusa prima della meta' dell'anno anche se certe cose non sono
completamente sotto il nostro controllo (contratti di locazione, hardware...).

Seconda parte - tecnicalita'

Queste sono solamente tecnicalita', non cambiano il modo in cui il sistema
funziona o non funziona, non cambiano il modo con cui noi gestiamo il
sistema, non cambiano il modo con cui si affrontano i problemi. Potremmo
decidere che sono utili ed implementarle, decidere che non sono utili o
semplicemente ignorarle. 

Log file in databases.
La mia esperienza e' che non si vanno a leggere i file di log se non si sta
cercando di debuggare un problema, nel qual caso non fa alcuna differenza
se il file e' un file di testo o un database.

Tool per la creazione degli script di firewalling
Ne abbiamo gia uno. Non ha nessuna interfaccia grafica, gli script che
crea non sono ottimali forse ma funzionano. Lo scopo di questi tool e' la
creazione di uno script di iptable, che lo script sia creato da un tool o
a manina non fa alcuna differenza alla fine.

Hardware per hubs/servers
Personalmente, non vedo perche' $venditore dovrebbe essere preferito a
$altrovenditore se le macchine che fornisce hanno le stesse caratteristiche
tecniche ed alla fine lo stesso prezzo.

OpenVPN/IPSEC/CIPE
Dobbiamo metterci a cambiare l'intero algoritmo di crittografia usato...
esattamente per quale motivo?

Terza parte - trivialita'

Quindi, l'intera proposta si esaurisce in una prima parte che stiamo gia'
affrontando, alcune tecnicalita' di dubbia utilita' ed una terza parte
che si puo' riassumere in "non mi piace $distribuzione, spianiamo tutto
ed installiamo $altradistribuzione".

Per usare le stesse parole di UL: questa e' una stronXata.

Prima regola del sysadmin: non cambiare una cosa che funziona a meno che:
1) e' una tale pena che cambiare ha senso, 2) la nuova cosa ha talmente tante
nuove funzionalita' di cui non puoi fare assolutamente a meno o 3) la
nuova corregge dei bachi in cui tu caschi sempre.
Nessuno dei 3 punti e' rilevante, quindi cambiare non e' un'opzione.

24 ore dopo aver inviato questa mail ho ricevuto plausi da Aquila che anche da una spiaggia australiana si legge la sua mail, plausi dai nostri uomini a San Francisco e Seattle. E TB mi ha detto che questo documento "e' proprio quello che mi serviva".... mi devo preoccupare?

Davide
17/01/2009 14:41

Previous Next

Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.

1 message this document does not accept new posts
DanieleDaniele By Daniele - posted 26/05/2008 13:07
Ti devi preoccupare? No, perchè significa che hai fatto bene a cambiare lavoro, e adesso sei in un posto che, pur avendo la sua buona quota di CL, ha anche qualcuno che capisce e apprezza quello che sai fare. E scusa se è poco!

Previous Next


This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.


This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.

This site isn't optimized for vision with any specific browser, nor it requires special fonts or resolution.
You're free to see it as you wish.

Web Interoperability Pleadge Support This Project
Powered By Gojira