Uno dei problemi, o se vogliamo degli aspetti riguardanti l'open source è sicuramente la mancanza di documentazione approfondita ed esempi che coprano tutti i casi d'uso.

Questo può essere un problema per chi di solito lavora in fretta e non ha tempo di studiare per avere poi una visione approfondita che gli consenta di comprendere profondamente tutti gli aspetti del funzionamento di una libreria.

Operazioni di sviluppo software che potrebbero richiedere mezz'ora alla fine riescono così poi ad assorbire lo sviluppatore per una giornata intera.

Un esempio è sicuramente la difficoltà di lavoro con certificati SSL autofirmati con JAVA.

La documentazione ufficiale tende ad essere di parte e a nascondere alcuni semplici meccanismi che contentirebbero di lavorare con poche righe di codice, proprio nel caso in cui uno sviluppatore si trovi a dover supportare certificati SSL autofirmati, che sono più comuni ed utili di quanto la SUN voglia farci credere.

Quando uno sviluppatore chiede in un forum di supporto o in una discussione come poter lavorare con certificati SSL autofirmati si trovano in rete le risposte più disparate, che sicuramente aiutano a risolvere il problema, ma sono tutte strade non utili a lavorare solo da codice (per esempio l'acquisizione del certificato nel sistema) e che richiedono una configurazione ad hoc per ogni utente.

Ovviamente la cosa è di difficile digestione per uno sviluppatore.

Introduzione al problema della deduplicazione

La domanda che più affligge gli utilizzatori di ZFS è sicuramente questa. Deduplicare i dati o no? La risposta può arrivare solo dopo un'attenta valutazione richi/benefici.

Sin dal momento delll'introduzione della feature di deduplicazione in ZFS, gli amministratori di sistema si sono divisi in tra i dediti alla deduplicazione e tra gli scettici. Certo, la deduplicazione consente di risparmiare notevoli quantità di spazio, anche se la deduplicazione ha un costo elevato, che non può essere ignorato e non sempre è l'opzione migliore.

Da quello che si legge nelle offerte commericali di NAS dotati di ZFS, viene dichiarato un risparmio di spazio di circa 10 volte. E' vero? Dipende da come si utilizza. Si può arrivare anche a proporzioni molto più alte. Facendo una media direi più che si risparmia lo spazio 5 volte, attivando sia deduplicazione che compressione.

Vediamo un po' più in profondità i vantaggi della deduplicazione ZFS e il relativo costo perché alla fine tutto si riduce ad effettuare un'analisi costi/benefici della deduplicazione ZFS.

Deduplicazione ZFS: quale valore ottieni?

Il gestore ZFS scarterà ogni blocco di dati identico a un blocco già scritto, mantenendo un riferimento in modo che possa riprodurre sempre lo stesso blocco quando viene letto.

Prima di decidere di utilizzare la deduplicazione, è bene sapere quale valore si otterrà. Ecco alcune cose da fare pima, per capire quanto spazio si riesce a recuperare a seguito dell'utilizzo della deduplicazione ZFS:

  • Prova con alcuni dati reali. Questa è l'opzione più precisa e semplice: configurare un pool di test, attivare la deduplicazione ZFS, quindi copiare una quantità rappresentativa dei dati che stai valutando su di esso. Quindi utilizzare l'elenco zpool e guardare la colonna DEDUP per il rapporto di deduplicazione. La cosa importante è utilizzare un numero rappresentativo di dati, in modo da ottenere una stima accurata di quanti risparmi potremo aspettarci.
  • Simulare applicando il comando zdb -S a uno zpool esistente con i dati da deduplicare. Questa opzione è meno accurata dell'utilizzo di dati reali con una vera e propria serie deduzione, ma può fornire una stima di riuscita basata sui dati esistenti.
  • Stima tu stesso, in base alla conoscenza che hai dei tuoi dati. Non è l'opzione migliore, ma a volte, la creazione di un pool di test non è fattibile e la simulazione dei calcoli sui dati esistenti non funziona perché semplicemente non disponete di dati da analizzare. Ad esempio, se si prevede di eseguire un server di archiviazione per le macchine virtuali: quante macchine supportate? Quante volte sono patchate? Quanto è probabile che le persone applichino gli stessi software / patch / dati alle vostre macchine? Quanti sono i GB di dati deducibili che verranno generati?

In ogni caso, finirete ad avere un rapporto di deduplicazione previsto per i dati: per ogni GB di dati che effettivamente memorizzi, quanti GB di spazio libero otterrai? Questo numero può avere un valore: alcune persone assegnano arbitrariamente un valore di 1,00 (nessun duplicato), altri ipotizzano risparmi moderati come 1,5 (ogni 2 GB, uno libero) e alcuni sistemisti fortunati possono arrivare ad ottenere fino a 20 volte, per esempio su un server di archiviazione per virtualizzazione con profili di utilizzo molto ripetitivi.

Ora prendi la tua quantità totale di archiviazione e dividila per il rapporto di deduplicazione, e sottrai il risultato dalla quantità totale di spazio. Questo è il risparmio di conservazione previsto a seguito della deduplicazione.

Ci sono diversi modi per configurare la replica dei database con MySQL. Il più utilizzato è la configurazione master-slave, anche se da diverso tempo è possibile utilizzare MySQL Fabric (su cui scriverò un articolo più avanti).

 

Il processo di replica consente di avere copie multiple dei dati di MySQL sincronizzando automaticamente dal server master al server slave. Questo consente di avere un server di database di backup che in caso di guasti può diventare il master, oppure semplicemente può essere utlilizzato per ripristinare i database all'ultima transaction disponibile. In pratica ogni transazione SQL viene eseguita sul master e sugli slave in modod tale da avere sempre due server completamente allineati. I server possono avere configurazioni diverse, quello che conta è che i database vengano replicati attraverso un utente dedicato. I software possono poi accedere ai dati in lettura su tutti i server del poll e in scrittura solo sul master. Per questo consiglio comunque di valutare attentamente se sia il caso di impiegare la replica o un cluster di mysql fabric.

 

Configurare l'instanza master di MySQL

Per configurare l'istanza master bisogna modificare il file di configurazione di MySQL, generalmente /etc/mysql/my.cnf

Aprite il file di configurazione my.cnf, e trovate queste righe, modificandole così:

bind-address = 0.0.0.0  
server-id = 1  
log-bin = /var/log/mysql/mysql-bin  
binlog-ignore-db = “mysql”  

Dovete decommentare le righe server-id e log-bin, aggiungere la riga inlog-ignore-db = “mysql” al file di configurazione di default. Potreste anche lavorare su un nuovo file che poi dovreste linkare alla configurazione del demone MySQL, oppure potreste anche creare un nuovo demone MySQL con una nuova configurazione. Per esempio potreste creare un demone di test che viene poi bindato ad una porta non ancora utilizzata, lasciando intaccato il MySQL originale, solo per scopi di test.

Note:

  • bind-address configura l'idirizzo dell'interfaccia che deve essere bindata al demone. Di default è configurato su 127.0.0.0 per consentire connessioni client solo da localhost. Se il vostro demone di replica si troverà su una VLAN dedicata, allora configurate solo l'IP dedicato alla replica.

  • server-id è un integer che viene assegnato ad ogni server MySQL. Ogni server deve avere un id univoco. Viene normalmente assegnato in sequenza.

  • log-bin attiva e configura la directory per il bin-log.

  • binlog-ignore-db fondamentale parametro che consente di NON replicare il database di sistema, che deve chiaramente essere diverso.


Configurare l'utenza di replica sul server master

Accedete al server MySQL e create l'utenza dedicata alla replica:

mysql> grant replication slave on *.* TO 'replica-user'@'<SLAVE>' identified by '<some_password>';  
mysql> flush privileges;  
mysql> quit  

Questo creerà l'utente replica-user, assegnandogli i diritti di replica. Questo utente esisterà solo sul server master, perché i database mysql, che contengono le configurazioni del server mysql, sono differenti e rimarranno indipendenti tra di loro.

Per verificare se l'utente è configurato correttamente, provate ad effettuare l'accesso dal server slave verso il master, impersonando l'utente replica-user:

mysql -h<MASTER> -ureplication -p  

Se tutto è stato configurato correttamente, avrete accesso al server MySQL.


Ottenere le coordinate del replication master binary log

Per configurare la replica sullo slave, dovrete ottenere la posizione attuale sul binary log. Si tratta dell'id dell'ultima SQL transaction.

Effettuate il log sul server MySQL master ed eseguite questa query:

mysql> FLUSH TABLES WITH READ LOCK;  
mysql > SHOW MASTER STATUS;  
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |     1234 |              | mysql            |
+------------------+----------+--------------+------------------+

La posizione in questo output di esempio è 1234.


Configurate l'istanza slave.

Come con l'istanza master, dobbiamo configurare il file di MySQL con l'id del server, in /etc/mysql/my.cnf.

Anche in questo consiglio di utilizzare una VLAN dedicata e un indirizzo raggiungibile solo all'interno di una subnet dedicata alla replica MySQL.

bind-address = 0.0.0.0  
server-id = 2  

Ora, configuriamo i dettagli del master sulla shell MySQL del server slave (dopo aver riavviato il demone ovviamente).

mysql>stop slave;  
mysql>CHANGE MASTER TO MASTER_HOST='<MASTER>', MASTER_USER='replica-user', MASTER_PASSWORD='<replica-user password>', MASTER_LOG_FILE='mysql-bin.0000001', MASTER_LOG_POS=1234;  
mysql>start slave;  

Le prove

Se tutto è andato a buon fine, la vostra istanza slave sta già replicando i dati dal server master.

Per verificare, effettuate l'accesso al MySQL sul server slave ed eseguite questa query : show slave status \G.

L'output somiglierà a questo:

mysql> show slave status \G  
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: mysqltest01
                  Master_User: replica-user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000002
          Read_Master_Log_Pos: 1515
               Relay_Log_File: mysqld-relay-bin.000002
                Relay_Log_Pos: 1661
        Relay_Master_Log_File: mysql-bin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 1515
              Relay_Log_Space: 1958
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No  
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1

 

Consiglio anche di effettuare delle query di scrittura sul master e verificare trmaite la lettura sullo slave.

Vedrete poi tutti i database ricrearsi e popolarsi sullo slave in breve tempo. Una volta terminato l'allineamento, la sincronizzazione sarà immediata.

In caso di perdita di connettività, quando questa sarà ripristinata la sincronizzazione riprenderà automaticamente.

Per attivare più slave ripetete semplicemente i passaggi riguardanti la configurazione del demone, utilizzando lo stesso utente di replica.

 

 

Più il tuo business cresce, più aumentano gli oneri relativi all'infrastruttura informatica e i rischi soprattutto per la sicurezza.

L'infrastruttura IT, essendo il cuore pulsante della tua azienda, dovrebbe essere gestita con un occhio di riguardo. Se dovesse fermarsi tutto, solo in quel momento capiresti la portata dell'errore fatto: sottovalutare l'importanza della tua infrastruttura IT.

 

Consiglio 1 – Forma il tuo staff e aumenta la protezione attraverso security policy

 

Il tuo staff deve sempre essere formato per accogliere correttamente i rischi riguardanti la sicurezza, soprattutto quando si tratta dei sistemi informatici della tua azienda. Nella quasi totalità dei casi, è a causa del tuo staff non formato che avrai problemi di sicurezza informatica. Per esempio, aprire un allegato o link sospetto in una email è la causa più frequente di infezione. Avete sicuramente sentito parlare di Cryptolocker e delle sue varianti, che prediligono questo metodo di infezione.

 

Consiglio 2 - Non risparmiare sull'infrastruttura informatica

Anche se comporta dei consistenti investimenti, potresti considerare di utilizzare degli ambienti protetti per far svolgere il lavoro ai tuoi dipendenti. Per esempio, una segretaria amministrativa può utilizzare strumenti cloud per lavorare, rendendo il pc solo un guscio vuoto, sul quale potresti installare una distribuzione linux ad hoc per gestire connessioni remote e browsers. Contatta solo aziende leader nella distribuzione di sistemi informatici, quando si tratta della tua azienda, non puoi affidarla a piccoli consulenti indipendenti e normalmente lavorano in situazioni meno complesse, per esempio gli utenti privati.

Assicurati che la tua rete sia progettata bene da sistemisti e che i dipartimenti siano adeguatamente separati. L'accesso ad internet deve essere effettuato attraverso un proxy per evitare che gli utenti utilizzino internet in modo non corretto.

 

Consiglio 3 – Usa software affidabile

Se sei costretto ad operare in ambito Windows, esistono soluzioni a pagamento molto ben fatte per proteggere la rete e i server. Assicurati di averne implementata una che non intacchi la velocità di lavoro del tuo staff. E' molto più importante progettare bene i sistemi che installare semplicemente un antivirus. Occorono sistemi di monitoraggio e prevenzione oltre che di disinfezione. Chi utilizza la posta elettronica deve farlo in un ambiente protetto dove anche con qualche errore umano (vedi consiglio 1) i rischi di sicurezza sono quasi azzerati.

 

Consiglio 4 - Utilizza password complesse

Di qualsiasi cosa si tratti: home banking, email, utenti di di active directory... ovunque ci sia una password, utilizza sempre tecniche di generazione di password sicure.

Assicurati che siamo presenti simboli, numeri, e caratteri maiuscoli e minuscoli nelle tue password. Non solo: i software devono implementare un sistema di lockout utente nel caso la password vengano inserire non corrette più volte. Questo blocca gli attacchi brute-force.

E se qualcuno accedesse alla tua posta elettronica? Cosa ci troverebbe? Sicuramente qualche password o qualche cosa che lo aiuterà ad ottenere altre informazioni e ad accedere così ad ulteriori informazioni.

Per questo non conservare mai le password dentro le email, ma stampale e collezionale in un raccoglitore da conservare in cassaforte.

 

Consiglio 5- Il piano di emergenza

Che cosa accadrebbe se perdessi tutti i dati e si bloccassero tutti i computer della tua azienda? Sappi che succede ogni giorno. E i giorni di fermo produzione pesano come macigni. Assicurati che ci sia un piano di emergenza per riprendere il lavoro anche in caso di disastro. In questo, i sistemi cloud sono di grande aiuto.

One of the things sometimes may be elusive while working with a group of younger and inexperienced programmers, is the team agreement on the correct encapsulation level to implement in the team project.

Encapsulation is one of the four fundamental OOP concepts. The other three are inheritance, polymorphism, and abstraction.

Encapsulation in Java is a mechanism of wrapping the data (variables) and code acting on the data (methods) together as a single unit. In encapsulation, the variables of a class will be hidden from other classes, and can be accessed only through the methods of their current class. Therefore, it is also known as data hiding.

To achieve encapsulation in Java you have to:

  • Declare the variables of a class as private.

  • Provide public setter and getter methods to modify and view the variables values.

 

This obviosly is the small project point of view. But what to do when you have to deal with lots of different projects that share a core, for example the Database Manager? Please make use of managers and APIs to make the project modular.

Always remember to draw down the correct encapsulation by project first. How did you managed this situations? Tell me your experiences!

Facendo seguito ad alcune richieste ricevute dai nostri utenti Zimbra, pubblichiamo alcune strategie antispam utilizzate sui nostri server.

Parametri postfix

RBLs

A livello postfix utilizziamo solo alcune RBLs molto conservative e alcune ad esse complementari, un controllo DNS e un controllo di protocollo. Questo perché ancora molti ISP utilizzano configurazioni con vecchie versioni di postfix e le configurazioni non vengono aggiornate da anni. E' ancora presto implementare tutti i controlli di protocollo e di DNS che teoricamente sono richiesti per eliminare quasi completamente lo SPAM.

Le RBLs che utilizziamo sono:

zen.spamhaus.org	psbl.surriel.com	b.barracudacentral.org

Ulteriori RBLs (complementari) sono:

bl.spamcop.net

 

Le RHSBLs Client che utilizziamo:

dbl.spamhaus.org	multi.uribl.com		multi.surbl.org

RHSBLs Client aggiuntive:

rhsbl.sorbs.net

Sender RHSBLs utilizzate:

multi.uribl.com 	multi.surbl.org		rhsbl.sorbs.net		dbl.spamhaus.org

Reverse Client RHSBLs utilizzate:

dbl.spamhaus.org

 

Controlli sui DNS e di protocollo:

reject_non_fqdn_sender

reject_unknown_sender_domain

 

Per consentire l'utilizzo di client di vecchia generazione come Outlook e Thunderbird non attiviamo l'append del X-Originating-IP (sarebbe impossibile inviare posta da quasi tutti gli ip dinamici e in blacklist).

ImpresaCloud

ImpresaCloud

Richiedi riparazione

5 facili step per la riparazione della tua pratica

Laboratorio di informatica e di elettronica

Cerchi informazioni sulle riparazioni in laboratorio? Hai qualche curiosità riguardo la riparazione di qualche scheda elettronica in particolare? Nella sezione Riparazioni del nostro Blog troverai moltissime informazioni utili e curiosità riguardanti il mondo dell'informatica e dell'elettronica.

 

Software gestionali

Nel nostro Blog troverai gratis tante informazioni utili riguardo i nostri software gestionali, guide passo-passo per l'utilizzo dei programmi, suggerimenti e aiuto.

 

Sistemistica informatica

Nel Blog Sistemistica troverai interessanti articoli scritti dal nostro team riguardanti il mondo di BSD, Linux, e dei Server Windows. Tutorial, best-practices, e tanto altro.

 

Notizie

Notizie interessanti riguardanti l'elettronica e l'informatica.