• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

(Sub-)Domain für SVN auf Ubuntu-Server

MarCologne

New Member
Hallo zusammen,

ich habe einen vServer bei einem Anbieter clean mit Ubuntu installiert und geupdatet.
Das hat alles prima funktioniert.
Dann habe ich Subversion installiert und eingerichtet.
Der SVN ist mit Usernamen/PW für verschiedene Benutzer/Projekte angelegt.
Wenn ich nun SVN nutzen will, funktioniert auch das einwandfrei, wenn ich die Verzeichnisse von extern über die IP und das Verzeichnis anspreche.
Nun würde ich aber gerne vereinfachen und für die Projekte eine Domain mit dem jeweiligen Projektnamen anlegen und nutzen:
Der Pfad ist bisher:
svn://ip.ip.ip.ip/home/repositories/ProjektA
Und soll aber sein:
svn://domainname.de/ProjektA
oder
svn://svn.domainname.de/ProjektA

Ich habe die Domain beim Anbieter registriert und auf der Weboberfläche bereits auf die Domain eingerichtet. Nun muss ich aber ja noch irgendwo eine Datei mit der Konfiguration anlegen/bearbeiten, habe leider aber keine Ahnung wo.

Ich habe hier im Forum den Code dafür gefunden (copy&paste aus einem anderen Beitrag):
Code:
<VirtualHost *>
        ServerName svn.domain.com
        ServerAdmin admin@domain.com
        <Location />
         DAV svn
         SVNParentPath /var/lib/svn
         AuthType Basic
         AuthName "Subversion Repository Access"
         AuthUserFile /etc/apache2/svn.htpasswd
          Require valid-user
        </Location>
        ErrorLog /var/log/apache2/error.log
        LogLevel warn
        CustomLog /var/log/apache2/access.log combined
        ServerSignature On
</VirtualHost>
Kann mir evtl. jemand helfen und kurz erklären, was ich dort ändern muss und wo diese Datei gespeichert/angelegt werden muss? Da hört leider mein KnowHow auf :(
Tausend Dank
 
Nun muss ich aber ja noch irgendwo eine Datei mit der Konfiguration anlegen/bearbeiten, habe leider aber keine Ahnung wo.
Zum Beispiel in einer Datei

/etc/apache2/sites-enabled/svnprojekt.conf

Die Vorlage unten kannste nicht so ohne Weiteres kopieren. Nutze lieber solche Zeilen:

<Location /ProjektA>

<Location /ProjektB>

<Location /ProjektC>


Pfiffikus,
der es auf seinem Server genau so handhabt
 
Zum Beispiel in einer Datei

/etc/apache2/sites-enabled/svnprojekt.conf

Wenn schon, dann bitte richtig...

Die Configfiles für die vHosts gehören in den Subfolder .../sites-available/ und werden mit a2ensite/a2dissite aktiviert/deaktiviert.
Danach noch ein Reload bzw. Restart des Apache.
 
Muss ich dafür den Apache2 installieren/starten?

Sähe die Datei dann so aus?

Code:
<VirtualHost ip.ip.ip.ip>
        <Location Subdomain/>
         DAV svn
         SVNParentPath /home/repositories/
         AuthType Basic
         AuthName "Subversion Repository Access"
         AuthUserFile /etc/apache2/svn.htpasswd
          Require valid-user
        </Location>
        ErrorLog /var/log/apache2/error.log
        LogLevel warn
        CustomLog /var/log/apache2/access.log combined
        ServerSignature On
</VirtualHost>

Dazu noch die Fragen:
- Welcher User (svn.htpasswd) hat darauf Zugriff? Das ist ja eigentlich in den SVN-Daten geregelt?
- Wofür sind die einzelnen anderen Zeigen? Logs könnten raus, oder?

Sorry, ich kenne mich nur so gerade mit den Grundbefehlen aus.
Danke für eure Hilfe.
 
Wenn schon, dann bitte richtig...

Die Configfiles für die vHosts gehören in den Subfolder .../sites-available/ und werden mit a2ensite/a2dissite aktiviert/deaktiviert.
Danke für diesen Hinweis. Das ist mir bekannt und auch gängige Praxis.

Doch bei dieser Gelegenheit würde ich gerne mal eine kleine Hilfestellung von Dir erbitten. Worüber ich mir die ganze Zeit schon den Kopf zermartere, kannst Du mir möglicherweise beantworten.

Welchen Sinn hat dieser Umweg über einen Link?


Bisher kam ich zu dem Ergebnis, dass dieses Vorgehen vor allem für Distributoren sinnvoll sei. Diese hätten die Möglichkeit, fertig konfigurierte Dateien für
subversion.beispiel.de
phpmyadmin.beispiel.de
backups.beispiel.de
... und weitere Subdomains
im Verzeichnis /sites-available/ bereitzustellen. Mit Hilfe des Links im Verzeichnis /sites-enabled/ können die Anwender diese Subdomains nun aktivieren oder deaktivieren/ungenutzt lassen.

Scheinbar habe ich es aber nicht korrekt verstanden. Der TO will gerade eine Datei schreiben, die er ganz gewiss auch benötigen wird. Das Feature, die Subdomain nur bei Bedarf zu aktivieren, wird von ihm ja nicht benötigt.



Pfiffikus,
der sich jetzt brennend dafür interessiert, welche Vorteile der Umweg über die Verlinkung bringen kann
 
Muss ich dafür den Apache2 installieren/starten?
Oh!
Na ich antworte trotzdem mal.

Sähe die Datei dann so aus?
Die Definition der Domain fehlt noch. Ich nehme mal die Konfiguration von meinem Server als Beispiel:
Code:
<VirtualHost *:80>
	ServerAdmin webmaster@beispiel.de

	ServerName svn.beispiel.de
	DocumentRoot /var/www/svn-beispiel-de/

	<Directory />
		Options FollowSymLinks
		AllowOverride None
	</Directory>
	<Directory /var/www/svn-beispiel-de/>
		Options Indexes FollowSymLinks MultiViews
		AllowOverride None
		Order allow,deny
		allow from all
	</Directory>

	<IfModule mod_dav_svn.c> 
		<Location /kalkulationsprojekt>
			DAV svn
			SVNPath /Repositorys/kalkulationsprojekt_repo

			AuthType Basic
			AuthName "Subversion Zentralstelle (Repository)"
			AuthUserFile /etc/irgendwo/svn-auth-file
			AuthGroupFile /etc/irgendwo/svn-group-file
			Require group kalkulation
		</Location>

		<Location /design>
			DAV svn
			SVNPath /Repositorys/design_repo

			AuthType Basic
			AuthName "Zugang zu schoenen Dingen"
			AuthUserFile /etc/irgendwo/svn-auth-file
			AuthGroupFile /etc/irgendwo/svn-group-file
			Require group designer
		</Location>
	</IfModule>

</VirtualHost>
Ob damit jede bestehende DIN eingehalten wird, entzieht sich meiner Kenntnis. Doch es funktioniert.


- Welcher User (svn.htpasswd) hat darauf Zugriff? Das ist ja eigentlich in den SVN-Daten geregelt?
Du kannst den Zugriff sowohl vom Webserver, als auch von Subversion kontrollieren lassen. Im hier gezeigten Beispiel erledigt es der Webserver. Wenn es nur darum geht, wer das Archiv nutzen darf und wenn alle Leute sowohl lesen, als auch schreiben dürfen, ist das so ausreichend.

Auf einem anderen Server habe ich als Zugriffsberechtigung
Code:
Satisfy Any
  AuthzSVNAccessFile /home/ich/SVNAccessFile.txt
eingetragen. Das ist ein Archiv, welches für jedermann zum Lesen und Auschecken zur Verfügung steht. Nur die Schreibberechtigungen werden hier von Subversion geregelt.


Pfiffikus,
der mit solchen Subversionsservern recht gut zurecht kommt
 
Hallo Nexus,

Doch bei dieser Gelegenheit würde ich gerne mal eine kleine Hilfestellung von Dir erbitten. Worüber ich mir die ganze Zeit schon den Kopf zermartere, kannst Du mir möglicherweise beantworten.

Welchen Sinn hat dieser Umweg über einen Link?
...
Scheinbar habe ich es aber nicht korrekt verstanden. Der TO will gerade eine Datei schreiben, die er ganz gewiss auch benötigen wird. Das Feature, die Subdomain nur bei Bedarf zu aktivieren, wird von ihm ja nicht benötigt.
an dieser Stelle hätte ich mich wirklich sehr gefreut, eine Antwort zu erhalten.


Pfiffikus,
der seine Kenntnisse zur Serveradministration gerne immer weiter ausbauen wollte
 
an dieser Stelle hätte ich mich wirklich sehr gefreut, eine Antwort zu erhalten
Klar doch, das hatte ich wohl damals überlesen...

Scheinbar habe ich es aber nicht korrekt verstanden. Der TO will gerade eine Datei schreiben, die er ganz gewiss auch benötigen wird. Das Feature, die Subdomain nur bei Bedarf zu aktivieren, wird von ihm ja nicht benötigt.
Das hat was mit Standardisierung zu tun.
Bspw. werden alle Konfigurationen in /etc und darunter erwartet und genau deshalb würdest du wahrscheinlich auch nie empfehlen, ein Configfile an eine völlig andere Stelle im Filesystem zu schreiben, obwohl dies (mit entsprechender Anpassung aller relevanten Pfadangeben) durchaus möglich wäre und sicher auch funktionieren würde.
 
Das hat was mit Standardisierung zu tun.
... übrigens ein Standard, der nur für Debian und Abkömmlinge gilt.

Apache selbst weiß nichts davon - weder von den Tools a2ensite und anderen, Debian-spezifischen Dingen.

... von daher würde ich es eher als "kann man auf entsprechenden Systemen so machen" bezeichnen - aber keinesfalls als Standard.
 
von daher würde ich es eher als "kann man auf entsprechenden Systemen so machen" bezeichnen - aber keinesfalls als Standard
Deswegen sprach ich auch von Standardisierung und nicht von Standard ;)
Aber der ergänzende Hinweis ist natürlich berechtigt, daß dies eine Eigenheit von Debian und dessen Derivaten ist.

BTW:
a2ensite ist übrigens kein Tool, sondern (genauso wie a2enconf, a2disconf, a2dismod und a2dissite) nur ein Symlink, der auf das Script /usr/sbin/a2enmod zeigt.
 
deshalb würdest du wahrscheinlich auch nie empfehlen, ein Configfile an eine völlig andere Stelle im Filesystem zu schreiben, obwohl dies (mit entsprechender Anpassung aller relevanten Pfadangeben) durchaus möglich wäre und sicher auch funktionieren würde.
Oh, Ertappt...! Gerne schreibe ich in den Konfigurationsdateien solche Zeilen, denn diese Dateien lege ich mir der Bequemlichkeit halber ins Homeverzeichnis:
Code:
        AuthName "Hochgeheimer Bereich des Servers"
        AuthUserFile /home/Pfiffikus/https-users.txt
        AuthGroupFile /home/Pfiffikus/https-groups.txt
        Require group privat


Pfiffikus,
der nun grübelt, ob das irgendwann einmal Probleme bereiten könnte
 
Hallo,
Ich hatte einige Zeit keine Möglichkeit das zu testen, aber noch eine Frage, die bisher nicht beantwortet wurde (oder habe ich es überlesen?)
Muss Apache2 dafür installiert werden? Ich denke schon, oder? Das hat dann aber zur Folge, dass man den Server auch über das Web erreichen kann, wenn man die URL eingibt, oder? Das wollte ich ja (wenn möglich) vermeiden.

Grüße und vielen Dank.
 
Hallo,
Muss Apache2 dafür installiert werden? Ich denke schon, oder?
Natürlich.

Hallo,
Das hat dann aber zur Folge, dass man den Server auch über das Web erreichen kann, wenn man die URL eingibt, oder? Das wollte ich ja (wenn möglich) vermeiden.
Ja wenn Du das Archiv aus dem Netz nutzen willst, muss der Server erreichbar sein.

Und wenn jemand die URL eingibt, dann zeige doch einfach eine leere Default-Seite ohne weitere Bedienmöglichkeiten.


Pfiffikus,
der das dadurch entstehende Risiko für sehr überschaubar hält
 
Ok. Ich teste es in den nächsten Tagen.
Risiko meine ich damit gar nicht mal, ich möchte eigentlich nur, dass nicht jeder sieht unter welchem Pfad es liegt und dass es "schöner aussieht" :)
 
Das ist doch kein Problem.

Wenn ein Fremder Deine Seite aufruft, http://www.beispiel.de/ , dann sieht er eine nichts sagende Standardseite. (Keine Ahnung, ob Du dafür ein Impressum umd eine Datenschutzerklärung präsentieren musst?)

Deine Daten hältst Du unter http://www.beispiel.de/mein_Geheimes_Archiv/ bereit. Und schon hast Du alles, was Du hier willst.


Pfiffikus,
der darauf hinweist, dass diese Geheimhaltung keinesfalls die ordentliche Absicherung des Servers ersetzen darf
 
Er kann das Webverzeichnis auch direkt mit einem Passwort schützen. Damit würde dann keiner mehr ran kommen.
 
Back
Top