Questo week end ho lavorato un pochino – nel tempo lasciatomi libero da famiglia &co – e ho riscritto parte del codice. Stasera mettero’ online i sorgenti della 2.0.57, e chi scarica la PPA , cioe’ la versione gia’ compilata, ricordi che adesso DEVE creare un file di configurazione, e quindi…. RTFM. CI sono diverse novita’ che ho implementato su richiesta.
Per prima cosa, dicevo, il file di configurazione. Il meccanismo della riga di comando va bene, ma nelle subshell degli MTA vari essere sicuri che si ereditino tutte le stringhe di ambiente e’ difficile. Cosi’ ho fatto in modo che sia possibile scrivere un file di configurazione , che a parita’ di ambiente produrra’ lo stesso comportamento.
Ho migliorato le condizioni di uscita nella SM, in modo che comunque in standard output , in caso di fallimento, esca il messaggio che e’ entrato, tale e quale. Ne risulta che potete usarlo anche per la posta in USCITA dal vostro server SMTP. Se viene trovata una chiave pubblica per il destinatario il messaggio viene criptato, altrimenti rimane intatto. Integrandolo in u MTA , per esempio come pipe in master.cf, ne risultera’ che scriverete posta criptata a chiunque abbia una chiave pubblica nei server che indicate.
Questo per chi mi ha chiesto come usare il keyserver tra due MTA diversi, ma poter inviare mail in chiaro a chi non usa quel keyserver. Adesso potete.
Lo stesso dicasi per il cloud: se andate a creare un bundle in un cloud AWS, a patto di tenere il keyserver esterno potete duplicare i backend quanto vi pare.
Sempre per chi deve usare un cloud: si, ho capito il punto. Di fatto, gpg sta usando male la compressione. Il valore di default e’ 6, che fa in modo che gpg tenti di comprimere, abbia senso o meno, ogni messaggio in entrata. Questo fa spendere CPU per nulla su email contenenti jpg,mpg,zip &co. Anche se le email non contengono mai binario in se’, usando base64 , dando cosi’ un falso senso di comprimibilita’, un settaggio fisso produce una fatturazione ingiustificabile sui cloud.
Del resto, pero’, non comprimere il comprimibile sarebbe un peccato, perche’ sui cloud si paga lo storage. Cosi’, la soluzione e’ di comprimere quando il costo di CPU vale lo spazio su disco. Ho implementato un controllo basato sull’entropia dell’informazione contenuta nel body.
Se abilitate zlib sul file di configurazione, gpg_body andra’ a calcolare l’entropia dei file, e sulla base di questa scegliera’ il livello di compressione. Ho creato un file di tutti zeri da due MB e me lo sono spedito, e il risultato e’ stato questo: (ecco il file di dump di cui parlero’ dopo)
Microsec: 1: From status entering to 0 : Starting State Machine ( done: ) Initializing program
Microsec: 66: From status 000 to 100 : Entering the SM ( done: ) Setting everything to go in status 100
Microsec: 91: From status 100 to 101 : changing status ( done: ) finished to check for argv
Microsec: 135: From status 101 to 102 : changing status ( done: ) found a config file
Microsec: 1871: From status 102 to 120 : changing status ( done: ) read the config file
Microsec: 100776: From status 120 to 140 : changing status ( done: ) read the mail from stdin
Microsec: 103728: From status 140 to 180 : changing status ( done: ) splitting headers and body
Microsec: 103757: From status 180 to 200 : changing status ( done: ) smime generated
Microsec: 103850: From status 200 to 220 : changing status ( done: ) mime headers separated
Microsec: 103853: From status 220 to 239 : changing status ( done: ) mime body enclosure generated
Microsec: 103882: From status 239 to 240 : changing status ( done: ) syntax ok in config file
Entropy: 0.215627 bit per ASCII 7bit symbol ==> compression level: 9
Gpg command to execute: /usr/bin/gpg -ea -z 9 –batch -r [email protected] -o /tmp/Fp4ypVMEUjcIuF6b
Microsec: 286668: From status 240 to 280 : changing status ( done: ) generating tmp filename and command
Microsec: 319126: From status 280 to 300 : changing status ( done: ) encrypting the body with original mime headers
Microsec: 319793: From status 300 to 320 : changing status ( done: ) read the encrypted message
From status 320 to 400 : terminal status reach – everything ok ( step: ) print encrypted message all together
La compressione in questo caso, e’ stata circa di 1:1000.
Usando un file gis’ zippato con livello 9 come allegato dentro la email, gpg_lib ha scelto il livello di compressione 1, e la dimensione dell’email e’ scesa solo del 10% circa, per via della codifica base64 che produce overhead.
In pratica, se abilitate le librerie, userete la CPU per comprimere solo quando salvate MOLTO spazio sullo storage del cloud. A voi calcolare i prezzi a seconda del vostro provider.
Ma ancora: che diavolo e’ quel dump sopra?
Chi mi ha chiesto come ottimizzare il programma mi ha fatto una bella domanda. Ha senso mettere il file temporaneo su un file in un disco SSD? Ha senso usare un ramdisk? Bella domanda, perche’ senza usare un profiler non e’ facile fare questo tipo di conti.
Cosi’ nel file di configurazione potete settare un file di dump, il quale di scrivera’ ogni passaggio di stato della SM, con il tempo in microsecondi. Se vedete che la fase “leggere dal file temporaneo” vi prende molto tempo, allora probabilmente vi conviene spostare (usando il file di configurazione) la directory su un SSD. Se invece vedete che e’ la lettura della email da stdin a prendervi tempo, probabilmente il problema sta negli IPC della vostra macchina. Se vi prende molto eseguire la crittazione, provate a disabilitare la compressione, oppure andate a verificare la latenza verso il keyserver, oppure provate ad aggiungere (usando il file di configurazione) parametri che permettano di salvare la chiave nel local keyring quando la si legge dal keyserver.
Il dump puo’ essere abilitato sia quando il programma fallisce che quando il programma riesce, in modalita’ debug, se volete osservarne le performance: dategli in pasto una email (in formato testo, tipo .eml) sullo standard input e vedete che succede nel vostro sistema.
Il file di configurazione vi offre la possibilita’ di passare altri comandi che saranno aggiunti alla command line di gpg, ma ci sono alcune limitazioni. Non sono permesse redirezioni dell’output e le opzioni di cui si occupa gia’ il programma non sono consentite, quindi anche -z non passa piu’. In generale adesso il programma accetta solo UNA opzione in input, che e’ -r KEY_ID o -r
[email protected] , ovvero qualsiasi cosa si possa usare per una query al keyserver o al keyring onde avere la chiave pubblica.
Uriel
Correlati
