Sempre più spesso il codice ha un cattivo odore.

Sei sicuro di non scrivere codice puzzolente? Vediamo come riconoscere quali sono le code smell più frequenti e quali metodologie utilizzare per minimizzarle.

Se si deve acquisire un hard disk in maniera forense, ossia con tutti i crismi necessari al fine di garantire che la copia sia identica all'originale, a tutti quelli che operano nel settore viene subito in mente l'uso di DD, DCFLDD o DC3DD (nel mondo Open Source GNU/Linux), con le classiche opzioni e parametri.

Gli approcci sono due:

1. Ottimistico (consideriamo il disco sano e tutti i settori sani).
2. Pessimistico (consideriamo che il disco abbia qualche settore danneggiato)

Nel caso in cui l'approccio ottimistico sia sconfessato, perchè durante l'acquisizione ci si ritrova con degli errori di lettura, allora si tenderà a porsi nell'ottica pessimistica, a volte anche ricominciando tutto d'accapo.

Esaminiamo gli scenari:

dd if=/dev/sdb of=/media/sdc1/disco.dd conv=noerror,sync bs=32K

Il suscritto comando leggerà blocchi da 32Kb dal disco /dev/sdb e scriverà sul disco destinazione /media/sdc1 (montato in scrittura) il file disco.dd, l'opzione conv=noerror,sync serve a due cose:

1. Noerror - indica a dd di non fermarsi di fronte ad eventuali errori di lettura, ignorando i blocchi illeggibili, ma questo, senza il sync, cambierebbe l'indirizzamento del disco, poichè l'immagine (disco.dd) del disco avrebbe una dimensione finale errata, inferiore a quella del disco originale.
2. Sync - Il flag sync forza dd a scrivere i blocchi della dimensione prescelta (es. BS=32K) e se non ci sono abbastanza dati per riempire il blocco, quest'ultimo sarà riempito di zeri (0s padding). Questo crea un problema, il file immagine di destinazione avrà una dimensione multipla del BS prescelto. Es. se il disco origine è di 6Kb ed il BS=4K, il file immagine avrà come dimensione 8Kb.

Inoltre, con un BS=32K e conv=noerror,sync, se dovessimo incontrare dei settori danneggiati, che però appartengono al buffer di lettura di 32Kb, il dd così configurato andrebbe a riempire ben 32Kb di zeri, sacrificando anche i settori sani che potrebbero esserci in quei 32Kb.

Se ci sono solo due di settori danneggiati 512 bytes * 2 =1024 bytes = 1Kb, significa che i rimanenti 31Kb saranno azzerati, perchè dd ha letto un blocco da 32Kb ha incontrato degli errori ed ha fatto il riempimento di zeri su tutto il blocco letto.

Quindi la soluzione sarebbe quella di impostare dd con un BS=512, che è la misura minima di un settore, così da leggere il disco, settore per settore e nel caso uno di essi fosse illeggibile, sarebbe riempito di zeri (sync), mentre il settore successivo (leggibile) sarebbe letto correttamente, preservandone il suo contenuto.

dd if=/dev/sdb of=/media/sdc1/disco.dd conv=noerror,sync bs=512

Il problema di questa configurazione è che stressa di più gli hard disk, costringendoli a moltissime letture (sector by sector) e rende l'operazione più lenta.

Come risolvere?

Ci sono dei tools alternativi come ddrescue o dc3dd, che permettono di leggere blocchi di dimensioni maggiori di 512 bytes, ma nel momento in cui si trovano di fronte ad un errore, questi useranno il block size di dimensione minima, 512 bytes appunto e lo riempiranno di zeri.

DC3DD ha il default blocksize di 32768 bytes (32Kb), al fine di aumentarne la performance.

Il file immagine finale è calibrato sulla dimensione del disco sorgente indipendentemente dalla dimensione del blocco, così la dimensione del file immagine è esattamente la stessa, come se avessimo usato un BS=512. 

Sector Error Recovery

Quando si incontra un errore ed il block size è più grande del settore del device sorgente, e il parametro conv=sync,noerror è impostato, dc3dd cerca dalla fine all'inizio del blocco e prova a leggere ciascun settore indvidualmente, così i settori buoni saranno acquisiti e quelli cattivi saranno rimpiazzati dagli zero.

Questa caratteristica permette di acquisire le aree non danneggiate del disco a velocità maggiori, (dato che il BS=32K), senza perdere i blocchi di dati che circondano un bad sector.

Per attivare questa modalità è richiesto il direct I/O mode abilitato (iflag=direct su Linux, /dev/rdisk* su Mac OS X). 

dc3dd if=/dev/sdb of=/media/sdc1/disco.dd conv=noerror,sync bs=32k iflag=direct

oppure con ddrescue 

ddrescue -d -r3 /dev/sdb /media/sdc1/disco.dd log.txt

In sostanza il parametro iflag=direct o -d per ddrescue, serve a bypassare la Kernel Cache (pagecache)¹ e accedere direttamente al disco (direct I/O), considerando così la dimensione minima del settore.

Chi volesse usare DCFLDD con direct access non può utilizzare il parametro iflag=direct, dato che dcfldd è un fork di dd, quindi non segue lo stesso sviluppo di quest'ultimo, ma può accedere al device sorgente in direct I/O tramite il /dev/raw (per questo documentarsi sul device raw in Gnu/Linux).

E' chiaro che per uso forense si tende ad usare di più uno strumento come DC3DD dato che ha anche caratteristiche di multiple hashing automatico, verifica, ecc.. Es.:

dc3dd if=/dev/sdb of=/media/sdc1/disco.dd conv=noerror,sync bs=32k iflag=direct progress=on hash=md5,sha1 log=log.txt vf=/dev/sdb verifylog=log_verifica.txt

¹ La page cache è il luogo in cui il kernel mantiene in RAM una copia dei dati, per migliorare le prestazioni evitando l'I/O del disco, quando i dati che devono essere letti sono già in RAM. DC3DD è basato su DD, quindi iflag=direct funziona anche con DD.

Una volta c'era debootstrap, un tool fantastico che permetteva di creare un rootfs Debian di base in una directory qualsiasi di un sistema già funzionante; gli utilizzi potevano essere molteplici: crearsi un  ambiente protetto da chroot, oppure creare una Debian di base per poi montarla via NFS, anche da una architettura diversa dal sistema ospite.

Poi è nato multistrap, un tool che fa quasi tutto quello che fa debootstrap ma, in più, permette di scaricare i pacchetti Debian da più repository! Non che debootstrap non ci sia più ,intendiamoci... ma questo nuovo tool merita senz'altro un po' di attenzione. :)

Vediamo allora come si usa.

Chiunque di voi abbia avuto a che fare con la linea di comando avrà senz'altro apprezzato due cose: la possibilità di ridare un comando già digitato semplicemente cercandolo con le freccie «su» e «giù» e la possibilità di completare un comando con la doppia pressione del tasto «TAB».

Quelli più esperti poi apprezzeranno la possibilità di muovere il cursore più velocemente spostandolo direttamente da una parola all'altra, oppure la possibilità di cancellare parte della linea di comando con una combinazione di tasti particolare, ecc.. Bene, vi sieti mai chiesti come e ossibile questo? E perché queste funzionalità alle volte si trovano anche in altri programmi? No? Beh, ve lo dico io! Dipende tutto dalla libreria readline.

Questa libreria, che fa parte del progetto GNU, è alla base di molte interfacce di testo di diversi programmi a cominciare, ovviamente, delle shell. In questo articoletto vedremo molto brevemente come poter utilizzare questa libreria per realizzare un piccolo programma che possa essere utilizzato, ad esempio, per ottenere una serie di informazioni da un ipotetico dispositivo installato sul nostro sistema. Ovviamente, poiché nella realtà il dispositivo non esiste, metteremo del codice ad hoc per simularne il funzionamento.

Se avete il mail server in proprio potrebbe succedere che questo non sia raggiungibile dall'esterno; ad esempio una mancanza di corrente, un problema alla connessione di rete ecc..

In questo caso succede che tutte le mail dirette al vostro server non verranno consegnate, peggio ancora, se l'interruzione è prolungata può succedere che queste vengano ritornate al mittente per l'impossibilita di consegnarvele!

Ecco allora che si rende necessario avere un mail server di backup in modo tale che quando il server primario non funziona il secondario possa ricevere le mail in sua vece, e poi, una volta che il primario ritorna attivo, il secondario rimandi tutte le mail ricevute al server primario.

Qualche tempo fa il mio ex istituto superiore mi aveva chiesto di fare una piccola lezione presso i loro studenti sulle potenzialità del sistema GNU/Linux. Io ho subito accettato ed ho creato per loro, insieme al mio «socio» Massimiliano Rossi, anche lui ex studente, una piccola demo su come poter realizzare un semplice ma funzionante sistema di monitoraggio remoto di una stazione di rilevazione; il quale permetta poi di controllare l'evoluzione delle grandezze trattate via Web.

Nonostante le decine di installazioni delle varie distribuzioni Linux eseguite sia ad uso didattico che professionale mai mi ero imbattuto in una "stranezza" a cui ancora non sono riuscito a dare una spiegazione tecnica.

Durante un tentativo di installazione in dual boot di Ubuntu 9.10 (su un pc con pre-installato Win Xp sp3), al momento del controllo delle partizioni, l'installer mi presenta la normale situazione dell'hd con la presenza di Windows ma senza l'opzione della possibilità di ridimensionare la partizione esistente con la possibilità di installare Ubuntu solo dopo aver formattato tutta la stessa partizione.

Questa "anomalia" mi stranizza da subito visto che due giorni prima avevo effettuato la stesso operazione su un altro PC con lo stesso Win XP sp3 installato.

Decido di lanciare una versione live di GParted con l'idea di poter creare una partizione ex novo formattandola in ext3 e in seguito installare Ubuntu. Gparted mi fa vedere la partizione ma non mi permette di ridimensionarla nè di crearne di nuove.

A questo punto chiedo aiuto a Parted Magic pensando di poter utilizzare un altro strumento di partizionamento, ma scopro che si tratta del "gemello" di GParted: nulla da fare anche con questo strumento!

L’installazione  e l'avvio di una distribuzione Linux Live da un supporto USB può essere utilizzato come alternativa al metodo standard di masterizzazione dei CD. Ciò è particolarmente utile per l'installazione  su computer che hanno difficoltà a fare il boot da CD/DVD, o per quelli che non possono a causa della mancanza della periferica (per es. i netbook).

Quindi, quale migliore alternativa se non quella di utilizzare una semplice e veloce chiavetta USB reperibile ovunque? Vediamo allora come installare un distribuzione Linux su una pendrive da 4GB in soli 15 minuti sia usando Windows che Linux!

Volete fare un server Linux per la vostra impresa, ufficio o semplicemente per casa? Ecco una serie di indicazioni generali utili al consulente o all'utente finale per scegliere i componenti hardware, la distro e tutto quello che serve per realizzarlo da soli.

Prima Parte: l'Hardware

La scelta.

Quando si va a scegliere un server solitamente si parte dal valutare lo scopo per il quale verrà usato: sarà un file server, un mail server, un desktop server o un application server?

Essenzialmente però la differenza nell'uso si riduce a queste domande:

1. Quanto dovrà essere prestante l'elaborazione?

   Un application server e un desktop server avranno bisogno di molta potenza di calcolo, a differenza di un file server e di un mail server che non richiedono elaborazioni veloci; la velocità di clock della CPU è secondaria rispetto al numero di core e alla cache di 2 livello; la velocità di clock delle RAM è fondamentale negli application server.

2. Quanto veloce deve essere l'accesso ai dati?

   File server e mail server  trovano giovamento da dischi capienti e decentemente veloci, al contratio degli application server e dei desktop server - dove le prestazioni di accesso ai file vengono migliorate maggiorando la RAM; i dischi SAS hanno un vantaggio rispetto ai SATA solo nel caso di lettura /scrittura continua di nuovi dati e di RAM insufficente a fare la cache.

Detto questo, possiamo andare a vedere quello che offre il mercato - e qui anche il più esperto si perde in un mare di prodotti e sigle; tanto più che anche quando si conoscono fino in fondo le caratteristiche tecniche, non si ha mai la certezza del risultato finale, perchè l'ingegneria della motherboard, i BIOS e le periferiche possono avere caratteristiche nascoste o il tutto non andare d'accordo nell'insieme.

L'esperienza la fa da padrone: solo provando un certo modello ci si può rendere conto delle reali prestazioni - assodato di aver già fatto il tuning del proprio Linux per l'hardware in uso.

Mi permetto comunque di dare un opinione personale basandomi su 11 anni di esperienza nel settore, per quello che riguarda server entry level e di fascia media (1.000-6.000 euro al rivenditore):

IBM ha macchine inappuntabili, costruite a dovere e ben ottimizzate per le prestazioni più intensive; anche l'assistenza è ottima; sono i più cari e i pezzi usati nei server sono quasi sempre custom - se acquistate un server IBM quindi acquistate sempre anche l'assistenza per il periodo più lungo possibile; talvolta sulle macchine entry level i BIOS escono troppo presto (leggi: hanno qualche bug e bisogno di aggiornamento) e le macchine hanno spesso procedure  di intervento, come il reset di fabbrica, nascoste (leggi: non documentate, top secret).

Consigliati per application server e desktop server.

HP negli ultimi hanni produce server entry level economici (sotto i 1500 euro) imbattibili per il rapporto prezzo/prestazioni; sempre di più i loro server appaiono come assemblati, anche i modelli più costosi, con alcuni componenti custom e talvolta incompleti - sono rimasto un paio di volte senza parole difronte a un server da 4200 euro in cui mancava un connettore SAS da 25 euro per collegare i dischi forniti colla macchina. L'assistenza telefonica è ottima, quella presso il cliente fatta da ditte terze con compentenze tecniche medio-basse.

Il BIOS e l'integrazione dei componenti è ottima e difficilmente si possono aver problemi di installazione.

Consigliati per realizzare file server e mail server economici.

DELL ha cambiato negli anni molto le sue politiche: i primi server erano simili agli IBM, custom e fatti "con un solo pezzo", poi sono andati verso gli assemblati, poi verso gli assemblati con componentistica fatta in economia; l'assistenza nel passato era veloce e ben organizzata, ma da un paio d'anni non ho più avuto occasione di testarla. Stranamente su una dozzina di server da noi seguiti nove si sono rotti (alimentatori, motherboard) esattamente poco dopo finito il periodo di garanzia - un caso o contengono un meccanismo ad orologeria??

Il BIOS e l'integrazione dei componenti è buona, anche se talvolta ci sono problemi di installazione soprattutto sui controller disco.

FUJITSU produce anche server.

ACER prova a produrre server.

La configurazione

In base al tipo di lavoro che il server dovrà svolgere si andrà a intervenire sulla configurazione:

• La RAM più ce n'è meglio è; in particolare per gli application server e i desktop server; nelle distribuzioni standard di Linux difficilmente però vengono usati più di 8 GB - si può ricorrere però alla ramdisk  per usare la RAM in eccesso come disco, con un guadagno notevole in prestazioni.

• I dischi e la capacità: non troppo capienti, perchè quelli più capienti (es ad oggi i dischi da 1TB) solitamente sono anche quelli che si rompono prima perchè di prima produzione; esistono tre qualità dello stesso disco: se prendete un disco Seagate marchiato IBM, che costa 3, lo trovate anche OEM a prezzo 1 - ma la differenza c'è ed è dentro nella qualità (produzione di prima con testing e scarto).

  Da valutare con attenzione anche l'uso delle memorie a stato solito (CF, USB Pendrive),ma solo per l'installazione del sistema operativo.

• I dischi e l'accesso: SATA o SAS? visto il rapporto prezzo/capacità indubbiamente SATA e ramdisk, a meno che non abbiate bisogno di letture/scritture continue di grosse quantità di dati (es grossi, cioè >1GB, database); le SSD sono ancora fuori portata.

• I dischi e il controller: su server entry level e medi e/o con dischi SATA i controller hanno poco senso; il kernel di Linux fa già un ottimo lavoro di buffering e caching. Un salto di qualità si ottiene accoppiando controller buoni e dischi SAS; sì ai controller ServerRAID IBM con almeno 512MB, no ai controller economici LSI.

• Il RAID: Linux fa molto bene le funzioni per il raid a livello di kernel, spesso meglio dei controller entry level; sì al RAID 1 e 10, no al RAID 5 (soprattutto sui controller ServerRAID 8k, che in molte occasioni hanno fatto piangere i clienti). Consiglio il mirroring per la semplicità e immediatezza del processo, che in caso di disaster recovery è un punto a favore rispetto al raid 5.

• La CPU: maggiore il numero di core, meglio è, ma ancora più importante per applicazioni intensive è la cache L2; una differenza di 4MB (es da 8 a 12MB) può fare molto; il FSB e la velocità delle RAM sono direttamente correllati e hanno un influenza notevole nel calcolo generale, soprattutto nei desktop server.

• La ethernet: attenzione a verificare il chipset della scheda di rete e se possibile la memoria; in particolare se acquistate schede multiporta per fa il bonding delle interfaccie, scegliete schede ethernet con chipset Intel e una buona quantità di RAM. Ad esempio nel catalogo HP la stessa scheda ethernet si trova con RAM diverse e le prestazioni sono molto differenti. Non usate schede multiporta sopra le 2 ethernet: lo slot PCI ne risente e il decadimento delle prestazioni con Linux è visible (a differenza di FreeBSD).

• Gli slot di espansione: su un server dal piccolo budget l'espandibilità può essere importante, ma ha poco agio: è sempre limitata; infatti HP e IBM propongono le soluzioni blade per una vera scalabilità. Comunque se intendete inserire una scheda PCI Express, ad esempio una Sangoma per il VoIP, su un IBM fate molta attenzione agli interrupt e sperate che tutto funzioni; su un HP avrete più fortuna.

• L'alimentazione: il doppio alimentatore può essere molto importante, ma evitatelo sui server più economici, perchè vengono montati alimentatori di scarsa fattura e non ne vale la pena. Su ACER e COMEX ho visto anche tre alimentatori (!), ma servono più per fare scena che per reale utilizzo - soprattutto perchè su questi server era sempre difettosa la motherboard.

• La forma: rack, tower o blade? escludiamo il terzo, che richiede investimenti complessivi oltre il badget medio piccolo; rack o tower? in genere i tower a parità di prezzo forniscono maggiori prestazioni; attenzione agli IBM: le macchine a rack hanno spesso i dischi particolari, da 2,5''.

  Consiglio il rack per chi ha due o più server; superando i due server è conveniente la soluzione di un NAS e due server rack senza dischi.

Per ora abbiamo finito, nei prossimi articoli vedremo quale distribuzione usare ed i pacchetti software da installare e daremo anche un'occhiata al sistema di backup ed alle connessioni di rete. Stay tuned!

Dr Gabriele Gallacci - Questo indirizzo e-mail è protetto dallo spam bot. Abilita Javascript per vederlo.

La trading room o sala mercati è il luogo dove vengono effettuate le operazioni sui mercati finanziari regolamentati e non. Solitamente si presentano come degli open space con grandi desk suddivisi per tipologia di operatività trading azionari, su tassi, divise etc.

Per soddisfare le esigenze degli operatori vengono impiegati software specifici, a partire dai pc che sono tutti dotati di multi screen, questo permette di accedere agevolmente ai software utilizzati per il trading avendo sempre su un altro monitor grafici, quotazioni e  news da consultare.

Le tipologie di software

Volendo suddividere il software in macro categorie ne possiamo individuare tre.

Informativa

Le piattaforme informative forniscono al trader la situazione dei mercati. Prezzi, volumi, grafici, e news sono visualizzate in tempo reale.

Data la vastità delle informazioni disponibili, (si spazia dalle divise alle materie prime su mercati di tutto il mondo) ogni operatore configura specifiche viste in relazione all’area di interesse.

Queste piattaforme forniscono anche strumenti di analisi, utilizzati dai trader per supportare le attività di compravendita.

Trading

Le applicazioni di trading permettono all’operatore di accedere direttamente ai mercati per la compravendita di strumenti finanziari. Le piattaforme si differenziano  in base agli strumenti trattati.

Position keeping - risk managemen

Provate ad immaginare una trading room di 100 operatori che eseguono ciascuno 30-40 transazioni ogni giorno. La prima domanda da porsi è

dove sta andando il businnes ?.

Sì perché mentre il mercato azionario gode di ottima salute quello delle divise o delle materie prime potrebbe attraversare un momento di debolezza …. ed i tassi ?

Ecco che entrano in scena le applicazioni di position keeping, che funzionano da collettore di tutti gli ordini effettuati in sala mercati.

Le applicazioni di position keeping sono connesse mediante “interfacce”, ai mercati su cui vengono trattati i vari strumenti finanziari, e tramite le interfacce eseguono la cattura delle transazioni.

In ogni momento il responsabile della sala mercati può consultare la posizione globale, o divisa per desk.

Questo strumento viene utilizzato anche dai responsabili dei singoli desk e dai trader i quali vedranno la posizione del proprio portafoglio.

Per consentire al software di position keeping di fornire il profit&loss delle attività esso dovrà essere collegatoall’informativa, che fornirà in ogni istante il valore di ogni strumento in posizione.

Oltre a profit & loss questi strumenti forniscono i dati per la gestione del rischio (VAR).

Architettura di una sala mercati

Analizziamo ora l’architettura di una sala mercati, tralasciando in questo schema per semplicità, tutti i classici servizi standard , internet, mail etc.

Ad un Primo livello troviamo le DMZ a cui sono connessi gli info provider che alimentano le applicazioni di informativa, e la connessione ai mercati telematici.

I dati di informativa possono arrivare o da parabola o tramite linee dedicate (a seconda del fornitore), in molti casi l’utilizzo dei due canali è simultaneo e svolge funzione di backup.

L’accesso ai mercati avviene anch’esso tramite linee dedicate, il tutto separato da un firewall che garantisce la sicurezza tra DMZ e rete interna.

A seconda del numero di postazioni di informativa i dati possono venire distribuiti da un server posto sulla rete interna, al fine di rendere più snello il traffico sulla rete geografica.

Accanto all’informativa troviamo le applicazioni di trading. Anche in questo caso l’accesso è garantito da connessioni con linee dedicate o tramite VPN.

Particolarmente interessanti sono le applicazioni di position keeping, le quali come già detto dovranno funzionare da collettore di tutti gli ordini eseguiti sui mercati telematici, e per garantire la corretta valutazione degli strumenti dovranno essere connessi con i dati di informativa.

System integration

Particolarmente interessante è l’integrazione che si rende necessaria tra le applicazioni di position keeping i mercati e le procedure di back office.

L’integrazione verso i mercati richiede lo sviluppo di interfacce che restano in “ascolto” intercettando gli eseguiti ed alimentando il software di position keeping. Solitamente tale cattura deve essere realtime , perché in base alla posizione acquisita sui mercati vengono prese le decisioni operative.

L’integrazione verso i sistemi di back office può essere realtime o batch. In questo caso dal software di position keeping, vengono inviati i dati necessari per movimentare flussi di cassa.