Tests fail under headless Centos7
ahmed-bacha opened this issue · comments
Hello,
I have downloaded and tried this package under Centos7 (headless server) but the tests failed, any idea ?
[vagrant@localhost go-keyring]$ go test
--- FAIL: TestSet (0.04s)
keyring_test.go:15: Should not fail, got: The name org.freedesktop.secrets was not provided by any .service files
--- FAIL: TestGet (0.00s)
keyring_test.go:23: Should not fail, got: The name org.freedesktop.secrets was not provided by any .service files
keyring_test.go:28: Should not fail, got: The name org.freedesktop.secrets was not provided by any .service files
keyring_test.go:32: Expected password test-password, got
--- FAIL: TestGetNonExisting (0.00s)
keyring_test.go:40: Expected error ErrNotFound, got The name org.freedesktop.secrets was not provided by any .service files
--- FAIL: TestDelete (0.00s)
keyring_test.go:48: Should not fail, got: The name org.freedesktop.secrets was not provided by any .service files
FAIL
exit status 1
FAIL github.com/zalando/go-keyring 0.043s
Thanks :)
It looks like you don't have gnome-keyring installed. But even if you do it might not work because gnome-keyring will ask you to unlock the keychain by showing a gtk3 dialogbox, which isn't possible on a headless server.
We also have this issue on travis and still haven't found a way to solve it #1.
Test should run fine on a desktop with gnome-keyring installed and configured though.
I do not think that it is related to gnome-keyring, thanks any way :).
[vagrant@localhost ~]$ sudo yum list | grep gnome-keyring
Repository sysdev-main is listed more than once in the configuration
gnome-keyring.x86_64 3.14.0-1.el7 @centos
libgnome-keyring.x86_64 3.8.0-3.el7 @centos
gnome-keyring.i686 3.14.0-1.el7 centos
gnome-keyring-pam.i686 3.14.0-1.el7 centos
gnome-keyring-pam.x86_64 3.14.0-1.el7 centos
libgnome-keyring.i686 3.8.0-3.el7 centos
libgnome-keyring-devel.i686 3.8.0-3.el7 centos
libgnome-keyring-devel.x86_64 3.8.0-3.el7 centos
My second guess would be that the dbus session isn't started when you are running headless. (It's usually started by your login manager [1]).
You could try to run the tests like this:
$ dbus-launch go test
Thanks for your help, I have tried also this and the result remains the same.
[vagrant@localhost go-keyring]$ sudo systemctl status dbus
● dbus.service - D-Bus System Message Bus
Loaded: loaded (/usr/lib/systemd/system/dbus.service; static; vendor preset: disabled)
Active: active (running) since jeu. 2016-08-11 15:31:56 UTC; 6h ago
Main PID: 597 (dbus-daemon)
CGroup: /system.slice/dbus.service
└─597 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
août 11 20:11:11 localhost.localdomain dbus[597]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
août 11 20:11:11 localhost.localdomain dbus-daemon[597]: dbus[597]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
août 11 20:11:12 localhost.localdomain dbus[597]: [system] Activating via systemd: service name='org.freedesktop.machine1' unit='dbus-org.freedes...service'
août 11 20:11:12 localhost.localdomain dbus-daemon[597]: dbus[597]: [system] Activating via systemd: service name='org.freedesktop.machine1' unit=...ervice'
août 11 20:11:12 localhost.localdomain dbus[597]: [system] Successfully activated service 'org.freedesktop.machine1'
août 11 20:11:12 localhost.localdomain dbus-daemon[597]: dbus[597]: [system] Successfully activated service 'org.freedesktop.machine1'
août 11 21:04:04 localhost.localdomain dbus[597]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.fr...service'
août 11 21:04:04 localhost.localdomain dbus-daemon[597]: dbus[597]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' ...ervice'
août 11 21:04:05 localhost.localdomain dbus[597]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
août 11 21:04:05 localhost.localdomain dbus-daemon[597]: dbus[597]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Hint: Some lines were ellipsized, use -l to show in full.
[vagrant@localhost go-keyring]$ dbus-launch go test
--- FAIL: TestSet (0.00s)
keyring_test.go:15: Should not fail, got: The name org.freedesktop.secrets was not provided by any .service files
--- FAIL: TestGet (0.00s)
keyring_test.go:23: Should not fail, got: The name org.freedesktop.secrets was not provided by any .service files
keyring_test.go:28: Should not fail, got: The name org.freedesktop.secrets was not provided by any .service files
keyring_test.go:32: Expected password test-password, got
--- FAIL: TestGetNonExisting (0.00s)
keyring_test.go:40: Expected error ErrNotFound, got The name org.freedesktop.secrets was not provided by any .service files
--- FAIL: TestDelete (0.00s)
keyring_test.go:48: Should not fail, got: The name org.freedesktop.secrets was not provided by any .service files
FAIL
exit status 1
FAIL github.com/zalando/go-keyring 0.006s
It would be great if we could make this library working with this case. Python manages its keyring lib with a dedicated dbus package.
- Python DBUS :
https://pypi.python.org/pypi/dbus-python/1.2.4 - Python Keyring (works on headless Linux) :
https://pypi.python.org/pypi/keyring
Your log shows the system bus being active. dbus-launch should start a session bus but maybe it doesn't do it here since it still doesn't find the service.
Does the python keyring lib work correctly on the same setup with the secret service backend? IIRC the python keyring library will fallback to a file based storage if the secret service (dbus) interface isn't available, so make sure that isn't happening.
Hi @ahmed-bacha, do you need anything else on this topic? I'll close it for now, but ping back if you still have questions. cc @mikkeloscar