Tales from the Machine Room |
Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Set language to:en it | Login/Register
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:
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
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.
Daniele By Daniele posted 26/05/2008 13:07
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.