Linux | Davide Ferrero

Django + Supervisor su Ubuntu server

17/10/2015

Supervisor, Django e Gunicorn

Continuando ad interessarmi al mondo Django sono venuto a conoscenza di un interessante sistema da utilizzare nello stack per il deploy di un’app sviluppata con questo framework.

Sto parlando di Supervisor, un sistema client/server per il controllo di processi Unix. Inizialmente nel mio stack avevo utilizzato Upstart, il controllore di processi presente di default su Ubuntu, ma utilizzando la funzione respawn, ossia per ogni processo terminato ne viene lanciato un altro, il sistema si perde il riferimento con il processo lanciato e i comandi di stop non hanno più effetto. Sentendo parlare bene di Supervisor mi sono deciso a provarlo ed effettivamente funziona alla grande!!! E’ possibile conoscere lo stato di tutti i processi registrati in Supervisor oltre ai classici comandi di start, stop e restart dei vari processi attivi.

Supervisor è presente all’interno del repository dei pacchetti Ubuntu, quindi per installarlo è sufficiente il comando:

sudo apt-get install supervisor

Per il primo avvio è necessario digitare:

service supervisor restart

A questo punto possiamo aggiure un nuovo programma, che nel caso di applicazioni Django sarà lo script python per l’avvio di Gunicorn (il server wsgi per Django di cui ho già ampiamente parlato qui), vediamo un esempio:

command = '/opt/APP_VIRTUAL_ENV/bin/gunicorn'
pythonpath = '/SRC/APP/PATH/'
bind = '127.0.0.1:8000'
workers = 3
user = 'CUSTOM_USER'
pid = '/var/run/APP_NAME.pid'
accesslog = '/var/log/gunicorn/APP_NAME/access.log'
errorlog = '/var/log/gunicorn/APP_NAME/error.log'

Ovviamente questo è un mio esempio di script per il lancio di gunicorn relativo ad una app django, ma questo tipo di configurazione è valido per qualsiasi processo che si vuole controllare, basta specificare all’interno di “command” il comando che supervisor deve lanciare e controllare. Io sono solito mettere questo script in una cartella chiamata appunto “script” allo stesso livello dei sorgenti dell’app, ma può essere posizionato in qualunque punto del sistema. Sarà poi il file di configurazione del programma in supervisor a dover sapere dove recuperare lo script appena preparato.

Come dicevo, supervisor viene informato di un comando da lanciare mediante un file (un file per ogni comando) all’interno della cartella /etc/supervisor/conf.d/APP.conf contenente le seguenti linee:

[program:APP_NAME]
command=/opt/APP_VIRTUAL_ENV/bin/gunicorn APP_NAME.wsgi:application -c/SRC/APP/SCRIPT/PATH/gunicorn_config.py
autostart=true
autorestart=true
stderr_logfile=/var/log/gunicorn/APP_NAME/supervisor_stderr.log
stdout_logfile=/var/log/gunicorn/APP_NAME/supervisor_stdout.log

Non sto a spiegare nel dettaglio il significato della prima linea, che è il comando per avviare Gunicorn con la nostra app django tramite lo script precedentemente scritto, mentre la seconda e la terza linea dicono a Supervisor rispettivamente di avviare il comando all’avvio del sistema e di riavviare i processi che vengono terminati in modo non naturale. Le ultime due linee specificano i percorsi dei files di log di Supervisor.

A questo punto dobbiamo dire a Supervisor di leggere la nuova configurazione:

supervisorctl reread

Seguito dal comando per abilitare il nuovo programma:

supervisorctl update

Adesso la nostra app dovrebbe essere avviata!

Potete controllare lo stato di Supervisor con il semplice comando:

supervisorctl status

Per avviare, stoppare o riavviare i processi sono presenti i comandi:

supervisorctl start

supervisorctl stop

supervisorctl restart

Mentre per avviare la console interattiva di Supervisor è sufficiente digitare:

supervisorctl

Non vi resta che scrivere app (Django, Node, ROR o ciò che più preferite) e farne controllare i loro processi da Supervisor!

Installare Ubuntu Server 10.04 LTS con RAID 10 e LVM

02/05/2011

Eccomi qua! Dopo un po’ di tempo con poche “scoperte” interessanti, oggi ritorno con un articolo che riguarda i server.

Ovviamente quando parlo di server, parlo di linux e ancora più nello specifico di Ubuntu.

Ultimamente per andare sul sicuro mi sono abituato ad utilizzare solo più le versioni LTS ossia le Long Term Support, le versioni supportate per 3 anni, decisamente molto più stabili rispetto alle altre.

Quando si installa un server generalmente si ha a che fare con la necessità di mantenere il più possibile al sicuro i dati che vi verranno salvati e per fare ciò è buona norma gestire lo spazio a propria disposizione con il RAID ossiamo un sistema di replica delle informazioni in tempo reale che tenta di ridurre al minimo le possibilità di perdita di dati (ridurre, non eliminare, ne ho le prove ;-) ).

L’installazione di Ubuntu consente di creare un RAID software nel caso in cui il server che stiamo preparando non abbia un sistema di RAID hardware.

Tralasciamo la discussione sulla scelta del RAID, per quello che ho potuto provare sulla mia pelle in genere è sempre meglio un RAID 0 o un RAID 1 o meglio ancora un RAID 1+0 detto anche RAID 10 perchè a differenza dell’alternativo RAID 5 lascia i dati in chiaro e quindi leggibili in qualsiasi momento, anche collegandolo su un’altra macchina (in caso di problemi). Detto ciò, veniamo a come preparare le partizioni per costruire il RAID.

Prendendo l’esempio di 2 dischi da 500 Gb vi conviene creare due partizioni primarie per ciascun disco (scegliete la voce “partizionamento manuale”): una dimensionata il doppio della ram presente sul server, e una con lo spazio rimanente. Ripetete la stessa cosa con le altre due partizioni dell’altro disco. Per ogni partizione alla voce “usare come” dobbiamo ricordarci di impostare “volume per il raid”. Fatto ciò possiamo terminare il partizionamento e configurare gli array raid tramite l’apposito menu, scegliendo il raid desiderato e settando quanti dischi usare per il raid (2) e quanti dischi di spare(0).

Come detto dobbiamo configurare due array, uno per la swap e uno per il sistema vero e proprio. Per il primo array scegliamo i due volumi a cui abbiamo assegnato il doppio della dimensione della ram, confermiamo e passiamo alla configurazione del secondo array con i restanti due volumi.

Finita la configurazione dei due array del raid possiamo terminare l’operazione e scrivere le modifiche.

Quando apparirà nuovamente la schermata con le tabelle delle partizioni potremo notare che sono state aggiunte due voci all’elenco, ossia quelle corrispondenti ai due arrays. A questo punto possiamo creare due partizioni (una per array) e impostare la voce “usare come” su “volume per LVM”.

L’LVM è un gestore dei volumi logici, ossia consente di creare dei volumi “estendibili” in qualsiasi momento. Infatti smontando i volumi si possono aumentare le loro dimensioni senza dover formattare e senza subire perdite di dati, e addiritture si possono raggruppare in un unico volume più dischi (anche aggiunti in un secondo momento). Un po’ quello che si può fare tramite l’ormai conosciutissimo GParted in Ubuntu desktop.

Tornando all’installazione del nostro ubuntu server, una volta impostate le nostre partizioni come volumi per LVM possiamo procedere alla creazione dei due volumi logici, come già detto uno per lo swap e uno per il sistema. Una volta confermata la creazione dei due volumi logici (dovrete assegnare un nome ai volumi da creare, ad esempio “swap” e “srv”) nella tabelle delle partizioni troveremo altre due voci, rappresentati i due nuovi volumi appena creati.

A questo punto possiamo procedere alla creazione delle partizioni da far usare all’installazione di Ubuntu: una da impostare come “volume swap” e l’altra da impostare con ext4 (o ext3 per i più tradizionalisti :-P ). Ovviamente la partizione formattata con ext4 dovrà avere come punto di mount “/” (root). Confermate queste modifiche l’installazione procederà a gonfie vele, e in pochi minuti il vostro server sarà pronto per l’uso! :-)

Preparare un web server per django su ubuntu server 10.04

21/11/2010

Poco tempo fa ho scoperto il favoloso mondo di Django, un web framework che consente di scrivere meno codice e creare applicazioni python davvero molto efficienti.

Oltre ad essere un framework che implementa l’MVC(Model View Controller), la caratteristica che mi ha attratto maggiormente è una fantastica funzionalità di ORM(Object Relational Mapping).. cosa significa? In poche parole nel file che implementa il “Model” (models.py) dovrete dichiarare gli oggetti che verranno trasformati in tabelle del vostro database, al resto penserà django. Infatti una volta collegato un db e scritte le classi del modello, con la funzione syncdb verranno create le tabelle residenti sul db. Vi rimando però al tutorial ufficiale per capire davvero qualcosa in più su questo fantastico framework…

In questo post vi farò vedere i pochi e semplici passi per configurare un web server adatto ad ospitare un’applicazione django. Ovviamente il server linux girerà grazie ad ubuntu server ed in particolare nella versione LTS(long term support) 10.04. Salterò ovviamente i passi dell’installazione vera e propria del sistema operativo (anche perchè ormai è a prova di win-user :-P ).

Partendo da un sistema pulito, su cui non è stato installato nessun componente, dovremo per prima cosa assicurarci che il sistema sia aggiornato:

sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get upgrade

Fatto ciò possiamo procedere con l’installazione dei componenti necessari a mettere in piedi un server web, il che equivale ovviamente ad installare il buon vecchio Apache:

sudo apt-get install lamp-server^

In questo modo installeremo tutti i pacchetti per avere un server LAMP ovvero con apache come detto, e con mysql per la parte di database (verrà installato anche php5 per poter utilizzare phpmyadmin, l’interfaccia per la gestione da web di mysql)

Attesi i dovuti tempi per lo scaricamento, l’installazione e la configurazione dei vari pacchetti (vi verrà chiesta la password per mysql) dovreste avere il vostro server web funzionante (potete testarlo collegandovi da un qualsiasi browser nella rete all’indirizzo ip del server es: http://192.168.0.1 ).

Bene, ora manca un ultimo componente per avere il server pronto: il mod_wsgi ovvero il modulo apache per l’interpretazione del codice python:

sudo apt-get install libapache2-mod-wsgi

Ora non ci resta che installare il driver per fare comunicare python e mysql, che come detto sarà per comodità il nostro dbms:

sudo apt-get install python-mysqldb

Ora possiamo procedere al download e installazione del framework dal sito ufficiale di django(vi risparmio il “wget”, mi sembrava troppo da nerd, ma si può fare ;-) ). Trasferite il tar.gz sul server se non è già lì, e scompattatelo (tar -xvzf nomefile.tar.gz per i newbie). Ora entrando nella cartella che avete ottenuto dalla scompattazione potete installare django:

sudo python setup.py install

Vi consiglio spassionatamente di installare la release ufficiale di django e non quella dagli archivi ubuntu per un puro fatto di aggiornamento della versione, infatti sul canale ufficiale sarete sicuri di avere l’ultima stable-release mentre ubuntu è sempre più indietro in queste cose…

Bene adesso abbiamo tutto ciò che ci serve(r) (battuta di bassissimo umorismo, non ci fate caso, è l’età :-P ).

Procediamo con la creazione del file python che darà le direttive al mod_wsgi sui percorsi della nostra applicazione, nella cartella del nostro progetto, creiamo il file django.wsgi:

vim /home/user/py-srv/applicazione1/django.wsgi

Ipotizzando che la nostra applicazione risieda in /home/user/py-srv/applicazione1 …

Il file dovrà contenere il seguente codice:

import os
import sys

sys.path.append('/home/user/py-srv/applicazione1')

os.environ['PYTHON_EGG_CACHE'] = '/home/user/py-srv/.python-egg'
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

Ora dobbiamo solamente dire ad apache quale sarà la cartella della nostra applicazione. Per fare ciò editiamo il file default nella cartella sites-available di apache (prima però facciamo una copia del file per sicurezza ;-) ) :

sudo cp /etc/apache2/sites-available/default /etc/apache2/sites-available/default.old
sudo vim /etc/apache2/sites-available/default

Il file dovrà contenere le seguenti configurazioni:

<VirtualHost *:80>
   DocumentRoot /home/user/py-srv/applicazione1/public_html

   WSGIScriptAlias / /home/user/py-srv/applicazione1/django.wsgi
   <Directory /home/user/py-srv/applicazione1>
      Order allow,deny
      Allow from all
   </Directory>

   Alias /favicon.ico /home/user/py-srv/applicazione1/public_html/favicon.ico
   Alias /images /home/user/py-srv/applicazione1/public_html/images
   Alias /static /home/user/py-srv/applicazione1/public_html/static

   ErrorLog /home/user/py-srv/applicazione1/logs/error.log
   CustomLog /home/user/py-srv/applicazione1/logs/access.log combined
</VirtualHost>

Come potete immaginare la cartella “public_html” sarà quella che conterrà i file html pubblici, ovvero i file del template della vostra applicazione.

Bene, se avete fatto tutto nel modo giusto, vi basterà collegarvi all’indirizzo ip che avete già usato prima per testare apache, e vedrete come per magia che funzionerà tutto!

(non funziona? non fate come me che avevo lasciato il vecchio path nel file settings.py, e ci ho perso mezz’ora per accorgermene :-P )

Buon divertimento!

Installare un server VPN con OpenVPN su Ubuntu Server

02/08/2010

Qualche giorno fa, a lavoro ho configurato il mio primo server vpn. Avevamo la necessità di accedere alla rete dell’ufficio anche dall’esterno. Insomma ci avrebbe fatto comodo essere “virtualmente” in ufficio quando fisicamente non è possibile. Avevo ricevuto consigli in merito a queste necessità, e mi era stato detto che come OpenVPN non ce n’erano molti. Ovviamente Open VPN è un software gratuito e multipiattaforma, aveva quindi tutti i prerequisiti necessari per piacermi.

Diciamo che prima di intraprendere il lavoro ho perso qualche minuto a cercare la documentazione necessaria, che mi avrebbe accompagnato durante il cammino.

Inizialmente avevo preso un pc davvero modesto (con processore AMD Duron, qualcosa di simile al Sempron ma un po’ più vecchio ;-) ) con 40 ghiga di disco e 512 Mb di ram SO DIMM, credendo di usarlo come test per la macchina vera. Ovviamente ho installato Ubuntu server come sistema operativo, scaricando l’ultima versione (10.04) siccome è un LTS. Nell’installazione del S.O. non c’è stato alcun inghippo, oramai queste ultime versioni sono una pacchia, filano dritte dritte in pochi minuti verso il traguardo ;-).

Una volta installato Ubuntu ho seguito il wiki in inglese per la corretta installazione di open vpn. Come prima passo, la guida consiglia di configurare un bridge sulla scheda ethernet per consentire al segmento LAN di essere connesso al segmento WAN, consentendo (se si vuole) di filtrare i pacchetti che li attraversano con un firewall. Per fare ciò basta installare un pacchetto chiamato bridge-utils con il comando:

sudo apt-get install bridge-utils

Fatto ciò si deve editare il file di configurazione della rete con il comando:

sudo vim /etc/network/interfaces

modificarlo come segue:

auto lo
iface lo inet loopback

auto br0
iface br0 inet static
        address 192.168.0.10
        network 192.168.0.0
        netmask 255.255.255.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        bridge_ports eth0
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

Così facendo si assegna il bridge all’interfaccia eth0 con l’ip 192.168.0.10.

Adesso potete riavviare il servizio networking:

sudo /etc/init.d/networking restart

(per evitare di dover digitare sempre il comando sudo davanti ad ogni comando vi consiglio di digitare sudo su una volta per tutte)

Ora possiamo passare all’installazione vera e propria di OpenVPN:

apt-get install openvpn

Finita l’installazione del pacchetto creiamo una cartella che conterrà i programmi per generare le chiavi e le chiavi stesse:

cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/
mv /etc/openvpn/2.0 /etc/openvpn/easy-rsa

Dopodichè editiamo il file vars in modo da modificare le seguenti linee con le informazioni che ci riguardano:

export KEY_COUNTRY="US"
export KEY_PROVINCE="NC"
export KEY_CITY="Winston-Salem"
export KEY_ORG="Example Company"
export KEY_EMAIL="steve@example.com"

Salvate il file e chiudetelo. Accertandovi di essere loggati come utente di root, iniziate la procedura di generazione delle chiavi:

cd /etc/openvpn/easy-rsa/
source ./vars
./clean-all
./build-dh
./pkitool --initca
./pkitool --server server
cd keys
openvpn --genkey --secret ta.key
cp server.crt server.key ca.crt dh1024.pem ta.key /etc/openvpn/

Ora che abbiamo generato le chiavi e i certificati per il server procediamo a generare quelli per il client (basterà ripetere la prossima procedura modificando l’identificativo del client per generare altre chiavi/certificati):

cd /etc/openvpn/easy-rsa/
source vars
./pkitool client1

Copiate ora sul client i file:

/etc/openvpn/ca.crt
/etc/openvpn/easy-rsa/keys/client1.crt
/etc/openvpn/easy-rsa/keys/client1.key
/etc/openvpn/ta.key

Ora non ci resta che editare i file di configurazione per server e client (partiamo da una configurazione di esempio):

cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
gzip -d /etc/openvpn/server.conf.gz
vim /etc/openvpn/server.conf

Accertatevi di correggere le seguenti linee con i vostri dati:

local 192.168.0.10
dev tap0
script-security 3
up "/etc/openvpn/up.sh br0"
down "/etc/openvpn/down.sh br0"
proto tcp
;server 10.8.0.0 255.255.255.0
server-bridge 192.168.0.10 255.255.255.0 192.168.0.100 192.168.0.110
push "route 192.168.0.1 255.255.255.0"
tls-auth ta.key 0 # This file is secret
user nobody
group nogroup
cipher AES-256-CBC

La voce local sarà quella corrispondente all’indirizzo del vostro bridge, come la prima voce accanto a server-bridge. La seconda voce di server-bridge sarà la subnet mask mentre la terza e la quarta sarà il range di ip che openvpn assegnerà ai client che si connetteranno alla rete.
Il comando push “route… servirà per creare una rotta sugli indirizzi della LAN.
Fatto ciò, creiamo i due script per l’avvio e la chiusura dell’interfaccia virtuale (la tap0 che vedete nel file di configurazione). Creiamo il file up.sh come segue:

vim /etc/openvpn/up.sh

#!/bin/sh
BR=$1
DEV=$2
MTU=$3
/sbin/ifconfig $DEV mtu $MTU promisc up
/usr/sbin/brctl addif $BR $DEV

e il file down.sh così:

vim /etc/openvpn/down.sh

#!/bin/sh
BR=$1
DEV=$2
/usr/sbin/brctl delif $BR $DEV
/sbin/ifconfig $DEV down

Rendiamoli eseguibili:

chmod 755 /etc/openvpn/down.sh
chmod 755 /etc/openvpn/up.sh

Ora che il server è correttamente configurato, possiamo dare una riavviata al servizion openvpn:

/etc/init.d/openvpn/restart

Adesso passiamo al file di configurazione del client:

sudo cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn

Il quale dovrà contenere:

dev tap
proto tcp
remote 192.168.0.10 1194
cert client1.crt
key client1.key
tls-auth ta.key 1
cipher AES-256-CBC

Ora copiate nella cartella di configurazione del client il file appena editato (chiamatelo client1.conf o client1.ovpn). Ovviamente si presuppone che i file delle chiavi e dei certificati siano nella stessa cartella di quest’ultimo file (sul client). Riavviate anche qui openvpn e il gioco è quasi fatto. Dico quasi perchè per potervi connettere al server dall’esterno dovrete dire al vostro router di aprirvi la porta 1194 e reindirizzare il traffico proveniente dall’esterno verso l’ip 192.168.0.10 (quello del bridge).

Ora siete davvero pronti per collegarvi dall’esterno alla vostra LAN (così com’è stato configurato openvpn non è possibile accedere da dentro la LAN alla vpn appena creata).

Spero di non aver dimenticato niente! ;-)

Che ve ne pare?

Pollycoke sta tornando…

19/01/2010

A quanto pare, l’abbassamento delle luci sul miglior sito italiano del mondo “linux-e-non-solo” era solo (come tutti noi speravamo) temporaneo, e come scritto dal buon Felipe nell’ultimo articolo (datato 19/01/2009), sembra che qualcosa si stia muovendo.

Intanto ci suggerisce di aggiornare i puntatori al suo blog cambiando l’url dal vecchio pollycoke al nuovo-vecchio pollycoke.org.

In attesa del completamento delle operazioni preliminari sul nuovo dominio, io ho ascoltato il consiglio, e ora aspetto di vedere tutte le altre novità per poter definitivamente dire “bentornato pollycoke”!
[ad]

Il superuser in ubuntu…

16/01/2010

Ecco un modo semplice e veloce per descrivere a cosa serve il comando sudo in una shell in Ubuntu:

[ad]

Google chrome beta per linux e mac!

08/12/2009

Ebbene sì ragazzi è arrivata!

Proprio in questi minuti è stata anche inviata la mail a chi si era iscritto per ricevere un avviso quando fosse stata pronta la versione di Google Chrome per linux.

Che dire, io aveva già installato la versione unstable da tempo, e di tanto in tanto la provavo, ultimamente gli aggiornamenti si erano fatti più frequenti, e così il team di google ci ha regalato la beta del suo browser in anticipo rispetto al Natale.

Adesso sia gli utenti linux, sia i macachi hanno a disposizione un nuovo browser…

Collegandovi a questa pagina, verrà riconosciuto il vostro SO e potreste scaricare la versione adatta a voi ;)

Questo invece è il link al post ufficiale sul chrome-blog ;-)
[ad]

Sincronizzare files tra due server e schedulare i backup

04/12/2009

Nuovo capitolo delle mie avventure lavorative… Ieri ho impiegato la mia giornata nel configurare una nuova macchina come server di backup di un file server già presente nel nostro ufficio.

All’inizio di aprile avevo già provato l’ebrezza di installare un file server, con 4 dischi da 1 TB ciascuno in RAID 5. Ora quel server, usato soprattutto per backup di progetti adobe premiere, quindi file di grandi dimensioni, è quasi pieno (93% di spazio occupato, su 2 TB). La settimana scorsa così, è partito l’ordine per la nuova macchina, che dovrà eseguire il backup dei dati presenti su quel server. Un hp con 4 dischi da 1,5 TB.

Ho così scaricato la nuova versione di ubuntu server (9.10) e avviato l’installazione, partizionando il disco con volumi per il raid e installando il raid 5 software. Il multidevice RAID è stato configurato in modo da usare tutti i 4 dischi, senza prevedere un disco di spare (quindi bisogna ricordarsi di rivolgere qualche preghiera ogni tanto :P), per un totale di 4,5TB disponibili.
A questo punto dopo aver installato l’ssh :

sudo apt-get install openssh-server

… e la condivisione samba (maggiori informazioni qui) ho googleggiato un po’ per scoprire come configurare rsync e schedulare un backup da un server ad un’ora prestabilita della notte.

rsync è un ottimo programma per il backup da linea di comando e usa l’ssh per eseguire una copia tra due macchine in rete.

Le cose però si fanno più complicate quando bisogna schedulare il backup… Quando si stabilisce una connessione ssh infatti, il server destinazione richiede l’autenticazione (nome utente e password), e se si vuole eseguire un backup notturno, inserire nome utente e password non è possibile. Esiste quindi un modo per bypassare l’autenticazione ssh creando una chiave rsa e condividendola tra i due nodi (sorgente e destinazione).

Il primo passo è quello di abilitare l’autenticazione con chiave rsa sul server destinazione:

sudo vim /etc/ssh/sshd_config

…e assicurarsi che siano presenti le tre linee seguenti:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

…e riavviare il server ssh:

sudo /etc/init.d/ssh restart

Bene ora spostiamoci sul server sorgente e creiamo la chiave rsa (consiglio, autenticatevi come root per non avere problemi di permessi):

ssh-keygen -t rsa

A questo punto andiamo nella cartella .ssh nella home (se avete ascoltato il consiglio sarà /root/.ssh) e troverete due file: id_rsa e id_rsa.pub (chiave privata e chiave pubblica). Aprite il file contenente la chiave pubblica, e copiate il suo contenuto per intero.

A questo punto torniamo sul server destinazione e creiamo la cartella .ssh nella home del profilo con il quale si vorrà connettersi via ssh. Qui creiamo il file authorized_keys e copiamoci dentro la chiave pubblica del server. Bene (assicuratevi di assegnare i giusti permessi, in genere 600 al file e 700 alla cartella se non volete che qualcuno si impossessi della chiave rsa) a questo punto dovreste testare la connessione ssh dal server sorgente a quello di destinazione. Vi chiede la password? allora avete sbagliato qualcosa, o avete avuto sfortuna :-P cancellate i file creati e ripartite dalla creazione della chiave.

Se invece tutto sembra andare per il meglio non vi resta che schedulare lo script di rsync.

Per schedulare un job, su linux è buona prassi usare crontab.

Prima di tutto andate nella cartella /root e create un file rsync.sh. Il suo contenuto potrebbe essere una cosa del tipo:

#!/bin/bash

SOURCEPATH=’/source/directory’
DESTPATH=’/destination’
DESTHOST=’123.123.123.123′
DESTUSER=’destuser’
LOGFILE=’rsync.log’

echo $’\n\n’ >> $LOGFILE
rsync -av –rsh=ssh $SOURCEPATH $DESTUSER@$DESTHOST:$DESTPATH 2>&1 >> $LOGFILE
echo “Completed at: `/bin/date`” >> $LOGFILE

…salvate ed è tutto (quasi) a posto.

Non rimane che editare il file di crontab e aggiungere l’istruzione per lanciare ad un’ora prestabilita il file .sh appena creato:

sudo crontab -e

Qui dentro dovrete inserire una linea del tipo:

0 4 * * * /root/rsync.sh

Salvate ed uscite.

Ora il vostro lavoro partirà alle ore 4.00 di tutti i giorni, di tutti i mesi [,di tutti i giorni della settimana])

Bene, ora avete un backup giornaliero dei vostri dati, su un altra macchina. figo no? ;-)

ps: la maggior parte di questa guida, si basa su quest’altra guida, davvero ottima, anche se in anglais…
[ad]

Ubuntu 9.10 Karmic Koala: prime impressioni

08/11/2009

Dopo più di una settimana di utilizzo, posso finalmente dire che la nuova versione di Ubuntu (9.10, ndr) mi soddisfa.

Non ci sono nuove features sbalorditive ma è tutto l’insieme che lo rende, a mio parere, un buon sistema.

Con queste ultime parole appena scritte, scatenerò l’ira di qualcuno che non ama ubuntu (a favore di sbrindosw 7, che non ho ancora avuto il piacere di provare, ma dal quale non mi aspetto nulla di buono, per partito preso… ;-) ) o di altri che (beati loro) vivono nel giardino dell’eden (spero di raggiungervi presto ;-), ma temo non prima di gennaio/febbraio 2010 ).

Dicevo… E’ un buon sistema perchè è stabile, veloce e intuitivo… Come chiunque di voi abbia provato almeno una volta ad installare ubuntu sa, il setup (formattazione, partizionamento e installazione del nuovo sistema) è una cosa molto rapida ed indolore. In pochi minuti (non li ho contati perchè durante l’installazione facevo altro, ma credo siano stati circa 15-20) ho fatto backup dei miei vecchi dati, lanciato la live da usb e lanciato il setup.

Avvio:

Schermata d'avvio di Ubuntu 9.10

Buone sensazioni, nuova versione di grub (cambia poco, cenni di qualche colore in più, ma lo sostanza è sempre quella e funziona) e nuova grafica all’avvio. In davvero pochi istanti il sistema si avvia e ci si presenta senza troppa fatica la schermata di login. Questa forse è la prima piccola novità che non mi piace: infatti per accedere bisogna cliccare sul nome dell’utente e poi digitare la password, mentre essendo l’unico utente, vorrei non dover usare il mouse o comunque “scegliere” tra una sola opzione e scrivere direttamente solo più la password (ma son dettagli e forse son troppo pignolo…). In sostanza il passaggio ad upstart, va a favore dell’avvio più rapido di questa versione. GOOD.

Grafica:

Giudizio anche qui molto positivo. Nuovo tema grafico, comprensivo di nuove icone nella barra superiore, che ricordano un po’ la barra superiore del mac e tutto sembra molto sciccoso…

Nuove icone di sistema

Sono poi stati creati altri temi davvero interessanti e volendo (ma io non ho voluto) ce n’è uno davvero molto mac-like… Personalmente sono un po’ contro il far assomigliare un sistema non mac ad uno pseudo melacomputer che non lo è per nessun motivo. Per cui accetto di buon grado questo nuovo tema predefinito, e il suo color marrone-koala-col-mal-di-pancia (per stare in tema di koala) perchè nonostante tutti dicessero che gli faceva schifo sto colore, ubuntu continua ad andare per la sua strada, migliora il “marrone” e riesce quasi a farlo piacere in questa versione. NB: l’ho usato per qualche ora, poi come faccio dalla 6.06 vado in Sistema->Preferenze->Aspetto e modifico il marrone con un bel blu, che preferisco… ;-)

Il mio desktop (clicca per ingrandire)

Software Center:

Nothing of new… Niente di nuovo per i non anglofoni… è semplicemente il vecchio “Aggiungi/Rimuovi”, probabilmente con qualche software in più, probabilmente si vuole portare l’idea dell’apple store anche nella comunità ubuntista… Anche se non credo in una sua esplosione o in una comparsa di applicazioni a pagamento direttamente in questo store… In ogni caso funziona bene da parecchie versioni ed è un’aggiunta positiva di questo sistema… In pochi istanti si cerca, si trova e si incomincia ad usare il software di cui si ha bisogno…

Effetti grafici:

Qui arrivano le note dolenti… Sul mio pc funzionano, senza problemi, sono già attivi dalla live e funzionano senza installare nulla, niente, nada e sono parte integrante del sistema base… ma io li ho disattivati… :-) Quando il sistema deve fare qualcosa di pesante viene rallentato, e questo non dovrebbe succedere… Si vorrebbe imitare il mac, ma os x ha qualcosa di magico (hardware chiuso?) per cui quegli effetti grafici sono davvero parte integrante del sistema e non influiscono negativamente sulle prestazioni. Non ho provato gli effetti avanzati, ma il famoso “cubo” dovrebbe esserci, per gli affezionati…

Applicazioni:

Nessuna novità eccezionale, qualche piccolo cambiamento come ad esempio Empathy al posto Pidgin… Proprio Empathy diventa parte integrante del sistema, tra le icone in alto a destra c’è la busta che fornisce facile accesso al client di posta (Evolution) e quello di messaggistica appunto. Altra nota positiva l’ottimo punto raggiunto da google-chrome-unstable ovvero la beta in fase di sviluppo del browser di casa Big G, arrivato ad una versione davvero accettabile ed usabile. Per il resto, tutto come prima. ;-)

In sostanza il sistema è funzionale e non è da disdegnare soprattutto se si pensa che non si deve scucire un euro per avere tutto che funziona… Funziona per lavorarci su? Al solito, se uno non lavora sulla grafica pesante, può essere una buona fonte di risparmio… Come sostengo da un po’ di tempo, se certe aziende o il sistema pubblico provasse ubuntu per le proprie segretarie (la maggior parte usa word ed excel e stop) si potrebbero risparmiare un bel po’ di dindi… pensateci…

Come si può capire sono ampliamente soddisfatto di questo SO e vi consiglio di provarlo :-)
[ad]

Ubuntu 9.04 vs Kubuntu 9.04

12/07/2009

Ubuntu 9.04 vs Kubuntu 9.04

Da un po’ di tempo ormai sto sperimentando sui miei due pc due versioni di “buntu”… Una con la “U” davanti (sul fisso, con file system ext4) e l’altra con la “K” (sul portatile)…

Devo ammettere che ero molto scettico nel passare a KDE da buon gnomista… Però a distanza di qualche mese devo ricredermi… Non è male neppure KDE e come in ogni distribuzione linux che si rispetti anche Kubuntu ha i suoi pro e i suoi contro… In particolare posso raccontarvi alcune differenze che ho riscontrato tra le due versioni 9.04.

Ubuntu 9.04:

Molto rapido all’avvio, stabilità consolidata anche se ho fatto un passo indietro per quanto riguarda gli effetti grafici, infatti sulla 8.10 funzionavamo mentre ora sembra non abbiano voglia di attivarsi (c’è anche da dire che non mi sono minimante sbattuto per farli funzionare). Per il resto il solito marronume ubuntiano, poco accattivamente graficamente ma funzionante in tutto e per tutto e molto stabile(effetti grafici a parte)

Kubuntu 9.04

Per uno abituato ad ubuntu si parte subito con qualche punto in meno, per l’avvio… Nessuna differenza abissale ma un po’ più lento, forse dovuto al caricamento post-login di desktop ecc ecc. Bisogna anche dire che quando scompare lo splash si può iniziare ad usare il pc mentre con ubuntu c’è da aspettare che si carichino i vari componenti… Graficamente, decisamente più accattivante, pensavo fosse in stile giocattolo invece non è davvero niente male. Il file manager(dolphin) è qualche passo avanti rispetto a nautilus per alcune sciccherie stile mac (vedi la visualizzazione a colonne, molto intuitiva). Un’altra cosa da segnalare è kde 4, non ancora definitivo ma davvero qualche decina di anni luce avanti rispetto a gnome (aspettando di vedere la versione 3)… Per il resto bisogna semplicemente abituarsi ai software da utilizzare che ovviamente sono diversi, compreso il browser di default che è konqueror e che ovviamente ho subito piallato a vantaggio di firefox (idem per le mail, con Kmail cestinato a favore di Thunderbird)… Per quanto riguarda gli effetti grafici invece probabilmente ci sono dei conflitti con kde 4 perchè quando sono attivi si incappa in crash incontrollati anche solo muovendo il topo. In definitiva, ovviamente all’inizio bisogna abituarsi come in tutte le cose, ma se anche voi siete gnomisti convinti come me, vi consiglio anche solo di provarlo, potrebbe piacere anche a voi…

[ad]

Articoli precedenti →