Repository Git via Https/WebDav con IIS 7.5
Nei giorni scorsi ho avuto la necessità di ospitare alcuni repostitory Git su un server Windows preso in hosting, generalmente l’accesso ai file contenuti nei repository avviene mediante il protocollo SSH…purtroppo però Microsoft non integra client e server SSH nei suoi sistemi operativi. Il problema in sè potrebbe essere risolto installando ottimi programmi come: OpenSSH e PuTTY, nel mio caso però volevo lasciare il più possibile integra la configurazione di fabbrica del server quindi ho optato per una soluzione basata sul protocollo WebDAV e comunicazioni protette con HTTPS. Una soluzione di questo genere non richiede l’installazione di software accessori sui client Windows e sui PC dei colleghi che utilizzano MacOS o Linux.
Il processo descritto in questo articolo fa riferimento a Windows Server 2008 R2 versione inglese ma la procedura è sostanzialmente identica per Windows 8 .x o Windows 7 Professional.
Attenzione: utilizzate questa guida SOLO se avete familiarità con gli strumenti di gestione server Windows e IIS e/o SOLO sotto la supervisione di un sistemista Windows con esperienza.
Quello che vi servirà
Tutto quello che vi servirà è il programma d’installazione di Git nella sua declinazione per Windows e, opzionalmente, TortoiseGit per facilitare le operazioni sui vostri repository dai client. Scaricate quindi:
msysGit da: http://code.google.com/p/msysgit/downloads/list?q=full+installer+official+git
e TortoiseGit da: http://code.google.com/p/tortoisegit/downloads/list
Come configurare il server
1. Installazione di Git
Questa è la parte più semplice di tutto il processo…utilizzando il programma d’installazione di msysGit installate l’ambiente Git sul Server. Non dovendo lavorare direttamente sui repository l’integrazione con Windows Explorer sul server non interessa molto, la Git Bash fornita nel pacchetto è più che sufficiente:
Per quanto riguarda il resto dell’installazione potete mantenere le opzioni suggerite dal programma:
2. Preparazione del filesystem
Per mantenere la configurazione del server il più pulita possibile potete creare un nuovo gruppo d’utenti chiamato “GIT Users” al quale verranno aggiunti gli utenti che potranno lavorare sui repository. Aprite il “Server Manager” e selezionate “Groups” dalla voce “Local Users and Groups”, quindi create il nuovo gruppo e aggiungete gli utenti membri:
Ora preparate il filesystem. Nella mia installazione è stata creata, direttamente nella radice del disco fisso, una cartella chiamata “git_repo” destinata a ospitare le sottocartelle corrispondenti ai vari repository. File e cartelle resteranno perciò esterni al percorso predefinito in IIS per i siti Internet (c:\inetpub\wwroot), e si ridurrà il pericolo che manovre maldestre nella configurazione di IIS espongano i sorgenti al mondo intero. Inoltre risulterà più semplice assegnare i permessi d’accesso ai file. Si dovranno poi assegnare alla cartella “c:\git_repo” tutti i permessi di lettura, modifica e cancellazione al gruppo “GIT Users”. Ho enfatizzato “tutti” perché nella mia installazione ho dovuto aggiungere il permesso “Delete subfolders and files” dal pannello dei permessi avanzati (premere il pulsante “Advanced” nella scheda “Security” della finestra delle proprietà della cartella, cliccare sul pulsante “Change permissions…” della finestra “Advanced SecurySettings” quindi selezionare il gruppo “GIT Users” e premere il pulsante “Edit…”, attivare tutti i permessi necessari e confermare con “Ok” in tutte le finestre), qui sotto riporto un paio di immagini illustrative del processo:
A questo punto utenti, cartelle e permessi sono stati impostati procedete con la configurazione di IIS.
3. Preparazione di IIS
Per prima cosa vi dovrete assicurare che tutti i componenti di IIS necessari al funzionamento del protocollo WebDAV via HTTPS siano correttamente installati (do per scontato che IIS sia già installato sul server e pienamente funzionante). Aprite il programma “Server Manager” e selezionate “Web Server (IIS)” da “Roles” quindi scrollate la finestra verso il basso fino al pannello “Roles services”. Controllate che i componenti “WebDAV publising” e “Basic Authentication” siano stati installati, nel caso non lo fossero basterà selezionarli dall’elenco e cliccare sul link “Add Role Services”. I due servizi serviranno per attivare e configurare il protocollo WebDAV e per l’autenticazione di base degli utenti sul webserver. Qui sotto riporto un paio di immagini esemplificative:
4. Configurazione di IIS
In questa prima parte verranno configurate le impostazioni di base per siti Internet serviti mediante connessioni sicure HTTPS. Se il vostro webserver dispone già di una configurazione di questo tipo potete saltare questi primi step e passare alla creazione dell’application pool impiegata per l’accesso ai repository Git.
Per poter configurare una connessione HTTPS vi occorrerà un certificato contenente una chiave crittografica che verrà utilizzata per proteggere la connessione, se non diponete di un certificato autenticato da una Certificate Authority (CA) potete crearne uno autofirmato utilizzando l’apposita funzione del pannello d’amministrazione di IIS. Nota: i certificati di questo tipo non vengono riconosciuti come validi da Git, verrà tuttavia spiegato come sopprimere il controllo di validità del certificato sui PC client. Per creare un vostro certificato aprite “Internet Information Services Manager”, selezionate il nodo del sever dall’elenco ad albero “Connections” e fate un doppio click sull’icona “Server certificates” per aprire l’apposito pannello di gestione. Cliccate ora su “Create Self-Signed Certificate…”, digitate un nome per il vostro certificato e premete il pulsante “Ok”.
In alternativa potete utilizzare le funzioni del pannello “Server Certificates” perimportare un certificato in vostro possesso o richiederne uno a una CA (servizio a pagamento). La trattazione di questi argomenti è però fuori dalla portata di questa guida.
Ora potete creare un nuovo set di impostazioni di base per siti Internet serviti mediante connessioni HTTPS. Selezionate il nodo “Sites” dall’albero “Connections” e cliccate sul link “Add new site..” dal pannello “Actions”, digitate un nome per il nuovo sito Internet e scegliete il percorso cui farà riferimento (nel mio caso “Default Secure Web Site” e “c:\inetpub\wwroot”). Selezionate quindi “https” nel combobox “type” del gruppo “Binding” e scegliete il certificato che avete precentemente creato (o importato) nel box “SSL Certificate” poi premete il pulsante “Ok”.
A questo punto potete passare alla creazione dei vostri repository.
Nella mia configurazione ho ritenuto opportuno creare una nuova application-pool con la quale far girare tutti i repository Git, in questo modo potrei decidere di interrompere l’accesso ai repository (ad esempio per interventi di manutenzione) senza dover sospendere la pubblicazione di altri siti Internet o applicazioni presenti sul server. Nel caso condividiate questa scelta dovrete selezionare il nodo “Application Pools” e cliccate sul link “Add Application Pool…” dal pannello “Actions”, digitate un nome al nuovo pool di applicazioni (nel mio caso “GIT AppPool”) e premere “Ok”. Nel mio caso ho tolto anche il supporto al framework .NET, qui sotto riporto un’immagine con le opzioni da me utilizzate:
Ora potete creare una nuova applicazione web e farla puntare alla cartella che conterrà i repository Git (“c:\git_repo” nella mia installazione). Cliccate con il tasto destro del mouse sul nodo corrispondente al sito Internet con le impostazioni di default per le comunicazioni HTTPS (nel caso di questa guida “Default Secure Web Site”) e selezionate “Add Application”. Digitate un alias per la vostra applicazione (ad esempio “git”), scegliete l’application-pool appena creato (“GIT AppPool” oppure il pool di applicazioni già esistente che avete deciso di utilizzare) e selezionate la cartella creata in precedenza destinata a ospitare i repository Git (“c:\git_repo” in questa guida) quindi confermate con “Ok”. Nell’immagine qui sotto riposto le mie scelte:
Ora dovrete proteggere la cartella dei repository consentendone l’accesso ai soli utenti forniti di username e password validi. Per raggiungere questo scopo dovrete necessariamente utilizzare il sistema d’autenticazione di base di IIS (l’autenticazione Windows non funzionerà con i client Git), selezionate perciò il nodo corrispondente all’applicazione appena creata (“git”) e fate doppio click sull’icona “Authentication” quindi disattivate l’accesso anonimo selezionando “Anonymous Authentication” e cliccando sul link “Disable” (dal pannello “Actions” sulla destra), quindi selezionate “Basic Authentication” e cliccate sul link “enable” (sempre dal pannello “Actions”), assicuratevi che la “Windows Authentication” sia disabilitata e premete sul pulsante “Ok”. Dovreste avere una situazione simile a quella rappresentata dall’immagine qui sotto.
Uscite dal pannello “Autentication” e aprite le impostazioni relative alla cifratura del canale HTTPS facendo doppio click sull’icona “SSL Settings”. Attivate l’opzione “Require SSL” per abilitare la cifratura dei dati e lasciate su “Ignore” la richiesta dei certificati per i client, come nell’immagine qui sotto:
A questo punto dovrete abilitare il protocollo WebDAV, selezionate nuovamente il nodo corrispondente alle impostazioni di base per i siti Internet accessibili via HTTPS (“Default Secure Web Site” in questa guida) e fate doppio click sull’icona “WebDAV Authoring Rules”, quindi cliccate sul link “Enable” dal pannello “Actions” (sulla parte destra della finestra).
Abilitato il protocollo WebDAV dovrete ora definire le regole di collaborazione su file e cartelle per gli utenti dei repository, selezionate l’applicazione creata in precedenza (“git” in questa guida) e, anche in questo caso, fate doppio click sull’icona “WebDAV Authoring Rules”. Aggiungete una nuova regola di collaborazione cliccando sul link “Add Authoring Rule…”, permettete la modifica a tutti i tipi di file selezionando “All content” dal gruppo “Allow access to:” e restringete l’accesso ai soli utenti abilitati attivando l’opzione “Specified users:” del gruppo “Allow access to this content to:” e scrivendo i loro username nell’apposita casella. Nota: con l’autenticazione di base di IIS gli utenti che effettuano il login sul sito non vengono ricondotti al gruppo d’appartenenza di Windows, in questo caso perciò non funzionerebbe specificare “GIT Users” nella casella “Specified roles or user groups:”. Un’altra considerazione…questa regola varrà per ogni repository creato nella cartella “git_repo”, potrete in seguito restringere ulteriormente l’accesso creando altre regole di collaborazione WebDAV per ciascuna delle cartelle dei repository Git. Per finire concedere i permessi di lettura, scrittura accesso ai sorgenti attivando le opzioni “Read”, “Write” e “Source” nel gruppo “Permissions:” (il pemesso “Source” serve ad autorizzare o negare l’accesso ai file mappati agli handlers ASP, PHP, Perl, ecc… in IIS).
Come ultima cosa occorrerà segnalare a IIS come comportarsi con i file del repository privi di estensione (per default IIS notifica un errore 404…non proprio l’effetto desiderato). Tornate al pannello principale della vostra applicazione web (“git” nel mio caso) e fate doppio click sull’icona “MIME Types”, cliccate poi sul link “Add..” nel pannello delle “Actions”. Nella finestra relativa al nuovo MIME Type digitate “.” nella casella “File name extension:” e “application/octet-stream” in “MIME Type” come nell’immagine riportata qui sotto.
La configurazione di IIS è finita…o quasi. Per ogni singolo repository potrete successivamente intervenire sulla configurazione di IIS per consentire l’accesso solo ad alcuni utenti, variare le regole di collaborazione WebDAV, ecc…
5. Creazione di un repository Git
Finita la configurazione del server non resta che creare i repository Git. Per prima cosa create una nuova cartella all’interno di quella destinata a ospitre i vostri repository e chiamatela con il nome che desiderate ed estensione “.git” (come esempio utilizzerò il repository di un’applicazione chiamata “MyToDo”, creerò quindi la cartella “c:\git_repo\MyToDo.git”). Aprite ora la “Git Bash” utilizzando l’icona creata dal programma d’installazione di Git e posizionatevi all’interno della cartella del repository utilizzando il comando “cd”, nel mio caso: “cd /c/git_repo/MyToDo.git” (ricordatevi che questa è una shell GNU/Linux, comandi e relative sintassi sono quelle del sistema operativo open source).
A questo punto non resta altro che inizializzare il repository specificando l’opzione “bare”, obbligatorio per consentire le operazioni di push. Digitate perciò il comando “git –bare init” e poi “git update-server-info”, il repository verrà inizializzato con tutte le cartelle e i file necessari a Git, qui sotto trovate un’immagine del contenuto del repository di test dopo l’inizializzazione.
Il repository è finalmente pronto, ora dovrete configurare i client.
Come configurare i client
1. Installazione di Git
L’installazione di Git sui client è simile a quella effettuata sul server, l’unica cosa che potreste voler cambiare è l’integrazione con Window Explorer. Il programma d’installazione è infatti in grado di aggiungere i comandi “Git Bash Here” o “Git GUI Here” ai menù di contesto di Windows Explorer, rispettivamente per aprire una shell Git Bash nella cartella nella quale siete posizionati o aprire una rudimentale interfaccia grafica che potreste utilizzare per creare, clonare o aprire un repository. In alternativa msysGit propone l’installazione di Git Cheetah un’estensione cross-platform per file manager che prende a modello Tortoise SVN…al momento però il progetto sembra molto lontano dal raggiungimento dell’obbiettivo. Nel mio caso ho deciso di attivare la sola estensione “Git Bash Here”, per le altre fasi dell’installazione ho invece conservato le opzioni suggerite.
2. Installazione di Tortoise Git
Essendo abituato a utilizzare le estensioni Tortoise CVS e Tortoise SVN in Windows Eplorer la scelta del client GUI da installare non è stata difficile per me… Questo passaggio è facoltativo ma vivamente consigliato. Tortoise Git, come i suoi “cugini”, può darvi una grossa mano nel gestire le operazioni di commit, push, pull e gestione dei conflitti. L’installazione di Tortoise Git e molto semplice l’unica scelta che vi verrà proposta riguarderà il client SSH da utilizzare (scelta comunque non importante ai fini di questa guida), ToroisePlink (discendente da PuTTY) o OpenSSH fornito con Git.
3. Preparazione del repository locale
Ora potete creare la versione locale del repository sul PC client. Innanzitutto posizionatevi nel percorso dove desiderate creare il repository e aprite la Git Bash utilizzando l’apposita icona o o il comando “Git Bash Here” dal menù di contesto in Windows Explorer. Se avete utilizzato un certificato non autenticato da una CA per cifrare la connessione HTTPS sul server (come nel caso di questa guida), dovrete comunicate a Git di non verificarne la validità. Digitate quindi il comando: “git config –global http.sslVerify false” (purtroppo nella mia installazione è stato necessario sopprimere il controlle dei certificati a livello globale, Git ignorava questa impotazione a livello di singolo repository e non sono riuscito a stabilire se questo fosse un comportamento desiderato di Git, un mio problema di configurazione o un bug…).
Ora potete clonate il repository (anche se ancora vuoto) utilizzando il comando “git clone https://<server_host_name>/<repository_git> <nome_repository_locale>”, nel mio caso: “git clone https://<host_server>/git/MyToDo.git” e digitate la password dell’utente quando richiesto. Nota: se la vostra connessione passa attraverso un proxy server dovrete prima comunicare a Git i parametri del proxy utilizzando il comando: “git config http.proxy http://<proxy_host_name>:<porta_proxy>”.
Attenzione: al momento della scrittura di questo articolo sembra esserci un problema in Windows con l’autenticazione di base via HTTPS/WebDAV per le operazioni di push. Sembra infatti che al comando “curl” non vengano passati correttamente username/password…Per ovviare a questo problema dovrete creare nella cartella principale del vostro utente (dal prompt dei comandi di Windows digitate “set HOMEPATH” per controllare l’esatta posizione) un file chiamato “_netrc” (senza estensione) e aprirlo con un qualunque editor di testi, dovrete po aggiungere una linea del tipo: “machine <host_name_server> login <vostro_utente> password <vostra_password>” e salvate il file. Nella configurazione di Git non potrete inoltre specificare username e/o password direttamente nell’URL del repository remoto utilizzando una sintassi del tipo: “https://<username>:<password>@<server_url>”. Utilizzando questo sistema le operazioni di push funzioneranno senza problemi ma avrete scritto in chiaro vostri dati d’accesso al server…Una soluzione veramente poco accettabile, il file potrebbe essere letto da qualsiasi programma malevolo e passato in chissà quali mani…credo proprio che realizzerò un mio stub per il comando curl che decifri il file prima di eseguire un comando e lo torni a cifrare al termine.
Le stesse operazioni sopra descritte possono essere eseguite anche con TortoiseGit. Per prima modificate la configurazione di Git per sopprimere il controllo di validità dei certificati SSL, in Windows Explorer premete il tasto destro del mouse nella cartella scelta per contenere i repository e selezionate “Settings” dal menù “TortoiseGit”.
Nella finestra di configurazione di TortoiseGit selezionate il nodo “Git” e premete il pulsante “Edit global .gitconfig”, quindi aggiungete l’impostazione “sslVerify = false” nella sezione “[http]” (se non sono presenti aggiungetele voi), salvate le modifiche e premete il pulsante “Ok”.
Per clonare il repository utilizzate il comando “Git clone…” dal menù di contesto di Window Explorer, copilate il campo “URL” con l’indirizzo del repository remoto (nel mio caso “https://<host_server>/git/MyToDo.git”), controllate che il percorso del repository locale sia corretto nel campo “Directory” quindi confermate con “Ok”. TortoiseGit eseguirà per voi gli opportuni comandi Git e recupererà i file dal repository remoto comunicandovi l’esito delle operazioni.
Finito! Da questo momento in poi potrete lavorare sul vostro repository locale ed effettuare tutte le operazioni di commit, push, pull, ecc. che desiderate!