Ammetto di non essere riuscito a capire il perché, ma mi dava così tanto fastidio che ho iniziato a buttare l’occhio su MariaDB, che per qualche assurdo motivo ho sempre snobbato.
A discapito di quel che dice il sito, però, MariaDB non è un drop-in replacement per MySQL 5.7. Chiariamo meglio: alcune tabelle interne, quelle degli utenti per capirci, non sono compatibili. Il resto si.
Per sostituire MySQL con MariaDB, sarà sufficiente dunque fare un full dump, e poi aggiustare la tabella degli utenti (mancano giusto un paio di colonne) oppure riaggiungere gli utenti a mano.
Se non lo fate, il server si rifiuterà di avviarsi. Esatto, proprio non ne vuole sapere.

Sembrerà incredibile che, considerato che stiamo parlando di un software che può sostituire MySQL e che quindi ha la stessa interfaccia, l’utilizzo di memoria sia così differente. Eppure è proprio vero: al momento sta “vivendo” in meno del 9% di memoria.

Provare per credere.

• Decriptare l’hard disk che si vuole lasciare in pace
• Tenere l’hard disk offline, per poi metterlo online solo quando serve

Nel mio caso non era possibile seguire la prima via e, siccome non avevo per niente voglia di montare e smontare a mano ogni volta, ho reso tutto automatico nella maniera che sto per spiegarvi.

Montare automaticamente gli hard disk in caso di backup e smontarli quando finito

Windows Server sfrutta l’utilità di pianificazione per avviare i backup programmati; il lavoro si trova sotto

• Libreria
  • Microsoft
    • Windows
      • Backup

Ed è possibile aggiungere delle azioni a piacimento, in quanto modificabile. Creiamo due file txt con dentro i comandi per diskpart:

select disk 1
online disk

e

select disk 1
offline disk

E salviamoli dove ci pare.
Ora all’attività dobbiamo aggiungere 3 azioni, una di montaggio, attesa del completamento del backup, e una di smontaggio. Avremo quindi 4 avvii di programma in totale come questi:

diskpart.exe /s online.txt
wbadmin.exe start backup
wbadmin.exe get status
diskpart.exe /s offline.txt

Montare gli hard disk all’accesso e smontarli alla disconnessione

Per il montaggio automatico, creiamo una nuova attività:

• Generale
  • Utilizza l’account seguente: Amministratore
  • Esegui indipendentemente dalla connessione degli utenti
  • Esegui con privilegi elevati
• Attivazione
  • All’accesso
  • Utente specifico: X
• Azioni
  • Avvio programma: diskpart.exe /s online.txt

Per lo smontaggio premetto che ho avuto una piccola difficoltà: la modalità di attivazione predefinita “Alla disconnessione alla sessione utente” non c’è stato verso di farla funzionare. I passaggi sono gli stessi di cui sopra, l’unica differenza è la modalità di attivazione, che ora vado a spiegarvi, e il cambio del txt con quello per l’offline.

Come metodo di attivazione scegliamo quindi “Al verificarsi di un evento”, “Personalizzato”, e dentro “XML” incolliamo questi dati:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and Task = 12545 and EventID = 4647]] and *[EventData[Data[@Name='TargetUserName'] and Data = 'NOMEUTENTE']]</Select>
  </Query>
</QueryList>

 
Confermate il tutto e, da ora, avrete la certezza che il vostro hard disk si avvierà solo quando necessario.

Personalmente poiché uso nginx con configurazioni complesse non ho lasciato che il loro client vi mettesse mani, ed ho optato per la verifica tramite webroot. Tale tipo di verifica aggiunge un file nella root del sito, che viene poi utilizzato per verificare che voi ne siate gli effettivi amministratori. Questo è un enorme passo avanti dalle altre CA, che spesso chiedono, oltre che alla verifica dei dati personali, l’invio di un codice di conferma al dominio da verificare, presso una casella di posta a loro scelta. E se io non volessi/potessi mettere su un server di posta?

Decisa la modalità, attuarla è piuttosto semplice:

letsencrypt-auto certonly –webroot -w /var/www/sites/letsencrypt.dreamcode -d letsencrypt.dreamcode.it

Dopo alcuni semplici passaggi troveremo certificato e chiave privata in /etc/letsencrypt/live, pronti per essere utilizzati e già validi.

Il problema principale è che non forniscono certificati validi oltre i 3 mesi, e questo potrebbe creare dei problemi agli admin più pigri, me compreso. Personalmente preferirei che tale validità fosse estesa almeno all’anno o due, tanto coi sistemi OCSP odierni non c’è più pericolo che certificati revocati vengano utilizzati ugualmente.

Il sito indicato qui sopra esiste davvero ed è attivo, raggiungibile qui in caso foste curiosi. Qui invece potete trovare un report completo di SSL Labs, giusto per.

E voi, siete da A+?

Non mi dilungherò più di tanto perché nel link qui sopra troverete tutte le informazioni dettagliate per farlo funzionare. In caso voi stiate su ubuntu, verificate di avere i pacchetti necessari:

sudo apt-get install perl libswitch-perl libdbi-perl

Ho anche modificato leggermente lo script per fare scaricare la cache ogni 5 minuti invece che 30 secondi:

if ($cnt % 6 == 0) → if ($cnt % 60 == 0)

Unica cosa, vi consiglio di non utilizzare l’account di postfix ma un altro a vostra scelta, o nuovo. Meglio separare le cose.

Nella fattispecie, bisogna farli agire in quest’ordine: amavis, signing-milter e infine opendkim. Lasciare opendkim per ultimo è importante perché bisogna assicurarsi che l’email non venga più toccata dopo la firma.
Iniziamo col procurarci un certificato dedicato alla firma delle email. StartSSL e Comodo li offrono gratuitamente. Consiglio Comodo perché i certificati possono essere revocati gratuitamente, mentre StartSSL si fa pagare 25$. signing-milter richiede che certificato e chiave privata siano in formato pem senza password. Per convertirli usiamo openssl:

openssl pkcs12 -export -in email.crt -inkey email.key -out email.pem -nodes

Ora signing-milter, per associare i certificati alle email, utilizza un database statico in formato CDB. Immaginiamo di dover associare mia@email.com al certificato /etc/signing-milter/email.pem. Per fare ciò, creiamo un file vuoto, ad esempio db.txt, e poniamo come prima riga:

+13,29:mia@email.com->/etc/signing-milter/email.pem

Creiamo ora il database:

cdb -c signingtable.cdb db.txt

Ricordo che ogni processo che gestisce dati sensibili dovrebbe utilizzare un utente diverso. Creiamone uno per signing-milter e associamo ad esso i file:

adduser –system –no-create-home –group signingmilter

chown -R signingmilter:signingmilter /etc/signing-milter

chmod 500 /etc/signing-milter

chmod 400 /etc/signing-milter/*

Scaricate i sorgenti di signing-milter, compilateli e mettete il binario in /usr/sbin. Create uno script init.d per avviare il daemon all’avvio con questi parametri:

-g signingmilter -s inet:9991 -t 60 -u signingmilter -m /etc/signing-milter/signingtable.cdb

Questo creerà un milter sulla porta 9991. Se non usate amavis, aggiungete queste righe al main.cf:

smtpd_milters=inet:localhost:9991

non_smtpd_milters=inet:localhost:9991

Se usate amavis, invece, fate queste modifiche:

• togliete smtpd_milters e non_smtpd_milters dal main.cf
• togliete no_milters dalla config di amavis nel master.cf
• abilitate i milters nel master.cf aggiungendo sotto la riga da cui avete tolto no_milters:
  

  -o smtpd_milters=inet:localhost:9991

  -o non_smtpd_milters=inet:localhost:9991

Riavviate postfix e provate ad inviare una email. Tutto apposto?

Quando apprendi qualcosa, volente o nolente, questa influenza inevitabilmente ciò che crei o hai creato. Te la fa guardare con occhi diversi, ed è quando trovi qualcosa di migliore che ciò che avevi creato e che consideravi buono inzia di colpo a fare schifo. Uno di questi esempi è HttpSMS, un client web-sms per Android, creato un po’ di tempo fa da me quasi per noia. Mi sono reso conto che forse un po’ di CSS qua e la poteva non essere una cattiva idea, perché anche l’occhio vuole la sua parte; così come un po’ di JS qui e un po’ la avrebbe reso tutto migliore, non costringendo l’utente a ricaricare la pagina e così via. Ed ecco lo schifo che arriva. L’HTML puro sa di vecchio, ormai. Siamo nel 2015 e che cazzo.

Lo stesso è accaduto quando ho iniziato ad approcciarmi al mondo dell’hosting. Son partito con 1and1, un managed hosting molto diffuso, che nonostante il prezzo contenuto offre discrete possibilità. Spazio illimitato, account email, mysql e così via sembrano tutto ciò che si può desiderare; eppure…

Eppure no.

Man mano che il tempo passava iniziavano a saltar fuori le magagne, ovviamente non risolvibili perché si sa, se sei managed sei nelle loro mani, che un po’ come quelle del “signore” si muovono molto lentamente o non si muovono affatto. Tra queste troviamo:

• La app per Android di WordPress manda in pappa il server e bisogna aspettare qualche minuto che si riprenda (?!?)
• Banditi i certificati ssl custom. Con StartSSL che li regala, devo pagarli 50€ l’anno + iva l’uno… CERTO!
• Server tutt’altro che scattante
• Se avete qualche problema è colpa vostra e non faranno un beneamato cazzo se non mandarvi email in cui vi chiedono se sei soddisfatto dell’assistenza
• Il filtro spam è fin troppo aggressivo
• I cambiamenti alle impostazioni richiedono tempi che vanno dai 5 minuti alle 6 ore
• Le porte in uscita sono chiuse, 80 e 443 a parte. Se vuoi inviare una mail in php via smtp puoi anche scordartelo

Ovviamente ci sono anche molti pregi, non fraintendete, ma lo scopo di questo post è spiegare perché li ho lasciati. Il fatto che ti mantengono il dominio, che comunque è managed (se sei inesperto è un pregio), che per essere shared ha prestazioni costanti eccetera sono tutti buoni motivi per sceglierli se il prezzo e la semplicità sono d’obbligo.

Lasciare 1and1 significava rivolgersi al mondo unmanaged, il che a sua volta significava imparare a fare qualcosa che è tutt’altro che semplice, sia perché linux sa essere un gran bastardo, sia perché a meno che non vuoi vederti bucato 10 minuti dopo aver messo tutto online, è buona norma prendere delle precauzioni.

Per avvicinarmi a questo mondo ho ben deciso di installare il necessario sul mio Desktop ormai in disuso da un bel po’ (spoiler: non lo è più!). Il problema è che seppur avendo una linea stabile e costante, come la maggior parte delle linee domestiche è asincrona, con solamente 512k di upload: decisamente troppo poco per soddisfare la grande esigenza di un webserver.

Dopo un po’ inizio a stufarmi ma ecco che ci viene in aiuto CloudFlare. Cos’è? CloudFlare è una azienda che tra i servizi più rinomati offre gestione DNS, SSL (parziale o totale) e Caching di uno o più siti web, gratis. Bene mi dico, hanno tutto ciò che serve. Il Caching poi è disponibile sia per le pagine statiche che dinamiche. Avviene nei loro server sparsi per il mondo ed è veloce. O almeno dovrebbe.

La verità è che fin quando non ho attivato CF, i miei siti di test non hanno mai avuto problemi di funzionamento. Dopo qualche giorno con CF invece ho iniziato ad avere strani problemi di connessione, con la loro pagina di errore che mi informava che l’host era offline. Problema: non era vero. La loro assistenza ovviamente ha detto che era colpa del mio server, un i7 sgombro e dedicato, ma che soprattutto senza CF in mezzo funzionava perfettamente.

Bene mi son detto, qui è ora di cambiare. La loro gestione DNS è eccellente, tra le più veloci che io abbia mai visto, ma il proxy è a dir poco mediocre e non supporta protocolli diversi dall’HTTP. Investigando infine ho scoperto un’altra cosa poco carina: a dispetto delle vostre impostazioni se un file non viene richiesto per qualche ora viene cancellato dalla cache, vanificando completamente gli effetti per i siti poco frequentati.

Le aziende alternative poi sono poco interessanti per i prezzi decisamente esagerati (Incapsula: 60$/mese per sito…) o per la mancanza di funzioni che ritengo indispensabili.

La mia soluzione? Una VPS! Sembra scontato ma non lo è. Nginx permette di creare un reverse proxy con supporto SSL e cache locale pienamente configurabile come vi pare e supporta cose tipo il WAF (mod_security) che su wordpress son quasi d’obbligo. Postfix (archivio temporaneo e smistamento posta) e haproxy poi completano l’opera.

Indovinate un po’? I rallentamenti sono spariti.