I have read the guindance that the keyring package has in its project for headless linux systems.
So the main recommendation is to install the gnome-keyring package in order to work with the Secret Service Backend.
sudo apt install gnome-keyring
Then, as I already have the dbus package installed I just run:
dbus-run-session -- sh
But, as I am in WSL 2 I get a weird prompt, it seems that PS1 is not parsed and I get something like this:
\[\e]0;\u#\h: \w\a\]\[\033[01;32m\]\u#\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]$
In a normal Debian or Ubuntu instance I would get $
I send the password to unlock the keyring
echo 'db' | gnome-keyring-daemon --unlock
I also tried to enter the password manually through stdin as this answer points out, with the same result:
gnome-keyring-daemon --unlock
Now the guide says "run your application in the same D-Bus session as the daemon". I don't know if I need to do something special to achieve that. I just run python after entering the password.
$ python
>>> import keyring
>>> keyring.get_keyring()
<keyring.backends.SecretService.Keyring object at 0x7f383b89f220>
>>> keyring.set_password("system", "username", "password")
But at this point I get this error:
dbus-daemon[9337]: [session uid=1000 pid=9337] Activating service name='org.freedesktop.secrets' requested by ':1.4' (uid=1000 pid=9339 comm="python ")
GNOME_KEYRING_CONTROL=/home/db/.cache/keyring-TPE3M1
dbus-daemon[9337]: [session uid=1000 pid=9337] Successfully activated service 'org.freedesktop.secrets'
dbus-daemon[9337]: [session uid=1000 pid=9337] Activating service name='org.gnome.keyring.SystemPrompter' requested by ':1.5' (uid=1000 pid=9356 comm="/usr/bin/gnome-keyring-daemon --start --foreground")
Unable to init server: Could not connect: Connection refused
(gcr-prompter:9364): Gtk-WARNING **: 09:36:04.690: cannot open display:
dbus-daemon[9337]: [session uid=1000 pid=9337] Activated service 'org.gnome.keyring.SystemPrompter' failed: Process org.gnome.keyring.SystemPrompter exited with status 1
** (gnome-keyring-daemon:9356): WARNING **: 09:36:04.701: couldn't create system prompt: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.keyring.SystemPrompter exited with status 1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/path/to/env/lib/python3.9/site-packages/keyring/core.py", line 60, in set_password
get_keyring().set_password(service_name, username, password)
File "/path/to/env/lib/python3.9/site-packages/keyring/backends/SecretService.py", line 87, in set_password
collection = self.get_preferred_collection()
File "/path/to/env/lib/python3.9/site-packages/keyring/backends/SecretService.py", line 67, in get_preferred_collection
raise KeyringLocked("Failed to unlock the collection!")
keyring.errors.KeyringLocked: Failed to unlock the collection!
And the processes tree look like this
I also tried with
dbus-run-session -- bash
With the same result
Possible WSL 2 Issue
I also found an issue on WSL2 project where "jaraco" says that the guidance that I followed may give some hints, but I could not get it to work.
Alternative Backend
I tried with other backend as well, though in some places they say that this backend is not recommendable:
“alternate”, possibly-insecure backends, originally part of the core package, but available for opt-in"
pip install keyrings.alt
With similar result. The keyring backend was different:
>>> keyring.get_keyring()
<keyring.backends.chainer.ChainerBackend object at 0x7ffbad5fd040>
Any alternative or recommendation? Am I missing some step? Is this possible to make in WSL 2? I think I will try in a debian machine directly to check if it is a problem of WSL or all Debian headless distros. Anybody make it work on Debian without Gnome desktop installed?
The next step would be to automate all the process, but first I need to get this to work
Update
Well, I can confirm that in a virtual machine on Debian 11.3 works fine. So it must be something to do with WSL 2
Update 2
Ah, I have just realized that I had installed the WSL2, but my Debian System was in WSL so I had to update it to WSL2 with the following instruction. Anyway, I think the behaviour, in this case would be the same.
wsl --set-version Debian 2
Note that I have been able to get this to work (WSL2, Debian Bullseye, python3, gnome-keyring, Windows 10). I can understand parts of why it may not be working for you, but there are some minor differences in the errors you are seeing from what I can reproduce (when I try to break it). We'll come back to those if we need to, but let me go through what I've tried successfully so far.
But, as I am in WSL 2 I get a weird prompt
First, I think this is an orthogonal issue, but perhaps not. I always suspect startup configuration files for this type of weirdness, so I would try eliminating those from the equation:
dbus-run-session -- bash --noprofile --norc
If the prompt looks normal when running that, I'd look to ~/.profile since it sounds like it it happens both Bash and Dash (sh) for you and Dash doesn't have an rc file.
Again, I'm assuming that's not the problem with the keyring, but it doesn't hurt to eliminate it as a potential contributor.
As for the main keyring problem, that, I believe, is because:
Gnome Keyring is attempting to ask for a password. It does this with a graphical password prompt, which fails because ...
You are running Windows 10 without an X server, or if you are running an X server, then the DISPLAY variable is "lost". That's the cannot open display error in the trace. If you were on Windows 11, the graphical prompt would display. You could also configure Windows 10 WSL to use a third-party X server like VcXsrv. Or you could run with Xrdp. See this Super User question (and others) for more info.
Of course, that would no longer count as "headless", which is your question. So we need to figure out why gnome-keyring is asking for a password. I can think of at least possible three reasons, but there may be others:
The default collection (keyring) doesn't exist yet. I'm fairly sure that's not the case for you, since it should have been created when you ran the --unlock. Of course, you can verify this by checking ~/.local/share/keyrings.
gnome-keyring-daemon hasn't yet been started, and needs the keyring password. Again, you've clearly run that here. You've done the right thing by running the dbus-run-session first, then inside that session, run the --unlock. You can, of course, verify that it is running with a ps -efH or similar.
The password that was passed via --unlock is wrong.
So with the first two eliminated, we're left with the assumption there's an issue with the unlock password. If you created the collection with the initial --unlock, then the first password you used should be the one set on the collection.
There are some "gotchas" here. First, contrary to what the answer you linked says, I'm convinced that the newline is added to the password. If you somehow initially set the password without a newline, you'd need to unlock it with echo -n. E.g.:
echo -n 'db' | gnome-keyring-daemon --unlock
Second, it doesn't sound like this was the case for you, but if you create the keyring through the normal frontend, then it appears to me that the password may be salted. I have not been able to use gnome-keyring-daemon --unlock (in any of its forms) to unlock a collection where the password was entered through the graphical prompt. To clarify:
If I initially create the keyring via gnome-keyring-daemon --unlock, then I can unlock it either through the GUI askpass program that it uses (on Windows 11 or with a Windows 10 VcXsrv installation), but ...
If I initially create the keyring via an initial access of it which prompts for the password through the GUI, then I can subsequently only unlock it through the GUI. I can no longer use gnome-keyring-daemon --unlock.
Assuming this is a new keyring in WSL2, then my advice would be to remove it and try again:
dbus-run-session -- bash --noprofile --norc
# Back them up first if you'd like
rm -rf ~/.local/share/keyrings
echo -n 'db' | gnome-keyring-daemon --unlock
python3
Note that you can test the keyring module directly from the shell via:
python3 -m keyring set system username
# Will prompt for the secret
python3 -m keyring get system username
# Should return the secret
If things are working from there, they'll work from your code. If it fails, it should do so with the same error at least. This might save some time in troubleshooting if this doesn't work.
I'm new to linux coding and have just been given an account on a server at work. I don't have sudo permissions. For some unknown reason, the 'screen' program has suddenly stopped working. Every time I try to open a screen session I get the following error
Can't locate local/lib.pm in #INC (you may need to install the local::lib module) (#INC contains: /home/user/perl5/lib/perl5/x86_64-linux-thread-multi /home/user/perl5/lib/perl5 /home/user/miniconda3/lib/site_perl/5.26.2/x86_64-linux-thread-multi /home/user/miniconda3/lib/site_perl/5.26.2 /home/user/miniconda3/lib/5.26.2/x86_64-linux-thread-multi /home/user/miniconda3/lib/5.26.2 .).
BEGIN failed--compilation aborted.
I've tried opening up my .bash_profile and .bashrc to delete any lines referring to perl or the local::lib, and I don't have permissions to install the local::lib myself. I've tried navigating to the directories listed in the error message but they also don't exist. I also tried reinstalling perl and screen into a conda environment but screen needs to be activated before the environment so I just got the same message. Both perl and screen are still installed as I can print the version.
I have no idea why screen suddenly stopped working as I don't think I did anything, and it was working perfectly fine for the first few weeks. Any ideas/help would be much appreciated!
See #dave-mitchell's comments to what local::lib is, but as for how to solve the problem, you'll probably need to install local::lib yourself in your home directory. This does not require administrative access using the bootstrap method as outlined in the local::lib documentation:
https://metacpan.org/pod/local::lib#The-bootstrapping-technique
Following that, cpanminus (cpanminus) should be able to install most perl modules using the --local-lib option as needed.
However, if this is simply a problem with screen itself not working, and you don't care about perl modules per se, then I would recommend installing tmux as an alternative to screen which is also possible to do without administrative privileges (see this superuser question) and is widely considered to be a superior option
I'm running cygwin64 on Win10-64bit and have an X11 server running with a dbus-daemon. The X11 server is run rootless using startxwin. I'm not running anything gnome or kde based (because of the problem below).
I get long pause (30+ sec) and an error like:
(process:1199): GLib-GIO-WARNING **: Problems looking up entry in keyring: Error opening keyring “/cygdrive/c/Users/dc5/.dbus-keyrings/org_freedesktop_general” for reading: Failed to open file “/cygdrive/c/Users/dc5/.dbus-keyrings/org_freedesktop_general”: No such file or directory
This happens whenever any modern X11 app tries to start: emacs-X11, gnome-terminal, etc.
I tried creating a file there, but then it complains that it isn't valid and there is still the long hang.
It isn't clear to me why anything is trying to open a keyring. Sometimes it triggers at weird times. I just hit it loading the magit package under emacs-win32.
How can I either create a keyring or make it not try to find one?
first, i am using centos 6.9, and qt creator 3.0.0
I am able to connect with server using terminal directly with command
/usr/bin/teamviewer -i [serverid] -P [password]"
then i was implement it to a button in qt with this code :
system("gnome-terminal --hide-menubar --profile=noclose -x bash -c '/usr/bin/teamviewer -i [serverid] -P [password];'");
but thats not work, it show this error :
Init...
CheckCPU: SSE2 support: yes
XRandRWait: No value set. Using default.
XRandRWait: Started by user.
Checking setup...
/opt/teamviewer/tv_bin/wine/bin/wineserver: Symbol `wine_casemap_upper' has different size in shared object, consider re-linking
/opt/teamviewer/tv_bin/wine/bin/wineserver: Symbol `wine_casemap_lower' has different size in shared object, consider re-linking
Launching TeamViewer ...
/opt/teamviewer/tv_bin/wine/bin/wineserver: Symbol `wine_casemap_upper' has different size in shared object, consider re-linking
/opt/teamviewer/tv_bin/wine/bin/wineserver: Symbol `wine_casemap_lower' has different size in shared object, consider re-linking
Launching TeamViewer GUI ...
i am also tried with different method using Qprocess .start .execute, still no luck.
I just resolved it myself.
i have installed wine in system and i guess i have deleted it correctly, but not.
it happened because I am not deleted all wine commponent correctly.
i just remove wine with yum remove wine,then it solved with yum remove wine*.
btw thanks to #nwp to change my tag question to wine and teamviewer only. Thats make me to recheck the wine package on my system.
I am a linux noob trying to setup openbox on an arch linux base. I am trying to get it as lightweight as possible in terms of resources used.
My final plan is to use openbox, with tint1 and conky.
however I am having an issue getting openbox to start. I have followed numerous guides and am struggling to figure out the problem.
I have so far installed the following (and done this config)
openbox (installed default option with the extras asked for)
create ~/.conifg/openbox
copied, rc.xml, menu.xml, autostart, environment to the above location
pyxdg
xorg-xinit
xorg-server
this didn't work so I the installed the full
xorg
still nothing, although when I try to run startx the screen goes black for a second as though it is trying, but then goes back to text mode saying it has failed.
I have had a look at the attached log file, but I don't know enough to be able to interpret it properly.
log file: https://www.dropbox.com/s/r76fowkooi822y9/Xorg.log?dl=0
I would appreciate any assistance.
Thanks
Steve
still nothing, although when I try to run startx the screen goes black for a second as though it is trying, but then goes back to text mode saying it has failed.
what is it saying?
There is only one error: (EE) open /dev/fb0: Permission denied, try starting your environment with the same configuration as root - just to see if it works. Maybe its a problem related to rootless X.
Have you configured/checked your installation (xserver, graphics driver, xinit config) using the following guides?
https://wiki.archlinux.org/index.php/xorg
https://wiki.archlinux.org/index.php/xinitrc
Try to start a minimal X (As described in the xinitrc article) to see if your xserver and graphics driver is working correctly.