Purtroppo in Etch il praticissimo comando apache2-ssl-certificate è scomparso ma ciò non ci impedisce di creare il nostro bel certificato per Apache con openssl, infatti con questa lunghissima istruzione:

openssl req $@ -new -x509 -days 365 -nodes -out /etc/apache2/apache.pem -keyout /etc/apache2/apache.pem

otterremo lo stesso risultato del defunto apache2-ssl-certificate.

Adesso serve editare il file ports.conf per dire al demone di mettersi in ascolto anche sulla porta 443 e creare un file di configurazione per l’host in https che contiene, oltre alle normali direttive, anche:

SSLEngine on
SSLCertificateFile /etc/apache2/apache.pem

Basta abilitare con il vhost tramite l’ancor presente a2ensite ed ecco pronto il nostro https.

Qualcuno sa perché apache2-ssl-certificate è stato deprecato? Chiederò a quelli di “Chi l’ha visto?“.

Volevo fare una piccola riflessione su ciò che è descritto nell’articolo “Le sessioni PHP che scompaiono…” redatto da me pochi giorni fa.

Quando le applicazioni vengono portate al limite l’hardware viene sollecitato e stressato, quindi ci si accorge di aver oltrepassato il confine e si è un tantino spaesati.

Dico questo perché non è facile capire che il problema è l’hard-disk se PHP perde la sessione visto che il file viene correttamente scritto ma poi rimane immutato durante la navigazione delle pagine.

Ho pensato ad altri problemi, alcuni forse inverosimili, ma ciò che è successo ha aggiunto un capitolo alla mia esperienza e mi fa riflettere.

Read the rest of this entry »

Chi usa Debian conosce bene la versatilità e la forza del gestore dei pacchetti integrato nella distribuzione ma può capitare che ci siano dei software che o per licenza o per altre scelte non vengono impacchettati.
Questo è successo a me con l’addons di Asterisk.

Read the rest of this entry »

Tanto tempo fa l’informatica era 0 o 1.
Adesso fa come vuole tantè che in un server web, PHP riusciva a scrivere il file di sessione ma poi non poteva più aggiornarlo con i nuovi valori, il tutto senza errori o anomalie.
Il problema? L’hard-disk!
Mi è venuto in mente di cambiare il path del file di sessione tramite questa direttiva:

ini_set("session.save_path","nuovo_path");

Eh meravigliosamente tutto ha funzionato…
Evidentemente la porzione di filesystem usata /var/lib/php5 ha qualche problema.
Adesso l’hard-disk è stato spostato da primario a secondario nell’array RAID e pare che tutto funziona.

Staremo a vedere.

Ecco il video della notiza riportata da Punto-Informatico riguardo alla possibilità di far passare XUbuntu per Windows quando si effettua il test di autenticità presso il sito Microsoft.
L’intera notiza la si può trovare qui.

Ogni computer ha un orologio hardware che grazie alla batteria presente sulla scheda madre permette di tenere traccia del tempo anche a PC spento.

Il kernel di Linux ha, a sua volta, un altro orologio che si allinea a quello hardware in fase di avvio e poi scandisce il tempo indipendentemente tantè che se si cambia l’ora in Linux e si riavvia ci si ritrova con l’ora del PC e non con quella settata dal sistema operativo.

Una cosa da tenere sempre presente è che il kernel usa l’ora internazionale, ovvero quella relativa al meridiano di Greenwitch. L’orologio HW può essere sincronizzato con l’ora locale oppure anch’esso con l’ora internazionale. Se la macchina viene avviata anche con sistemi operativi diversi da Linux, probabilmente l’orologio HW è sincronizzato con l’ora locale, altrimenti ci sono molti più vantaggi ad usare l’ora internazionale anche per l’orologio HW.

Questo perché lavorando il kernel con l’ora internazionale, ogni richiesta di lettura dell’ora locale viene filtrata tramite la libreria principale (libc6) ed elaborata calcolando il fuso orario e la presenza dell’ora legale. Se anche l’orologio HW è sincronizzato con l’ora internazionale non serve neanche cambiare l’ora in concomitanza con il cambio dell’ora legale.

Read the rest of this entry »

In una normale richiesta web il server restituisce le informazioni riguardanti se stesso e sul sistema su cui è in esecuzione tramite la direttiva ServerTokens presente nell’header di risposta.

Questa informazione è ancor più visibile se si richiedono URL errati ed il server risponde con qualcosa del tipo:

Not Found

The requested URL /jkdnksdj/index.php was not found on this server.

---

Apache/2.2.3 (Debian) PHP/5.2.0-8+etch4 Server at www.ideafactory.it Port 80

La stringa riporta la versione del server in uso, il sistema operativo, l’abilitazione di PHP ed altri dati un pò meno importanti.

Per non espletare troppo la propria configurazione è bene impostare la variabile ServerTokens presente nel file di configurazione di Apache.

Read the rest of this entry »