[SOLVED] How can I lock kwallet from the command line?
Tags:
None
Registered Member 
|
I'd like for kwallet to be locked when my computer is suspended. I understand that you can lock kwallet automatically when the screensaver starts, but sometimes I manually suspend the computer, which bypasses the screensaver. There is a poll for this.
Since it appears that this is not possible, I'd like to write a suspend/hibernation script to lock the wallet. Is it possible to lock the wallet from the command line?
Last edited by sparhawk on Sat Apr 20, 2013 9:52 am, edited 1 time in total.
|
Administrator
|
Running the following should cause all wallets to be closed. Please note that if applications are interacting with the wallets, it may not work, in which case you may need to use the per-wallet interface instead.
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
|
Registered Member
|
Thank you again; that works great!
For the future, is there anywhere where all of these commands are documented? |
|
Administrator
|
To the best of my knowledge, there is no written documentation on these, however many KDE applications do use D-Bus and often offer an interface over which certain actions can be invoked.
You can use the tools 'qdbus' and 'qdbusviewer' to interact with applications connected to D-Bus.
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
|
Registered Member
|
Thanks again. I did have a brief look at qdbus, but I found it hard to know which method to use, and what additional parameters to use in some cases. I guess it is what it is. Cheers. |
|
Registered Member
|
I wanted to automatically lock kwallet when suspending. However, it doesn't seem to work so well. Quoting myself from this thread.
I guess that's not surprising, given your warnings. |
|
Administrator
|
What you could try and do is enable the screen lock on resume functionality, which should trigger a screensaver - and thus allow the "lock on screensaver" functionality to safely close the wallet in a normal, expected manner.
Given that Network Management did not need to open the wallet to retrieve the password to connect, the lack of automatic connection may be another issue altogether though. Does it normally automatically connect on login?
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
|
Registered Member
|
Ah okay. Not a bad idea, although then I'd have to type my password in twice on wake. Not too bad though. EDIT: although thinking about this, if I lock the screen on resume, is there any additional security to be gained from locking the wallet specifically? If it's unlocked, and no one can log in as me, isn't it still safe?
Yes it does. I assumed it was something to do with it thinking it needed access even though the password was cached. It seems like the network passwords are stored in the wallet. EDIT2: Hmm… Having lived with a few more suspend/wake cycles, I'm not sure if I'm hitting a different issue. Now (with no changes to the wallet system), it occasionally takes ages (e.g. minutes) to connect to my default network. It's circumstantial evidence, but if I then click on my network, then it's almost instantaneous. EDIT3: With a few more days of running sleep/wake cycles, I'm almost certain that my comments in EDIT2 are correct. Almost every time I wake from suspend, it takes about a minute or more to connect. If I open up the network plasmoid and click on my network, it's almost instantaneous. (I've had the wallet open at all times, to prevent potential issues confounding my testing.) |
|
Administrator
|
It could be that NetworkManager is waiting for the system to settle down and for scans to complete before it connects to the strongest network signal. Unfortunately it is hard to know why this is happening without some detailed logs from NetworkManager unfortunately. Could you try and time the delay to see if it happens to occur when the clock moves on to the next minute?
If this is what is happening, NetworkManager may not be handling the suspend properly.
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
|
Registered Member
|
FWIW I am only in range of a single wifi signal that is set to connect to automatically.[/quote]
Should I check these logs?
No, the last time I checked, it took almost two minutes to automatically connect, and finally connected at 40 seconds past the minute. |
|
Administrator
|
Even with only a single network in the area, a site survey will often wait out the full amount of time to give all available access points the chance to be detected, depending on the channel they are on and to account for interference.
The NetworkManager logs can usually be found in /var/log/NetworkManager/ or similar - it is distribution dependent unfortunately.
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
|
Registered Member
|
That's a possibility, although it was working fine in the last version (Kubuntu 12.10). It seems quite a strange "feature" to add, though.
Okay, it's in the kernel logs for Ubuntu (/var/log/kern.log). The output is pasted below. I've included the automatic idle-induced suspend, the wake up, and the connection of the wifi.
|
|
Administrator
|
Thanks. I couldn't see anything too out of the ordinary there to indicate why it may be taking so long to resume the connection.
Perhaps monitoring of the NetworkManager log files might reveal more clues as to why it is waiting? (Note that KDE Network Management doesn't control the automatic connection, that is left up to NetworkManager to perform when it is possible)
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
|
Registered Member
|
Sorry, perhaps I was being vague. I meant that in Ubuntu, the NetworkManager log files are all mixed into the kernel logs, which are what I pasted in my last post. |
|
Administrator
|
Hmm, that is unfortunate then, as there is nothing of particular detail in there which can help.
You'll need to ask the NetworkManager folks why this happens then I guess, as only they will know how to enable the debugging output from NetworkManager needed to ascertain why it is waiting so long to initiate a connection.
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
Bookmarks
Who is online
Registered users: Bing [Bot], daret, Google [Bot], Sogou [Bot]
