Questo post è protetto da password. Per leggerlo inserire la password qui sotto:

Password:

Questo post è protetto da password. Per leggerlo inserire la password qui sotto:

Password:

Lo strumento atto a questa operazione via shell è “update-manager-core”.

Ho quindi aperto una shell e seguito i seguenti passi (come suggerito dalla guida):

sudo apt-get install update-manager-core

update-manager-core dovrebbe essere installato, anzi lo è quasi sicuramente visto che la versione JeOS la installa di default. Ora sempre come suggerito dalla guida modifichiamo il file di configurazione:

sudo vi /etc/update-manager/release-upgrade

Il file dovrebbe essere questo:

# default behavior for the release upgrader
#

[DEFAULT]
# default prompting behavior, valid options:
#  never  – never prompt for a new distribution version
#  normal – prompt if a new version of the distribution is available
#  lts    – prompt only if a LTS version of the distribution is available
Prompt=lts

Dovete sostituire solo l’utlma riga da “Prompt=lts” a “Prompt=normal”, salvate, chiudete e poi semre su shell scrivete:

sudo do-release-upgrade

A questo punto parte l’aggiornamento, l’unica raccomdandazione che posso fare è quella di fare attenzione a non sovrascrivere i file di configurazione (vi verrà richiesto di volta in volta).

Finito l’aggiornamento poichè anche il kernel è stato aggiornato vi verrà richiesto un reboot. Al riavvio potreste incorrere in questo inconveniente:

Niente panico: è successo questo, l’aggiornamento automatico ha installato una la versione “-server” del nuovo kernel, la quale richiede una funzione non abilitata di default in VirtualBox. Quindi basta abilitarla, aprendo la pagina di impostazioni della macchina viruale e spuntare l’apposita casella

Attenzione però, se il sorgente è libero, la versione già compilata per il vostro OS è sotto licenza PUEL (Personal Use and Evaluation License) il che significa:

“Personal use is when you install the product on one or more PCs yourself and you make use of it (or even your friend, sister and grandmother). It doesn’t matter whether you just use it for fun or run your multi-million euro business with it. Also, if you install it on your work PC at some large company, this is still personal use. However, if you are an administrator and want to deploy it to the 500 desktops in your company, this would no longer qualify as personal use. Well, you could ask each of your 500 employees to install VirtualBox but don’t you think we deserve some money in this case? We’d even assist you with any issue you might have. “

Ovvero se sei una azienda che basa il suo lavoro sul “nostro” lavoro è giusto che tu paghi una licenza, che comprende anche l’assistenza tecnica…

L’installazione è rapida e semplice (io ho Leopard) e richiede solo 74 mb, vi verrà richiesto nome ed email, ma non abbiate timore, avrete solo notizie sugli aggiornamento la SUN non cercherà di vendervi nulla…

Altri due click e siamo proti avviate il programma e cliccate su “Nuova” per creare la prima macchina virtuale, next, datele un nome e segliete Ubuntu come Sistema operativo, selezionate la ram desiderata (256 mb dovrebbero bastare ma potrete aumentarla in seguito). Ok adesso dovrete creare/selezionare un HD virtuale, io li preferisco ad “Espansione Dinamica” ossia che si espandono in base a quanto serve.

Siamo già pronti per installare il nostro “GuestOS”. Io come al solito ho scelto Ubuntu come distro di riferimento. In particolare JeOS, ossia la versione di Ubuntu ottimizzata (sono solo 100mb) per le VM.

La prima volta che avviate la macchina virtuale vi verrà suggerito di selezionare un CD o un Floppy di avvio, Ma potete anche montare direttamente un file *.iso, quindi selezionate la iso di JeOS e avviate la VM.

L’istallazione di JeOS è minimalista ed installa solo il sistema di base… Quindi siete pronto per installare e configurare il vostro server LAMP o quello che volete…

Tema Portfolio

Se state pensando di pubblicare o rinnovare il vostro portfolio questo tema potrebbe facilmente risolvervi il problema…

Colourise

Veramente notevole questo tema… Colorato elegante… da non perdere

Ma in pratica come funziona? Preso per assunto che ogni computer in rete deve avere un indirizzo IP univioco, quando scrivete “www.pippo.it” nel vostro browser, parte una richiesta al sistema operativo che deve tradurre il nome in un indirizzo ip che corrisponde al server su cui si trova il sito che cercate. Per farlo il Sistema Operativo per prima cosa esamina il file hosts appunto, se non trova il nome nella sua lista (e questo succede nel 99,99% dei casi) passa la richiesta al server DNS. Noi interveniamo proprio qui, prima della richiesta al server DNS e traduciamo il nome in un indirizzo.

Per modificarlo per prima cosa dobbiamo trovarlo… Negli ambienti unix (quindi anche linux/bsd/osx) lo trovate in “/etc/hosts”, windows invece, lo custodisce in “c:/windows/sistem32/drivers/etc/hosts”

Cominciamo da Windows, il file originale dovrebbe essete più o meno questo:

# Copyright (c) 1993-2006 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a ‘#’ symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

127.0.0.1       localhost
::1             localhost

Se l’indirizzo ip del server web dove si trova www.pippo.it è 192.168.0.3 basta modificare

127.0.0.1       localhost
::1             localhost

in

127.0.0.1       localhost
192.168.0.3 www.pippo.it www.altro.it
192.168.0.4 www.altroserver.it
123.45.67.89 www.ancheesterni.it
::1             localhost

Potete aggiungere tutti gli ip che volete andando a capo, e ad ogni ip in nomi quanti e quali volete, separati da uno spazio

In osX (10.5-leopard) invece il file hosts è più o meno questo:

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
255.255.255.255 broadcasthost

::1             localhost
fe80::1%lo0     localhost

Potete modificarlo così:

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
255.255.255.255 broadcasthost

192.168.0.3 www.pippo.it www.altro.it
192.168.0.4 www.altroserver.it
123.45.67.89 www.ancheesterni.it

::1             localhost
fe80::1%lo0     localhost

In fine un esempio di file hosts per linux Ubuntu originale:

127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

e modificato:

127.0.0.1 localhost

192.168.0.3 www.pippo.it www.altro.it
192.168.0.4 www.altroserver.it
123.45.67.89 www.ancheesterni.it

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Diciamo che ho bisogno che più siti gìrino su questo server, una esigenza normale, la soluzione più logica è cofigurare dei virtual hosts su apache. Ci sono principalemente due modi per configurare i virtual host su apache:

• Name-based Virtual Hosts (più di un sito sullo stesso indirizzo ip)
• IP-based Virtual Hosts (un indirizzo ip per ogni sito)

In questo articolo mi occuperò solo dei Name-based, vista anche l’oggettiva impraticabilità dell’IP-based.

La configurazione di Apache su Ubuntu è un po’ particolare, infatti il classico httpd.conf è vuoto! Provate ad aprirlo:

# vi /etc/apache2/httpd.conf

~
~
~
“/etc/apache2/httpd.conf” 0 lines, 0 characters

In ubuntu il grosso del file httpd.conf si trova in apache2.conf, mentre le parti che devono essere modificate più frequentemente hanno sezioni esterne, in particolare i virtual hosts e la gestione dei moduli.

Questa suddivisione è comoda perchè ti permette di modificare le parti “mobili” senza rischiare di intaccare le parti più complesse della configurazione.

Tornando ai virtual hosts, sappiate che sono tutti archiviati nella cartella “sites-available”, la struttura prevede che abbiate un virtual host per file. Certo nulla vi impedisce, come vedremo, di raccogliere più di un VH nello stesso file, ma così si rischia di perdere i vantaggi offerti dalla particolare struttura di configurazione.

Entrando in “sites-available” troverete un solo file: “default”. Questo è il file di configurazione del Virtual host principale, proviamo se la configurazione di apache (prima di un qualsiasi nostro intervento) è buona e funzionante:

# apache2ctl -t
apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.0.1 for ServerName
Syntax OK

apache2ctl è un comando (bash) che ci permette di compiere comodamente le principali operazioni sul Apache, il parametro -t serve a testare la configurazione attuale senza riavviare il servizio httpd.

“apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.0.1 for ServerName” è solo un warning infatti il messaggio finale “Syntax OK” non è un messaggio di errore, per eliminarlo basta aggiungere il paramentro “ServerName” nella configurazione. Per farlo aprite apache2.conf  in modifica scorrete il file fino in fondo, le ultime 8 righe dovrebbero essere queste:

# Include of directories ignores editors’ and dpkg’s backup files,
# see README.Debian for details.

# Include generic snippets of statements
Include /etc/apache2/conf.d/

# Include the virtual host configurations:
Include /etc/apache2/sites-enabled/

Aggiungete “ServerName” alla terzultima riga così:

# Include of directories ignores editors’ and dpkg’s backup files,
# see README.Debian for details.

# Include generic snippets of statements
Include /etc/apache2/conf.d/

ServerName apollo
# Include the virtual host configurations:
Include /etc/apache2/sites-enabled/

Salvate e testate: apachectl -t

Ora siete pronti per modificare il VH di default, spostatevi in /etc/apache2/sites-avaible e aprite in modifica il file default. Quelle che ci interessano molto sono le prime due righe:

NameVirtualHost *
<VirtualHost *>

Per evitare confusione ed errori strani nelle configurazioni seguenti settiamo correttamente tutti i parametri:

NameVirtualHost NOME_SERVER_DI_DEFAULT:80
<VirtualHost NOME_SERVER_DI_DEFAULT:80>

Il carattere asterisco “*” comprende tutti i nomi e tutte le porte, quindi funziona in qualsiasi caso, ma anche in questo caso troppa libertà può generare confusione. Quindi diamo un nome (“NOME_SERVER_DI_DEFAULT”) e una porta (“:80″) al nostro VH principale.

Già che sitete qui date un’occhiata e semmai modificate:

• ServerAdmin (l’indirizzo di posta elettronica amministratore di sistema)
• DocumentRoot (la root del vostro sito)
• <Directory /var/www/> (deve essere uguare a DocumentRoot)

Fate attenzione settando la document root, se avete l’abitudine come me di raccogliere tutti i siti in /var/www/nomesito lasciate accessibili tutti i siti contenuti in /var/www dal VH di default. Per questo motivo io ho creato una cartella vuota “defult” (con un file index.html di conferma), e modificato il DocumentRoot in /var/www/default per limitare l’accesso del VH alla sola cartella “default”.

Salvate e testate la cofigurazione come abbiamo già fatto prima (apachectl -t)

Siamo pronti per configurare il nostro primo virtual host, lo chiameremo pippo.it, come il sito che stiamo sviluppando :

#cp default pippo.it

Abbiamo semplicemente copiato il VH di defult, il che è una buona base di partenza, adesso lo dobbiamo modificare secondo le notre esigenze:

Eliminate la prima riga “NameVirtualHost”, e modificate il nome del VirtualHost quindi:

NameVirtualHost NOME_SERVER_DI_DEFAULT:80
<VirtualHost NOME_SERVER_DI_DEFAULT:80>

diventa:

<VirtualHost www.pippo.it:80>

Il terzo livello (www) e la porta (:80) non sono obbligatori e potete ometterli, ma Vi consiglio di prendere la buona abitudine di scriverli sempre, evitanto un sacco di confusione quando i terzi livelli e le porte si ingarbugliano (vedi https…). Aggiornate la DocumentRoot e le altre impostazioni importanti e necessarie e poi salvate il file.

Se non eliminate (o commentate) il NameVirtualHost avere come risposta:

# apache2ctl -t
[Tue Sep 02 18:59:03 2008] [warn] NameVirtualHost pippo.it:80 has no VirtualHosts
Syntax OK
#

Adesso dobbiamo abilitare il nuovo virtual host, per farlo basta un collegamento simbolico del nuovo file pippo.it nella cartella sites-enabled. potete scrivere:

#ln -s /etc/apache2/sites-avaible/pippo.it /etc/apache2/sites-enabled/.

oppure più semplicemente

#a2ensite pippo.it

a2ensite -> abilita un VH contenuto in sites-avaible creando un collegamento simbolico in sites-enabled

a2dissite -> disabilita un VH eliminando il collegamento simbolico in sites-enabled

Ora prima di riavviare apache dovremmo testare la correttezza delle nostre modifiche, quindi eseguite un altro “apachectl -t”

Poichè il vostro pippo.it potrebbe essere un dominio di fantasia e quindi inesistente dovreste avere un errore del tipo:

# apachectl -t

[Sat Aug 23 11:36:00 2008] [error] (EAI 5)No address associated with hostname: Could not resolve host name pippo.it — ignoring!

Per risolvere questo problema basta configurare correttamente il file di hosts del vostro server (vedi qui come fare).

Siamo pronti per HTTPS. Per prima cosa dobbiamo attivare il modulo SSL che si occupa di criptare le comunicazioni. La configurazione dei moduli è molto simile alla gestione dei virtual hosts. Nella cartella “mods-available” ci sono i moduli disponibili, nella cartella “mods-enabled” i link simbolici a mods-available per i moduli da far caricare ad apache. Generalmente il modulo SSL di apache non è attivo, ma per saperlo basta entrare in/etc/apache2/mods-enabled e verificare la presenza di “ssl.load” e “ssl.conf”. Se non ci sono digitate:

#a2enmod ssl

a2enmod -> abilita un modulo contenuto in mods-avaible creando un collegamento simbolico in mods-enabled

a2dismod -> disabilita un modulo eliminandi il collegamento simbolico in mods-enabled

Testate la configurazioe e se non avete errori riavviate apache:

#apachectl -t

#apachectl graceful

Se vi aspettavate quacosa come “stop”, “start” o “restart” sappiate che il comando “graceful” esegue un reload delle configurazione di apache come restart ma senza far cadere le sessioni in piedi (buttando fuori dal vostro sito eventuali utenti connessi), un’altra buona abitudine…

Ok adesso dobbiamo abilitare https su un virtual host, diciamo che i ceritificati SSL sono già pronti (se non sono leggete qui per sapere come prepararli) e che pippo.it deve avere una sezione SSL, bene potete spostarvi nella cartella /etc/apache2/sites-avaible copiare il file pippo.it in pippo.it-ssl, (1 file per sito).

Ora aprite pippo.it-ssl e modificate tutti i “:80″ che trovate in “:443″ (dovrebbero essere 2):

NameVirtualHost develop.rmsoft.net:80
<VirtualHost develop.rmsoft.net:80>

diventa

NameVirtualHost develop.rmsoft.net:443
<VirtualHost develop.rmsoft.net:443>

Adesso dobbiamo solo aggiungere i comandi che attivano SSL e che specificano quali certificati SSL deve usare per questo virtual host

Io per comodità creo una cartella “ssl” all’interno di “/etc/apache2″ nella quale raccolgo icertificati sito per sito (es: /etc/apahe2/ssl/pippo.it/server.crt)

Quindi se avete chiave e certificato potete aprire pippo.it-ssl ed aggiungere queste righe proprio sotto la riga “DocumentRoot”

SSLEngine on
SSLOptions +StrictRequire
SSLCertificateFile /etc/apache2/ssl/pippo.it/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/pippo.it/server.key

Facendo attenzione a non sbagliare i nomi dei file del certificato e della chiave.

Siete pronti per l’ennesimo “apachectl -t”, e se non ci sono errori “apachectl graceful”…

Questo articolo fa riferimento a quella ufficiale potete trovare qui con lo scopo di chiarirla ed ampliarla.

Innanzi tutto dobbiamo chiarire cos’è un certificato SSL. É un “certificato digitale” ovvero un documento elettronico che associa l’identità di una persona ad una chiave pubblica. Per essere valido questo certificato deve essere controfirmato da una Autority, che lo rende valido inequivocabilmente. I browser sono attrezzati per verificare istantaneamente la validità. Questo certificato serve a garantire la provenienza della chiave SSL che proteggerà le vostre comunicazioni https. Un certificato firmato da una Autority costa intorno ai 30 dollari all’anno ma vi servirà solo se avete un server di produzione, infatti il vostro certificato potete controfirmarlo da soli! Certo i browser storcerannl il naso segnalando il sito come non sicuro… Ma tanto sul vostro server di sviluppo potete fare ciò che volete giusto?

Nell’altro articolo spiego i vantaggi della configurazione “anomala” di apache2 in Ubuntu, uno di questi è senz’altro la possibilità di avere più certificati SSL autofirmati per più virtual hosts diversi in maniera semplice e ordinata. Spostatevi nella cartella “/etc/apache2/ssl” ( se non esiste createla) e create una nuova cartella “pippo.it” (pippo.it è il sito di prova cui abbiamo fatto riferimento nell’articolo sui virtual hosts) e spostatevi nella cartella appena creata.

Il programma che useremo per creare i certificati è openssl, se non lo avete installato:

#apt-get install openssl

lo installa e quindi siampo pronti per generare una chiave:

#openssl genrsa -out server.key 1024

Generating RSA private key, 1024 bit long modulus
………………..++++++
…++++++
e is 65537 (0×10001)

Semplicissimo:

• openssl è il programma che genera le chiavi
• genrsa dice a openssl che deve generare una chiave privata di tipo RSA
• -out server.key questo paramentro serve a salvare in un file (server.key appunto) la chiave generata
• 1024 è il parametro che serve a definire la lunghezza della chiave appunto 1024 bit (di default sarebbero 512)

Se volessimo rendere ancora più sicura la chiave potremmo aggiungere una passphrase ossia una password casesensitive di almeno 4 caratteri (ma se ne consigliano almeno8) per proteggerne l’uso, aggiungendo il comando -des3 (vedi triple DES):

#openssl genrsa -des3 -out server.key 1024

Così facendo vi verrà richiesta la passphrase ad ogni passaggio successivo, compreso l’avvio di apache. Sicuro si ma anche scomodo se dovrete riavviare spesso il vostro server (che abbiamo definito di sviluppo…).

Ora useremo la chiave appena creata per generare file CSR (certificate signing request):

# openssl req -new -key server.key -out server.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [AU]:

Rispondete alle semplici domande che vi vengono poste avrete il vostro file server.csr

Analizziamo il comando:

• openssl è sempre lui!
  
• req dice a openssl che vogliamo generare un file CSR
• -new questo paramentro serve a generare un file csr da zero, se lo doveto rinnovare potete ometterlo e non vi saranno richiesti i dati riguardanti la vostra identità
• -key server.key specifica la chiave collegata al certificato (server.key appunto)
• -out server.csr salva il file generato nel file server.csr

Ora potreste inviare il certificato appena generato server.csr ad una CA (Certificate authority) perchè lo verifichi e lo controfirmi oppure controfirmarlo da soli… Ma come abbiamo già detto lo controfirmeremo da soli… Come?

#openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Analizziamo anche questa linea di comando:

• openssl ancora lui!
  
• x509 il comando che ci ci permette di generare il file .crt (il certificato)
• -req specifica in un certificato la nostra richiesta
• -days 365 specifica in giorni la durata del certificato
• -in server.csr specifica da quale richiesta deve essere generato il certificato
• -signkey server.key specifica la chiave collegata
• -out server.crt specifica in quale file deve essere salvato il certificato

Abbiamo finito: chiave generata, certificato firmato… naturalmente ora dovrete farlo capire al vostro browser ma vedrete che non sarà difficile

la reazione tipica di firefox è questa:

ma basta cliccare su “Oppure è possibile aggiungere un’eccezione”

quindi “Aggiungi eccezione”

e “Acquisisci ceritificato”, dopo averlo acquisito se non siete sicuri di quello che state dacendo potete visualizzare i dettagli del certificato

Se finalmente siamo sicuri possiamo cliccare su “Conferma eccezione di sicurezza” e finalmente avremo accesso al nostro sito https!

Esperimento riuscito!