Übersicht

Die erforderlichen Jobs für die Installation von svn mit Schlüsselringunterstützung und die Installation der Collabnet keyring_tool Anwendung sind bereits für unsere Linux-Server durchgeführt.

1) Konfigurieren Sie den SVN-Client so, dass er den Schlüsselring verwendet:

1.1) Bearbeiten Sie ~/.subversion/config

[auth]
password-stores = gnome-keyring

1.2) Bearbeiten Sie ~/.subversion / Server

[global]
store-passwords = yes
store-plaintext-passwords = no

2) Erstellen Sie einen Schlüsselring für Ihr Passwort. Sie werden aufgefordert, ein neues Passwort zu erstellen, um den Schlüsselring zu entsperren; dies kann alles sein, was Sie Wunsch:

keyring_tool --create=svn

3) Setzen Sie den neuen Schlüsselring als Standard:

keyring_tool --setdef=svn

4).bash_profile oder .bash_login (vorausgesetzt, Sie verwenden bash als Terminal)

    if [ -e /usr/bin/gnome-keyring-daemon ]; then
      if [ ! -z "`kill -0 $GNOME_KEYRING_PID 2>&1`" ]; then
        # Create dbus transport link for SVN to talk to the keyring.
        eval `dbus-launch --sh-syntax`

        # Start the keyring daemon.
        # The use of export here captures the GNOME_KEYRING_PID, GNOME_KEYRING_SOCK
        # env values echoed out at startup.
        export `/usr/bin/gnome-keyring-daemon`
      fi
    fi

5).bash_logout

    # Kill the message bus established for SVN / Keyring communication
    if [ ! -z "`kill -0 $DBUS_SESSION_BUS_PID 2>&1`" ]; then
      kill $DBUS_SESSION_BUS_PID > /dev/null 2>&1
    fi

    # Kill the Gnome Keyring Daemon prior to logout.
    if [ ! -z "`kill -0 $GNOME_KEYRING_PID 2>&1`" ]; then
      kill $GNOME_KEYRING_PID > /dev/null 2>&1
    fi

Hintergrund

Ich bin auf ein ähnliches Problem gestoßen, als ich versuchte, einen problemlosen Weg zu finden, um den autorisierten Benutzerzugriff auf bestimmte SVN-Repos bei der Arbeit sicherzustellen. Grundsätzlich mussten wir die Überprüfung der Anmeldeinformationen jedes Mal erzwingen, wenn ein Benutzer auf den Server zugreift, sodass selbst der Befehl svn update dies tun würde authentifizierung erforderlich. Offensichtlich war die Speicherung von Klartext-Passwörtern nicht möglich, daher habe ich mit ein wenig Recherche den Gnome-Schlüsselring verwendet, um unsere Benutzerbasis mit ständigen Authentifizierungsanforderungen zu belästigen und gleichzeitig unbefugte Benutzer von Repositorys fernzuhalten, auf die sie keinen Zugriff haben sollten.

Ein Großteil unserer täglichen Arbeit wird über SSH-Tunnel in einen RedHat-Server mit X-Unterstützung erledigt, sodass ich einen Weg um die X11-Unterstützung finden musste. Nach einiger Suche gelang es mir, den Weg zu finden um es hier:

Ausgangsmaterial

Http://support.wandisco.com/index.php?/Knowledgebase/Article/View/362/17/how-to-setup-encrypted-svn-password-storage-using-gnome-keyring-in-an-ssh-session

Der Schlüssel hier ist die Verwendung des Collabnet keyring_tool, um einen Schlüsselring ohne den Gnome-Keyring-Manager-Client zu erstellen und den dbus-launch selbst zu erstellen, anstatt SVN das Setup übernehmen zu lassen. SVN verwendet DBUS, um eine Verbindung zum gnome-Keyring-Daemon herzustellen und die allgemeine Authentifizierung. Wenn Sie die dbus-Sitzung manuell mit-sh-syntax starten und abreißen, vermeiden Sie es, beim Start von dbus eine Verbindung zu einem X-Client herzustellen. Wenn Sie gerade den Gnome-Keyring-Daemon starten und versuchen, SVN zu verwenden, werden Sie weiterhin nach Ihrem Schlüsselringkennwort gefragt, aber dann auch nach Ihren SVN-Anmeldeinformationen. Die Dbus schlagen fehl, wenn SVN versucht, sie zu starten, da kein X-Client vorhanden ist.Anscheinend verwendet SVN beim Starten der Dbus keine speziellen Flags.

Zuerst möchten Sie Ubuntu One ausschließlich über die Befehlszeile ausführen. Werfen Sie einen Blick durch die [[1]}Ubuntu One FAQ . Die FAQ sagt es ist derzeit nicht möglich, aber es gibt einige CLI-Tools wie u1sdtool und u1sync. Es gibt auch einen Satz von FAQs auf Ubuntu One bei Launchpad; Der Inhalt kann derselbe sein wie der vorherige wiki.ubuntu.com link.

In Bezug auf Ihre eigentliche Frage gnome-keyring-daemon - , die FAQ schlägt vor, (1) Auto-Login einstellen und (2) Ihr Schlüsselring-Passwort mit Ihrem Login-Passwort synchronisieren. Dies würde (theoretisch) die Kennwortaufforderung vermeiden, aber es würde erfordern, dass mindestens eine grundlegende X-Sitzung ausgeführt wird.

Es gibt einen [[21]}Ubuntu One Bug / Wishlist auf dem Launchpad, der es einfacher macht, kopflose Systeme zu handhaben. Anscheinend wird das Erstellen aus dem Quellcode für eine Lightweight-Installation empfohlen (um die Notwendigkeit aller GUI-Bibliotheken und wie). Dieser Kommentar ist alt, aber besonders interessant:

Das Problem ist, dass wir Python-gnomekeyring verwenden. Damit wir Headless unterstützen können, müssen wir zu Python-Keyring wechseln und das Speichern von Token an einer anderen Stelle als Gnome-Keyring auf Headless-Displays handhaben. Nichts davon wird jedoch für die karmische Verpackung passieren, da sie eingefroren ist, und diese Änderung wäre in einer SRU nicht akzeptabel.

Für Lucid sollten wir einen robusteren Authenticaton haben service, der es uns ermöglichen sollte, Headless Displays besser zu unterstützen.

Ich kann nicht sagen, ob dieser "robustere Authentifizierungsdienst" tatsächlich für Lucid eingerichtet wurde; Basierend auf den Paketabhängigkeiten scheint der Ubuntu One-Client immer noch von Python-gnomekeyring abhängig zu sein.

Ich hatte einige Erfolge damit, mysql-workbench dazu zu bringen, mit gnome-Keyring in einer x-forwarded SSH-Sitzung zu arbeiten. Dies war ein Konto, das die Publickey-Authentifizierung verwendete (kein Passwort).

Ich habe dbus-run-session verwendet, um dies zu erreichen, sobald eine Verbindung zur ssh-Sitzung hergestellt wurde:

dbus-run-session bash -c 'GNOME_KEYRING_CONTROL=1 mysql-workbench --verbose'

Hoffentlich ist diese Information für jemanden nützlich!