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:
- solo 4
- in cima a montagne
- in cima a montagne nel mezzo del nulla
- 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
Precedente
Successivo
