Advanced Technology

Il motore FTP di IIS6 è stato notevolmente migliorato rispetto alle versioni precedenti. Che io ricordi configurarlo per un vero ambiente di hosting era un bagno di sudore e comunque le prospettive per una facile gestione erano estremamente lontane.

Non che oggi le cose siano cambiate poi molto. Sicuramente Microsoft potrebbe adoperarsi per implementare un servizio migliore che permetta una vera isolazione degli utenti, con possibilità di assegnare permessi a gruppi di utenti, e con l’aggiunta del quota management.

Di queste ultime tre caratteristiche, con l’introduzione di IIS 6, solo la prima è stata introdotta: addirittura prima di IIS 6, avere un FTP con il servizio Microsoft significava che un utente A dalla sua root poteva salire di un livello, vedere tutte le altre cartelle che erano presenti nella root generale del servizio (e magari se qualche permesso era sbagliato, entrare pure dentro ad una di queste cartelle e far danni).
Certo si potevano creare tanti FTP root quanti erano gli utenti, ma chi è ha tutti questi indirizzi IP da dare gratuitamente? Facile quindi immaginare perché in quasi tutti i servizi di hosting non si trovava – e ancora non si trova – quasi nessuno che utilizza il server FTP di Microsoft.

In merito al quota management (assegnazione dello spazio disco), anche qua il servizio è carente, anzi direi totalmente estraneo. Si può ovviare con un escamotage, utilizzando il servizio a livello “windows”. Passatemi quest’ultima affermazione. In quanto a gruppi di utenti, beh lasciamo stare. Qui forse bisogna aspettare l’arrivo di Longhorn. In realtà potrei vedere come funziona sotto Windows Vista. Presuppongo che il servizio sia lo stesso, ma d’altronde, questo mio articolo verte a voler mettere in piedi un servizio FTP con quanto MS mette a disposizione sul server e null’altro. E dato che l’attuale installazione di Windows 2003 mette a disposizione IIS6, limitiamoci solo ad IIS6 e null’altro.

 

Microsoft finalmente partorì la User Isolation.

Il funzionamento del server FTP di Microsoft è un peletto strano. Parte dal presupposto che:

1. Non esiste un utente FTP scisso dall’utente Windows, quindi per fornire accesso ad un sito FTP bisogna creare un account sul server o nel dominio, con appositi permessi ridotti (per il vostro bene);
2. Ad ogni utente FTP deve necessariamente corrispondere una cartella che abbia lo stesso nome dell’account;
3. La cartella (o home directory utente) deve avere lo stesso nome dell’account Windows che farà login;

Sembra che alla Microsoft hanno pensato che tutti gli utenti necessitassero di una cartella diversa e che ognuno dovesse custodire gelosamente i propri dati. Alla faccia quindi dei principi di collaborazione, di Team Foundation Server e di tutto il lavoro di gruppo in genere.

Commenti a parte, i punti 2 e 3 sono indispensabili, pena tutti gli account che fanno login si ritrovano confinati nella ROOT impostata per il servizio FTP, e se avrete sbagliato con la pianificazione della creazione delle cartelle, tutti potranno vedere tutto. Più avanti farò quindi un esempio di corretta configurazione del servizio FTP per un ambiente multiutente.

Quanto sopra, comunque, non è proprio quello che si chiama uno scenario da hosting. Ammessa e non concessa anche una corretta configurazione poi, fino ad IIS 5.0, non esisteva una vera isolazione utente, e quindi per quanto l’amministratore del server avesse creati all’account specifica per l’utente, ci si ritrova nello scenario poc’anzi descritto, ovvero l’utente semplicemente premendo il tasto “Folder up” del client FTP si ritrovava nella ROOT e da li poteva scorrazzare in giro per le cartelle all’interno del servizio FTP (i danni si potevano limitare con appositi permessi NTFS, ma almeno la visione era possibile per un motivo che spiegherò più avanti).

Questa cosa è stata risolta con IIS6 e la User Isolation: in pratica si tratta di un nuovo modello di configurazione per il servizio FTP (relativo ad uno specifico sito FTP – ricordo che si possono creare molteplici siti FTP sotto lo stesso server) che rende la home directory dell’utente la sua root, al di sopra della quale è impossibile andare.

Le altre due impostazioni disponibili sono “Do not isolate users” (che è il vecchio sistema di default fino ad IIS 5.0) e Isolate User Using Active Directory. Questi ultimi due, per quanto per il primo abbia dato accenno su cosa realmente faccia, non verranno trattati nel seguente articolo.

Attenzione: la scelta su come impostare il modo di isolazione la si può fare esclusivamente durante la creazione del sito FTP, e non la si può assolutamente cambiare a posteriori; pensate prima di agire.

 

Alcune configurazioni essenziali, altrimenti non si va avanti !!

Essenziale perché il servizio FTP di MS possa funzionare sono due aspetti importanti.

1) I permessi utente: ogni utente che accede ad uno specifico sito FTP deve avere almeno i permessi di Lettura e di Folder listing; pena errore 530 User ftp_adhoc cannot log in, home directory inaccessibile. Questo spiega perché era sempre possibile vedere tutto il contenuto delle varie cartelle fino ad IIS 5.0 e anche con IIS 6.0 se configurato in modalità “Do not isolate user”.

Consiglio pratico: create un gruppo di utenti, con i soli permessi di List e read, associateci tutti gli account windows che utilizzeranno il servizio FTP e assegnate a livello NTFS questo gruppo alla ROOT del sito FTP, facendo in modo da abilitare la propagazione dei permessi partendo dal padre, così che per ogni nuova cartella creata, sempre e comunque tutti gli utenti di quel gruppo avranno garantita la lettura (che sarà invece circoscritta dalla user isolation) .

2) Partendo da una data directory X che sarà per noi la Home Directory del servizio FTP o ROOT che dir si voglia, per creare una Home Directory specifica per l’utente in modalità Isolated user e fare in modo che quello sia il suo punto di partenza e non possa andare oltre, bisogna creare dentro la X una cartella denominata LocalUser e dentro a questa cartella create tante cartelle, una per ogni account Windows che farà login al servizio FTP.

Per intenderci quindi avremo una struttura di questo tipo:

C:\FTP <Home del server FTP>

C:\FTP\LocalUser\Public <Home directory per l’account anonymous qualora lo abilitiate>

C:\FTP\LocalUser\Test <Home directory per l’account test>

C:\FTP\Domain\Test <Dove al posto di domain ci deve essere scritto il nome del dominio, qualora il server sia appartenga ad un dominio o sia lui stesso un PDC>.

 

Un caso reale

Create un nuovo sito FTP e seguite il wizard. Per quanto riguarda i permessi da assegnare alla ROOT directory, indichiamo sia lettura che scrittura e non preoccupiamoci di questo, perché il servizio FTP verifica i reali permessi dell’account che si sta loggando prima a livello di FileSystem e poi a livello di servizio.

Mi spiego meglio: ipotizziamo di impostare a livello di servizio i permessi in lettura/scrittura per la ROOT ma nella scheda Security (permessi NTFS) della cartella X indichiamo solo quelli di lettura per l’account Test. Test in quella cartella non scriverà mai.

Dopo aver ultimato il wizard, create un gruppo di utenti per l’accesso FTP, un utente vero e assegnatelo al gruppo. Create la sua home directory come descritto nel paragrafo precedente.

Se avete seguito tutto fin qua descritto, vi ritroverete con un servizio FTP parzialmente utilizzabile. Perché? Beh, l’impossibilità di poter redirigere un utente su di uno specifico path, rende di fatto il servizio FTP come una specie di storage folder personale. Ma cosa succede se due account utente (perché utenti dello stesso sito) devono poter inserire/modificare/cancellare dati nella stessa directory?
Così come siamo questa cosa è impossibile. Impensabile di mettere lo stesso contenuto nelle due home directory. Chi sincronizzerebbe il contenuto e con che precedenza? Ma soprattutto perché far fare del lavoro inutile ad un software di terze parti?

La soluzione è quindi quella di fare in modo che due o più utenti vedano, una volta fatto il login, lo stesso contenuto. Come fare?

Assodato che ogni utente una volta fatto il login va comunque a finire nella sua home directory, bisogna fare in modo di creare un collegamento verso un altro specifico path.
Non si tratta di un collegamento windows, anche se il principio è lo stesso, ma bensì di uno JUNCTION o Symbolic Directory per chi lavora anche sotto Unix / Linux.

Con uno JUNCTION si vedrà quindi una cartella e non appena ci si muoverà al suo interno, di nascosto il sistema operativo ci catapulterà nel path fisico al quale è associato.

Qui bisogna quindi fare attenzione, perché sarà necessario impostare correttamente i permessi NTFS per le cartelle fisiche alle quali l’utente avrà accesso, impostando non solo permessi di lettura, ma anche quelli di scrittura e i permessi speciali per poter consentire di cancellare e creare directory. Non mettere questi permessi equivali ad avere un mezzo utente FTP.

Così se avrete una cartella C:\FTPSites\LocalUser\Test\SitoWeb1 che punta a C:\WebSites\SitoWeb1, i permessi dovrete impostarli per quest’ultimo path.

Ne deriva che se un utente deve avere accesso a più siti, o a più directory, creeremo la cartella fisica C:\FTPSites\LocalUser\Test\ e al suo interno tante JUNCTION per le varie cartelle alle quali deve poter avere accesso, se invece l’utente ha un solo sito, addirittura la cartella Test (Stesso nome dell’account utente) potrà essere una JUNCTION.

 

Come creo queste Symbolic Directory (“Junction”)

Esistono due sistemi:

1) Scaricare il Resource Kit di Windows 2003 (20Mb e passa)

2) Utilizzare il tool di Rossinovich, Junction per l’appunto (Soli 41KB).

Ovviamente io opto per la seconda scelta.

Il tool funziona da riga di comando ed è estremamente semplice da utilizzare. Se con il prompt di Dos vi posizionate all’interno della cartella nella quale la vostra jucntion deve comparire, non dovrete far altro che scrivere: Junction <directory target>

La junction una volta create, per il sistema operativo, non sarà altro che una cartella normale, e di primo impatto, con le Risorse del computer non è possibile capire la differenza, che invece si evidenza da Prompt di MS-DOS.

 

 

Conclusione

Se avete fatto tutto bene, non resta che collegarvi al vostro server FTP di MS in modalità multiutente. Speriamo comunque che con la nuova versione di Windows Server, il supporto per tale servizio venga ulteriormente esteso e ampliato con il quota management e una migliore gestione degli accessi di gruppo.
Magari se slegassero anche l’account windows dall’account FTP sarebbe il non plus ultra.

Ricercare problemi non è una cosa semplice, indipendentemente dall’ambiente in cui ci si trova. Oggi i programmatori accorti si sono resi conto che è necessario scrivere dei file di log per poter manifestare lo stato di errore, ma dal file a capirci qualcosa di acqua sotto i ponti ce ne passa. Specie se poi i file di log sono un ammasso di informazioni “accodate” e “relazionate” tra loro, ma che in un semplice file di testo diventano incomprensibili.

IIS7 , fortunatamente ha rivisitato un pochino questo sua parte, e in aggiunta al tradizionale file di log (il cosiddetto RAW Log) ha affiancato un elegante sistema di estrapolazione da questo file, che alla fine della storia niente altro che genera un file xml un po’ più ordinato, al quale, affiancando un file .xsl (XML Stylesheet Transformation file) generato in automatico dal server, si riesce a leggere in maniera decisamente più semplice il file.

Ma come fare per abilitare questo sistema di troubleshooting? Bisogna utilizzare il Failed Requests Tracing Setting – meglio conosciuto come FREB (perché prima il servizio si chiamava Failed Requests Event Buffering). Per la sua abilitazione ci sono diversi passaggi da dover eseguire. Iniziamo da principio.

 

Passo 1

Assicurarsi che il servizio di Tracing di IIS7 sia attivo (lo trovate sotto Control Panel, Program and Features, Turn Windows feature on, World Wide Web Services – Health and Diagnostics – Tracing)

Passo 2

Entrare nel pannello di amministrazione di IIS7 (La management console), quindi selezionare il sito web per il quale si vuole abilitare questa funzione, e sull’immediata destra fare click sulla voce “Failed Request Tracing”. Alla finestra di popup che si presenta, cliccare in alto sulla voce Enable. Il resto delle impostazioni si possono lasciare così come sono.

Questa parte serve in sostanza per comunicare al nostro server web che deve generare i log, cioè quel file di testo dove IIS scrive tutte le pagine richieste, l’IP del richiedente, lo stato di errore (200 pagina ok, 404 pagina non trovata, 500 errore, …). Questo è lo stesso file che viene utilizzato dai software di statistica per mostrare chi si connette al nostro sito.

C’è una cosa che mi sfugge. Il perchè abbiano chiamato questa feature come Failed Request Tracing, quando in realtà analizzando il file di log, lo stesso contiene come ho già detto, tutte quante le richieste avanzate al web server, con tutti i codici.

Passo 3

Configurare le eccezioni d’errore delle quali IIS deve tener traccia. Questo lo si può fare cliccando su Failed Request Tracing Rules e seguendo il wizard che compare facendo doppio click. La prima schermata consente di selezionare il contenuto che si vuole analizzare (in base alla sua estenzione). La seconda schermata richiede quale sia l’errore che di cui si vuole tenere traccia. Si deve necessariamente specificare un errore (almeno sul mio sistema non c’è stato verso di dire li voglio tutti).

Infine, terzo e ultimo passaggio, si configura il provider (cioè chi controllare) e la tipologia di errori (verbosity) da restituire. Se tutto è ok , potrete premere ok e ritrovarvi una nuova entry dentro alla lista.

Da questo momento in poi – limitatamente all’errore 500 (perché questo è stato richiesto) – all’interno della cartella %systemdrive%\inetpub\logs\FailedReqLogFiles\ (supponendo che stiamo parlando del default web server), sarà possibile trovare una serie di cartelle denominate W3SVC? Dove al posto del ? ci sarà un numero che altro non è che l’ID assegnato dal sistema quando si è creato un sito web. L’id del default web site è 1. All’interno di questa cartella si troveranno tanti file per ogni errore generato. Essendo dei file xml, doppio cliccandoci sopra, verrà aperto Internet Explorer e, in base al file freb.xsl contenuto nella cartella (e aggiunto in automatico dal sistema qualora questo non esista) si potrà leggere un file di analisi sufficientemente dettagliato.

In merito alla leggibilità c’è poi la possibilità di scaricare un nuovo template rilasciato direttamente dal Program Manager di IIS e disponibile qui.

Per applicare il file, basta semplicemente sostituire il file freb.xsl presente nella cartella sopra menzionata con quello presente nello zip.

Per ripristinare il file originale, invece, basta cancellare il file presente nella directory. Al successivo log, se mancante, il file verrà nuovamente rigenerato dal sistema.

N.B. I passi 2 e 3 lavorano assieme. Non è possibile far generare il file xml senza abilitare i raw logs.

La Sitemap è un semplice file xml che elenca tutte le pagine di un sito Web con lo scopo di semplificare notevolmente l’attività di scansione e indicizzazione da parte dei crawler dei motori di ricerca.
Introdotta da Google con il servizio Google Sitemaps, e poi utilizzata anche da Yahoo!, Ask.com, Microsoft Live Search permette ai webmaster di enumerare all’interno di un file XML tutti gli URI delle pagine di un determinato sito web. In questo modo anche i siti dinamici possono fornire URI corretti permettendo una indicizzazione più intelligente. Il protocollo è regolamentato dalla Attribution-ShareAlike Creative Commons License che ne ha reso possibile l’uso anche ad altri motori di ricerca. Per maggiori dettagli potete consultare la traduzione italiana delle specifiche del formato Sitemaps 0.90.

Uno dei principali problemi che esisteva ancora sulle sitemaps era la necessità della segnalazione manuale in appositi pannelli di controllo messi a disposizione dai singoli motori di ricerca. La segnalazione manuale era ovviamente un processo che sottraeva del tempo prezioso. Finalmente da ieri, 11 aprile 2007, è stata attuata la modalità di autodiscovery del file Sitemap.xml del proprio sito.
Ebbene da ieri, Ask.com, Google, Microsoft Live Search e Yahoo! hanno comunicato, nei loro rispettivi blog, il supporto per l’autodiscovery delle Sitemaps, ovvero la possibilità, da parte dei webmaster di specificare il percorso per la Sitemap del sito all’interno del file robots.txt.

Quindi, per segnalare a tutti e quattro i motori la presenza della sitemap, sarà sufficente inserire questa riga nel proprio file robots.txt:

Sitemap: http://www.miosito.com/sitemap.xml

Sul sito sitemaps.org è specificato anche un’altro metodo alternativo per la segnalazione, ovvero attraverso una richiesta HTTP del tipo

/ping?sitemap=http://www.miosito.com/sitemap.xml

che può essere lanciata sia attraverso un browser (classico link) ma anche usando degli script.

Ovviamente per tutti i motori rimane attiva la possibilità di segnalare manualmente il percorso del Sitemap, ma perché precludersi questa comoda possibilità?

Quello dei cosidetti link morti è un altro degli errori spesso sottovalutati. Se si scrivono le pagine a mano, piuttosto che si fanno delle piccole correzioni senza un editor che selezioni automaticamente e scriva la risorsa, è molto facile commettere errore di battitura e di conseguenza creare link morti.

Finanto che i link morti sono riferiti ad immagini, il problema è “quasi” trascurabile; ma quando si parla di collegamenti morti verso pagine interne o esterne al sito, inutile che vi dica quanto fastidio queste possano portare.

Al motore di ricerca fastidio certo non ne dà, ma immaginatevi una macchina a 200 km orari cui di fronte gli compare un bel muro. Risultato? Schianto totale, che tradotto per il nostro motore di ricerca, significa “fine della corsa”.
In altre parole, il motore di ricerca, non potendo più proseguire con la sua azione di crawling, si trova costretto a passare al sito o a comunque al link successivo, che – per inciso – potrebbe anche non essere il vostro.
Questo significa anche che l’indicizzazione viene interrotta prematuramente, prima ancora che tutte le pagine siano state recepite dal motore.

Un consiglio caloroso è quindi quello di controllare tutte le vostre pagine e assicurarvi che non vi siano collegamenti morti. Un buono strumento on line, lo potete trovare a questo indirizzo. Ogni tanto produce falsi positivi, ma nel complesso aiuta moltissimo.