Subversion unter Apache hochziehen, Basis CentOS/RHEL
-
Leute,
irgendwie macht mich das fertig, die 5000 Linux- Hexenküchenrezepte, die alle nicht funktionieren.
Also, ich habe alle Module installiert und mal ein paar Beispielrepositories angelegt, will die irgendwie als virtual hosts zur Verfügung stellen, aber wie erkläre ich's dem Indianer, sprich Apache?
In anderen Worten: In welche conf muß ich was eintragen und wo finde ich die?Achso, ja - Bin dankbar um jede halbwegs nachvollziehbare Antwort!
-
Cent OS ist mir jetzt nicht im Detail bekannt. Normalerweise werden virtuelle Hosts in der vhost.conf gepflegt soweit ich mich erinnere.
Suse hat mit yast die Möglichkeit der automatischen Konfiguration, hinterher kann man sehen was in welchen Dateinen bearbeitet wurde, um einen Überblick über Linux config Dateien zu bekommen nicht schlecht. In den meisten Dateien steht auch drinn was für was bearbeitet werden sollte.
Das kann man in einer virtuellen Maschiene installieren und später im Produktivsystem umsetzen.
Es gibt allerdings auch Oberflächen wie Plesk und Webmin.
Spätestens beim Serverhardening kommt man allerdings ohne fundierte Linuxkenntnisse nicht weit.
Mein persönlicher Favorit IIS, einfachste Konfiguration und funktioniert.
Einen virtuellen Server 2008 bekommt man ab 12,00 / Monat.Ich habe den LPIC gemacht, bin allerdings imm froh wenn ich das Thema Linux umgehen kann.
-
Ja nun, den Server hab' ich am Laufen, echte Hardware, aaaber es tut nicht ganz so, wie ich will:
In der httpd.conf finden sich die magischen Zeilen:Include conf.d/*.conf
In conf.d (ein Verzeichnis) befindet sich ein subversion.conf folgenden Inhalts:
LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so <VirtualHost *:80> ServerName subversion ServerAlias *.subversion.crazymom.de DocumentRoot /var/www/virtual/subversion ErrorLog /var/log/httpd/subversion_error_log CustomLog /var/log/httpd/subversion_access_log combined # # Example configuration to enable HTTP access for a directory # containing Subversion repositories, "/var/www/svn". Each repository # must be readable and writable by the 'apache' user. Note that if # SELinux is enabled, the repositories must be labelled with a context # which httpd can write to; this will happen by default for # directories created in /var/www. Use "restorecon -R /var/www/svn" # to label the repositories if upgrading from a previous release. # # # To create a new repository "http://localhost/subversion/stuff" using # this configuration, run as root: # # # cd /var/www/svn # # svnadmin create stuff # # chown -R apache.apache stuff # <Location /svn> DAV svn SVNParentPath /var/www/virtual/subversion # Limit write permission to list of valid users. <LimitExcept GET PROPFIND OPTIONS REPORT> # Require SSL connection for password protection. # SSLRequireSSL AuthType Basic AuthName "Subversion Repository" AuthUserFile /etc/svn-auth-file Require valid-user </LimitExcept> </Location> </VirtualHost>
svn-auth-file ist auch existent und mit Testbenutzer "test" versehen, das Verzeichnis /var/www/virtual/subversion gibts nicht nur, sondern gehört auch group apache, user apache.
Der Virtual Host ist sowohl unter http als auch unter https erreichbar. Er wird wohl laufen.
Trotzdem meldet Netbeans' Subversion- Client: beim Zugriff auf http://subversion/test oder https://subversion/testorg.tigris.subversion.javahl.ClientException: RA layer request failed OPTIONS of 'https://subversion/test': 200 OK (https://subversion)
Habe den Fehler zwar ein paarmal dokumentiert gefunden, aber Null Peilung, wie der gelöst wurde.
Hat da jemand eine gute Idee?
-
Und woher weiss der client, dass https://subversion Dein server ist? Du solltest schon Namen verwenden, die Dir auch gehören (oder alternativ, eine /etc/hosts anlegen - das funktioniert dann aber nur für jeweils einen Rechner).
Edit: Wobei, da steht ja 200 - OK... von daher sollte es daran eigentlich nicht liegen.
-
Zwischenzeitlich hatte ich herumeditiert. Mein Gateway kann das schon auflösen, ich komme ja auf den Server, also zumindest sind die Namen bekannt. Ich bin mir nur nicht sicher,, ob das wirklich an Subversion durchgestellt wird.
-
Irgendwie habe ich die Schnauze voll,
die Linux- Heinis haben's mir mal wieder voll reingedrückt, daß ich nur einfach zu blöd bin, kann die Schwachmaten weltweit aber nichtmal innerhalb eines Jahres ordnungsgemäß abfahren und durchwatschen.
Daß ich das so nicht akzeptieren mag, liegt in der Pfanne. Die Zipfelklatscher können ja noch nicht einmal ordentlich dokumentieren, was auf Client/Serverseite stattzufinden hat.Also, ich will Netbeans Subversion- Client an ein Repository binden, so daß man locker ein Projekt rückspulen kann. Netbeans läuft unter Windows, der http(s)- Server ist bezeichnetes CentOS- System, das ein Rebuild eines RHELs ist. Könnte dem einen oder anderen bekannt sein.
Ich kriege immer den Fehler 200, was ich auch immer probiere. Das ist ein RA- Layer, der nix tut, von wem auch immer der gestellt werden sollte. Nichtmal das konnte mir jmd. schlüssig einpulvern und ich weiß nichtmal, ob ich mir durch die vielen Tipps Apache nicht völlig zernagelt habe.
Ich bin jetzt echt dick gefrustet, in gog (good old germany) kriege ich keine Info und von den Latino- Trotteln will ich jetzt auch nix mehr hören. Die können nichmal Englisch, sind aber arrogant wie Graf Rotz.
-
mhh ist /test denn ueberhapt gebunden? es sieht so aus als ob es http://subversion/svn/{reponame} sein sollte.
-
kannessein schrieb:
mhh ist /test denn ueberhapt gebunden? es sieht so aus als ob es http://subversion/svn/{reponame} sein sollte.
Ja, irgendwas an dem Pfad scheint nicht zu stimmen, aber http://subversion/svn/{reponame} und https://subversion/svn/{reponame} führen noch nicht zum Ziel, Netbeans will eine Zertifizierungsdatei, aber wo finde ich die?