Eclipse und sasl

obsigna schrieb:
Der erste Schritt ist ja in jedem Fall, daß der Server für SASL eingerichtet ist. Wenn das so erfolgt ist, wie in dem verlinkten Artikel beschrieben, dann muß man nur noch den Subversion-Client den Eclipse verwendet mit SASL-Support kompilieren, und dann sollte das einfach so funktionieren.

Das hatte ich jahrelang mit Xcode auf meinen Macs so gemacht, nämlich Subversion mit SASL-Support neu kompiliert und das Xcode-Subversion dadurch ausgetauscht. Funktionierte perfekt, bis einschließlich Xcode 9. Xcode 10 und danach kam dann ohne Subversion, und dann war die Aktion von daher sinnlos.

Jedenfalls, bei den Subversion-Clients muß nichts weiter gemacht werden - nur SASL-Support aktivieren. Hier auf einem der älteren Macs
Code: 
svn --version
:Anhang anzeigen 4541
Zum Vergrößern anklicken....
Nur des Verständnisses wegen: be mir läuft eclipse für den SVN Zugang (noch) mit folgenden "Modulen":

svn.png

Heisst dass dass nicht subclipse oder SVNKit, sonder "nur" subversion neu kompiliert werden müsste? Ich tue mich da ein wenig schwer, denn irgendwie ist das relativ undurchsichtig... Der SVNKit ist die Java Variante...
Viele grüsse :-)
 
github.com

Home

Subclipse - Eclipse SVN Provider. Contribute to subclipse/subclipse development by creating an account on GitHub.
github.com github.com

Subclipse is written against the Subversion Java interface which is called JavaHL. There are two implementations of this interface available:

JavaHL

This is the native implementation provided with Subversion itself. JavaHL is a thin Java API layer that talks to the Subversion native libraries via JNI. Subclipse provides the Java part of this, but you must have the native libraries installed, which means you also have to have the right version of those libraries installed for the version of Subclipse you are using.
Zum Vergrößern anklicken....

Für mich hört sich das ziemlich eindeutig an, nämlich daß das Subclipse-Plugin kein eigenes komplettes Subversion implementiert sondern die API des installierten Subversion benutzt.

Das kann man doch ziemlich einfach herausfinden. Man deinstalliert alle Subversions die man irgendwann mal installiert hat. Normalerweise sollte reichen
pkg delete subversion.

Wer noch 20 andere Subversions installiert hat, hat ein bisschen mehr Arbeit, aber die ist dennoch sinnvoll, denn „Es kann nur Eines geben.“

Dann sollte SVN-Zugriff via Eclipse nicht mehr funktionieren. Schließlich installiert man das eine Subversion aus den Ports neu und AKTIVIERT VORHER die SASL-Option.

Fertig.
 
Ich habe das mit SASL aufgegeben - dann müssten auch Kollegen Anpassungen vornehmen... Daher habe ich mal mit Apache und mod_dav gespielt. Dazu habe eine Jail gebaut. Darin der Verzeichnis /local/svn/repos als Basisverzeichnis der svn repositories. Der Kern dazu in https.conf ist

<Location "/">
DAV svn
SVNParentPath /local/svn/repos
AuthName "Repository"
AuthType Basic
AuthUserFile /local/svn/repos/.htpasswd
Require valid-user
AuthzSVNReposRelativeAccessFile "authz"
</Location>

Zum Testen habe ich den user svn mit Passwort in .htpasswd hinterlegt. Irgendwie möchte aber AuthzSVNReposRelativeAccessFile nicht so recht. es bleibt immer ein

[Tue Feb 07 12:33:20.259995 2023] [authz_svn:error] [pid 26385] [client 10.36.173.19:50590] Access denied: 'svn' GET xxx:/

da komme ich nicht weiter, trotz allem Spielens funktioniert es nicht so wie gewünscht. Denke ich falsch, wenn ich annehme, dass zuerst nach .htpasswd autorisiert weird und danach mittels svn und authz??

VG Norbert
 
bsd4me schrieb:
da komme ich nicht weiter
Zum Vergrößern anklicken....
Apache hat ein hervorragendes Logging, man muss es aber schon selbst hochsetzen:

Code: 
LogLevel debug authz_svn:trace6

Dies aktiviert generell Loglevel "debug" und spezifisch für das Modul authz_svn das Level "trace6".
Hinweis: authz_svn ist eigentlich unnötig, warum nutzt du dieses Modul?

Wie hast du den User svn in der Datei .htpasswd angelegt?

Rob
 
Ich würde das gar nicht so kompliziert aufziehen (make as simple as possible) und dann noch großartig mit speziellen Subversion-Setups oder gar noch Webserver rumfummeln usw.
Denn, wenn ich richtig verstanden hab, Du hast ja ein funktionierenden Subversion-Server und die Clients können sich da auch alle anmelden und tun was sie tun können sollen usw.

Es geht ja "nur" darum, das die Verbindung zum Server verschlüsselt ist. Und im Grunde tut die Lösung die Du auch schon im Visier hattest, nix anders. Nämlich diese SSH-Geschichte, wo SSH quasi die verschlüsselte Verbindung stellt.
Was dagegen sprach war ja lediglich: Will man sich deshalb ein SSH ans Bein binden wo man ja auch wieder eine zusätzliche Authentifizierung braucht usw.

Und eigentlich ist das auch nicht schwierig. Man könnte da sogar was mit Hilfe von netcat machen. :-)

Eine Nebenbedingung soll dabei sein, das man möglichst auf der Clientseite nix installieren bzw. großartig konfigurieren muss. Und dann würde ich in die Richtung gucken, was ich vorfinde und nutzen könnte (viele Systeme haben z.B. sowas wie VPN an Bord). Dazu etwas Konkretes zu sagen ist natürlich schwierig, wenn man die Gegebenheiten nicht kennt. Aber so als grundsätzlicher Weg könnte man den vielleicht gehen.
 
bsd4me schrieb:
keep it simple stupid
Zum Vergrößern anklicken....
As simple as possible, but not simpler. ;-)

bsd4me schrieb:
Ich schaue mal wegen ssh
Zum Vergrößern anklicken....
Im Prinzip kann man auch tatsächlich SSH nehmen. Man kann ja eine stripped-down-Config machen, wo man sich das ganze User-Management spart. Das wird bei Dir ja schon durch den SVN-Server gemacht. Gibt ja kein Grund es hier noch mal zu machen. Also entweder gibt man halt ein SSH-User vor, den alle benutzen. Oder man macht so einen Catch-all Ansatz und akzeptiert einfach jegliche Benutzernamen/Passwörter (wie gesagt; geht ja nicht um die Authentifizierung, sondern nur darum das die Verbindung verschlüsselt ist).

Aber wie gesagt. Eigentlich ist SSH oversized. Aber wenn es eh schon da ist und Du mit der Anwendung vertraut bist, dann kann man das natürlich so machen.
 
bsd4me schrieb:
Ich habe das mit SASL aufgegeben - dann müssten auch Kollegen Anpassungen vornehmen... Daher habe ich mal mit Apache und mod_dav gespielt. Dazu habe eine Jail gebaut. Darin der Verzeichnis /local/svn/repos als Basisverzeichnis der svn repositories. Der Kern dazu in https.conf ist

<Location "/">
DAV svn
SVNParentPath /local/svn/repos
AuthName "Repository"
AuthType Basic
AuthUserFile /local/svn/repos/.htpasswd
Require valid-user
AuthzSVNReposRelativeAccessFile "authz"
</Location>

Zum Testen habe ich den user svn mit Passwort in .htpasswd hinterlegt. Irgendwie möchte aber AuthzSVNReposRelativeAccessFile nicht so recht. es bleibt immer ein

[Tue Feb 07 12:33:20.259995 2023] [authz_svn:error] [pid 26385] [client 10.36.173.19:50590] Access denied: 'svn' GET xxx:/

da komme ich nicht weiter, trotz allem Spielens funktioniert es nicht so wie gewünscht. Denke ich falsch, wenn ich annehme, dass zuerst nach .htpasswd autorisiert weird und danach mittels svn und authz??

VG Norbert
Zum Vergrößern anklicken....

Brauchst du die AuthzSVN überhaupt? Genügt es nicht über htaccess zu authentifizieren? Du kannst ja jauch mehrere locations erstellen für die einzelnen rRpos. Oder hast du wirklich ein SVN Repo und darin die Pfade unterschiedliche berechtigt?
 
Ich denke, die nette Diskussion können wir erstmal hier beenden :-)

Ich danke allen, die sich beteiligt haben. Viele Grüsse! Norbert :-)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben