Storie dalla Sala Macchine


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Imposta lingua:en it | Login/Register


pezza pezza pezza pezza pezza pezza...

Che cosa e' una "pezza", anche nota, in gergo "informatico", come "hack"? E' una soluzione veloce, semplice e molto spesso raffazzonata, per aggirare un problema che si presenta occasionalmente. In genere un "hack" e' quello che si mette insieme quando ci si trova in una situazione e non si puo' o non si vuole andare per una soluzione piu' elaborata o definitiva.

Quando ti ritrovi con una gomma a terra, ci metti una pezza, e poi, con comodo, cambi la gomma... O meglio, dovresti cambiare la gomma. Ma sappiamo bene che molto spesso la "pezza" rimane li' finche' non cede. O finche' la gomma non cede del tutto.

E la cosa funziona... per tutto. "Soluzioni temporanee" le chiamiamo. Ignorando il fatto che molto spesso sono soluzioni definitive. Ho gia' detto, piu' di una volta, cosa penso al riguardo della cosa, ma capisco anche che in molti casi non ci sono molte possibilita' alternative. Una soluzione "definitiva" e' o impossibile o estremamente costosa, quindi... ci si lascia la pezza e si continua.

Il guaio e' che le pezze, a volte, anzi spesso, anzi quasi sempre, anzi sempre, "perdono". E ci si ritrova a dover gonfiare la gomma di continuo. E quando la pezza cede di colpo...

E dopo questa introduzione rappezzata, ritorniamo a parlare di UL e del suo "relay" di cui dissi tempo fa. E la prima cosa da fare, e' dare qualche dettaglio.

Taaaaaaanto tempo fa, qualcuno aveva pensato che, un bel giorno, ci potrebbe essere la necessita' di inviare messaggi di posta in modo... diverso. Perche', apparentemente, nessuno ha di meglio da fare che cercare di re-inventare la ruota ogni fottuto giorno. Percui invece di usare una cosa che esiste e funziona decentemnte (SMTP), questo qualcuno ha deciso di inventarsi un nuovo modo che usa (rullo di tamburi) HTTP. Yep. Perche'? Non ne ho idea.
La cosa e' stata documentata ed e' diventato un altro "standard". Che non essendo standard con niente viene usato in genere per funzioni di nicchia, molto spesso si tratta di quella branca di cose che sono riferite come 'B2B'. Insomma, invece di esseri umani che si scambiano spam, sono macchine che lo fanno.

La differenza fondamentale tra questo coso (chiamato AS2) e' che supporta la crittografia (via https) e che funziona solo tra "partner". Perche' un messaggio possa essere spedito, gli interessati (mandante e ricevente) devono scambiarsi i rispettivi certificati di sicurezza.

E se vi domandate "che differenza c'e' tra questo ed una mail segnata con pgp", la risposta e' "nessuna".

Comunque sia, il principio e' che e' possibile inviare messaggi tramite questo coso. Il problema e' che il "protocollo" e' solo per INVIARE o RICEVERE messaggi e basta. Ma per CREARE i messaggi o LEGGERLI... he...

Ora, l'accrocchio che UL aveva deciso di mettere in piedi serviva ad ovviare a questa piccola deficienza. La cosa si basava su un prodotto open source (e non piu' mantenuto da tempo) per l'implementazione del protocollo. E poi la parte che era stata "sviluppata" che prendeva i messaggi via imap da una certa casella di posta, li riformattava in modo che potessero essere mandati via AS2 e li "sottoponeva" all'invio. Dall'altra parte, prendeva i messaggi che erano ricevuti li ri-formattava e li sbatteva in pasto a postfix in modo da inviarli in modo "normale".

Almeno, questa era l'idea.

Il problema era che, come spiegato tempo addietro, lo "sviluppo" era stato fatto in modo abbastanza approssimativo ed il risultato finale era carente di alcune caratteristiche fondamentali. Come il fatto di funzionare.

Dato pero' che vi era un cliente (o speranzoso tale) pagante (o si supponeva), c'era un certo interesse ad avere questo coso funzionante. Percui, UL prese i vari "suggerimenti" che gli avevo inviato e, dopo aver millantato esperienza decennale nella programmazione in Python, decise di mettersi all'opera lui stesso.

Dopo due settimane di sudore e fatiche (cosi' ha detto lui), UL ha presentato il "prodotto finale" ed ha assicurato allo speranzoso cliente che tutto funzionava per il meglio. Io, ovviamente, avevo i miei dubbi. 

Dopo un mesetto, mi sono ritrovato una (non troppo) bella maillina nella casella di postina. Apparentemente il "cliente" chiedeva informazioni su un certo numeri di messaggi che avrebbero dovuto essere inviati ma sembrava non fossero andati da nessuna parte. Quindi e' il caso di armarsi di pazienza e cercare di capire come funziona questo coso.

Allora, la parte open source e' l'unica che mi ispira una certa fiducia, anche perche' c'e' un log che mi dice che il messaggio tal-de-tali e' stato ricevuto. Il problema viene dopo.

Si' perche' il messaggio viene scritto in un file su disco, poi entra in funzione l'accrocchio maledetto che dovrebbe leggere questo messaggio, cercare di capire a chi dovrebbe essere spedito e spedirlo a destinazione.

UL (o i programmatori di cui si e' detto) ha deciso che la cosa migliore da fare e' dividere il problema in 3 fasi. 

Fase 1: c'e' uno script che ogni 5 minuti guarda se ci sono nuovi messaggi in una directory, e si aspetta che un messaggio sia in un file con un certo nome. Se lo trova, legge il messaggio, e crea una "intestazione" che contiene il mittente ed il destinatario, poi ficca il tutto in una coda di messaggi da processare.

Problema numero uno: il "nome" del file che lo script si aspetta ha certe caratteristiche, che la part open source non sempre rispetta perche' quella parte usa il "message id" che e' indicato dal mittente. Percui se il mittente decide di fare qualche cosa di diverso, il sistema fallisce alla prima fase.

Fase 2: Una volta ficcato il messaggio nella coda, questo viene ripescato dal secondo script, il quale legge l'intestazione ed a seconda della combinazione mittente/destinatario, ficca il messaggio in una coda dedicata (IMAP o SMTP).

Problema numero due: la combinazione mittente/destinatario e' case-sensitive, ma la lista che viene letta da un file non viene controllata, percui se uno dei nomi non corrisponde, la combinazione non viene trovata ed il messaggio rimane non processato e viene lasciato per sempre nella coda.

Fase 3: A questo punto il messaggio e' in una coda per una destinazione, ed interviene, si', UN ALTRO SCRIPT, anzi due. Ognuno dei quali legge una coda specifica e gestisce i messaggi che arrivano in quella coda. Ognuno di quei due script, che si somigliano troppo per essere una coincidenza, prende il messaggio in questione e cerca di inviarlo o depositarlo nella casella di destinazione.

Problema numero tre: non c'e' nessun controllo sull'esistenza della casella di posta o destinazione del messaggio, se la casella o la destinazione non esistono, il messaggio finisce nella spazzatura.

Problema numero quattro: il messaggio ricevuto da AS2, ha un suo ID, ma quando il primo script lo legge e lo infila nella coda, questo ID viene ignorato. Quindi si perde il collegamento tra il messaggio ricevuto e quello processato.

Problema numero cinque: nessuno, dico NESSUNO, di questi cazzo di script fa un minimo di controllo di errore. Se qualche cosa va male le opzioni sono: lo script si schianta, il messaggio viene abbandonato da qualche parte o entrambe.

Problema numero sei (corollario a quello sopra): nessuno di questi stracazzo di script fa un minimo di "logging". Tutto quello che viene loggato e' "letto messaggio"... unito al numero quattro sopra, dato che non c'e' piu' un collegamento tra i messaggi che sono ricevuti via AS2 e quelli che sono (o non sono) trattati, e' impossibile sapere che cosa e' successo ad un particolare messaggio. Si, abbiamo ricevuto qualche cosa... e poi che cosa cazzo e' successo?

Dopo numerose ore perse a cercare di capire come cappero girano le cose in questo casino scopro diversi altri problemi, che non sono apparenti all'inizio ma cominciano ad emergere quando si guardano le cose piu' da vicino. Per esempio, se il messaggio ricevuto via AS2 non rispetta il formato che lo script in fase 1 si aspetta, lo script lo lascia dove sta' perche' non sa che farci. Quindi la directory puo' anche riempirsi ed a quel punto l'intero sistema si incrocchia e se non si incrocchia lo script diventa sempre piu' lento perche' continua a leggere e rileggere gli stessi files che sono gia' li'.

Altro esempio, gli script di fase 3, prendono il messaggio dalla coda e lo scrivono su disco in un file temporaneo, questo file ha il nome composto dal mittente e la data inclusiva di ora. Il che significa che se piu' di un messaggio viene ricevuto nello stesso secondo dallo stesso mittente, c'e' una buona possibilita' che lo stesso file venga sovrascritto e quindi uno o piu' messaggi possono essere "persi" senza traccia.

I vari script che leggono dalle varie code non fanno nessun controllo di errore, quindi se un messaggio viene letto e rimosso da una coda e poi lo script si schianta, quel messaggio e' andato, svanito, dissolto nel nulla.

Se pero' il messaggio non puo' essere processato, viene lasciato nella coda. Il che signfica che uno script puo' passare ore ed ore a rileggere sempre gli stessi messaggi senza inviarne nessuno. Inoltre puo' anche riempire la coda e schiantare, di nuovo, tutto il sistema.

Oppure puo' leggere un messaggio con un indirizzo sbagliato, rimuoverlo dalla coda, passarlo a Postfix che poi lo buttera' via perche' l'indirizzo e' sbagliato.

E dato che nessuno logga niente, io sono solo in grado di vedere dai log della parte open source che abbiamo ricevuto 20 messaggi il giorno tale, ma ne vedo solo 10 in uscita sui log di Postfix, quindi quali sono questi 10 e che e' successo agli altri? Quale messaggio e' stato inviato e quale e' stato invece lasciato cadere in /dev/null?

Dopo aver perso una buona giornata guardando questo coso e ricordandomi perche' detesto python (ed UL), ho messo insieme una lista di bugs e miglioramenti che dovrebbero essere implementati in questo coso.

Inoltre ho anche capito che e' molto meglio se il nostro cliente si rassegna a re-inviare i messaggi che sono mancanti, dopo che abbiamo implementato le correzioni del caso ovviamente.

A quel punto pero', il famoso "cliente" aveva cominciato a madonnare. Cosa che io potevo anche capire ed essere d'accordo con lui, in principio, ma non nella sostanza. Perche' da nessuna parte nel contratto che non aveva firmato c'era scritto che noi si assumeva un qualche tipo di responsabilita' nella funzionalita' della cosa. E questo e' cio' che feci presente durante la discussione che segui'. 

Feci anche presente pero' che questo coso allo stato attuale non era un "prodotto", era un hack. Una cosa che funziona solo ed unicamente se e' usato in modo "baby-sitter", non e' in grado di funzionare in modo stabile per conto suo, non fornisce nessuna informazione utile per il debug ed in generale, non e' possibile considerarlo un sistema di "produzione", non importa quante birre ti sei fatto la sera prima.

Ed UL? Lui sostiene che il sistema adesso e' di produzione quindi non vuole toccare il codice (che non funziona) se non c'e' un sistema di sviluppo dove fare le prove. Ovviamente.

Davide
13/11/2020 12:56

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.

8 messaggi this document does not accept new posts

Klang

Di Klang postato il 11/01/2021 10:49

Tutti quelli che tentano di reinventare la ruota finiscono per farla ovale, o quadrata, o a forma di poligono irregolare. Il vecchio SMTP e il PGP fanno forse venire l'orticaria a UL?

-- Klang

Anonymous coward

@ Klang Di Anonymous coward postato il 11/01/2021 12:43

Hanno tre difetti fondamentali ed irrisolvibili.

1) funzionano

2) bisogna studiarli e capirli

3) non sono cool o all'ultima moda

Tutti quelli che tentano di reinventare la ruota finiscono per farla ovale, o quadrata, o a forma di poligono irregolare. Il vecchio SMTP e il PGP fanno forse venire l'orticaria a UL?

 

 

-- Anonymous coward

Cobra78

Di Cobra78 postato il 11/01/2021 12:29

E questa storia esemplifica perchè qualcuno mi dice "mai si dai, intanto facciamo così, poi ci pensiamo a sistemarlo" gli dico "no, a meno che non ci sia una mail formale dal tuo superiore che se qualcosa si introia la responsabilità è tua" o in alternativa "ok, se mi dici che alla data X sarà apposto va bene, ma sappi che alla data X l'accrocchio smetterà di funzionare"

 

per fortuna nella mia ditta i tecnici sono sufficientemente ascolatit, e quindi tutto questo si traduce in un "ok, allora aspetta che facciamo per bene punto e basta"

-- Prendi la vita al minuto, non all'ingrosso.
Sogna come se dovessi vivere per sempre; vivi come se dovessi morire
oggi.

Thomas

Di Thomas postato il 11/01/2021 21:35

Perche' non hai girato la mailina del cliente ad UL dicendogli una roba tipo:

"sei tu che hai fatto le correzioni, sei tu che hai dieci anni di esperienza, puppatela tu 'sta $roba_fetida_marrone, auguri, fammi sapere come va a finire, o magari anche no"

?

...no lascia stare, la risposta la so gia', ma oggi ho avuto una brutta giornata al lavoro e sono ancora in fase "fankrulo cavatevela da soli"...

-- Thomas

Guido

Di Guido postato il 18/01/2021 15:13

sai quante volte ti senti dire "fai una cosa al volo poi ci si rimette mano ammodino" ?

e non devo dire quando e' quel poi vero?

-- who uses Debian learns Debian but who uses Slackware learns Linux

Guido

Di Guido postato il 18/01/2021 15:21

Gia' che non ha copia ed incollato codice ad mentula da internet...

-- who uses Debian learns Debian but who uses Slackware learns Linux

Anonymous coward

Di Anonymous coward postato il 22/01/2021 04:09

Se il cliente NON ha firmato il contratto, per definizione, é un NON cliente che suppongo NON ha ancora pagato né il saldo né, tanto meno, un anticipo.

ma il software é in produzione....

Mi sfugge qualcosa.

-- Anonymous coward

Anonymous coward

Di Anonymous coward postato il 31/01/2021 19:50

non ho mai capito perche questi UL che reinventano - male - la ruota per poi disconoscerne la paternità, non vengano semplicemente presti, portati fuori ne cortile sul retro, fatti inginocchiare, liquidati con una pallottola nella nuca per poi buttarne la carcassa nel tritarifiuti...

-- Anonymous coward

8 messaggi this document does not accept new posts

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.


Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.

Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".

Web Interoperability Pleadge Support This Project
Powered By Gojira