svn+ssh

[MatzeLoCal]

Hallo,

ich habe ein Problem mit svn+ssh.

Wenn ich dort einen checkout machen will, muss ich mein Passwort 3x eingeben und das ist nicht nur unlustig, sondern macht die Benutzung von subversion mit XCode unmöglich, da es da nicht bis zu einem gültigen Login kommt

Thx,
LoCal

 

[quarx]

Wie wäre es damit, Dir mit ssh-keygen ein Schlüsselpaar zu erzeugen?
(siehe z.B. hier)

 

[MatzeLoCal]

Problem ist ja nicht das Passwort an sich.

Bei einem import wird es beim erstenmal akzeptiert. Wenn ich mir nun eine Schlüssel erzeuge, dann bin ich mir nicht sicher, ob das Problem nicht weiter besteht, nur ist dann der Fehler für mich schwerer ersichtlich. Du verstehst?
Gruß,
LoCal

 

[quarx]

Bei einem import wird es beim erstenmal akzeptiert. Wenn ich mir nun eine Schlüssel erzeuge, dann bin ich mir nicht sicher, ob das Problem nicht weiter besteht, nur ist dann der Fehler für mich schwerer ersichtlich. Du verstehst?

Äh, nö, nicht ganz.
Also Du möchtest eine Fehlkonfiguration des svn-Servers ausschließen? Der Zugriff auf den geschieht doch über ssh, nicht? Ich kenn das nur mit cvs, da müsste ich bei korrekter Konfiguration auch mehrfach ein Passwort eintippen, wenn ich ohne die ssh-Public Keys arbeiten würde. Ich denke mal, das wird doch bei svn genauso sein, das habe ich bisher allerdings noch nie benutzt.

 

[MatzeLoCal]

Oh. wusste ich nicht.

Also bei mir ist das so:

$svn co svn-ssh://user@server/absolute-path
Password:
Password:
Password:
...

Nach dem drittenmal Password-eingeben funzt es dann.
Im Terminal ist das ja noch nicht das Problem, aber XCode sagt mir immer, dass das anmelden fehlschlug.

Aber sollte das oben normal sein, dann werd ich das mal über Schlüssel machen.

 

[quarx]

Oh. wusste ich nicht.

Also bei mir ist das so:

$svn co svn-ssh://user@server/absolute-path
Password:
Password:
Password:
...

Ich kenne wie gesagt svn nicht. Ist das nur ein Checkout? Bei cvs würde dabei nur einmal ein Passwort abgefragt. Meine o.a. Erfahrungen bezogen sich auf Folgendes: Ich arbeite meistens mit cvs unter Linux und benutze manchmal gerne tkcvs, eine grafische Oberfläche für cvs-Repositories. Wenn ich keine ssh-Schlüssel nutze, fragt selbige Oberfläche auch 3mal nach dem Passwort (wenn ich mich recht erinnere). Wie das bei XCode aussieht, kann ich nicht sagen, da habe ich noch kein ernsthaftes Projekt inklusive Versionskontrollsystem mit bearbeitet. Deine Schilderung hatte mich halt irgendwie an die Situation bei tkcvs erinnert.

 

[MatzeLoCal]

Jup, das ist ein reiner checkout.

 

[macfriendly]

$svn co svn-ssh://user@server/absolute-path
Password:
Password:
Password:
...

Klingt für mich eher wie eine Fehlkonfiguration. Hast du Zugriff auf die Server-Logs, um nachzuschauen, warum deine ersten Login-Versuche nicht klappen.

Mit SSH-Keys müsste aber selbst kein Problem sein. Zum Testen reicht es, wenn du dich direkt per ssh auf der Kiste (mit demselben Benutzernamen wie bei svn+ssh) anmeldest. Wenn das klappt, sollte auch 'svn co' per SSH-Key nichts im Wege stehen.

> macfriendly

P.S.: Das ist mit ein Grund für mich gewesen, svn nur über das Apache-Modul mit SSL zu benutzen. Geht wunderbar intern sowie extern.

 

[MatzeLoCal]

Normal ssh funktioniert an der Kiste völlig normal. Der Server steht bei mir zuhause, darum kann ich das erst heute abend checken.

Über Apache will ich das ganz bewusst nicht laufen lassen.

 

[stk]

Moin,

*threadkaper*

hab gestern abend versucht mir einen SVN unter Apache 2.0 auf dem OS X Server (10.4.7) nach der Apple Developer Anleitung aufzusetzen.

Den Apachen kriege ich unter 8080 auf angesprochen, beim Aufruf von /svn kriege ich aber nur:

Could not open the requested SVN filesystem

Was hab ich falsch gemacht?

Gruß Stefan

 

[MatzeLoCal]

- hast du 'fsfs' oder berkeleyDB?
- wo ist dein repository gemounted?
- wie sind da die zugriffsberechtigungen?

btw.. das Apple Dokument ist nicht mehr 100% aktuell ... AFAIK

 

[stk]

Moin,

wie in dem Dok beschrieben habe ich --without-berkley-db als Option beim Kompilieren eingetragen. Also sollte fsfs übrigbleiben - oder?

Das Repository liegt auf oberster Ebene meines RAID-Laufwerks und gehörte erstmal dem lokalen Serverbenutzer (-admin). Da ich das auch erst für den Fehler hielt, hab ich's auf www:www übertragen.

Gruß Stefan

 

[MatzeLoCal]

Gerade hat mir Google folgendes Vermeldet: link

 

[MatzeLoCal]

Oder trifft es das hier besser?

 

[stk]

Moin,

»link« war's nicht, aber »das hier« hat geholfen. Thx, jetzt läuft's

Gruß Stefan

 

[pepi]

Im kostenlosen und sehr empfehlenswerten SVN Book steht geschrieben, daß svn bei einem commit mehrmals eine Verbindung zum svn Server aufbaut. Du wirst also für drei unterschiedliche Verbindungen nach dem Passwort gefragt und nicht wie vermutet dreimal für fehlgeschlagene Authentifizierungen. (Sonst würdest Du entsprechend öfter gefragt werden.)

Host keys einrichten! Auch das ist im SVN Book gut beschrieben auch mit essentiellen Hinweisen zur Sicherheit. Ich betreibe es selbst wie im SVN Book beschrieben und bin rundum glücklich.
Gruß Pepi

 

[MatzeLoCal]

So, ich habe gestern mal auf Schlüssel umgestellt. Das Problem ist weiter da.

In der angehängten Datei seht ihr den Aufbau.
User A ist auf MacBoo und PowerMac "gleich". User B ist mein Account fürs Büro. Mit B will ich zuhause eigentlich "nichts zutun haben", aber die aktuellen privaten Projekte sollen da auch vorhanden sein.

Was ich dann gestern gemacht habe war folgendes:

- User B hat das Projekt eingestellt (import)
- User A (MacBook) hat checkout (Terminal) auf das Projekt gemacht.
- User A (MacBook) startet XCode, ändert Kleinigkeit am Code und commited.
- User A (PowerMac) hat checkout (Terminal) auf das Projekt gemacht.
- User A (PowerMac) starte XCode und erhält Authentifizierungsfehler
- User A (PowerMac) will commit über Terminal machen und erhält Fehler (Dateiname is missing or locked)
- User A (PowerMac) will commit über Terminal machen und erhält Fehler (Dateiname 2 is missing or locked)
- User A (MacBook) startet XCode.
- User A (MacBook) startet XCode, ändert Kleinigkeit am Code und commited.
- User A (MacBook) will commit über Terminal machen und erhält Fehler (Dateiname is missing or locked)
- User A (MacBook) will commitheckout über Terminal machen und erhält Fehler (Dateiname 2 is missing or locked)

Im Respository liegt übrigens das gesamte XCode-Projekt... ob es vll daran liegt?
Für mich ist nunmal sehr wichtig, dass User A auf beiden Rechnern auf svn Zugriff hat.

 

[quarx]

Mal drei ganz dumme Fragen: User A (Macbook) und User A (Power Mac) arbeiten aber nicht auf einem gemeinsamen Netzlaufwerk, oder? Sonst müsstest Du ja statt des Checkout ein Update durchführen.
Und stimmen die Xcode-Versionen auf den drei Rechnern überein?
Und, drittens, hast Du beim Erstellen des Projekts als User B auch genau die detaillierten Anweisungen aus dem Abschnitt "Xcode and Subversion" der Anleitung befolgt?

 

[MatzeLoCal]

Hmm.. nö, ich habe einen "normalen" Import gemacht und halt den gesamten Projekt-Ordner. Und hier könnte evtl das Problem liegen. Also mir kommt gerade der Gedanke, dass XCode den Zugriff irgendwie speichert und wenn es der gleiche User ist ....
Die beschriebene Methode dürfte bei mir nicht 100% funzen, da ich ja BerkeleyDB nutze...

 

[macfriendly]

- User B hat das Projekt eingestellt (import)
- User A (MacBook) hat checkout (Terminal) auf das Projekt gemacht.
- User A (MacBook) startet XCode, ändert Kleinigkeit am Code und commited.
- User A (PowerMac) hat checkout (Terminal) auf das Projekt gemacht.
- User A (PowerMac) starte XCode und erhält Authentifizierungsfehler
- User A (PowerMac) will checkout über Terminal machen und erhält Fehler (Dateiname is missing or locked)
- User A (PowerMac) will checkout über Terminal machen und erhält Fehler (Dateiname 2 is missing or locked)
- User A (MacBook) startet XCode.
- User A (MacBook) startet XCode, ändert Kleinigkeit am Code und commited.
- User A (MacBook) will checkout über Terminal machen und erhält Fehler (Dateiname is missing or locked)
- User A (MacBook) will checkout über Terminal machen und erhält Fehler (Dateiname 2 is missing or locked)

Warum machst du immer einen 'checkout'? Wird doch nur zum einmaligen anlegen einer Arbeitskopie benötigt. Danach kannst du mit 'update' und 'commit' deine Arbeitskopie auf den aktuellen Stand bringen oder dem Server deine Änderungen anvertrauen.

> macfriendly