Django + Supervisor su Ubuntu server

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!

Eseguire un’applicazione Django su ubuntu server con nginx, gunicorn, upstart e mysql (DUNG stack)

Gunicorn

Oggi torno a scrivere sul blog per raccontare come eseguire il deploy di un’applicazione Django su ubuntu server con Nginx come web server, Gunicorn come application server WSGI e MySQL come DBMS.

Inizialmente per ospitare un’applicazione scritta con il framework Django utilizzavo un classico stack in stile LAMPP (Linux + Apache + mod_wsgi). Successivamente per cercare di limitare l’utilizzo di ram ho scoperto (grazie al blog degli ingegneri di instagram) lo stack DUNG che rappresenta la configurazione con nginx + gunicorn + ubuntu.

Non appena si iniziano le configurazioni si comprendono la semplicità e la velocità di messa a punto del nuovo stack. Nginx usa file di configurazione scritti con una sintassi simile ad un linguaggio di programmazione, molto più semplici da comprendere e da scrivere per chi ha poca dimestichezza con queste cose.

Per prima cosa installiamo nell’ordine mysql e nginx, successivamente installiamo django.

Fatto ciò, tramite easy_install possiamo installare Gunicorn:

sudo easy_install gunicorn

A questo punto dobbiamo configurare nginx come proxy server per le richieste: tutto ciò che riguarda i file statici (immagini, css, js, ecc…) verrà servito direttamente da nginx mentre le richieste inerenti il codice python dovranno essere girate al server WSGI (gunicorn nel nostro caso) che le eseguirà e restituirà la pagina risultante.

Come per apache i file di configurazione dei vari siti sono in /etc/nginx/sites-available (invece di /etc/apache/sites-available), per cui creiamo il file di configurazione per la nostra applicazione django in questo modo:

upstream project {
        server 127.0.0.1:8200 fail_timeout=0;
        server 127.0.0.1:8201 fail_timeout=0;
}

server {
        listen 80;
        server_name mydomain.com www.mydomain.com;
        access_log /var/log/nginx/mydomain_access.log;
        error_log /var/log/nginx/mydomain_error.log;

        root /srv/django_srv/mydomain/app;

        location / {
                proxy_set_header Host $host;
                if (!-f $request_filename){
                        proxy_pass http://project;
                        break;
                }

        }
        location /upload  {
                alias /srv/django_srv/mydomain/uploads;
                }
        location /static  {
                alias /srv/django_srv/mydomain/app/_statics;
        }
        location /admin/media {
                alias /opt/Django-1.3.1/django/contrib/admin/media;
        }
}

Come potete vedere nel blocco di configurazione upstream project a questo punto dobbiamo configurare gunicorn in modo da farlo rispondere sulla porta 8200 e 8201. In questo modo quando caricheremo aggiornamenti del nostro progetto e dovremmo riavviare gunicorn, il sito non sarà mai irraggiungibile, inoltre se il processo gunicorn dovesse crollare per qualche motivo ce ne sarà sempre un altro disponibile. Gli alias che vedete sono per i file uploadati dagli utenti tramite l’applicazione, i file statici del sito e i file statici per il backend amministrativo (per questi ultimi dovete dare il path alla cartella di installazione di Django). Dopo aver salvato questo file create un link simbolico nella cartella effettiva dei siti di nginx:

ln -s /etc/nginx/sites-available/mydomain.com /etc/nginx/sites-enabled/mydomain.com

Per avviare gunicorn, essendo su ubuntu, utilizziamo upstart il nuovo sistema per avviare tasks e servizi all’avvio del sistema. Creiamo il file /etc/init/gunicorn_8200.conf e copiamo le seguenti istruzioni:

description "Gunicorn Django on 127.0.0.1:8200"
start on runlevel [2345]
stop on runlevel [06]
respawn
respawn limit 10 5
exec /usr/local/bin/gunicorn_django --bind=127.0.0.1:8200 --workers=2 --access-logfile=/var/log/gunicorn/8200_access.log --error-logfile=/var/log/gunicorn/8200_error.log --daemon /srv/django_srv/mydomain/app/settings.py

Con queste istruzioni diciamo al processo gunicorn di ripartire in caso di crash (respawn) di rispondere all’indirizzo 127.0.0.1 sulla porta 8200 (–bind) di partire come demone (–daemon) e gli diamo i percorsi dei file di log e del file di settings della nostra applicazione.

A questo punto riavviamo il server per verificare che anche upstart funzioni:

shutdown -r now

Il gioco è fatto e la nostra applicazione è pronta per essere utilizzata. I file del progetto django (in base a questa configurazione) devono risiedere in /srv/django_srv/mydomain/app, mentre i file di upload sono in /srv/django_srv/mydomain/uploads per fare in modo che non siano all’interno dell’applicazione e che siano facilmente backuppabili ;)

Spero di essere stato esaustivo, di sicuro con questa configurazione vi potrete accorgere del notevole risparmio di ram rispetto ad un classico stack che utilizza apache come webserver.

Server virtualizzato con VirtualBox 4.0 su Ubuntu Server 10.04 LTS

Oracle Virtualbox

Oggi inauguro la nuova grafica del blog con un articolo molto interessante. Questo tutorial vi aiuterà a virtualizzare dei server con VirtualBox da linea di comando.
Ho installato virtualbox 4.0 su una macchina ubuntu server 10.04, ma repository a parte penso che vada bene su qualsiasi versione di ubuntu e più in generale su qualsiasi debian.

Per chi lavora come me su ubuntu server 10.04 per prima cosa bisogna aggiungere il repository di virtualbox nei sorgenti apt. Aprite il file source.list:

sudo vim /etc/apt/sources.list

E aggiungete in fondo la linea:

deb http://download.virtualbox.org/virtualbox/debian lucid contrib

Salvate e chiudete e scaricate la chiave pubblica:

wget -q http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc -O- | sudo apt-key add -

A questo punto aggiornate:

sudo apt-get update

..e installate il software necessario:

sudo apt-get install linux-headers-$(uname -r) build-essential virtualbox-4.0 dkms

Il pacchetto dkms serve per far sì che ogni volta che il kernel verrà aggiornato verrà aggiornato automaticamente anche virtualbox.

A questo punto scaricate l’extension pack di virtualbox

cd /tmp
wget http://download.virtualbox.org/virtualbox/4.0.16/Oracle_VM_VirtualBox_Extension_Pack-4.0.16-75491.vbox-extpack
sudo VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-4.0.16-75491.vbox-extpack

Ora dovrete aggiungere il vostro utente al gruppo utenti di virtualbox:

sudo adduser your_user vboxusers

Ora la configurazione di virtualbox è terminata, possiamo procedere con la creazione di una nuova virtual machine.

VBoxManage createvm --name "ubu_srv_1" --register
VBoxManage modifyvm "ubu_srv_1" --memory 512 --acpi on --boot1 dvd --nic1 bridged --bridgeadapter1 eth0
VBoxManage createhd --filename /home/your_user/vbox/ubu_srv_1/ubu_srv_1.vdi --size 10000
VBoxManage storagectl "ubu_srv_1" --name "IDE Controller" --add ide
VBoxManage storageattach "ubu_srv_1" --storagectl "IDE Controller" --port 0 --device 0 --type hdd --medium /home/your_user/vbox/ubu_srv_1/ubu_srv_1.vdi
VBoxManage storageattach "ubu_srv_1" --storagectl "IDE Controller" --port 1 --device 0 --type dvddrive --medium /home/your_user/downloads/ubuntu-10.04.4-server-amd64.iso

Con queste istruzioni la nuova macchina virtuale è pronta.

Ora per il primo lancio vi consiglio di usare VBoxHeadless che oltre a lanciare la vm appena creata metterà in piedi un server VRDP, in modo che possiate accedere alla macchina con un client di desktop remoto. Per cui, settiamo la porta del vrdp:

VBoxManage modifyvm "ubu_srv_1" --vrde-port 9800

..e lanciamo la macchina virtuale (abbiate cura di mettere la “&” al fondo del comando in modo da poter continuare sulla stessa shell senza chiudere bruscamente il processo della virtual machine):

VBoxHeadless --startvm "ubu_srv_1" &

Quindi aprite il vostro client di desktop remoto preferito e collegatevi all’ip della vostra macchina su cui avete installato virtualbox aggiungendo “:9800”. Il mio indirizzo a cui rispondeva il server rdp era ad esempio 192.168.0.200:9800.
Potete quindi installare normalmente ubuntu server come se foste su una macchina fisica. Finita l’installazione riavviando la macchina partirà il sistema in automatico. Collegatevi e come prima cosa controllate l’ip (meglio assegnarne uno fisso). Prima di poter dire di avere la vm pronta dobbiamo fare in modo che al prossimo lancio non parta più l’immagine di installazione, per cui spegnete la macchina e ritornate sulla shell del server virtualbox:

VBoxManage modifyvm "ubu_srv_1" --boot1 disk

Adesso siete davvero pronti per lanciare la vostra nuova virtual machine. I passi successivi servono per ottimizzare l’utilizzo di ram del vostro server.

Riavviate la macchina fisica che ospita la/le macchina/e virtuale/i e ricollegatevi. Da shell modificate ancora la vm con il seguente comando per non lanciare il server vrdp quando avviate la vm, così da occupare la sola ram indicata per la vostra vm:

VBoxManage modifyvm "ubu_srv_1" --vrde off

Ora potete nuovamente lanciare la vostra macchina virtuale con il comando:

VBoxManage startvm "ubu_srv_1" --type headless &

Per tutti i comandi di VBoxManage fate riferimento all’help:

VBoxManage --help

Per spegnere o mettere in pausa la macchina i comandi sono:

VBoxManage controlvm "ubu_srv_1" poweroff
VBoxManage controlvm "ubu_srv_1" pause

Buon divertimento!

Installare tomcat 6 e postgresql 8.4 su ubuntu server 10.04

L’ambiente più familiare (lato server) per realizzare applicazioni web su linux è senza ombra di dubbio un server LAMP (Linux Apache MySQL PHP).

Ormai lo si riesce ad installare senza grosse difficoltà anche in ambiente linux, grazie (ancora una volta) ad ubuntu che mette a disposizione e ci configura tutti i pacchetti necessari per avere un ambiente completamente funzionante.

A volte risulta però necessario uscire dal seminato, cambiando magari DBMS o linguaggio di programmazione. Vuoi perchè si vuole avere un db più simile ad Oracle o vuoi perchè si preferisce un linguaggio più strutturato o più familiare ai programmatori.

Mi è successo alcuni giorni fa di provare a configurare sul mio server di casa, un ubuntu server 10.04 LTS, un gestionale web scritto in java compatibile con sql server o postgresql. Visto che, come saprà chi mi conosce, non amo molto le tecnologie microsoft e che non credo si riesca ad installare sql server su linux, ho deciso di buttarmi su postgresql ;-)…

Dovremmo quindi installare tomcat per avere un server web java e postgresql per il lato database.

Per prima cosa, assicuriamoci di avere il java development kit di Sun installato:

sudo apt-get install sun-java6-jdk

Ora possiamo procedere con l’installazione del server web tomcat:

sudo apt-get install tomcat6
sudo apt-get install tomcat6-admin

Una volta installati questi pacchetti il nostro server web sarà pronto per essere utilizzato e amministrato, potete verificarne il funzionamento digitanto da browser http://ip_server:8080/, dove ipserver sarà l’indirizzo ip della macchina su cui avete installato tomcat.

Per poter entrare nella sezione di amministrazione delle applicazioni installate in tomcat e verificare lo stato del server, si dovrà creare un utente e fornirgli i privilegi di amministrazione. Per fare ciò editate il file /etc/tomcat6/tomcat-users.xml inserendo le seguenti linee:

<role rolename="admin"/>
<role rolename="manager"/>
<user username="admin" password="admin" roles="admin,manager"/>

Tomcat su linux usa di default le openjdk ovvero le jdk java open source e non quelle ufficiali sun, perciò potreste incorrere in problemi di incompatibilità se installate software non testato su questa piattaforma, per modificare le jdk usate editate il file /etc/default/tomcat6/ e alla voce JAVA_HOME sostituite la linea con questa:

JAVA_HOME=/usr/lib/jvm/java-6-sun

Bene, ora che il server è installato e configurato possiamo passare all’installazione di postgresql:

sudo apt-get install postgresql

Ora che postgresql è installato configuriamo gli indirizzi ip sui quali il db server sarà in ascolto. Potrebbe non essere necessario fare questa configurazione se non desiderate gestire postgresql dall’esterno, ma pgadmin è un tool di gestione per postgresql davvero comodo. Editate quindi il file /etc/postgresql/8.4/main/postgresql.conf così:

listen_addresses = 'localhost,<em>ip_server</em>'

Dove ip_server sarà sempre l’ip della macchina su cui avete installato postgre.

Ora inseriamo la password per l’utente default postgres:

sudo -u postgres psql template1

Si aprirà la shell di postgre e dovremo eseguire la query:

ALTER USER postgres with encrypted password 'password';

Fatto ciò possiamo editare il file dei permessi di postgre /etc/postgresql/8.4/main/pg_hba.conf:

local   all   all   md5
host   all   all   192.168.0.0/24   md5

A questo punto possiamo riavviare sia tomcat sia postgre:

sudo /etc/init.d/tomcat6 restart
sudo /etc/init.d/postgresql-8.4 restart

…e andare a posizionare le nostre applicazioni in /var/lib/tomcat6/webapps/ e gestire i database da shell o tramite pgadmin ;-)

Installare un server VPN con OpenVPN su Ubuntu Server

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…

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]

Google chrome beta per linux e mac!

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]

Ubuntu 9.10 Karmic Koala: prime impressioni

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 davvio di Ubuntu 9.10

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

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

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

Ubuntu 9.04 vs Kubuntu 9.04

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]