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…

Uso di base

Per un uso normale, con autenticazione tramite password, si può usare direttamente rsync, aggiungendo un solo parametro, oltre ai soliti utente, nome server, cartella remota e cartella locale:

 rsync -ravz -e ssh utenteremoto@serverremoto:/path/alla/dir/remota/ /path/alla/dir/locale/

Fatto. Non serve altro. Le opzioni che ho usato sono quelle classiche: a per mantenere i permessi, r per fare una copia ricorsiva, v per aumentare la “verbosità” dell’operazione, z per comprimere i file in transito (utile se si fanno backup di log non compressi o di file di testo). L’opzione -e è quella che ci interessa qui: specifica la shell remota da utilizzare per la copia. rsync richiamerà automaticamente il suo omologo sul server remoto e gestirà automaticamente le differenze tra i file. In questo caso specifichiamo ssh come shell remota.

Seguono il nome utente (sul server), il nome del server stesso (o il suo IP) e il path alla directory che vogliamo copiare, raggruppati. Quindi il path locale dove vogliamo copiare i file. Sarà sufficiente invertire questi due componenti (prima il locale e poi il remoto) per caricare i file sul server, invece di scaricarli. Rimangono validi tutti gli altri switch di rsync (cancellazione dei file, tipi di controllo per determinare l’aggiornamento, ecc.)

Naturalmente questo sistema ci chiederà la password dell’utente sul server remoto ogni volta che faremo la sincronizzazione, quindi è poco adatto ad essere usato, per esempio, con cron.

Autenticazione tramite chiavi pubblica e privata

Per questo ci viene in aiuto ssh. Possiamo generare una coppia di chiavi, una pubblica e una privata, da utilizzare per autenticarci sul server senza bisogno della password. Ecco il comando per generarla:

ssh-keygen -t dsa -b 1024 -f chiave-ssh

Questo comando crea una chiave DSA a 1024 bit e la memorizza in due file: la parte privata nel file “chiave-ssh”, e quella pubblica in “chiave-ssh.pub”.

La chiave privata va tenuta al sicuro, non deve essere vista da nessuno. Assicuratevi che abbia permessi 600 (rw——-) e come proprietario l’utente stesso. Copiatela in ~/.ssh (la cartella .ssh nella home dell’utente), e assicuratevi che la stessa cartella .ssh abbia permessi 700 (rwx——).

La chiave pubblica, invece, mandatela sul server in qualche modo. Io ho attivato SFTP, quindi mi basta un

scp chiave-ssh.pub utenteremoto@serverremoto:~/

Ora collegatevi al serverremoto, e aggiungete questa chiave al portachiavi, che si chiama authorized_keys e si trova, sorpresa sorpresa, nella directory .ssh

cat chiave-ssh.pub >>.ssh/authorized_keys

Poi potete cancellare il file con la chiave pubblica, tanto lo avete appena accodato al portachiavi (attenzione a non fare il redirect con un solo >, altrimenti cancellerete eventuali altre chiavi pubbliche conservate lì dentro).

Assicuratevi che anche questo file (authorized_keys) abbia permessi 600.

Abbiamo concluso la fase preparatoria, ora potrete usare la chiave pubblica sia per loggarvi su quel server via ssh, sia per fare SFTP, sia con rsync. Per esempio, per collegarvi:

ssh -i .ssh/chiave-ssh utenteremoto@serverremoto

Mentre per usare rsync dovrete ricordare di racchiudere la linea di comando di ssh tra virgolette:

rsync -e "ssh -i .ssh/chiave-ssh" utenteremoto@serverremoto:/dir/da/copiare /dir/locale/

Una piccola dritta

Il sistema descritto sopra è ottimo per tenere le chiavi separate tra diversi server. In pratica potete avere una coppia di chiavi (pubblica e privata) per ogni server al quale dovete collegarvi.

Ma potete anche semplificare il processo e usare la stessa coppia di chiavi per tutti i server. In questo caso generate le chiavi e memorizzate la parte pubblica su tutti i server come ho scritto sopra. In locale, invece, copiate la chiave privata nella directory .ssh ma chiamatela “id_dsa” (per le chiavi DSA) o “id_rsa” (per le chiavi RSA):

cp chiave-ssh .ssh/id_dsa

Assicuratevi sempre che abbia permessi 600.

Così facendo non sarà più necessario specificare la parte “-i nomechiaveprivata”, perché ssh se la andrà a cercare direttamente.

Possibili problemi

Ricordate che se perdete la chiave privata dovrete entrare col solito sistema a password, ma se qualcuno ve la ruba potrà entrare su tutti i server che la utilizzano senza bisogno di altre autorizzazioni! In questo caso conviene fare immediatamente il giro di tutti i server e rimuovere la chiave pubblica dal file authorized_keys, e quindi rigenerare una nuova coppia di chiavi (sono sempre diverse).

Se il login automatico non funziona, verificate sul server che non siano disabilitati i login con chiave pubblica (di solito nel file /etc/ssh/sshd_config):

RSAAuthentication     yes
PubkeyAuthentication  yes
AuthorizedKeysFile    .ssh/authorized_keys

Consiglio di usare l’autenticazione DSA, e possibilmente di disabilitare il protocollo SSH1 e lasciare attivo solo SSH2, molto più sicuro.

Se ancora non funziona niente, aumentate il logging di ssh sul server tramite il parametro LogLevel (potete impostarlo a DEBUG per avere molto output, o a DEBUG3 per averne anche troppo).

© Alex for /dev/random, 2008. | Permalink | 3 comments | Add to del.icio.us
Post tags: backup, Linux, reti, server, sicurezza

Feed enhanced by Better Feed from Ozh

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.

Prelink

Ed è qui che ci viene in aiuto prelink. Questo software, infatti, analizza tutti i programmi e tutte le librerie che abbiamo installato, e precalcola una volta per tutte degli spazi in memoria dove andranno allocate, quindi modifica i binari stessi per “suggerire” tale allocazione. Può anche spingersi ad analizzare le librerie che non vengono mai usate contemporaneamente e sovrapporre le loro aree di memoria, in modo da ottimizzarne la gestione.

Ma allora perché non lo usano tutti, chiederete voi! Il motivo principale è che ogni volta che si aggiorna qualcosa questo prelinking viene perso, quindi le prestazioni decadono, anche se lentamente. Un altro motivo è che alcuni vecchi software non lo supportano molto bene e rischiano di smettere di funzionare. Per esperienza personale non ne ho ancora incontrato uno, a dire il vero. In ogni caso prelink permette anche l’undo, quindi di ripristinare i binari come erano in origine.

Ma se avete una macchina che non aggiornate troppo spesso (un server, un palmare, ma anche un client, a meno che non usiate Debian sid o non aggiorniate la Debian testing 2-3 volte al giorno), o se siete disposti ad aspettare qualche minuto in più alla fine di ogni aggiornamento, il gioco vale decisamente la candela.

Come usarlo

Se avete una Debian (e, presumo, anche una Ubuntu o altre derivate da Debian), l’installazione e la configurazione sono banali:

aptitude update
aptitude install prelink

vi installerà il pacchetto assieme agli script cron necessari. Controllate il file /etc/default/prelink e, se necessario, modificate la linea che inizia con PRELINKING:

PRELINKING=yes

Nello stesso file ci sono altre opzioni impostabili. Lasciate così com’è la seguente:

PRELINK_OPTS=-mR

mentre, se aggiornate spesso, può essere utile modificare l’intervallo in giorni a cui avviene un “full prelink”:

PRELINK_FULL_TIME_INTERVAL=5

Questo specifica ogni quanti giorni il cronjob farà uno scan completo del sistema per ricalcolare i prelink. In questo caso l’abbiamo impostato a 5 giorni. Potete metterlo a 14 o a 30 se aggiornate molto poco (un server, per esempio), oppure a 1 o 2 se aggiornate ogni giorno.

C’è un ultimo parametro in questo file:

 PRELINK_NONRPM_CHECK_INTERVAL=7

Questo serve a specificare che se non ci sono stati cambiamenti di pacchetti (installazioni o disinstallazioni) negli ultimi 7 giorni, non viene comunque forzato un full prelink, e viene eseguito un prelink incrementale. Funziona analizzando il file di stato della distribuzione, quindi non lasciatevi ingannare da quell’RPM: funziona anche coi deb (se usate il pacchetto deb di prelink, naturalmente).

La configurazione è finita. Tranne la prima riga, che di solito è undefined o no di default, le altre potete anche lasciarle come sono. Non era difficile, no?

Avvio del prelink

Ora potete aspettare che cron faccia il suo lavoro (verso le 6 di mattina per il default Debian), o che lo faccia anacron (se spegnete la macchina ogni sera e, naturalmente, avete installato anacron).Oppure potete lanciare l’operazione manualmente richiamando, da utente root, direttamente il cronjob:

/etc/cron.daily/prelink

Undo

Se volete tornare alla situazione di partenza, togliendo tutti i prelink, il comando da dare, sempre da root, è:

prelink -au

Disclaimer

Come ho detto all’inizio, io finora non ho avuto alcun tipo di problema da prelink, e lo uso su una lenny (e prima su una etch, quando era testing) da oltre due anni. Ma, come dicono i ‘mmericani, your mileage may vary: potreste avere qualcosa che non va con prelink, o potrebbe saltarvi la corrente mentre scrive libc.so e impastarvi il sistema (compratevi un UPS!). A vostro rischio e pericolo. Ma la differenza sui tempi di caricamento si vede a occhio nudo, soprattutto su pacchetti grossi come OpenOffice o simili.

 Altre opzioni

La manpage di prelink elenca molte opzioni possibili. Per un uso normale non servono, ma se volete addentrarvi nei meandri del funzionamento del link su Linux, man prelink è vostro amico. L’unica opzione su cui voglio richiamare l’attenzione è -R, che comunque viene impostata di default in Debian, e serve a rendere casuale l’indirizzo di allocazione di ogni libreria. Questo serve ad evitare che un attaccante (un cracker) che abbia un sistema come il vostro possa prevedere a quale locazione di memoria viene installata una certa libreria, rendendogli più facile l’attacco.

In /etc/prelink.conf la Debian preimposta già quali directory controllare e quali tipi di file ignorare durante il prelink. Si può personalizzare questo file nel caso si installino binari in luoghi fuori dalla gestione della distribuzione (per esempio in /usr/local o in /home). La sintassi è molto semplice, se avete letto e capito il man, altrimenti evitate di metterci mano.

© Alex for /dev/random, 2007. | Permalink | No comment | Add to del.icio.us
Post tags: desktop, Linux, memoria, ottimizzazione, server

Feed enhanced by Better Feed from Ozh

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.

© Alex for /dev/random, 2007. | Permalink | No comment | Add to del.icio.us
Post tags: Debian, Linux, memoria, ottimizzazione, server, storage

Feed enhanced by Better Feed from Ozh

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.

© Alex for /dev/random, 2007. | Permalink | No comment | Add to del.icio.us
Post tags: Linux, server

Feed enhanced by Better Feed from Ozh