Tag Archives: server

Vagrant and Ansible (part 1)

I am used to have a complete LAMP stack on my development machine, so that I can test my sites on a browser directly while writing code.

It’s probably an old-school way to develop, but it has worked well until recently.

Now I am working on two projects. One is a completely new project, but it needs to run on a Ubuntu 12.04 server but could be tested without problems on a more recent Linux config; the other is some legacy PHP4 code that runs fine on Ubuntu 12.04 with PHP 5.3 but it’s a mess to adapt to PHP 5.5.

I thus decided to give Vagrant a try and install an Ubuntu 12.04 image on Virtualbox. I found a Vagrantfile on the Internet and, allons-y!, everything works.

Then I thought: what would happen if I misconfigured the Vagrantfile, or the server config, or, worse, deleted the wrong file? Let’s study some devops tools!

Some months ago I read a book on Puppet and did some tests, but I found it quite complicated, and I heard Chef is similar. The new kid on the block is Ansible, and, from what I read on the Internet, it looked nice. Of course I tested it.

And then, keeping a terminal window open on the old VM’s Vagrant directory, it happened: a vagrant destroy in the wrong directory.

So I had to rush my Ansible study. :)

Continue reading

Pogoplug, altra delusione…

Continuo coi miei rant, spero di non sembrare troppo disfattista. Magari nei prossimi giorni parlo un po’ del Galaxy S2, di cui invece sono soddisfattissimo. :)

Circa un anno fa l’agenzia dove lavoro ha comprato un Pogoplug Business. L’esigenza principale era di avere un “file server” semplice da usare, con interfaccia sia web (da dare ai clienti) che “locale” (per montare le condivisioni sui PC della LAN). Era essenziale la multiutenza, in modo da dare, per esempio, una cartella ad ogni utente locale, e una ad ogni cliente, dove potesse caricare i file da mandarci e scaricare quelli preparati da noi.

Per questo siamo andati sulla versione Business, la più costosa, pubblicizzata proprio con queste caratteristiche.

Come funziona

Spiego brevemente come funziona il Pogoplug.

Continue reading

Rsync via SSH

Come sincronizzare dati tra due computer senza installare servizi sul server.

SSH continua a stupirmi ogni giorno. Sapevo che permetteva di trasferire file, tramite protocollo SFTP, come se si trattasse si un FTP (e con Nautilus si possono vedere i server remoti come fossero cartelle locali). Sapevo che ci si potesse forwardare X attraverso, anche se non ho ancora mai provato. Sapevo che ci si potevano fare tunnel generici. Ieri ho scoperto che lo si può usare come proxy SOCKS verso un proprio server, in modo da navigare “protetti” anche da reti pubbliche.

Oggi ho scoperto che lo si può usare direttamente da rsync senza bisogno di configurare nulla sul server. A patto di avere rsync installato sul server, naturalmente, ma non è necessario configurarlo in modalità daemon, né definire le “share” da esportare o le protezioni da attuare. Una porta aperta in meno! Vediamo come fare… Continue reading

Ottimizzare Linux (3)

Accorcio il titolo dei post, perché ormai non si tratta più solo di portatili e server, ma rientrano anche i client. L’argomento di oggi infatti è totalmente trasversale e riguarda tutti gli usi possibili.

Per motivi di efficienza nell’allocazione delle risorse, ogni (buon) programma su Linux si appoggia a una serie più o meno lunga di librerie condivise, le cosiddette Shared Objects, riconoscibili per l’estensione .so

Queste librerie sono gestite in modo da averne in memoria una sola copia in ogni momento, e tutti i software che hanno bisogno delle funzioni fornite leggono dalla stessa copia in memoria. In questo modo si risparmia RAM e tempo di caricamento da disco, in quanto la libreria viene letta da disco una volta sola e poi viene collegata (link) agli eseguibili che ne fanno richiesta.

Ma c’è un problema: ogni programma ha una sua area di memoria isolata dagli altri programmi, e il kernel deve mappare all’interno di ognuna di queste aree le diverse librerie, e ricalcolare tutti gli offset delle funzioni all’interno del binario che le richiama. Questa operazione ha il vantaggio di slegare completamente il binario dalle librerie (possiamo avere due versioni della stessa libreria in memoria con due software diversi che le usano, e caricarli quando vogliamo), ma ha lo svantaggio che, al caricamento del programma, tutte queste mappature devono essere ricalcolate.

Ma c’è, naturalmente, un modo per rendere più efficiente questa operazione.

Continue reading

Ottimizzare Linux per dispositivi mobili e server (2)

Da un po’ sto raccogliendo informazioni per la seconda parte di questo articolo, cercando di estrapolare solo suggerimenti non troppo complicati da applicare.

Durante questa ricerca sono incappato in due documenti che raccolgono una messe di informazioni su come configurare varie componenti in diversi modi.

Non sono sempre “digita e dimentica”, anzi, a volte richiedono un’analisi preventiva dell’hardware presente, e un tuning dei parametri per funzionare al meglio, ma sono una bella lista abbastanza completa. Alcune cose le ho già scritte nella prima parte di questo articolo.

Ma ecco i link: Velocizzare Debian e Recuperare spazio sull’HD.

I consigli sono diretti a utenti Debian, ma la maggior parte sono validi per qualsiasi distribuzione.

Non tutti sono da applicare ad occhi chiusi, ma richiedono una minima conoscenza del (sotto-)sistema che si sta configurando. Magari in futuro ne estrapolerò qualcuno e lo approfondirò qui. Nel frattempo ne approfitto per ringraziare il progetto Linguistico per queste e per le altre guide che hanno pubblicato, oltre che per i dizionari e i thesaurus in italiano, naturalmente.

qMail nel Pubblico Dominio

Il destino di un server SMTP.

La notizia è passata un po’ in sordina, annunciata solo da pochi siti come LWN, ma Bernstein ha (finalmente) rilasciato qMail come public domain. La definizione di public domain non (mi) è mai stata chiarissima, ma qui credo che intenda rilasciare i sorgenti con la formula “fate quello che volete”.

In passato qMail è stato penalizzato, dal punto di vista della diffusione, dalla posizione troppo chiusa del suo autore. La Debian non l’ha potuto inserire nella sua distribuzione, se non in forma di sorgente da compilare prima di poter essere usato. L’ultima versione ufficiale è la 1.03 da diversi anni, e non è mai stata aggiornata. Era impossibile redistribuire il sorgente modificato, ma le patch potevano essere applicate solo in seguito, da ogni sistemista che lo installasse. Erano nati progetti di raccolte di sole patch da applicare prima della compilazione.

Questa politica di chiusura ha fatto storcere il naso a molti, determinando spesso il passaggio ad altri server SMTP, come postfix ed exim. Dal punto di vista della sicurezza qMail è sempre stato apprezzato, ma la mancanza di molte funzioni e la complicazione necessaria per l’installazione, unite anche all’adozione di politiche di posizionamento dei file diverse da quelle ormai standardizzate su Linux, ha portato molti, me compreso, ad abbandonarlo.

Questa mossa, forse giunta troppo tardi, potrebbe invertire la tendenza, e riportare alcuni a tornare a qMail. Ma prima sarà necessario un po’ di lavoro per integrare le patch necessarie a portarlo al passo coi tempi cercando di mantenerne la sicurezza, e magari riuscire a conformarlo al FHS. Il rischio è che si creino decine di fork del codice che frammentano la comunità più di quanto lo sia adesso. L’ideale sarebbe che un gruppo di programmatori ne adottasse il codice e iniziasse a lavorare in modo coordinato per svilupparlo.

Immagino che uno dei primi passi verrà effettuato dalle distribuzioni, con l’integrazione delle patch già usate nel pacchetto sorgente, per creare finalmente un binario installabile direttamente.