ka.da

Aller au contenu | Aller au menu | Aller à la recherche

mercredi, janvier 30 2008

Mercurial : partage de dépôts différents en http et https + push par https

J’ai commencé à regarder du côté des SCM[1] (marre de la gestion CPOLD ;-) il y a quelque temps déjà, et m’était tout d’abord arrêté sur Subversion [2] étant novice en la matière. Il s’est vite révélé peu adapté à ma pratique : “développement” sur plusieurs machines pas toujours online, et pas de serveur dédié toujours en ligne pour stocker mes dépôts. Depuis peu, ce dernier problème s’est réglé (merci Gandi Hébergement[3]) mais pour autant, j’ai abandonné Subversion pour Mercurial, un gestionnaire de code source distribué.

Je ne vais pas entrer ici dans les détails sur les caractéristiques d’un gestionnaire de code source distribué, ses avantages, ou même sur une présentation détaillée sur Mercurial et son mode de fonctionnement (je vous laisse visiter le site officiel pour cela). Je vais uniquement présenter des détails sur la configuration que j’ai mise en place afin de parvenir à partager aisément des dépôts différents via http et https, ainsi que comment faire pour autoriser la mise à jour de ceux-ci via https.


présentation des dépôts Mercurial sur le web


Imaginons que vos dépôts soient stockés dans /mercurial et que vous vouliez pouvoir donner un accès en lecture sur le web, à l’adresse http://hg.domain.tld. Nous allons configurer Apache et Mercurial pour ce faire.

Tout d’abord, nous allons créer un emplacement pour les fichiers web et le script CGI en Python pour Mercurial. Prenons /var/www/domain.tld/hg. Créons à cet endroit un répertoire hgweb dans lequel nous allons placer le script hgwebdir.cgi que vous pouvez trouver sur votre système (sous Debian /usr/share/doc/mercurial/examples/hgwebdir.cgi) ou sur le site de Mercurial. Éditez ce fichier pour avoir à la fin :

def make_web_app():
    return hgwebdir("/etc/mercurial/hgweb.config")

Nous allons ensuite créer le fichier /etc/mercurial/hgweb.config avec un contenu comme suit :

[paths]
depot1  =  /mercurial/depot1
depot2  =  /mercurial/depot2

On peut également utiliser la directive [collections] pour partager une hiérarchie de dépôts mais nous partons du principe que l’on veut contrôler précisément ce que l’on partage.

À partir de là, il nous reste à configurer Apache. Créez un fichier /etc/apache2/sites-available/hg.domain.tld afin de déclarez votre VirtualHost. Voici en exemple mon fichier

NameVirtualHost *:80

<VirtualHost *:80>
    ServerAdmin webmaster@hg.domain.tld

    ServerName hg.domain.tld  

    DocumentRoot /var/www/domain.tld/hg

    <Directory /var/www/domain.tld/hg/>
        Options FollowSymLinks +ExecCGI
        AddHandler cgi-script .cgi
        DirectoryIndex hgweb/hgwebdir.cgi
        AllowOverride None

        RewriteEngine on
        RewriteBase /hgweb
        RewriteRule ^$ hgwebdir.cgi  [L]
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteRule (.*) hgwebdir.cgi/$1  [QSA,L]
    </Directory>

    LogLevel warn
    ErrorLog /var/log/apache2/hg.domain.tld-error.log
.   CustomLog /var/log/apache2/hg.domain.tld-access.log combined
    
    ServerSignature Off
</VirtualHost>

Notez ici les règles de réécriture qui permettent de faire disparaître hgwebdir.cgi de vos URL. C’est ce qui m’a pris le plus de temps à trouver avant de tomber sur cette doc.

Activez votre nouveau “site” ainsi que les modules Apache dont vous aurez besoin

# a2ensite hg.domain.tld
# a2enmod mod_python
# a2enmod rewrite
# /etc/init.d/apache2 restart

Vous pouvez maintenant aller voir http://hg.domain.tld et parcourir vos dépôts Mercurial depot1 et depot2


partager des dépôts différents par https


Tout ça, c’est très bien, mais on aimerait également pouvoir avoir accès à certains dépôts que l’on ne veut pas donner en lecture à tout internet : des dépôts privés en somme. Nous allons donc partager ceux-ci sur un site sécurisé avec authentification.

Nous allons donc retourner dans notre répertoire /var/www/domain.tld/hg/hgweb, copier hgwebdir.cgi en hgwebdirssl.cgi et éditez ce fichier pour avoir :

def make_web_app():
    return hgwebdir("/etc/mercurial/hgwebssl.config")

Créons le fichier /etc/mercurial/hgwebssl.config avec :

[paths]
depot1  =  /mercurial/depot1
depot2  =  /mercurial/depot2
depot_prive3 = /mercurial/depot3
depot_prive4 = /mercurial/depot4

Et retournons éditer /etc/apache2/sites-available/hg.domain.tld pour y ajouter :

# en haut du fichier
NameVirtualHost *:443

# à la fin du fichier
<VirtualHost *:443>
    ServerAdmin webmaster@hg.domain.tld

    ServerName hg.domain.tld

    DocumentRoot /var/www/domain.tld/hg

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/hg.domain.tld.pem
    SSLCertificateKeyFile /etc/apache2/ssl/hg.domain.tld.key

    <Directory /var/www/domain.tld/hg/>
        Options FollowSymLinks +ExecCGI
        AddHandler cgi-script .cgi
        DirectoryIndex hgweb/hgwebdirssl.cgi
        AllowOverride None

        RewriteEngine on
        RewriteBase /hgweb
        RewriteRule ^$ hgwebdirssl.cgi  [L]
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteRule (.*) hgwebdirssl.cgi/$1  [QSA,L]

        AuthUserFile /etc/mercurial/hgweb.htpasswd
        AuthGroupFile /dev/null
        AuthName "hg.domain.tld Mercurial repository"
        AuthType Basic
#       <LimitExcept GET OPTIONS>
                Require valid-user
#       </LimitExcept>
    </Directory>

    ErrorLog /var/log/apache2/hg.domain.tld-error.log

    LogLevel warn

    CustomLog /var/log/apache2/hg.domain.tld-access.log combined
    ServerSignature Off

</VirtualHost>

On retrouve ici les directives rewrite que nous avons utilisé dans la première partie, à la différence qu’elles pointent vers le CGI spécifique à notre configuration SSL, et quelques directives spécifiques justement à https/SSL. Bien évidemment, il vous faudra créer un fichier de mots de passe (nommé ici hgweb.htpasswd) avec :

# htpasswd -c /etc/mercurial/hgweb.htpasswd hguser

pour autoriser l’utilisateur hguser.

Notez les directives <LimitExcept GET OPTIONS> qui, si elles sont décommentées, permettent à tout le monde de visualiser les dépôts tout en demandant une authentification pour interagir via les commandes de Mercurial (clone, pull, push…).

Rechargez la configuration d’Apache et regardez la différence entre http://hg.domain.tld et https://hg.domain.tld


autoriser la mise à jour des dépôts via https


Pour autoriser le push via https, une fois le travail ci-dessus effectué, il suffit d’éditer la configuration des dépôts en modifiant le fichier .hg/hgrc de chaque projet. Éditez-le ou créez-le et insérez les lignes suivantes :

[web]
allow_push = hguser


utilisation


Voilà c’est fait, vous pouvez maintenant interagir très simplement avec vos dépôts Mercurial. Pour cloner un dépôt public

$ hg clone http://hg.domain.tld/depot1

Pour cloner un dépôt privé

$ hg clone https://hguser@hg.domain.tld/depot_prive3

Pour mettre à jour (push) ce même dépôt

$ hg push https://hguser@hg.domain.tld/depot_prive3

J’ajouterais que le plus dur est de gérer finement les droits d’accès aux divers fichiers nécessaires au bon fonctionnement de cette configuration. Pour faire simple, comme d’habitude, laissez le minimum de droits sur les fichiers de configuration (appartenance à l’utilisateur www-data et lecture pour lui), et pour les dépôts j’ai choisi la solution un groupe devel pour mon utilisateur principal ainsi que www-data et les droits pour ce groupe.

mise à jour : il semble nécessaire (depuis les dernières mises à jour de Mercurial ?) d’ajouter une ligne baseurl = dans la section [web] des fichiers .hg/hgrc afin de cacher les hgweb(dir).cgi dans les url.

Notes

[1] définition en français et en anglais

[2] cf cet article

[3] je sais que je n’ai pas parlé de cette nouvelle offre très intéressante de Gandi le registrar bien connu (pour sa qualité de service, son support et son engagement) alors allez voir le bar de gandi

jeudi, juin 1 2006

sortie de Ubuntu Dapper Drake et de Gandi v2

Aujourd'hui 1er juin, c'est un grand jour puisque qu'on a :

  • la sortie de la nouvelle version de Ubuntu, Dapper Drake, également nommée 6.06 LTS, 6.06 parce qu'elle sort en juin 2006 et LTS parce que c'est la première à avoir un support commercial longue durée (long term support).
    Vous pouvez la télécharger sur le site de Ubuntu ou sur le site français (attendez quand même la mise à jour des mirroirs ;-).
    Il est intéressant de noter que cette fois-ci, vous avez comme versions officielles non seulement la version Ubuntu avec l'environnement Gnome par défaut, mais également KUbuntu avec KDE, XUbuntu avec XFCE, et même le projet Edubuntu version d'Ubuntu dédiée à l'éducation. Si vous voulez, vous pouvez même recevoir de jolis CDROM pressés de votre distribution Ubuntu favorite grâce au programme ShipIt, et ainsi en distribuer à tous vos amis susceptibles de passer à Linux...
  • la nouvelle version du site de Gandi le célèbre registrar Internet français. Il faut bien avouer que la version précédente n'était pas vraiment belle, ni même pratique à utiliser, problèmes qui sont normalement réglé avec cette nouvelle version (voir la présentation).. Pour information, Gandi soutient de nombreux logiciels libres dont Dotclear[1] et Debian. [via]

update : comme je le disais, le développeur principal de Dotclear fait partie de l'équipe Gandi, et on se doutait (savait ?) qu'ils proposeraient une offre d'hébergement de blogs, et bien maintenant on en est sûr ils offriront bien une offre d'hébergement basé sur Dotclear 2 : GandiBlog [via canardplus.com]

Notes

[1] Olivier Meunier son développeur principal a été embauché par Gandi

dimanche, novembre 27 2005

achetez votre .info

Si vous avez envie d'avoir votre propre nom de domaine (que ce soit pour héberger votre site web, avoir des adresses e-mails sans dépendre de votre fournisseur ou d'un webmail comme yahoo, gmail...), c'est le moment ! En effet :

  • gandi propose en ce moment le '.info' à 1€ [cf le bar de Gandi] ;
  • 1&1 proposent eux gratuitement un pack comprenant un nom de domaine .info, et un hébergement de site web pendant 3 ans... [via monde de nerds]

update : vous pouvez également obtenir un .be sur namebay ou eurodns gratuitement... mais est-ce vraiment une bonne affaire ?