Storie dalla Sala Macchine

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

Precedente Successivo

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

34 messaggi this document does not accept new posts

peccato... Di Argaar postato il 19/10/2009 09:10

giusto! Di Herr Franz postato il 19/10/2009 09:11

PHP Di Palin postato il 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 Di Eugenio Dorigati postato il 19/10/2009 10:29

non è il PHP, è il programmatore Di Anonymous coward postato il 19/10/2009 09:30

ho mollato la storia a meta'... Di R.P. postato il 19/10/2009 09:35

@ R.P. Di Anonymous coward postato il 19/10/2009 10:23

povero PHP Di Golan Trevize postato il 19/10/2009 10:01

Regola numero uno del CL. Di Davide Inglima postato il 19/10/2009 10:16

Ci risiamo... Di Anonymous coward postato il 19/10/2009 10:26

PHP e sedicenti “programmatori” Di Diego E. Pettenò — Flameeyes postato il 19/10/2009 10:54

centos? Di Riccardo Cagnasso postato il 19/10/2009 12:13

@ Riccardo Cagnasso Di Davide Bianchi postato il 19/10/2009 12:19

@ Riccardo Cagnasso Di Kesty postato il 19/10/2009 13:54

@ Riccardo Cagnasso Di z f k postato il 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 Di Tsumi postato il 19/10/2009 18:46

@ Tsumi Di ringo postato il 20/10/2009 10:27

@ ringo Di Tsumi postato il 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 Di Anonymous coward postato il 21/10/2009 14:52

php da' troppa liberta' Di alessiodp postato il 19/10/2009 19:22

@ alessiodp Di Golan Trevize postato il 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 Di Davide Bianchi postato il 20/10/2009 11:34

query da migliaia di righe Di LuciferSam postato il 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 Di Davide Bianchi postato il 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 Di Kent Morwath postato il 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 Di LuciferSam postato il 20/10/2009 21:14

Adesso che lo rileggo.... Di Herr Franz postato il 19/10/2009 20:49

Query MSSQL Di Andrea postato il 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 Di Kent Morwath postato il 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 Di Angkarn postato il 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 Di Alberto postato il 20/10/2009 00:48

Query complesse Di Gas postato il 21/10/2009 20:40

Cambiare idea Di Strider postato il 26/10/2009 20:28

@ Strider Di Davide Bianchi postato il 27/10/2009 08:38

34 messaggi this document does not accept new posts

Precedente Successivo

Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.