hg Server Notizen
Ziel: hg Repositories mit anderen Entwicklern teilen, so dass diese die Repositories klonen und branchen können. Ebenso soll es möglich sein, Änderungen auf den Server zu pushen. Die Inhalt der Repositories sollen über ein Webinterface sichtbar sein. => Mini-Version von bitbucket.org
Für den hg/ssh-Zugriff kommt mercurial-server zum Einsatz, dass einfach aus den Paketquellen installiert werden kann.
Website: http://www.lshift.net/mercurial-server.html
Dokumentation: http://dev.lshift.net/paul/mercurial-server/docbook.html
Anschließend muss ein HOME-Verzeichnis für den hg-Benutzer eingerichtet und konfiguriert werden. Dieser Schritt geht aus der offiziellen Dokumentation leider nicht hervor. Wenn man ihn vergisst, scheitert der spätere Aufruf des refresh-auth Skripts mit folgender Fehlermeldung:
No section: 'paths'
Must be run as the 'hg' user
Standardmäßig ist in der Datei /etc/passwd das Verzeichnis /var/lib/mercurial-server eingetragen. Ich benutze lieber /srv/hg, um alle Serverdienste an einer Stelle zu vereinen.
$ sudo usermod -d /srv/hg hg
$ sudo mkdir /srv/hg
$ sudo mkdir /srv/hg/.ssh
$ sudo mkdir /srv/hg/repos
$ sudo touch /srv/hg/.mercurial-server
$ sudo chown -R hg:hg /srv/hg
| Datei /srv/hg/.mercurial-server |
| # WARNING: a .mercurial-server file in your home directory means # that refresh-auth can and will trash your ~/.ssh/authorized_keys file. [paths] repos = ~/repos authorized_keys = ~/.ssh/authorized_keys keys = /etc/mercurial-server/keys:~/repos/hgadmin/keys access = /etc/mercurial-server/access.conf:~/repos/hgadmin/access.conf [env] # Use a different hgrc for remote pulls - this way you can set # up access.py for everything at once without affecting local operations HGRCPATH = /etc/mercurial-server/remote-hgrc.d |
Als nächstes muss mindestens ein root-Benutzer angelegt werden. Dieser Benutzer darf alle Repositories lesen und schreiben, sowie neue Repositories (durch Rüberklonen) anlegen. Esmüssen folgende Befehle ausgeführt werden. username ist der Name des neuen Benutzers und hostname der Name des Public Keys.
$ cd /etc/mercurial-server/keys/root
$ mkdir username
$ sudo nano username/hostname
In die Datei username/hostname muss der SSH-Public Key des Benutzers eingetragen werden. In der Regel handelt es sich um den Inhalt der Datei ~/.ssh/id_rsa.pub auf der Workstation.
Nun müssen nur noch die Berechtigungen aktualisiert werden. Der Befehl erzeugt keine Ausgabe, wenn alles in Ordnung ist.
$ sudo -u hg /usr/share/mercurial-server/refresh-auth
Die Datei /etc/mercurial-server/access.conf ist standardmäßig mit folgenden Berechtigungen konfiguriert:
Neue Benutzer können nun angelegt werden, indem ihre Public Keys nach /etc/mercuria-server/keys/users/username/hostename kopiert werden. Anschließend muss wieder refresh-auth ausgeführt werden:
$ sudo -u hg /usr/share/mercurial-server/refresh-auth
Für einfache Setups ist das in Ordnung. Komfortabler ist jedoch die Administration über das spezielle Repository hgadmin. Es ist nicht identisch mit den Verzeichnissen innerhalb von /etc/mercurial-server/keys, sondern ergänzt diese. Anders gesagt: Benutzer, die direkt in diesem Verzeichnis angelegt wurden, können nicht über das hgadmin-Repository wieder entfernt werden und umgekehrt. Der Vorteil des Repositories ist aber, dass keine Shell-Verbindung zum Server hergestellt werden muss und dass alle Konfigurationsänderungen durch mercurial verwaltet werden,
Zunächst klont man sich also auf seine Workstation das hgadmin-Repository rüber:
$ hg clone ssh://server/hgadmin
Wenn das nicht klappt (repository not found), liegt es daran, dass man das HOME-Verzeichnis des hg-Benutzers manuell angelegt hat. In diesem Fall muss man zunächst auf dem Server das Repository hgadmin anlegen. Anschließend kann der clone-Befehl wiederholt werden.
$ cd /srv/hg/repos
$ sudo -u mkdir hgadmin
$ cd hgadmin
$ sudo -u hg hg init
$ sudo -u hg nano .hg/hgrc
| Datei /srv/hg/repos/hgadmin/.hg/hgrc |
| # WARNING: when these hooks run they will entirely destroy and rewrite # ~/.ssh/authorized_keys [extensions] hgext.purge = [hooks] changegroup.aaaab_update = hg update -C default > /dev/null changegroup.aaaac_purge = hg purge --all > /dev/null changegroup.refreshauth = python:mercurialserver.refreshauth.hook |
Innerhalb des Repositories findet man dann wieder ein Verzeichnis keys und die Datei access.conf (wenn nicht, können sie einfach angelegt werden). Über einen Hook ist sichergestellt, dass nach jedem Push die Zugriffsberechtigungen serverseitig aktualisiert werden. Das Skript refresh-auth muss also nicht manuell auf dem Server ausgeführt werden.
Als erstes sollte man die Datei access.conf, wie sie bisher auf dem Server in /etc/mercurial-server liegt, in das Repository aufnehmen. Ebenso alle Public Keys. Anschließend die Änderungen mit folgendem Trio bestätigen:
$ hg add
$ hg commit
$ hg push
Von nun an, können /etc/mercurial-server/access.conf und /etc/mercurial-server/keys gelöscht oder zumindest in ein Backup-Verzeichnis verschoben werden. Die Administration erfolgt dann ausschließlich über das hgadmin-Repository.
Unter Umständen kann es sinnvoll sein, den Benutzer nicht für alle Repositories Schreibzugriff einzuräumen. In diesem Fall schlägt die Dokumentation vor, für jeden Benutzer eine eigene "Benutzergruppe" einzurichten und in der Datei access.conf die Repositories zu hinterlegen. Zum Beispiel so (für den Benutzer dennis, der Zugriff auf repo1 und repo2 bekommen soll).
$ cd hgadmin
$ mkdir keys/dennis
$ nano keys/dennis/hostname
hostname ist hierbei wieder der Name eines SSH-Public Keys. In die Datei access.conf muss folgendes eingetragen werden:
write repo=repo1 user=dennis/*
write repo=repo2 user=dennis/*
Aus der Dokumentation geht hervor, dass repo= und user= mit den Wildcards * oder ** arbeiten. Ein Blick in das Handbuch lohnt sich hier.
