Tales from the Machine Room

L'Hydra

Il che significa che mi aspetta la reinstallazione di tutto l'ambaradam di 32 server nel prossimo futuro.

Il tipo che aveva installato il tutto (quello che tirava le tastiere dalla finestra e che ci ha lasciato di colpo), ha lasciato un po' di documentazione sparsa, ma non e' che vi sia molto da leggere, in particolare i vari "dettagli" sul come e perche' installare le cose sono molto nebulosi. Ed anche alcune delle sue scelte non sono proprio allineate con le mie. In particolare ritengo l'uso di daemon tools per la gestione dei servizi in vece del normale sistema di processi una gran rottura. Che finche' funziona va tutto bene, ma a me e' gia' capitato che uno dei processi si incatasti e daemon tool si incatasta pure lui e l'unica e' un bel riavvio.

In ogni caso, dato che voglio rifare il tutto, usare versioni aggiornate dei vari software eccetera eccetera, ho deciso di fare le cose per bene, quindi sono qui' occupato a mettere insieme un mega Kick-start file sul nostro server di installazione remota in modo che con un colpo solo mi installi l'intero server con tutto il software necessario pronto al lavoro. E poi aggiungere un piccolo, rapido e crudele script di autoconfigurazione che finisca il lavoro aggiungendo tutti i dettagli necessari, in modo che in una mezz'oretta mi ritrovo con un server pronto al funzionamento, invece di perdere due giorni per cercare ed installare tutti i pezzi che mi servono.

La destinazione e' fissa, la strada e' segnata, l'unico problema e' che il cammino e' una barbosa ripetizione di: installa, vedi che cosa manca, aggiungi al kickstart, modifica lo script di configurazione, reinstall, risciacqua, ripeti.

Mentre sono qui' che mi delizio guardando l'ennesima reinstallazione della macchina virtuale che non trova un qualche rpm, A si appropinqua.

Non ho ancora presentato A. Allora, lui e' un Network Administrator, cioe' si occupa per lo piu' di mettere insieme switch, router e roba simile e farli parlare tra di loro e con il resto dell'universo noto (e ignoto). Si occupa anche di alcuni firewall e di mantenere il nostro sistema di monitoring basato su Nagios.

IO - (segnandomi quali rpm mi servono) Che ti serve?
A - Ho un problemino con il backup dei router di un cliente.
IO - Che problema?
A - Allora, tu conosci vero il nostro database di configurazione?

Il database di configurazione e' l'ennesimo accrocchio in php scritto da una tipa (si' era donna) tempo addietro. E' una mostruosita' che mi ricorda l'Idra. Purtroppo, H era anche quello che si occupava di quell'arnese e quindi temo che, dopo avere ereditato il mailscan, sono in pista per ereditarmi anche questo di accrocchio.

IO - Si', lo conosco... che c'entra quel coso?
A - Allora, tempo addietro con H avevamo fatto un affare che prendeva gli indirizzi ip dei router dal database e preparava uno script per fare il backup via tftp dei router direttamente. In modo che c'era da mantenere un solo database invece che due. Solo che, per qualche motivo, ci sono alcuni routers che non entrano in quello script. Ed io devo aggiungerli a mano ogni volta.
IO - Interessante.
A - E quindi mi chiedevo, se tu non potessi spendere dieci minuti guardando perche' quei router non si trovano nello script.
IO - Che routers? Dove sta lo script? Come si crea?

A fornisce tutti i dati e, dopo essermi tappato il naso, mi metto a guardare anche questo problema.

Allora, i routers sono inseriti nel database di configurazione, che ha una struttura multi-livello. Ci sono "oggetti" che hanno "proprieta'". Ed ogni "oggetto" puo' essere in relazione con uno o molti altri "oggetti", il quale puo' essere a sua volta in relazione con altri "oggetti". E cosi' via, ad libitum.

Va bene cominciamo dall'interfaccia. Guardo uno dei router che sono nello script e guardo come e' definito. Allora, una delle "proprieta'" e' "backup" con valore "tftp". Ok. Poi c'e' un "oggetto" collegato che si chiama "interfaccia" ed ha l'indirizzo IP come una delle proprieta'. Ok. Facile.

Adesso vediamo uno dei famosi routers che nello script non c'e'.

E non ci trovo assolutamente niente di anormale. Esattamente come l'altro ha una proprieta' "backup", con lo stesso valore, ha un oggetto collegato... ummmm... pare tutto ok. Almeno, dal punto di vista dell'utente, e' tutto ok. Adesso si tratta di andare a vedere come viene creato questo script.

Scovo lo script di generazione dello script (sic) nei meandri del database server (si', quello in cluster-che-non-e'-un-cluster e che io ho iniziato a sostituire), ok, banale script in perl che fa una query... mooooomento... query???

select parent.name, object.name, p.value
from object
inner join property on property.object_id=object.id
inner join relation as rp on object.id=rp.object2 and rp.type='eigendom'
inner join object as parent on rp.object1=parent.id
inner join relation as ri on ri.object1=object.id and ri.type='interface'
inner join object as interface on ri.object2=interface.id
inner join property as p on p.object_id=interface.id
where property.value='tftp' and object.active=1
and p.value not like '192.168.%' and p.value not like '10.%'
and p.value not like '172.16.%' and p.value not like '172.17.%'
and p.value not like '172.18.%' and p.value not like '172.19.%'
and p.value not like '172.20.%' and p.value not like '172.21.%'
and p.value not like '172.22.%' and p.value not like '172.23.%'
and p.value not like '172.24.%' and p.value not like '172.25.%'
and p.value not like '172.26.%' and p.value not like '172.27.%'
and p.value not like '172.28.%' and p.value not like '172.29.%'
and p.value not like '172.30.%' and p.value not like '172.31.%'
and p.value not like ''
order by parent.name, object.name, p.value;

Alura, taglia e incolla la query nella console di mysql e lui mi ritorna correttamente l'elenco dei routers che sono nello script. E perche' non mi ritorna quegli altri?

Mi metto percio' a vivisezionare le varie relazioni. Allora, la tabella "proprieta'" e' in relazione con "oggetti", la quale e' in relazione con "relazioni", la quale e' in relazione con "oggetti" (di nuovo) la quale e' in relazione con "proprieta'" (di nuovo)...

Dopo aver tirato una manica di accidenti alla tipa e ad H riesco a scovare il problema, la maledetta cosa cerca una relazione di tipo "eigendom" (che, credeteci o no, significa "proprieta'"), mentre, per qualche strano motivo, il router che non compare, la relazione l'ha di tipo "network".

Dopo essermi grattato la pera per una buona mezz'ora ed aver cercato di capire esattamente a che cappero servono i tipi di relazione, provo a cambiare il tipo nel db e rifaccio la query alla console.

Certo come il sorgere del sole, il router "mancante" appare nella lista.

Una rapida ricerca nei meandri del codice dell'interfaccia di questo database non mi ritorna nessuna spiegazione del perche' uno degli oggetti ha una relazione di un tipo e l'altro no. Quindi mi limito a cambiare i vari record che non compaiono ed a verificare che a) siano ancora riportati nell'interfaccia e b) compaiano nello script.

Butto giu' due note di documentazione sulla cosa ed informo A che il suo problema per il momento e' risolto.

Adesso, il prossimo passo nel mio (lungo) elenco di cose da fare e': proporre il rifacimento del maledetto database di configurazione. Possibilmente NON in php.

Davide
19/10/2009 08:00

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.

34 messages this document does not accept new posts

peccato... By Argaar posted 19/10/2009 09:10

giusto! By Herr Franz posted 19/10/2009 09:11

PHP By Palin posted 19/10/2009 09:25

> Adesso, il prossimo passo nel mio (lungo) elenco di cose da fare e': proporre
> il rifacimento del maledetto database di configurazione. Possibilmente NON in php.

Probabilmente il problema non è del php ma stava tra la sedia e la tastiera...
-- Palin

@ Palin By Eugenio Dorigati posted 19/10/2009 10:29

non è il PHP, è il programmatore By Anonymous coward posted 19/10/2009 09:30

ho mollato la storia a meta'... By R.P. posted 19/10/2009 09:35

@ R.P. By Anonymous coward posted 19/10/2009 10:23

povero PHP By Golan Trevize posted 19/10/2009 10:01

Regola numero uno del CL. By Davide Inglima posted 19/10/2009 10:16

Ci risiamo... By Anonymous coward posted 19/10/2009 10:26

PHP e sedicenti “programmatori” By Diego E. Pettenò — Flameeyes posted 19/10/2009 10:54

centos? By Riccardo Cagnasso posted 19/10/2009 12:13

@ Riccardo Cagnasso By Davide Bianchi posted 19/10/2009 12:19

@ Riccardo Cagnasso By Kesty posted 19/10/2009 13:54

@ Riccardo Cagnasso By z f k posted 19/10/2009 14:34

> Umm, ma io mi sono imbattuto in centos un paio di volte e l'impressione che ne ho avuto e' che

CentOS l'ho incrociato perche' una ditta di informatica (leggi cert MS) ha scoperto DimDim, che fa quello che chiede il cliente e non costa nulla per meno di 20 utenze.
Ora, se voi siete una ditta fondalmentalmente MS-centrica e vi trovate di fronte questo:
http://sourceforge.net/projects/dimdim/files/Dimdim%20v4.5%20Release/
cosa scegliete di fare?
Una banana al vincitore!
Esatto: vi scaricate l'immagine della macchina virtuale, prendete una macchina con su MSWin, installate VMWare e ci piazzate la suddetta immagine. Reiterare per ogni sede.

CYA

P.S.: un saluto a flameeyes e a Bosk (ma tanto sono in incognito hehehe)
-- z f k

Query By Tsumi posted 19/10/2009 18:46

@ Tsumi By ringo posted 20/10/2009 10:27

@ ringo By Tsumi posted 20/10/2009 11:48

> Vorrei spezzare una lancia!
> Anche una delle mie query sta diventando come quella qui sopra.
>
> Tutto era cominciato qualche anno fa quando bisognava estrarre dei record con un campo appartenente ad un ridottissimo insieme:
>
> SELECT * FROM TABELLE WHERE CAMPO IN ('uno', 'due', 'tre');
>
> A mia domanda se CAMPO nel tempo avesse potuto avere altri valori mi risposero $assolutamente_mai_impossibile_quelli_sono_quelli_restano!
> tanto che gia' tre mesi dopo avevo dovuto aggiungere anche 'quattro' e 'cinque'
>
> A quel punto chiesi se non era il caso di valutare di inserire quei valori in una tabella aggiornabile dall'utente e riscrivere la query con una join.
> Mi chiesero "quanto costa?" non tanto per il costo del lavoro (siamo tutti interni) quanto perche' la creazione di una ulteriore tabella non prevista nella analisi (la parola "analisi" deve sempre essere accompagnata da una fragorosa grassa risata in sottofondo, come fanno i cavalli di Frankenstein Junior quando sentono il nome Blucker).
>
> La tabella la devono creare $quelli_del_db, quindi costa, quindi non si fa, perche' non c'e' il budget. (siamo tutti interni, ma l'IT e' ripartito in $programmatori, $sistemisti e $quelli_del_db, tutti team diversi con budget separati)
>
> E cosi' per non far fare una tabella a $quelli_del_db, la mia query e' gia' arrivata a CAMPO 'diciannove' e non e' ancora finita...
>

Vabbè però un modo tecnico di risolvere il problema c'era, quindi possiamo dare la colpa alla gestione del progetto che per 4 soldi in meno ha fatto si che si producesse questo orrore piuttosto che ad un limite tecnico
Cmq qui si è arrivati almeno CAMPO 'tremila' che è un po' di più di 'diciannove' :| -- Tsumi

@ ringo By Anonymous coward posted 21/10/2009 14:52

php da' troppa liberta' By alessiodp posted 19/10/2009 19:22

@ alessiodp By Golan Trevize posted 20/10/2009 11:18

> il php da' troppa libertà nell'uso delle variabili delle funzioni e degli interrupt...

interrupt? Tipo int13? Dove?

> pertanto si presta bene a piccoli algoritmi o piccoli script
> alcuni lo usano alla menopeggio...

Il C dà molta più libertà. Puoi anche formattare gli hard disk o far resettare il computer. E riesci anche a spararti sul piede...
-- Golan Trevize

@ Golan Trevize By Davide Bianchi posted 20/10/2009 11:34

query da migliaia di righe By LuciferSam posted 19/10/2009 20:25

eh eh, peccato che io ho visto query e stored procedures con migliaia di righe e non sono nemmeno identate decentemente... -- LuciferSam

@ LuciferSam By Davide Bianchi posted 19/10/2009 20:42

> eh eh, peccato che io ho visto query e stored procedures con migliaia di righe e non sono nemmeno identate decentemente...

Ma qualche cosa mi dice che non erano in MySql.
-- Davide Bianchi

@ Davide Bianchi By Kent Morwath posted 19/10/2009 23:40

> Ma qualche cosa mi dice che non erano in MySql.

No, infatti nessuno implementa un datewarehouse su MySQL

A parte gli scherzi, in genere le query su sistemi OLTP sono piuttosto semplici (specialmente se lo schema è fatto bene) - quelle complesse di solito appaiono nei DW, specialmente se si fanno calcoli e aggregazioni direttamente nella query, che di solito è un po' più performante che spostare il 75% del database sul client per i calcoli.

Se si impara a ragionare a "set" invece che proceduralmente con SQL si possono creare query apparentemente complesse, ma che alla fine sono performanti e sfruttano appieno il motore DB. Però è anche facile pastrocchiare e scrivere decine di linee che ingarbugliano solo il tutto.
-- Kent Morwath

@ Davide Bianchi By LuciferSam posted 20/10/2009 21:14

Adesso che lo rileggo.... By Herr Franz posted 19/10/2009 20:49

Query MSSQL By Andrea posted 19/10/2009 22:54

Per un cliente($VESTITI_FIRMATI_DAL_NOME_STRANO) di cui la ditta per cui lavoravo gestisce il world wide shop ed una serie di ammennicoli, ci sono delle stored procedure con queries... come dire... un pelino complicate
Al confronto, quella query è piccola.
Per non parlare di un certo programma in VB... un giorno questa la mando!

Andrea -- Andrea

Aaaaah, il mitico database "generico" :-D By Kent Morwath posted 19/10/2009 23:36

Eccolo un altro che ha deciso di implementare il mitico database universale - ogni database può essere implementato in sole 4 tabelle! Si gettano al vento i tipi (si usano solo campi generici stringa...) e altre amenità quali vincoli e integrità, per ottenere il dato più stupido si fanno ventisette join, ma una volta creato la schema non lo si tocca più! Vuoi mettere? -- Kent Morwath

@ Kent Morwath By Angkarn posted 20/10/2009 11:47

> Eccolo un altro che ha deciso di implementare il mitico database universale - ogni database può essere implementato in sole 4 tabelle! Si gettano al vento i tipi (si usano solo campi generici stringa...) e altre amenità quali vincoli e integrità, per ottenere il dato più stupido si fanno ventisette join, ma una volta creato la schema non lo si tocca più! Vuoi mettere?
>
>

Proprio l'immagine che ha dato a me!
Di query ne ho viste e scritte anche di molto più lunghe, ma comunque molto più chiare. Mappare ogni oggetto reale con tabelle così generiche da obbligare i "query-writers" a fare filtro su un campo che specifica il tipo di relazione è follia pura. Peraltro, l'interminabile serie di filtri che va a includere o escludere gli indirizzi di determinate classi IP grida vendetta... sono le classiche query che richiedono manutenzione continua.
Purtroppo, ben pochi sanno come si progetta per bene un database.
-- Angkarn

2 cose By Alberto posted 20/10/2009 00:48

Query complesse By Gas posted 21/10/2009 20:40

Cambiare idea By Strider posted 26/10/2009 20:28

@ Strider By Davide Bianchi posted 27/10/2009 08:38

34 messages this document does not accept new posts

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.