Oggi è risaputa l’utilità di poter accedere ai propri dati/files/cartelle in remoto, avvalendosi di sistemi di archiviazione dei dati come il Cloud.
Il Cloud, termine inglese che vuol dire nuvola, non è altro che uno spazio di archiviazione virtuale di file accessibile ovunque utilizzando semplicemente una connessione internet.
Le informazioni sono stoccate su un server remoto, a cui l’utente accede grazie ad una password.
In particolare, il web definisce Cloud computing, una serie di tecnologie che permettono di elaborare, archiviare e memorizzare dati grazie all’utilizzo di risorse hardware e software distribuite nella rete.
Il Cloud non deve necessariamente essere associato ad un utilizzo strettamente professionale; può usare il cloud chiunque voglia tenere a portata di mano dati utili, come pin per operazioni bancarie, carta d’identità, fatture. Tutti possiamo usufruire di questo straordinario strumento.
Oramai gli smartphone hanno sostituito in gran parte i cellulari di vecchia generazione e stanno portando tutti gli utenti a conformarsi all’utilizzo di sistemi operativi come Android oppure iOS che funzionano grazie ad un account di posta elettronica. Questo vuol dire che tutti i possessori di uno smartphone possono utilizzare un servizio cloud, collegato all’e-mail, ed abbandonare chiavette USB o altri dispositivi a favore di un sistema che viaggia insieme a noi.
Il Cloud oltre a consentire una gestione sicura dei documenti, consente l’indicizzazione di ogni contenuto (es. pdf, word; excel etc) rendendo facile e rapida la ricerca delle informazioni. E’ ovvia l’utilità di tale funzione, in quanto consente un ottimizzazione in termini di tempo soprattutto quando si è in una situazione di pressione o di tempi ristretti.
Per quanto riguarda i costi, ovviamente vale la regola che un cloud gratuito è meno performante e limitato rispetto ad un cloud in abbonamento, sia in termini di spazio disponibile per l’archiviazione che di servizi e funzioni aggiuntive.
Per far fronte a tali esigenze, BETA Technologies ha sviluppato dei servizi di datacenter altamente specializzati e su misura per le aziende: BETA Cloud.
BETA Cloud offre tutto quello che attualmente non è possibile trovare in altri servizi cloud:
assistenza sistemica
collaborazione con il competente tecnico di fiducia
configurazioni su misura per tutte le esigenze.
Il backup su BETA Cloud offre alle aziende un servizio funzionale ed utile per evitare il rischio di perdere i dati della propria azienda, grazie alla protezione dei dati in locale e nel cloud, alla crittografia dei dati durante il transito su internet e all’assistenza di sistemisti preparati.
Per approfondimenti e per contattarci clicca qui:
http://www.betatechnologies.com/it/cloud
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.
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.
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.
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.
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;
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.
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.
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.
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.
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.
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!
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).