projectje: SVN serveren via apache met DB-backend en trac

[Boudewijn]

Hoi


Ik ben met een projectje bezig (het is een vervangend vak voor mijn hogeschool-studie, en de docent leek dit wel grappig omdat ik graag veel met Linux doe).

Op zich heb ik nog geen concrete problemen, maar ik zou het leuk vinden als mensen eens hun mening over mijn aanpak geven, of mischien zelfs wel verbeteringen aandragen. Ik heb dit nog nooit zo gedaan met subversion en er zijn dus ongetwijfeld dingen die fout gaan. Deze staan hieronder (tijdens het schrijven had ik weer iets wat ik niet weet).

de passwords die ik hier neer drop zijn 'echt', maar ze staan allemaal op een bak achter 2 firewalls die niets naar buiten serveert. Graag dus niet wijzen op de zwakke passes etc; dit is geen productie-setup.

Alles draait momenteel op mijn gentoo amd64 desktop, die is er snel genoeg voor.

Mijn doel:

Het hosten van een subversion repo met dezelfde userbase als een trac repo. Deze userbase moet makkelijk te managen zijn via een db (mysql\postgresql\ldap). Het moet mogelijk zijn om users per repo rechten te geven via wat shell scriptjes, en ook user-management moet ermee kunnen (denk aan: delete, add, password als management functies).


Hoe ga ik dat nou doen?


Ik ga mijn svn repo serveren met apache met de dav_fs module. Deze zal zich gaan authenticeren tegen een postgresql-db. Deze pgsql-db heb ik gekozen omdat trac niet met mysql werkt (zie: trac error bij initenv).

Op zich is het dus een aantal stapjes:

1: Apache-pgsql authenticatie (gedaan, werkt prima)
2: Trac laten serveren door apache (gaat niet goed, zie hieronder).
3: Apache SVN laten serveren, via mod_dav en mod_dav_fs.
4: Wat nette scripts maken om snel repo's te adden , en aan httpd.conf toe te voegen etc.


Er zullen on the fly vast wel wat wat stapjes bij komen.
Ik zit nu echter met het volgende concrete probleem:

Ik heb het trac repo naar /var/www/localhost/htdocs gemoved zodat ik het kan laten serveren door apache onder http://localhost/trac/<projectnaam>.

Dat gebeurt momenteel prima, maar de shiny webinterface die ik krijg bij localhost:8000 (tracd) kan i kdus nergens vinden. Die staat gok ik in templates, maar nergens html, php of python files.

Iemand enig idee hoe dat netjes te doen?

[GX]

Helaas kan ik weinig zinnigs over trac zeggen, gezien ik geen idee heb wat het is; over svn daarentegen wel:

Voor apache heb je svn_dav nodig en die configureer je, mod_dav is weinig interessant verder - maar wel nodig voor svn_dav; dan hoef je dat daarna alleen maar voor authenticatie te koppelen naar je apache/pqsql setup.

Die scriptjes zijn ook geen zorg, let er alleen op datje het goed doet. En met svn_dav kan je een 'parent-repos-dir' opgeven, waardoor je niet in httpd.conf continu repositories toe hoeft te voegen.

[Boudewijn]

Trac is een bug tracker die je vrij makkelijk met sf-achtige projectjes kunt combineren.
Dit is een voorbeeld van trac:
http://www.hosted-projects.com/trac/TracDemo/Demo

Heb je een voorbeeldje van de setup die jij noemt met svn_dav?

Ik ben deze trouwens even aan het doorspitten:
http://gentoo-wiki.com/HO...th_subversion_SVN_and_DAV

[GX]

Het grote svn-book (zie tigris.org) kent duidelijke voorbeelden; morgen op m'n werk kan ik wel even de configuratie plakken (die tik ik immers ook niet zo uit m'n hoofd ); daar hebben we ook 10+ svn-repositories en het is meer dan dwaas om daarvan de gegevens in bestanden te blijven proppen.

[ Voor 6% gewijzigd door GX op 27-02-2007 22:04 ]

[Boudewijn]

jep het grote svn boek (Die van o reilly dus) ken ik.
gadaar zo nog even in kijken

iig bedankt voor de respons.
zou jij nog dingen anders aanpakken?

[GX]

Los van de configuratie en dav_fs die ik anders heb aangepakt heb ik een soortgelijk systeem opgezet . We schelen in ons setup dus niet veel...

[Boudewijn]

nou ja als jij jouw setup met mij wil delen zou dat gaaf zijn.
ik maak er straks een vrij kant en klaar pakketje van, en dat gaat sf.net op.
er is al een repo met wat (on)zin, onder sf.net/projects/subfonsion, maar dat ga ik gedurende de lifecycle aanvullen (de svn van dat projectje dan)

[GX]

Eigenlijk is het heel simpel. Voor onze setup hebben we een aparte user (svn) op het systeem welke de repositories beheert en ze geautomatiseerd aanmaakt; deze is dus logischerwijs ook geauthoriseerd om met repositories te klieren.

We doen het zelf nog met .htpasswd, onze users veranderen toch zelden en het is daarmee geen moeite (er is wel een script voor geschreven) om in users aan te maken voor samba, svn, http en op de machine zelf. Hoewel dat ook allemaal met ldap kan, is het overbodig in onze situatie

code:

<Location /svn>
        DAV svn
        SVNParentPath /home/svn/repos

        # Enable this for source browsing:
        # SVNIndexXslt "/svnindex.xslt"

        AuthType Basic
        AuthName "Subversion Repository"
        AuthUserFile /etc/apache2/dav_svn.passwd
        Require valid-user
</Location>

Onder /home/svn/repos/ zitten dus alle repositories. Stel dat ik project x uit wil checken dan is die terug te vinden in /home/svn/repos/x of remote via http://host/svn/x

Ik ben nog wat te lui geweest om een xslt te maken; dus die staat nog uit De configuratie van apache is met betrekking hierop nog maar weinig aangepast

[Boudewijn]

thanks, ik zal daar straks eens mee gaan spelen

[Boudewijn]

ik schop deze weer eens vanwege het trac-probleem uit de TS.
ik ben nog geen meter verder.

iemand?

[Verwijderd]

Boudewijn schreef op maandag 05 maart 2007 @ 00:47:
ik schop deze weer eens vanwege het trac-probleem uit de TS.
ik ben nog geen meter verder.

iemand?

Waarschijnlijk een config-dingetje van Apache. Ik heb het bij een out-of-the-box install van Debian Sarge opgelost met dit in de apache config:
Alias /trac/chrome/common /usr/share/trac/htdocs

Even kijken wat die als plaatjes enzo probeert.

[Boudewijn]

die doet het ook niet.

You don't have permission to access /trac/chrome/common/ on this server.

met

code:

 Alias /trac/chrome/common /usr/share/trac/htdocs
 <Directory /usr/share/trac/htdocs>
 Order allow,deny
 Allow from all
 </Directory>

in httpd.conf, geen idee waarom het niet draait.
trac is echt wazig (of ik ben dom )


antwoord:

ik ben niet wakker.

localhost/trac/chrome/common/xml.pmg (een van die files) is prima te serveren.

maar goed, ik kan nu nog steeds geen trac serveren met apache

[ Voor 31% gewijzigd door Boudewijn op 06-03-2007 21:21 ]

[Boudewijn]

Okay dit werkt beter:

code:

<Location /projects>
  SetHandler mod_python
  PythonHandler trac.web.modpython_frontend
  PythonOption TracEnvParentDir /var/trac
  PythonOption TracUriRoot /projects
</Location>

Aan httpd toevoegen.
Zorgen dat -D PYTHON in /etc/conf.d/apache2 staat (doh).

Hiermee kan ik dus ook meerdere projecten tegelijk serveren van trac via apache dmv mod_python. Dit gaat razendsnel (ook met CGI getest, maar dat scheelt niet merkbaar).

Nu de authenticatie fixen


edit om 01:05 (7 maart):

code:

<LocationMatch "/projects/[^/]+/login">
  AuthName "Subversion repository"
  AuthType basic
  Auth_PG_host localhost
  Auth_PG_port 5432
  Auth_PG_user apache
  Auth_PG_pwd demos684
  Auth_PG_database apache_auth
  Auth_PG_pwd_table valid_users
  Auth_PG_uid_field username
  Auth_PG_pwd_field password
  Auth_PG_encrypted off
  <Limit GET POST>
    Require valid-user
  </Limit>
</LocationMatch>
#

de authenticatie

password is plaintext in de DB.
voldoet voor nu wel.

[ Voor 34% gewijzigd door Boudewijn op 07-03-2007 01:05 ]

[Verwijderd]

Ik snap je moeilijkheden eigenlijk niet, ik heb een gelijkaardige setup gedaan in Debian, gewoon een paar keer apt-get, en de instructies volgen in de desbetreffende readme.Debian van elk package? Heb je op een minuutje of 10 klaar.

[Boudewijn]

met 1 pgsql backend voor alles? deel je settings dan maar

sowieso bedocumenteer ik wel alles.
heb je soms bezwaar tegen deze draad?

[Boudewijn]

zo, weer eens een schop.

Momenteel ben ik een heel stuk verder gekomen: ik kan authenticeren tegen pgsql, en kan alles netjes serveren met apache (webdav ...).

code:

<Location /svn/repos>
        DAV svn
        AuthType Basic
        AuthName "Subversion repository"
        SVNParentPath /var/svn

        Auth_PG_host localhost
        Auth_PG_port 5432
        Auth_PG_user apache
        Auth_PG_pwd demos684
        Auth_PG_database apache_auth
        Auth_PG_pwd_table valid_users
        Auth_PG_uid_field username
        Auth_PG_pwd_field password
        Auth_PG_encrypted off

        <LimitExcept GET PROPFIND OPTIONS REPORT>
                Require valid-user
        </LimitExcept>
</Location>

Dit werkt prima, op 1 ding na. Het is nu zo dat je OF xs hebt tot alle repos, of geen xs. Dit wil ik per repo in kunnen stellen.

Momenteel werkt het met dit schema:

code:

[ocde]apache_auth=# select * from valid_users;
 id | username  | password |       creation_date
----+-----------+----------+----------------------------
  2 | boudewijn | 123      | 2007-03-17 22:04:00.644156
(1 row)

Daar wil ik om het netjes repo-afhankelijk te maken twee tabellen bij gooien, waaronder dus een koppeltabel:

code:

apache_auth=# select * from perm;
 id | repo_id | user_id | creation_date
----+---------+---------+---------------
(0 rows)

apache_auth=# select * from repos;
 id | reponame | description | creation_date
----+----------+-------------+---------------
(0 rows)

Ik gooi zo als user x met userid '1' rechten heeft op een repo met id 684, een record in "perm" met repo_id = 684 en user_id = 1.

Ik weet dat dit met pgsql kan doen met de Auth_PG_pwd_whereclause optie (zie http://www.giuseppetanzil...th_pgsql/#pwd_whereclause voor meer info).


Echter weet ik niet hoe ik nou de naam van het aangevraagde repo kan opvissen. (hierna kan ik het id ervan via de where query uitvinden etc)
Iemand een idee?

[Boudewijn]

bump

[Boudewijn]

laatste bump, ik zit er nog steeds mee.
wat wel kan is per repo een fixed conifg aanmaken met eigen where-clause maar dat is onhandig met veel repo's (telkens apache HUPen)

[CyBeR]

SVN selective auth doe je gewoonlijk met 'authz'...

[Boudewijn]

ja dat klopt.

echter zie ik (voor zover ik heb gelezen) geen mogelijkheid om autz te gebruiken icm een database.
De reden voor de DB is dat ik specifiek 1 backend wil en niet een losse voor trac en een voor svn.

[Boudewijn]

na wat research: ik kan inderdaad path based authentication gebruiken waarbij ik los in een file voor elk repo definieer wie wat mag. Nadeel is dat natuurlijk per repo aangepast moet worden enzo.

niet echt handig, maar het zou wel moeten werken (test: vandaag).