[[PageOutline]] = Verwalten der Subversion-Repositories = Der `paedml`-Rechner dient als unser Subversion-Host. Momentan verwenden wir als Zugriffsmethode "svn über ssh-Tunnel" (siehe unten). Unser Repository heißt [source:keplertools]. Es enthält zur Zeit die Unterprojekte - [source:keplertools/etc etc] (auszuchecken nach `/etc`) - [source:keplertools/scripts scripts] (auszuchecken nach `/root/scripts`) - [source:keplertools/sophomorix sophomorix] (auszuchecken nach `/usr/share/sophomorix`) - [source:keplertools/trac trac] (diverses zur Trac-Verwaltung) - [source:keplertools/LTSP-setup LTSP-setup] (Skripts zum Einrichten neuer LTSP-Server) == Clients == Jeder Nutzer, der sich per ssh am paedml-Rechner einloggen kann, kann Arbeitskopien des Repositories auschecken. Der Zugriff wird besonders angenehm, wenn der Nutzer seinen ssh-Schlüssel hinterlegt, so dass er sich über den ssh-agent einloggen kann (=Passphraseeingabe nur einmal nötig, dann jeder weitere Zugriff ohne !Passwort/Passphrase). Zum Umgang mit der Arbeitskopie siehe [http://svnbook.red-bean.com/ Subversion-Manual]. === Auschecken des kompletten Repositories === - Checkout von innerhalb des Kepler-Netzwerkes: {{{ svn checkout svn+ssh://paedml.kg-fds.de/srv/svn/keplertools }}} - Checkout von außen: {{{ export SVN_SSH="ssh -p 2222" svn checkout svn+ssh://paedml.kg-fds.de/srv/svn/keplertools }}} === Auschecken eines Unterprojektes === - Checkout von innerhalb des Kepler-Netzwerkes: {{{ svn checkout svn+ssh://paedml.kg-fds.de/srv/svn/keplertools//trunk }}} - Checkout von außen: {{{ export SVN_SSH="ssh -p 2222" svn checkout svn+ssh://paedml.kg-fds.de/srv/svn/keplertools//trunk }}} == Server == === Physikalischer Speicherort === `/srv/svn/` (z.B. `/srv/svn/keplertools`) Orientiert am [http://proton.pathname.com/fhs/ File System Hierarchy Standard (FHS)], dem [http://www.debian.org/doc/debian-policy/ch-opersys.html Debian folgt]. - WikiPedia:Filesystem_Hierarchy_Standard - [http://proton.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM Beschreibung von `/srv/`im FHS] Achtung!:: Auf den physikalischen Speicherort eines svn-Repositories wird **nie direkt zugegriffen**. Sämtliche administrativen Aufgaben erfolgen über den `svn`-Befehl. (Einzige Ausnahme: Backups.) === Einrichten eines neuen Repositories === {{{ svnadmin create /srv/svn/ }}} == Zugriffsmethode == Subversion erlaubt verschiedene Server-Szenarien. Für uns kommen zwei davon in Frage: 1. svn über ssh-Tunnel 1. svn über Apache Beide Varianten wären sinnvoll, weil 1. alle potentiellen Nutzer einen vollständigen Systemaccount besitzen, sich also ssh-Schlüssel anlegen und sich dann über ssh einloogen können. 1. der Apache V2 bereits gut läuft, mitsamt LDAP-Authentifizierung, und nur konfiguriert werden muss. Beide Methoden haben Vor- und Nachteile, besonders hervorzuheben: 1. svn über ssh-Tunnel hat potentiell Probleme mit den Nutzerrechten beim Schreiben auf das svn-Repository. Die lassen sich aber durch ein gewissenhaftes Rechtedesign lösen. 1. Apache als Server ist äußerst flexibel (wobei wir die Flexibilität auf absehbare Zeit nicht benötigen), erzeugt bei den Zugriffen aber erheblich mehr Systemlast (=langsamer) Das [http://svnbook.red-bean.com/ Subversion-Manual] ist eine hervorragende Dokumentation zu allen diesen Fragen. Wir müssen eine Entscheidung treffen, welches Szenario wir anwenden wollen. Ehrlichgesagt, bei unserem zu erwartenden Traffic (zwei aktive User und eine handvoll Dateien) ist der Systemaufwand vernachlässigbar. **Zur Zeit verwenden wir die Methode 1 (svn über ssh-Tunnel).** === svn über ssh-Tunnel === Dieser Abschnitt beschreibt die notwendigen Einrichtungsschritte für Zugriff über das `svn+ssh`-Protokoll. Bei dieser Zugriffsmethode greift jeder Nutzer unter seinem eigenen Namen auf das Repository zu. (Andere Szenarien, wie ein geteilter Account für mehrere Nutzer, siehe Svn-Manual.) Um Probleme mit Schreibrechten zu lösen, sollten alle Nutzer, die auf das Repository zugreifen, in einer gemeinsamen Unix-Gruppe sein. Bei uns habe ich dazu die Gruppe `svn` eingerichtet. {{{ smbldap-groupadd svn }}} Für jeden Nutzer ausführen: {{{ smbldap-usermod -G +svn }}} Das gesamte Repository muss der Gruppe `svn` gehören: {{{ chgrp --recursive svn /srv/svn/ }}} Alle Verzeichnisse im Repository sollten das `setgid`-Bit gesetzt haben: {{{ find /srv/svn/ -type d -exec chmod g+s \{} + }}} ==== Nutzerabhängige Konfiguration ==== - Checkout von innerhalb des Kepler-Netzwerkes: {{{ svn checkout svn+ssh://paedml.kg-fds.de/srv/svn/ }}} - Checkout von außen: {{{ export SVN_SSH="ssh -p 2222" svn checkout svn+ssh://paedml.kg-fds.de/srv/svn/ }}} - Die Nutzer müssen "vernünftige" `umask`s haben (Schreib- und Lesezugriffe für Gruppe nicht verbieten!) - Für die Nutzer wird der Zugriff besonders angenehm, wenn sie ihren ssh-Schlüssel hinterlegen, so dass sie sich über den ssh-agent einloggen können (=Passphraseeingabe nur einmal nötig, dann jeder weitere Zugriff ohne !Passwort/Passphrase). === svn über Apache === (details hierhier) == Svn und Trac == Trac unterstützt von Haus aus die Integration eines lokalen svn-Repositories. Damit das richtig läuft, müssen lediglich zwei einfache Hooks angelegt werden. Das ist hier gut beschrieben: TracRepositoryAdmin. Problem:: Die Hooks werden von dem User ausgeführt, der den svn-Zugriff macht. Bei unserem derzeitigen Setup (svn+ssh) ist das der jeweilige User selbt. Die Hooks brauchen aber Schreibberechtigung auf dem Trac-Environment. Dazu müsste jeder svn-Nutzer auf dem Trac-Envirmonment schreibberechtigt sein. Das ist in unserem svn-über-ssh-Szenario derzeit nicht gegeben. **Unser Trac läuft daher zur Zeit mit der alten `repository_sync_per_request`-Option.** Das sollte geändert werden und die Hooks eingerichtet werden, sobald Trac von Apache verteilt wird (#41). Näheres unter TracRepositoryAdmin. == Extrerne Links == - trac:TracSubversion - trac:RepositoryType