wiki:AdminSvn
close Warning: Can't synchronize with repository "keplertools" (/srv/svn/keplertools does not appear to be a Subversion repository.). Look in the Trac log for more information.

Version 24 (modified by Rüdiger Kupper, 15 years ago) ( diff )

Zum Ändern der Gruppen müssen die smbldap-* Kommandos verwendet werden

  1. Verwalten der Subversion-Repositories
    1. Clients
      1. Auschecken des kompletten Repositories
      2. Auschecken eines Unterprojektes
    2. Server
      1. Physikalischer Speicherort
      2. Einrichten eines neuen Repositories
    3. Zugriffsmethode
      1. svn über ssh-Tunnel
        1. Nutzerabhängige Konfiguration
      2. svn über Apache
    4. Svn und Trac
    5. Extrerne Links

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 keplertools. Es enthält zur Zeit die Unterprojekte

  • etc (auszuchecken nach /etc)
  • scripts (auszuchecken nach /root/scripts)
  • sophomorix (auszuchecken nach /usr/share/sophomorix)
  • trac (diverses zur Trac-Verwaltung)
  • 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 ​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/<project>/trunk <project>
  • Checkout von außen: 
    export SVN_SSH="ssh -p 2222"
svn checkout svn+ssh://paedml.kg-fds.de/srv/svn/keplertools/<project>/trunk <project>

Server

Physikalischer Speicherort

/srv/svn/<repos> (z.B. /srv/svn/keplertools)

Orientiert am ​File System Hierarchy Standard (FHS), dem ​Debian folgt.

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/<repos>

Zugriffsmethode

Subversion erlaubt verschiedene Server-Szenarien. Für uns kommen zwei davon in Frage:

  1. svn über ssh-Tunnel
  2. 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.
  2. 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.
  2. 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 ​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 <username>

Das gesamte Repository muss der Gruppe svn gehören: 

chgrp --recursive svn /srv/svn/<repos>

Alle Verzeichnisse im Repository sollten das setgid-Bit gesetzt haben: 

find /srv/svn/<repos> -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/<repos>
  • Checkout von außen: 
    export SVN_SSH="ssh -p 2222"
svn checkout svn+ssh://paedml.kg-fds.de/srv/svn/<repos>
  • Die Nutzer müssen "vernünftige" umasks 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 vom svn-User ausgeführt und brauchen Schreibberechtigung auf dem Trac-Environment. 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.
Note: See TracWiki for help on using the wiki.