E’ importante chiarire che non stiamo parlando del re-indirizzamento DNS del dominio o del subdominio: se raggiungiamo una pagina in entrambi i modi (sia col prefisso www che senza) significa che il servizio DNS è configurato correttamente. I server DNS provvedono a risolvere il nome verso lo stesso server, perciò “tutto va bene” dal punto di vista dell’ipotetico visitatore. Le cose cambiano dal punto di vista dei motori di ricerca. Una prova molto semplice potrebbe essere quella di confrontare due modi di scrivere l’URL di AziendeItalia

http://aziendeitalia.com

http://www.aziendeitalia.com

dopo aver verificato di raggiungere la stessa pagina in ambo i casi, è interessante osservare cosa succede nella barra dell’indirizzo del browser. I casi sono due

1. Dopo aver caricato la pagina entrambi gli indirizzi restano invariati
2. Dopo aver caricato la pagina uno degli indirizzi si allinea automaticamente all’altro

le due situazioni sono indifferenti dal punto di vista dell’utente, ma impattano il Page Rank della pagina: se gli indirizzi restano invariati, un ipotetico motore di ricerca che sta seguendo un link alla pagina, o analizzando il sito, tratterà i due indirizzi come casi distinti. Ad esempio, se 10 link puntano alla pagina senza www, e 10 link puntano alla pagina con www, lo scenario 1 significa che il motore di ricerca conterà 10 link (e non 20) per ciascuno dei due indirizzi. Nello scenario 2, invece, grazie alla correzione automatica dell’indirizzo, il motore di ricerca conterà 20 link totali.

L’esempio dovrebbe spiegare perché, nonostante il DNS risolva correttamente entrambi gli indirizzi, il fatto di avere due URL equivalenti (ma distinti) riduca l’efficacia del SEO. Se ci troviamo nello scenario 1, possiamo usare un tool per capire come vengono divisi i “punteggi” del motore di ricerca.

Un problema di questo genere si risolve scegliendo uno dei due indirizzi, probabilmente quello più “gettonato” dei due, e decidere che tale indirizzo diventerà il riferimento canonico al nostro server. Si potrebbe poi pensare di “educare” tutte le persone che referenziano il sito, chiedendo loro di usare solo l’indirizzo canonico. Da un punto di vista tecnico la cosa funzionerebbe, ma non è questa la soluzione: un domani nuovi e numerosi link (ci auspichiamo) potrebbero puntare al nostro sito, e non possiamo certo prenderci la briga di comunicare a tutti, o pretendere da tutti, di aggiornare il link che abbiamo scelto come indirizzo canonico.

Un’ottima soluzione, molto più semplice ed indolore, ci viene offerta dallo stesso protocollo HTTP, che offre la possibilità del redirect HTTP 301.

Per capire il funzionamento del redirect HTTP 301 possiamo controllare l’header HTTP delle risposta tramite i comuni strumenti di sviluppo web, come ad esempio Firebug. Considerando come esempio il dominio aziendeitalia.com, proviamo a raggiungere il sito usando i due indirizzi (con www e senza www) e confrontare i risultati. Nel caso dell’indirizzo con il prefisso www abbiamo

Esempio di HTTP 200

mentre senza il prefisso www risulta

dal confronto emerge che il dominio canonico (o authoritative domain) per il sito di AziendeItalia è quello con il prefisso www: se digitiamo l’indirizzo senza tale prefisso riceviamo la risposta “HTTP 301 Moved Permanently”, che serve proprio a risolvere il problema in oggetto: la risposta HTTP 301 significa che l’indirizzo richiesto è stato spostato altrove, specificando dove ridirigere le richiesta. Subito dopo questa risposta, infatti, abbiamo (vedi figura qui sopra) una nuova richiesta HTTP GET verso il dominio canonico (www.aziendeitalia.com), con esito HTTP 200, che significa “tutto ok”.

Il caso appena visto è un buon esempio di utilizzo del redirect HTTP 301: grazie al re-indirizzamento, qualsiasi sia l’indirizzo, ogni volta che raggiungiamo il sito di AziendeItalia siamo indirizzati (alla fine delle transazione HTTP) verso il dominio corretto. Ciò accade, tra l’altro, anche quando il sito viene analizzato dai motori di ricerca, che grazie a questo stratagemma indicizzano solamente il dominio canonico.

Per realizzare il redirect basta aggiungere alcune righe al file .htaccess presente nella root del sito. Se non abbiamo mai usato un file .htaccess, possiamo crearne uno nuovo, che conterrà solamente le righe qui sotto. Se non sappiamo cos’è un file .htaccess, e vogliamo saperne di più, possiamo leggere l’articolo introduttivo all’argomento.

Per realizzare il redirect di un ipotetico indirizzo www.prova.org, verso l’indirizzo prova.org, le righe da inserire nel file .htaccess sono

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^www.prova.org [NC]
RewriteRule ^(.*)$ http://prova.org/$1 [L,R=301]

Ovviamente, per ottenere lo stesso risultato su un altro sito, occorre sostituire le stringhe www.prova.org e prova.org con quelle del dominio in questione.

Esistono in realtà modi diversi di realizzare il redirect, usando sempre il modulo rewrite di Apache: questa libertà è dovuto alla flessibilità delle regole di rewrite, che possono essere scritte in maniera differente pur realizzando lo stesso risultato. Poiché il funzionamento di un file .htaccess dipende dalla politica del provider, il fatto di poter scrivere le regole del redirect in modi diversi dovrebbe aiutarci a trovare la “giusta sintassi” per il “giusto provider”. Se l’esempio qui sopra non dovesse funzionare, non scoraggiamoci e cerchiamo altri esempi di “redirect HTTP 301”: l’argomento è abbastanza popolare e la ricerca sul web offre numerosi esempi di sintassi alternativa.

Se abbiamo modificato qualche traduzione, dal menù principale clicchiamo sul Utilità – Traduzioni. Nella sezione Esporta una lingua selezioniamo la lingua e il tema corrente, poi clicchiamo su Esporta.

Come ultima precauzione, disabilitiamo momentaneamente il negozio: dal menù Preferenze – Abilita negozio spuntiamo la voce “no”. Subito sotto, nel campo Indirizzo IP di manutenzione, inseriamo il nostro IP corrente (trova IP), allo scopo di poter accedere al negozio per le verifiche necessarie. Se lavoriamo in locale inseriamo l’indirizzo 127.0.0.1.

Scarichiamo la nuova versione (in formato compresso), estraiamo i files e rinominiamo la cartella

/prestashop/admin

con il nome della nostra cartella di amministrazione (quella che usiamo per entrare nel backend). D’ora in poi faremo riferimento a questa nuova copia di PrestaShop come la “nuova versione”. Durante la procedura avremo quindi due istanze di PrestaShop: quella vecchia, che non toccheremo mai, e quella nuova (estratta dallo ZIP), che dovremo trasformare in una nuova versione funzionante.

1° step: procedura manuale

Copiamo la cartelle del nostro backup dentro le cartelle delle nuova installazione. Le cartelle da copiare sono:

• img: immagini di categorie e prodotti, sovrascrivendo il contenuto della cartella img della nuova versione, in modo da mantenere le nostre immagini
• modules: i moduli aggiunti dopo l’installazione, sovrascrivendo il contenuto della cartella modeles della nuova versione. Se abbiamo installato PrestaShop con tutti i moduli di default, e non abbiamo mai aggiunto alcun modulo, possiamo saltare questo passaggio. Se non siamo sicuri che i moduli siano compatibili con la nuova versione, conviene disinstallarli (disabilitarli senza disinstallarli potrebbe essere inutile)
• themes/<nome>: copiamo solamente il tema che stiamo utilizzando. Se usiamo il tema di default (i.e. Prestashop) saltiamo questo passaggio, ovvero non portiamo il vecchio tema nella nuova installazione. Altrimenti è bene verificare che il tema sia compatibile con la nuova versione prima di procedere con l’aggiornamento, usando l’apposito tool online (con istruzioni in inglese). Se il tema non è compatibile conviene disabilitarlo (tornando su quello di default) prima di proseguire, e ripristinarlo al termine dell’aggiornamento (scaricandone l’ultima versione)

Se abbiamo personalizzato manualmente alcune pagine, probabilmente dovremo copiare anche le cartelle mail, download e upload: se invece non abbiamo mai toccato queste cartelle, possiamo evitare di copiarle nella nuova versione.

Dalla cartella config copiamo solamente il file settings.inc.php, facendo attenzione ai soliti parametri (gli stessi che dobbiamo tenere d’occhio in caso di migrazione).

__PS_BASE_URI__ : il percorso rispetto alla root di Apache, ad esempio ilmiosito

_DB_NAME_: il nome del database

_DB_SERVER_: l’host del dabase, probabilmente localhost

 La cartella classes merita una trattazione a parte: se abbiamo aggiunto classi nuove, non previste da PrestaShop, ci toccherà editarle a mano e cambiare tutti i nomi, per appendere il suffisso Core. Ad esempio, la classe Pippo andrà rinominata come PippoCore. Quest’operazione va effettuata solo sui nomi delle classi, non sui nomi dei files PHP che le contengono.

2° step: wizard di aggiornamento

A questo punto apriamo il browser per raggiugere il wizard di aggiornamento. Se lavoriamo in locale ci colleghiamo ad un indirizzo del tipo

http://localhost/prestashop/install/

Nella prima pagina spuntiamo la casella Voglio aggiornare il mio PrestaShop, nella seconda confermiamo di aver fatto il backup dell’installazione precedente. Se il wizard ci segnala che i parametri del server sono insufficienti (ad esempio max_execution_time), provvediamo a modificare il parametro nel file .htaccess (o il file php.ini se siamo in locale) e rilanciamo il wizard dall’inizio.

Al termine del processo ci verrà detto se sono avvenuti errori. In caso di errori SQL dobbiamo copiare il rapporto completo (cliccando su visualizza rapporto) e cercare l’errore. Questo potrebbe essere piuttosto noioso, perché non sapendo cosa cercare, probabilmente dovremo scorre l’intero file. A titolo d’esempio, un possibile errore potrebbe essere

(1048) Column 'id_module' cannot be null

Per risolvere gli eventuali problemi SQL dobbiamo identificare la risorsa che genera l’errore (ad esempio il modulo pagesnotfound) e provare a rimuovere, installare o re-installare la risorsa (in questo caso il modulo Pagina non trovata). Se gli errori non sono bloccanti, possiamo ugualmente concludere l’installazione: ciò significa cancellare la cartella install e i file readme*.txt e CHANGELOG (nella cartella doc).

3° step: validazione

Per validare l’aggiornamento di PrestaShop eseguiamo alcune operazioni nel backend:

• Dal menù principale clicchiamo sul Utilità – Traduzioni. Nella sezione Importa una lingua manualmente importiamo la traduzioni esportate all’inizio della procedura
• Verifichiamo nel menù Preferenze – SEO & URLs che i valori PS directory e Nome di dominio del negozio siano corretti
• Rigeneriamo il file .htaccess dal menù Utilità – Generatori, cliccando su Crea un file “.htaccess”

La validazione dell’aggiornamento dovrebbe includere alcuni test funzionali, che potrebbero essere: navigare le sezioni del sito; creare un account utente; fare un ordine; fare un prova di pagamento; verificare (nel backend) che l’ordine sia ricevuto; mandare una mail dalla pagina dei contatti; controllare la fatturazione della vendita; controllare i moduli. Se abbiamo poco tempo, e l’aggiornamento sembra andare a buon fine in locale, probabilmente conviene effettuare i test live, ed intervenire in modo specifico solo dove serve.

Per ulteriori informazioni possiamo consultare la guida completa all’aggiornamento.

Un modo di ridurre il problema è quello di creare un ambiente di lavoro locale il più possibile simile a quello remoto. Una delle prime operazioni in questa direzione è la consistenza degli indirizzi locali rispetto a quelli remoti. Molto spesso capita di lavorare in locale su un indirizzo come

http://localhost/prova.com/

e di volerlo farlo funzionare in remoto come

http://prova.com/

Una situazione di questo tipo rappresenta un possibile problema: se la nostra applicazione utilizza una riscrittura dinamica degli indirizzi (rewrite di Apache), o semplicemente gestisce le pagine in base alla posizione rispetto alla root del server, una discrepanza come quella qui sopra potrebbe creare dei fastidi al momento del deploy in remoto. Una buona soluzione, per tutti i problemi di questo tipo, è la configurazione di un Virtual Host in locale.

Abbiamo già visto come configurare un Virtual Host nel caso di Apache2 (su Linux). Oggi vedremo come compiere la stessa operazione su Windows, facendo riferimento all’installazione di Apache tramite il pacchetto XAMPP.

Configurazione dell’host virtuale

Il primo passo è la creazione del Virtual Host in Apache. Cerchiamo il file httpd-vhosts.conf, che dovrebbe trovarsi all’interno della cartella

<Installazione di XAMPP>\apache\conf\extra

e facciamone una copia di backup per sicurezza (chiamandola ad esempio httpd-vhosts.original.conf). Dopodiché apriamo il file con un editor qualsiasi (su Windows consigliamo Notepad++) e scommentiamo la riga

# Use name-based virtual hosting.

NameVirtualHost *:80

in questo modo abilitiamo il riconoscimento degli host virtuali in base al nome presente nell’URL, ovvero in base al nome del dominio (in questo caso virtuale). Alla fine del file inseriamo invece le righe

<VirtualHost *:80>

ServerName localhost

DocumentRoot "C:\Apps\xampp\htdocs"

</VirtualHost>

<VirtualHost *:80>

ServerName prova.com

DocumentRoot "C:\Apps\xampp\htdocs\prova"

<Directory "C:\Apps\xampp\htdocs\prova">

Order allow,deny

Allow from all

</Directory>

</VirtualHost>

cambiando ovviamente i riferimenti alla directory prova. La prima sezione dice ad Apache di continuare a lavorare come prima quando scriviamo http://localhost nel browser: se omettiamo questa sezione non vedremo più le pagine deployate nella cartella htdocs. La seconda sezione è quella che ci interessa, e serve ad associare l’host virtuale prova.com alla cartella locale C:\Apps\xampp\htdocs\prova (o l’equivalente percorso locale).

Configurazione del file host

La modifica vista sopra è sufficiente per creare un host virtuale, in questo caso prova.com. Rimane però una cosa da fare: se non abbiamo registrato il dominio prova.com, il browser non sarà capace di raggiungere l’Apache locale. Viceversa, se abbiamo già registrato prova.com, molto probabilmente digitando http://prova.com finiremo (giustamente) sul server remoto e non sull’istanza locale.

Il modo più semplice di costringere la nostra macchina (e solo lei) a raggiungere l’Apache locale usando lo stesso URL di produzione è tramite il file hosts, che su Windows dovrebbe trovarsi qui

C:\WINDOWS\system32\drivers\etc\hosts

apriamo il file con i permessi di amministratore e inseriamo la riga

127.0.0.1 prova.com

L’istruzione dirà a Windows che qualunque richiesta verso l’host prova.com va risolta sull’indirizzo IP 127.0.0.1, ovvero quello della nostra macchina locale.

Questo è tutto. Dopo aver riavviato Apache, ogni volta che scriveremo http://prova.com vedremo le pagine dell’Apache locale, e potremo navigare con gli stessi indirizzi della versione remota del sito (o applicazione). Ricordiamoci che la modifica nel file hosts ci impedirà di raggiungere il sito remoto (quello “reale”): per vedere di nuovo le pagine del sito remoto basta commentare la riga inserita nel file hosts, senza toccare (né riavviare) Apache. Il file hosts riguarda il comportamento del sistema operativo, non gli applicativi installati sulla macchina (come ad esempio Apache).

Se qualcosa va storto, o non funziona, verifichiamo che nel file httpd.conf non sia commentata l’istruzione

Include "conf/extra/httpd-vhosts.conf"

altrimenti Apache non degnerà di interesse le modifiche nel file httpd-vhosts.conf.

Oggi proveremo a fare un po’ di chiarezza sui diversi protocolli utilizzati per gestire la posta elettronica, allo scopo di fornire le competenze di base che dovrebbero rendere meno ostica la configurazione di un client di posta. Questa conoscenze ci serviranno, tra l’altro, a capire meglio i meccanismi di accesso alle caselle di posta di una VPS, oppure al servizio BCMail di AziendeItalia.

Introduzione

Il servizio di posta elettronica è un esempio di architettura client-server. Qualsiasi sia il protocollo utilizzato, o il programma usato per leggere la posta, da qualche parte abbiamo un server di posta che comunica con il client locale. Quest’ultimo può essere un client tradizionale, come ad esempio Outlook, oppure un browser (se usiamo la webmail). Vi sono molte differenze tra i vari client, ma questo lascia inalterata l’architettura di base: in tutti i casi la posta viene gestita dal server e l’utente vi accede tramite un programma client. A seconda del protocollo, e quindi della modalità di lavoro, cambiano alcune funzionalità, come vedremo caso per caso.

Accesso via POP e SMTP

L’accesso alla posta elettronica attraverso i protocolli POP e SMTP può essere considerato il modo tradizionale di consultare l’e-mail. Il client scarica i messaggi dal server mediante il protocollo POP (Post Office Protocol), detto anche POPmail. Ogni volta che il client controlla la posta in arrivo viene aperta una connessione POP tra client e server, che resta aperta mentre viene scaricata la posta, e chiusa al termine del processo. Questo non implica che i messaggi vengano cancellati dal server: è possibile configurare l’accesso POP in modo da mantenere una copia dei messaggi sul server anche dopo averli scaricati. Quando viene spedita la posta, il cliente apre una connessione SMTP (Simple Mail Transfer Protocol)verso il server, il quale si occupa di ricevere la posta e occuparsi della consegna.

Protocolli di posta

Accesso via HTTP

E’ la modalità di lavoro via webmail. Il ruolo del client viene svolto da un browser, che consulta le pagine di una web application installata sul server remoto. La comunicazione in questo caso è sostanzialmente identica alla normale navigazione su internet: da un punto di vista tecnico non c’è differenza tra consultare la mail via browser o accedere ad una qualsiasi altro servizio autenticato. Ovviamente, nella maggioranza dei casi, la comunicazione client-server della webmail avviene in modalità sicura, attraverso il protocollo HTTPS anziché HTTP, ma le differenze riguardano le modalità di trasporto (SSL) e non ci interessano in questa sede.

Trattandosi di una normale navigazione su internet, i contenuti visualizzati nel browser sono presenti in locale solamente in qualità di risorse del browser. Possiamo lavorare offline, salvare le pagine della mail o rivedere la posta già consultata al termine del collegamento, ma non possiamo visualizzare il contenuto di una mail qualsiasi, come ad esempio una mail di cui abbiamo letto solo l’oggetto: ogni “e-mail” viene trattata come una pagina web, pertanto non viene scaricata in un formato gestibile localmente, ma è presente solamente tra i files temporanei del browser.

Accesso via IMAP e SMTP

E’ una delle modalità di lavoro più moderne. La trasmissione della posta avviene sempre via SMTP, come nel caso tradizionale (vedi sopra). La ricezione avviene invece attraverso il protocollo IMAP (Internet Message Access Protocol), che in linea di massima assomiglia al precedente POP, ma offre alcune interessanti novità:

• Connessione persistente: un client IMAP non si disconnette dal server dopo aver scaricato la posta, ma rimane connesso. Questo permette di realizzare le funzionalità sottoelencate
• Sincronizzazione degli attributi: grazie alla persistenza della connessione client-server, il client può notificare al server qualsiasi cambiamento locale. Quando l’utente legge una mail, assegna un’etichetta o sposta la mail in una cartella, queste operazioni vengono comunicate al server. In questo modo sul server sono sempre presenti tutte le informazioni relative alla posta elettronica: differenze tra messaggi letti e da leggere, etichette, commenti, risposte e qualsiasi altro attributo della posta elettronica
• Molteplicità di utenti e client: la sincronizzazione degli attributi tra client e server permette di utilizzare la stessa casella di posta tra utenti diversi, o tra programmi client diversi, anche contemporaneamente. Esempio: posso accedere alla posta via Thunderbird e col browser nello stesso istante, e lavorare su entrambi i client. Quando leggerò un messaggio con Thunderbird vedrò cambiare lo stato della mail anche nel browser, e viceversa. Potrei anche accedere alla stessa casella di posta via smartphone, spostare la mail in una nuova cartella, et voilà: il cambiamento si rifletterà anche su Thunderbird e nel browser.

Esistono altre differenze tra i protocolli POP e IMAP, ma quelle elencate qui sopra sono probabilmente le più importanti dal punto di vista dell’utente. Il supporto del protocollo IMAP, da parte di un server di posta, permette un uso più flessibile e moderno della posta elettronica, trasformando i client di posta in una sorta di thin client e delegando al server il compito di memorizzare le modifiche operate dall’utente. Nelle prossime puntate vedremo alcuni esempi di configurazione delle interfacce IMAP e SMTP, con particolare attenzione ai servizi di posta offerti da AziendeItalia.

http://www.aziendeitalia.com/pagina.html

in questo caso, esemplificando, possiamo pensare alla prima parte dell’indirizzo come l’URL (http://www.aziendeitalia.com), alla seconda parte come l’URN (pagina.html) e all’insieme delle due (l’intero indirizzo) come all’URI. Abbiamo detto “esemplificando” per evitare di entrare nei dettagli, altrimenti le differenze tra URI e URL diventerebbero piuttosto sfumate, rischiando di fare confusione. Per quello che ci interessa possiamo benissimo pensare all’URL come all’indirizzo comune di un gruppo di risorse, per certi versi analogo al concetto di cartella o directory, mentre l’URN assomiglia al concetto di nome di un file o di un documento. Ecco perché servono entrambi (URL e URN) per definire un URI, che può essere pensato come il percorso completo (cartella più nome del file) di una generica risorsa sul web.

L’esempio appena visto dovrebbe spiegare perché è diffusa la pratica di considerare sinonimi URI e URL: da un punto di vista pratico un URL è anche un URI, perché di fatto rappresenta il nome completo di una risorsa. Se scrivessimo infatti

http://www.aziendeitalia.com

potremmo pensare di avere scritto solamente un URL, e non un URI, perché manca il nome della pagina (cioè l’URN). In realtà, siccome l’indirizzo qui sopra identifica comunque una risorsa, che in questo caso è la pagina di benvenuto di AziendeItalia, è lecito parlare di URI.

Encoding degli indirizzi

Dopo aver chiarito le (sottili) differenze tra URL e URI, possiamo affrontare la questione che ci interessa: l’encoding degli indirizzi. Consideriamo gli indirizzi

http://prova.com/domanda/pagina?n=5

http://prova.com/?/pagina?n=5

il primo caso è semplice: si tratta di una richiesta HTTP GET inviata alla risorsa domanda/pagina, passando il parametro n, con valore 5. Nel secondo caso stiamo immaginando che l’ipotetico sviluppatore del sito prova.com abbia pensato di abbreviare l’indirizzo, usando il simbolo “?” al posto della stringa domanda.

Si tratta ovviamente di una pessima idea, ed il motivo dovrebbe essere chiaro: come può il server, al momento di ricezione della richiesta, capire che non stiamo passando un parametro di nome /pagina?n con valore 5? In altre parole, la seconda richiesta potrebbe essere interpretata come: “voglio invocare l’indirizzo http://prova.com/ passando il parametro /pagina?n, e assegnando il valore 5 a questo parametro.”

Per evitare ambiguità di questo tipo si è ricorsi all’encoding di alcuni caratteri riservati. Ciò significa che all’interno di un URL o di un URI non è possibile usare liberamente tutti i caratteri, ma dobbiamo ricordarci che alcuni caratteri hanno un significato speciale. Alcuni di questi caratteri sono

 ! * ' ( ) ; : @ & = + $ , / ? # [ ]

procedere con la codifica (encoding) di questi caratteri significa rappresentarli in modo alternativo, in questo caso usando il loro codice ASCII preceduto dal carattere % (percentuale). In questo modo l’indirizzo ambiguo scritto sopra potrebbe diventare

 http://prova.com/?%2Fpagina%3Fn=5

questo perché, nella codifica convenzionalmente accettata degli URL, il carattere riservato / (slash) diventa %2F, mentre il carattere riservato ? (punto di domanda) diventa %3F.

Un’ottima domanda, a questo punto, potrebbe essere: quando dobbiamo utilizzare l’encoding di un URL o di un URI? La risposta è: quando vogliamo usare un carattere riservato per uno scopo particolare, attribuendogli un significato speciale. Questo è esattamente quello che abbiamo fatto sopra: siccome volevano usare i caratteri / e ? come parte del nome della risorsa (/pagina?n), abbiamo dovuto codificare i caratteri per evitare ambiguità.

Il problema inverso

L’encoding degli URL risolve i problemi di ambiguità, e ci permette di usare tutti i caratteri liberamente, anche quelli riservati, previa la loro codifica. Esiste però un possibile problema: in alcuni casi un indirizzo viene codificato per altri motivi (ad esempio per essere scritto in un database), e quando viene proposto come link potrebbe avere una forma del genere

 http://prova.com/pagina.php%3Fn%3D5

se copiamo l’iindirizzo qui sopra nella barra del browser, probabilmente non raggiungeremo alcuna pagina. L’indirizzo corretto, in questo caso, potrebbe essere quello decodificato

 http://prova.com/pagina.php?n=5

 un modo semplice e veloce di decodificare l’indirizzo potrebbe essere quello di usare l’apposita funzione JavaScript, ovvero

 unescape(“http://prova.com/pagina.php%3Fn%3D5”);

 che fornisce come risultato

 http://prova.com/pagina.php?n=5

 Ovviamente JavaScript fornisce anche la funzone escape(), che permette di codificare una generica stringa. Ricordiamoci di queste due funzioni tutte le volte che dobbiamo maneggiare un URL o un URI, perché sono spesso il modo più semplice di gestire qualsiasi esigenza di codifica.

Con questo articolo vogliamo fornire al lettere le poche basi teoriche che servono per capire cosa sta dietro frasi come “assegnare i permessi 755” oppure “verificare che le cartelle abbiamo i permessi 644”, le quali utilizzano la notazione ottale. Si tratta di una notazione molto semplice, che ci permetterà di prendere due piccioni con una fava: nell’apprendere la notazione ottale impareremo anche a leggere a colpo d’occhio i numeri espressi in base binaria.

Gli unici requisti necessari, prima di proseguire la lettura, sono le conoscenze base di Linux relative alla gestione degli utenti, dei gruppi e dei permessi. Chi non conoscesse l’argomento può trovare alcuni spunti qui:

• Linux Quick Start
• Il comando chmod
• I gruppi utenti
• Priorità dei permessi

Cenni teorici

La notazione ottale è semplicemente un modo abbreviato di esprimere una cifra binaria. Se non conosciamo il sistema numerico binario possiamo dare un’occhiata qui, ma i concetti sono talmente semplice che, in virtù della completezza di questo articolo, possiamo riassumerla in poche righe. Per contare in binario basta fare quello che facciamo, senza rendercene conto, quando leggiamo una cifra scritta in base decimale (il sistema numerico che usiamo tutti i giorni). Ad esempio, la cifra 125 può essere scritta come

125 = 1*100 + 2*10 + 5*1

in altre parole, sappiamo tutti che la cifra 125 è composta da 1 centinaio, 2 decine e 5 unità. Trattandosi di un sistema in base 10, in termini matematici si usa dire che i “pesi” delle varie cifre (le cifre sono i simboli 1, 2 e 5) sono, rispettivamente, 10², 10¹ e 10⁰. Se non conosciamo le potenze, o non ci piace la notazione 10ⁿ, nessun problema: impariamo (come fanno tutti) a memoria la sequenza 1, 10, 100, 1000 ecc. ed il gioco è fatto. Se ci pensiamo un attimo, lo facciamo tutti i giorni, ogni volta che leggiamo una qualsiasi cifra numerica.

In binario abbiamo la stessa cosa, con un’unica differenza: la sequenza “da imparare a memoria” non è più 1, 10, 100, 1000 bensì 1, 2, 4, 8, 16 ecc… Se ci piace giocare con le potenze possiamo ricordare la sequenza come “le potenze di 2”, altrimenti va benissimo ricordarla col metodo che preferiamo.

Questo è tutto. Basta ricordare la sequenza per tradurre qualsiasi cifra binaria. Ad esempio

101 = 1*4 + 0*2 + 1*1

L’unica “stranezza”, rispetto a prima, è che dobbiamo fare la somma per capire di che numero si tratta (in questo caso 5). In realtà non c’è nulla di strano, anche prima abbiamo fatto la somma, ma senza rendercene conto, perché lo facciamo tutti i giorni. Una volta capito il meccanismo, ci accorgeremo che il sistema binario fa ormai parte della vita quotidiana. Non è un caso che le memorie RAM siano passate da 256MB a 512MB, poi ad 1024MB (1 GB) ed infine a 4096MB (4 GB): anche questi sono numeri della sequenza 1,2,4,8,16,32…

Pratica e sintassi

Per utilizzare la notazione ottale basta saper leggere e scrivere i numeri binari di 3 cifre. Consideriamo ad esempio la risorsa

-rwxrw-r-- 1 pippo adm 249 9 mag 22.13 foo.txt

in questo caso i permessi di utente, gruppo e altri (ricordiamo la sigla UGO) sono, rispettivamente: rwx (utente), rw- (gruppo) e r-- (altri). La regola è semplice: trasformiamo qualsiasi carattere (sia esso r, w o x) nella cifra “1”, mentre il trattino va letto come “0” (zero). Avremo così

Utente: rwx = 111 = 1*4 + 1*2 + 1*1 = 7

Gruppo: rw- = 110 = 1*4 + 1*2 + 0*1 = 6

Altri : r-- = 100 = 1*4 + 0*2 + 0*1 = 4

ed il gioco è fatto. I permessi della risorsa foo.txt, che in notazione simbolica si scrivono come -rwxrw-r--, in notazione ottale diventano 764.

Quali sono i vantaggi della notazione? Immaginiamo di voler cambiare i permessi del file foo.txt, per lasciare all’utente solo il permesso di lettura, togliere ogni permesso agli altri utenti, e dare tutti i permessi al gruppo proprietario. Quello che vogliamo ottenere è

r--rwx--- 1 pippo adm 249 9 mag 22.13 foo.txt

Tramite il comando chmod ci toccherebbe eseguire l’operazione in più passaggi, digitando prima chmod u-wx, poi chmod g+x ed infine chmod o-r. Oppure dovremmo ricordarci la sintassi per compiere l’operazione con un solo comando, cosa che nella pratica non succede quasi mai.

La notazione ottale permette di ottenere lo stesso risultato con un solo comando. Basta osservare che, con la regola vista sopra, la sequenza r--rwx--- si traduce nei numeri binari 100,111 e 000, ovvero 4, 7 e 0. Per settare i permessi basterà quindi digitare

chmod 470 foo.txt

Con un po’ di pratica, trattandosi di maneggiare solo numeri di 3 cifre, è naturale imparare a memoria le diverse combinazioni, ad esempio: 777 sta per 111,111,111, ovvero rwxrwxrwx (tre volte rwx) che significa “tutti i permessi a tutti”. Analogamente, il permesso 000 sta per 000,000,000, ovvero --------- (9 trattini), che significa “non permettere mai alcuna operazione”.

Dopo aver svelato l’arcano dovrebbe essere facile, o addirittura divertente, capire al volo i permessi di cui si parla nei vari tutorial. Ad esempio

644 significa 110, 100, 100, ovvero rw-r--r--

755 significa 111, 101, 101, ovvero rwxr-xr-x

Oltre a questi servizi, la VPS ovviamente ospita anche un server di posta, che permette di aprire caselle di posta (mailbox) associabili ai domini presenti sulla VPS. Prima di vedere come utilizzare Plesk è bene chiarire i possibili scenari d’uso

1. Se stiamo usando la VPS per ospitare dei domini, e per ogni dominio vogliamo offrire anche il servizio di posta, può essere una buona idea creare i diversi account direttamente da Plesk e fornire i dati di configurazione al cliente, affinché possa usare il client di posta che più gli piace (ad esempio Outlook oppure Thunderbird)
2. Se vogliamo usare il servizio di posta come webmail, anziché tramite un client di posta, forse conviene cercare un’altra soluzione (come ad esempio la BCMail di AziendeItalia). La configurazione di Plesk sulla VPS (al momento di questo articolo) utilizza Horde come client webmail. Horde è un software funzionante e completo, ma forse un po’ datato rispetto agli standard attuali. E siccome anche l’occhio vuole la sua parte, in molti casi la webmail offerta da Horde potrebbe non essere la soluzione ottimale.

Qualunque sia l’utilizzo che abbiamo in mente, sia tramite client di posta o webmail, è bene vedere l’intera procedura di configurazione, per arricchire la nostra cassetta degli attrezzi.

Iniziamo con il verificare che il server di posta sia attivo

una configurazione corretta potrebbe essere la seguente

Configurazione server di posta

dopodiché spostiamoci nel pannello del dominio, dove abbiamo a disposizione i pulsanti per creare un nuovo account di posta, o controllare quelli già esistenti. Per creare una nuova casella di posta clicchiamo su Crea l’account email

Gestione account di posta

dovrebbe aprirsi il pannello qui sotto, dove inseriamo il nome dell’account (ad esempio: stefano) e la password (due volte)

Nuovo account

Facciamo attenzione alla capitalizzazione, quando inseriamo il nome dell’account. Nell’esempio qui sopra abbiamo scritto “Stefano” con la “S” maiuscola: anche se la casella di posta funzionerà in modo case-insensitive (cioè indifferentemente dalla capitalizzazione), molto probabilmente le credenziali dell’account rispetteranno la capitalizzazione. In altre parole, quando l’utente dovrà inserire login e password, dovrà digitare correttamente le eventuali lettere maiuscole.

Dopo aver creato la casella di posta, dal pannello del dominio clicchiamo su Account di posta per visualizzare l’elenco della caselle esistenti. Qui clicchiamo su Impostazione di posta per attivare la webmail

Elenco caselle di posta

per attivare il servizio di webmail clicchiamo sul campo WebMail per scegliere il software che realizza la webmail (nell’esempio qui sotto Horde 4.3.6)

Preferenze email

Con questo abbiamo finito. Per accedere alla posta via webmail possiamo usare il pulsante Aprire WebMail (dal pannello principale del dominio) e cliccare sul nome dell’account che ci interessa. Si aprirà il pannello di login di Horde, dove inseriamo le credenziali dell’account

Horde

In alternativa, il login dovrebbe essere possibile anche tramite accesso diretto (senza entrare in Plesk), utilizzando un indirizzo del tipo

http://webmail.hostingtech.it/

Come detto sopra, anche se la grafica di Horde non è in linea con le ultime tendenze, vale la pena provare almeno una volta a navigare tra i vari menù: Horde è un client webmail completo, con gestione di rubrica, calendario, ricerca e note, che potrebbe tornarci utile per verificare il corretto funzionamento del server di posta.

Per fissare le idee, vedremo un caso pratico di applicazione della tecnica in PHP: i concetti esposti varranno per qualsiasi altro linguaggio di programmazione, salvo ovviamente le opportune modifiche sintattiche. Iniziamo con il parametrizzare tutti i dati che ci interessano

// Definizione di autori e libri
 $books = array(
 0 => array("book_1.php", "Titolo 1" , "Mario Rossi", "2010" ) ,
 1 => array("book_2.php", "Titolo 2" , "Bruno Verdi", "2012" ) ,
 ecc.
 ) ;

nell’esempio qui sopra abbiamo definito i dati di alcuni libri, specificando rispettivamente: la landing page del libro, il titolo dell’opera, il nome dell’autore e l’anno di pubblicazione. Per farlo abbiamo usato un array bidimensionale (array 2D), che in pratica può essere visualizzato come una tabella, dove ogni riga contiene i dati di un’opera letterale, e ogni colonna contiene una serie di dati omogenei. Chi è pratico con i database può pensare ad un array 2D come una specie di tabella o vista di un database. L’elemento generico $books[i][j] rappresenterà il dato j-esimo della riga i-esima, ad esempio

$books[1][2] = “Titolo 2”

Ovviamente, a seconda del contesto e degli argomenti trattati, il nostro array sarà diverso. A volte è comodo definire più di un array, per evitare di ritrovarsi un unico array composto da troppe colonne. Continuando l’esempio qui sopra, un secondo array potrebbe essere:

// Definizione di risorse
 $resources = array(
 0 => array("/img/copertina_1.jpg", "libri/titolo_1.pdf" ) ,
 1 => array("/img/copertina_2.jpg", "libri/titolo_2.pdf" ) ,
 ecc.
 ) ;

La scelta di quali e quanti array usare dipende dal contesto, ed è forse la scelta più importante. Se definiamo troppi array dobbiamo ricordarci, quando aggiorniamo o aggiungiamo qualcosa, di modificare tutti gli array coinvolti. Di contro, se usiamo un unico grande array con tutti i dati che ci servono, dobbiamo essere lungimiranti ed ordinati nel gestire le colonne, onde evitare di perdere troppo tempo ogni volta che vogliamo modificare qualcosa. La scelta dipende anche dagli strumenti di lavoro: se usiamo un editor in colonna probabilmente terremo tutte le colonne ben formattate. Se invece diamo molto peso alla performances, e gestiamo gli array tramite un framework o tool apposito, forse sceglieremo di compattare gli array sacrificandone la formattazione.

Rendering

Dopo aver deciso come organizzare i contenuti all’interno di uno o più array, possiamo occuparci di renderizzare i dati, ovvero produrre l’HTML finale. Ciò si realizza scrivendo una sorta di blocco template, ovvero una sezione di codice HTML e PHP, ad esempio

<?php
for ($n = 0 ; $n < count($books) ; $n++) {
?>

<div class="my_div">
  <a class="link_1" href="<?php echo $books[$n][0] ?>" title="<?php echo $books[$n][1] ?>">
  <img class="my_image" src="<?php echo $resources[$n][0] ?>"/>
  </a>
  <a class="link_2" href="<?php echo $books[$n][0] ?>" title="<?php echo $books[$n][1] ?>">
  <span class="title"><?php echo $books[$n][1] ?></span>
  </a>
  <br/><br/>
  <span class="subtitle">di <?php echo $books[$n][2] ?> - <?php echo $books[$n][3] ?></span>
  <p class="description"><?php echo $abstracts[$n] ?>
  <br/><br/>
  <a class="link_3" href="<?php echo $resources[$n][1] ?>" title="<?php echo $books[$n][1] ?>">Scarica</a>
  </p>
</div>

<?php } ?>

Il codice qui sopra produrrà tutti i blocchi HTML del caso (in questo caso dei div con classe my_div).

Il vantaggio è evidente: se dobbiamo cambiare layout, grafica o aspetto ci basterà mettere le mani nel codice qui sopra, anche se la pagina contenesse decine di libri.

Prima di concludere osserviamo che

• Nell’esempio qui sopra abbiamo usato un terzo array, avente nome abstract, che potrebbe contenere una breve descrizione dei libri. Come detto sopra questa è solo una delle scelte possibili: volendo avremmo potuto inserire i dati degli array resources e abstract all’interno dell’array books
• Abbiamo evitato la sintassi abbreviata <?= $books[i][j] ?>, perché potrebbe dare problemi a seconda della configurazione di PHP (per dettagli vedi qui)
• Usiamo echo al posto di print perché è leggermente più veloce. Si potrebbe guadagnare ancora qualcosa sulle performances evitando la concatenazione di stringhe tramite l’operatore dot (il punto), ma la questione non è banale  e merita di essere trattata a parte

Oggi vedremo come affrontare, in modo pratico, l’eventuale migrazione di un’istanza di PrestaShop da una macchina ad un’altra. Si tratta di uno scenario abbastanza frequente, che potrebbe presentarsi per motivi diversi

1. Cambiamo host provider (tipicamente perché migriamo il dominio)
2. Dobbiamo copiare un’istanza remota in locale, o viceversa
3. Vogliamo aggiornare PrestaShop in remoto, e vogliamo prima provare in locale la procedura di aggiornamento

Tutti questi casi si possono ricondurre al secondo scenario: se siamo in grado di migrare PrestaShop da remoto a locale, e viceversa, siamo potenzialmente capaci di effettuare qualsiasi migrazione. Per questo motivo consideriamo, come esercizio e tutorial,  il caso di migrazione da remoto a locale.

Copia locale

Assumiamo di avere un’installazione di PrestaShop già attiva in remoto. Per portarle in locale, la prima cosa da fare è effettuare un export del database. A parte rare eccezioni, PrestaShop utilizza MySQL, per cui phpMyAdmin si presta perfettamente allo scopo. Colleghiamoci al database utilizzando phpMyAdmin tramite l’indirizzo o lo strumento fornito dal nostro provider (ad esempio Plesk o cPanel). Dall’interfaccia di phpMyAdmin scegliamo la tab Esporta: nel riquadro Esporta selezioniamo il database di PrestaShop, controlliamo di avere selezionato le check-box SQL (formato di esportazione) e Salva con nome (in basso), scegliamo un nome per il file di export e clicchiamo su Esegui.

Volendo, è possibile spuntare una voce di compressione, come ad esempio zip o gzip, a seconda del volume d’affare della nostra attività. Se l’attività è modesta, o in piedi da pochi mesi, probabilmente l’export del database sarà molto leggero e possiamo scaricarlo senza compressione. In caso contrario vale la pena scegliere un formato di compressione.

Il secondo passo è collegarsi al sito con un client FTP (quello che usiamo di solito), verificare di avere impostato l’interfaccia del client per visualizzare i files nascosti, e portare in locale l’intera copia del sito. La durata di questo processo dipende dalla dimensione del nostro catalogo: se abbiamo qualche centinaio di prodotti, con relative immagini, il download del sito potrebbe richiedere parecchie ore. Se temiamo di non poter lasciare acceso il PC, o abbiamo problemi di tempo, è buona norma iniziare a scaricare il sito al mattino, come attività in background.

Configurazione locale

Dopo aver portato in locale il file di export del database e la copia dell’intero sito (files e directories), dobbiamo riprodurre l’ambiente locale adeguato. Questo è il passaggio più laborioso e delicato, ma non spaventiamoci: seguire la procedura qui sotto è semplice e non richiede alcuna competenza specifica. L’unico svantaggio, se non siamo dei sistemisti esperti, è che potremmo non essere in grado di risolvere eventuali problemi o difficoltà. Ma vale la pena provare comunque, per almeno tre motivi: non rischiamo di perdere nulla, sbagliando si impara e la probabilità di successo sono elevate.

1. Creiamo un database vuoto sul nostro MySQL locale, ad esempio tramite phpMyAdmin, usando tutte le ipotesi di default
2. Importiamo nel database appena creato il file di export scaricato dal sito remoto, sempre con tutte le opzioni di default
3. Creiamo sul database locale un utente dedicato al nostro database. Per semplicità possiamo creare l’utente usando lo stesso login e password del database remoto. Subito dopo, inoltre, è una buona idea testare la connessione (con l’utente appena creato) usando un client SQL
4. Copiamo (o spostiamo) l’intero sito (tutti i files e le cartelle) nella htdocs o www dell’Apache locale. Questo ovviamente dipende da come e dove abbiamo installato Apache. Se possibile evitiamo di copiare nella root di Apache, ma copiamo il sito in una directory dedicata (ad esempio ilmiosito)
5. Modifichiamo il file settings.inc.php locale per inserire in nuovi dati. I parametri da cambiare dovrebbero essere __PS_BASE_URI__ (il percorso rispetto la DocumentRoot di Apache, ad esempio ilmiosito) e _DB_SERVER_ (l’host del dabase, probabilmente localhost): tutti gli altri parametri dovrebbero restare invariati
6. Facciamo una copia del file .htaccess originale, chiamandolo ad esempio htaccess.original: questo è necessario se lavoriamo su Windows, perché Windows non permette di creare file senza nome (come .htaccess), per cui siamo costretti a modificare quello originale
7. Apriamo il file .htaccess con un editor qualsiasi (Notepad, Notepad++, VIM o quello che ci piace) e cancelliamo il suo contenuto, dopodiché salviamo. Come accennato al punto precedente, questo è uno modi più semplici di creare un file .htaccess vuoto su Windows: ecco perché al punto 6 abbiamo fatto una copia di backup dell’originale
8. Avviamo il web server locale (Apache) e il database locale (MySQL): se usiamo un pacchetto AMP probabilmente possiamo compiere quest’operazione con un click
9. Colleghiamoci al backend, usando lo stesso indirizzo remoto, modificato ad hoc in locale. Ad esempio, se in remoto usiamo

http://www.ilmiosito.com/my_admin/

in locale probabilmente useremo

http://localhost/ilmiosito/my_admin/

10. Nell’interfaccia del backend andiamo in Utilità – Generatori e clicchiamo sul pulsante (o scritta) Genera file .htaccess

In conclusione, i files modificati in locale, rispetto l’installazione remota, dovrebbero essere solamente il file .htaccess e settings.inc.php: ricordiamocelo al momento di riportare il sito in remoto, o altrove, per evitare di perdere o sovrascrivere i due files dell’installazione originale.

Iniziamo con il considerare il dominio aziendeitalia.com, cioè il dominio registrato da AziendeItalia. Ogni host viene registrato presso un dominio di primo livello (ovvero TLD, Top Level Domain), che in questo caso è .com. Ricordiamoci che non sempre il dominio di primo livello è quello dopo l’ultimo punto. In alcuni casi (vedi ad esempio .uk) il ruolo del dominio di primo livello viene svolto da “particolari sottodomini”, come ad esempio co.uk oppure org.uk. Da un punto di vista tecnico, anche in questi casi, il vero dominio di primo livello è quello dopo l’ultimo punto (cioè .uk), e le etichette come co e org sono domini di secondo livello registrati presso .uk. Ma, da un punto di vista pratico, siccome i domini sotto .uk vanno registrati come prova.co.uk oppure prova.org.uk, possiamo pensare alle sigle co.uk e org.uk come se fossero davvero domini di primo livello.

Subito prima del dominio di primo livello (ad esempio .com) abbiamo il dominio di secondo livello (ad esempio aziendeitalia): è questo quello che va registrato presso l’authority competente. Poiché il dominio di secondo livello è l’unico a necessitare una registrazione, quando si dice “registrare un dominio” si da per sottinteso che stiamo parlando di un dominio di secondo livello. I domini registrati sono, proprio in virtù della procedura di registrazione, unici all’interno di un dominio di primo livello. Per questo motivo non possiamo usarli liberamente, o cambiarli quando ci pare e piace, ma dobbiamo sempre sottostare alla procedura di registrazione.

Eccoci così giunti al nocciolo della questione: prima del nome del dominio registrato abbiamo gli eventuali sottodomini di terzo livello. Qui abbiamo libertà completa: se abbiamo spazio, e se il nostro hosting provider lo permette, possiamo inventarci tutti i sottodomini che ci piacciono, senza alcuna necessità di registrarli. Il motivo è semplice: se pensiamo al dominio di primo livello come l’indirizzo postale della nostra città (esempio: Milano – Italia), e al dominio di secondo livello come l’indirizzo stradale (esempio: Via Roma, 1), allora i sottodomini di terzo livello sono quella parte dell’indirizzo che ci compete: il nome scritto sulla cassetta delle lettere, o sul citofono.

Siccome il dominio di secondo livello è l’unico a dover essere registrato, esso viene detto semplicemente “dominio”. Questo spiega perché i domini di terzo livello, in quanto contenuti in quello che viene detto “dominio”, sono detti per brevità“sottodomini”.

Una volta chiarita la terminologia, e giustificato l’uso dei vari sinonimi, possiamo finalmente chiarire la questione del sottodominio www. Consideriamo ad esempio

www.aziendeitalia.com

prova.aziendeitalia.com

Per quanto appena detto, in questo caso abbiamo un dominio registrato (cioè di secondo livello), avente nome aziendeitalia, che contiene due sottodomini: www e prova. Se siamo abituati a pensare (erroneamente) alla sigla www come sinonimo di Internet, il fatto che www sia in realtà un sottodominio potrebbe confonderci. Per convincerci, basta fare un salto nel passato e ricordare che la nascita di Internet coincide con l’adozione del protocollo TCP/IP su scala mondiale. Il World Wild Web coincide invece con la diffusione, in un secondo tempo, del protocollo HTTP sopra la rete TCP/IP. Per questo motivo, all’inizio (primi anni ’90) il protocollo HTTP era uno dei tanti possibili modi di usare Internet. Riprendendo l’analogia tra la struttura di un URL e un indirizzo postale, dove il sottodominio rappresenta ciò che scriviamo sul citofono o sulla cassetta delle lettere, avremmo

 smtp.aziendeitalia.com (cassetta delle lettere)

ftp.aziendeitalia.com (box dedicato ai pacchi)

www.aziendeitalia.com (nome sul citofono)

 L’analogia è azzeccata, perché la funzione iniziale dei sottodomini era esattamente questa: differenziare i diversi protocolli di comunicazione su indirizzi diversi. Solamente in un secondo tempo, quando il protocollo HTTP si è imposto sugli altri, si è iniziato a pensare al sottodominio www come quello “normale” o di “default”, perché era quello da “usare dentro il browser”.

Vantaggi e svantaggi

Dato che l’utilizzo del sottodomino www è un retaggio storico, è chiaro che se ne potrebbe fare a meno. E’ per questo che, sia scrivendo www.aziendeitalia.com o aziendeitalia.com, apparentemente non cambia nulla. Esistono però delle differenze che si riflettono in vantaggi o svantaggi effettivi. Alcune questioni associate alla scelta di usare o non usare il prefisso www sono

• Valutazione del Page Rank da parte dei motori di ricerca: se il nostro sito viene indicizzato a volte come www, a volte senza www, di fatto il numero di link verso il nostro sito viene diviso in due parti. Per ottimizzare l’indicizzazione, soprattutto relativamente al SEO, è bene scegliere uno solo dei due indirizzi. Vanno bene entrambi, scegliamo quello che più ci piace, però usiamone solo uno.
• Scalabilità e balancing: il vantaggio dei sottodomini, rispetto all’uso delle directories (esempio: aziendeitalia.com/prova) è che possiamo impostare i record DNS di un sottodominio per puntare ad IP diversi. Questo permette di migrare, in modo trasparente all’utente, i sottodomini su macchine diverse. Un altro vantaggio è di poter reindirizzare le richieste dai sottodomini su server in load balacing, migliorando le performances.
• Gestione dei cookies: il fatto di avere dei sottodomini impatta lo scope dei cookies, e in alcuni casi può ridurre la banda effettiva a disposizione del sito. Si tratta di un argomento che merita di essere trattato a parte, come vedremo nelle prossime puntate.

Se non siamo dei tecnici specializzati, ma usiamo il web per fare impresa, l’aspetto più importante dovrebbe essere il primo: ricordarsi di utilizzare sempre un solo tipo di riferimento al nostro sito. Per ottimizzare l’indicizzazione delle nostre pagine, conviene decidere se vogliamo farci conoscere con il prefisso www o senza di esso. Se abbiamo già avviato il sito, già indicizzato molte pagine e utilizzato una volta un indirizzo, una volta l’altro, non è troppo tardi per rimediare. Prossimamente vedremo come sfruttare il redirect HTTP (o addirittura DNS) per risolvere il problema.

Per capirlo vediamo un esempio: consideriamo due gruppi: adm (con id=4) e  dialout (con id=20). Assumendo di avere i permessi di amministratore, creiamo due utenti e assegniamoli a questi gruppi

useradd -g 20 -c "Prova permessi" pippo
useradd -g 4 -c "Prova permessi" pluto

Siccome vogliamo loggarci con questi utenti, assegniamo loro una password (trattandosi di una prova, va benissimo usare una password uguale al nome)

passwd pippo
passwd pluto

Sempre come amministratore, creiamo infine una directory dove mettere alcuni files di prova, ad esempio

-rw-rw----  1 pippo   adm        5 2012-05-02 16:57 due.sh
-rw-rw----  1 pluto   adm       14 2012-05-02 16:13 uno.sh

Per creare una situazione come questa, dopo aver creato i due files (uno.txt e due.sh) assegniamo proprietari e permessi tramite i comandi

chmod o-r uno.sh
chmod o-r due.sh
chown pluto:adm uno.sh
chown pippo:adm due.sh

Siamo finalmente pronti per fare qualche prova: entriamo come utente pippo, usando ad esempio “su pippo”, e proviamo a maneggiare il file uno.sh.  Com’è giusto che sia, non potremo né leggere, né modificare, né eseguire il file uno.sh. Ovviamente non potremo né cambiare i suoi permessi (comando chmod) né assegnarlo ad altro utente o gruppo (comando chown). Le cose cambiano se ci logghiamo con l’utente pluto (usando “su pluto”) e proviamo a maneggiare il file due.sh. In questo caso potremo leggere e modificare il file (permessi del gruppo), ma non potremo eseguirlo. Anche qui ovviamente non potremo cambiare né permessi né utente o gruppo proprietario.
Proviamo ora a cambiare i permessi, aggiungendo i permessi di esecuzione a livello di gruppo

-rw-rwx--- 1 pippo adm 3 2012-05-02 17:24 due.sh
-rw-rwx--- 1 pluto adm 3 2012-05-02 17:27 uno.sh

Se ci logghiamo come utente pippo, giustamente non potremo eseguire nessuno dei due files. Come invece pluto potremo eseguire il file due.sh, ma non potremo eseguire uno.sh!
Cos’è successo? Nel caso del file due.sh, le operazioni permesse all’utente pluto sono regolamentate dal suo gruppo (ovvero adm), e siccome questo gruppo ha i permessi di esecuzione, anche l’utente pluto potrà eseguire questo file. Le cose sono diverse quando proviamo ad eseguire il file uno.sh. Siccome come utente non ha i permessi di esecuzione, l’utente pluto non potrà eseguire il file uno.sh, anche se potrebbe farlo in quanto membro del gruppo adm!

Se ci pensiamo un attimo, questo è il comportamento giusto: lo scopo dei gruppi è quello di fornire regole generiche, valide per molti utenti e molti tipi di risorse, senza preoccuparci del singolo caso o eccezione. I permessi dei gruppi potrebbero essere sufficienti a regolamentare tutte le risorse del file system, per cui non abbiamo, in teoria, necessità di assegnare anche un utente proprietario ad ogni risorsa. Il vantaggio di decidere che una certa risorsa ha due “padroni” (un utente e un gruppo) è quello di poter gestire delle regole particolari, che potrebbero non andar bene a livello di gruppo. E’ quindi giusto che, là dove ci sia contraddizione tra i permessi come utente proprietario e come gruppo proprietario, i permessi dell’utente siano prioritari: solamente in questo modo saremo in grado di assegnare regole specifiche e puntuali sui singoli utenti.
Per verificare quanto detto basta invertire la situazione, assegnando i permessi di esecuzione (per il file uno.sh) all’utente proprietario anziché il gruppo

-rw-rwx---  1 pippo   adm        3 2012-05-02 17:24 due.sh
-rwxrw----  1 pluto   adm        3 2012-05-02 17:27 uno.sh

se riproviamo adesso, l’utente pluto potrà eseguire uno.sh perché ha il permesso di farlo in quanto utente, ma non potrebbe farlo in qualità di membro del gruppo adm. La situazione appena vista è un ottimo esempio di buon uso dei permessi in combinazione con la distinzione tra gruppi e utenti: in molti casi è bene assegnare dei permessi piuttosto “contenuti” ai gruppi, ed aumentare eventualmente “i poteri” solamente agli utenti giusti.

Come ultima cosa osserviamo che quanto detto vale per qualsiasi gruppo, sia esso primario o secondario. Anche qui, il modo migliore di imparare è fare qualche prova nella shell (usando, se necessario, il comando usermod  per assegnare gli utenti già creati ad altri gruppi).

All’interno del file di configurazione di Apache dovrebbe sempre trovarsi una direttiva del tipo

<Directory />

...

</Directory>

la direttiva riguarda la root del server perché il percorso “/” è specificato subito dopo la keyword Directory: ciò significa che la direttiva si applica alla root del server, ovvero a tutte le risorse presenti sotto il percorso definito nella DocumentRoot, incluse le eventuali sotto directories.

Se vogliamo applicare una direttiva Directory ad un particolare percorso, basterà scrivere (su Windows è bene delimitare il percorso tra “doppi apici”) qualcosa come

<Directory /usr/local/httpd/mysite>

…

</Directory>

Questo dovrebbe farci capire perché la direttiva Directory è così importante: si tratta di una “meta direttiva”, che non riguarda una regola particolare di Apache, ma permette invece di specificare quando applicare un gruppo di direttive. Se pensiamo alle direttive come ad un mazzo di carte da gioco, la direttiva Directory dice a quale “giocatore” (leggi: sito o percorso nel file system) va assegnato un’intera mano di carte (leggi: gruppo di direttive). All’interno della direttiva Directory possiamo inserire molte direttive diverse, e caratterizzare così il comportamento del singolo sito o applicazione. Tanta libertà potrebbe disorientare: andiamo perciò a vedere quali sono le direttive usate più spesso all’interno dell’elemento Directory.

Options

Permette di specificare molti comportamenti diversi, che riguardano quali script possono essere eseguiti lato server (ExecCGI), come gestire i link simbolici (FollowSymLinks e SymLinksIfOwnerMatch), i tipi di include permessi lato lato server (Includes e IncludesNOEXEC), le modalità di negoziazione dei contenuti (MultiViews) e come vanno visualizzati le directory sprovviste di una index.html (Indexes). Se lavoriamo in locale, possiamo tranquillamente scegliere il valore Options All che attiva tutte le modalità che abbiamo elencato. Se invece dobbiamo amministrare un server remoto, non possiamo esimerci dallo studiare bene questa direttiva.

AllowOverride

Direttiva molto importate per le applicazioni in hosting remoto. Se questa direttiva è settata su None, tutti i files .htaccess sotto la directory in questione saranno ignorati. Esistono diversi modi di configurare dove e quando è permesso l’override tramite un file .htaccess, non possiamo discuterli tutti in queste sede. Ci basta invece ricordare che, se un file .htaccess tenta di eseguire un override non consentito, nella maggior parte dei casi avremo un internal server error.

Order, Deny e Allow

Sono tre direttive diverse, ma vale la pena vederle assieme. La direttiva Order decide con quale priorità considerare le altre due, e può assumere solo due valori: Deny,Allow (le richieste “dubbie” vengono accettate) oppure Allow,Deny (le richieste “dubbie” vengono respinte). Per richieste “dubbie” si intendono tutte quelle non regolamentate da qualche regola di tipo Allow o Deny (o da entrambe). Alcuni esempi dovrebbero chiarire l’uso combinato delle tre direttive

Order Deny,Allow
Deny from all
Allow from aziendeitalia.com

significa che le uniche richieste accettate sono quelle provenienti dal dominio aziendeitalia.com. Notiamo che in questo caso non esistono richieste dubbie e ambigue, perché la direttiva Deny from all è chiara quanto imperativa: tutto ciò che non è regolamentato va rifiutato.

Lo stesso risultato si potrebbe ottenere scrivendo

Order Allow,Deny
Allow from aziendeitalia.com
Deny from ilmiosito.com

infatti in tal caso tutte le richieste “dubbie” (ovvero quelle che non provengono né da AziendeItalia, né dal “mio sito”) saranno scartate perché abbiamo scelto l’impostazione meno permissiva (cioè Order Allow,Deny), che respinge tutto ciò che non soddisfa una qualsiasi regola.

Dovrebbe essere chiaro che non è possibile riassumere in poche pagine tutte le potenzialità offerte dalla direttiva Directory. Nelle prossime puntate vedremo alcuni esempi specifici, sperando di coprire almeno i casi più frequenti per chi lavora sul web. Vale però la pena, prima di concludere, accennare a cosa succede se un percorso del file system viene descritto da più direttive Directory. Consideriamo ad esempio

<Directory /> ecc... ecc...</Directory>

<Directory /mysite> ecc... ecc...</Directory>

in questo caso al percorso /mysite si applicano entrambe le direttive, perché la directory mysite si trova sotto l’albero della root (regolata dalla direttiva <Directory />). Per risolvere ambiguità come questa Apache assegna la priorità al percorso più breve: siccome la stringa “/” è più breve delle stringa “/mysite”, le istruzioni della prima riga verranno applicate prima di quelle della seconda riga. Il discorso cambia se specifichiamo il percorso a cui fa riferimento la direttiva usando un’espressione regolare: direttive di questo tipo sono valutate dopo le direttive normali, e dopo gli eventuali file .htaccess. Per questo motivo, almeno all’inizio, sconsigliamo di lavorare con le espressioni regolari, ma di identificare i percorsi delle directory in maniera esplicita.