[Thinlinc-technical] automatically unlocking screen saver on session connect?

[Jens Maus]

Hi,

now that someone has pointed you to sessionreconnect.d I just tried myself to automatically unlock a waiting xscreensaver session when connecting to an existing thinlinc session. And in fact I was able to perform exactly what you are searching for by using the following script:

— cut here —
#!/bin/sh
/usr/bin/pkill -u ${USER} --signal HUP xscreensaver &
— cut here — 

Put that into a „01-screenunlock.sh“ file in the sessionreconnect.d directory and give it executable rights. Please note that this will of course unlock ALL sessions of a particular user. So if you are running thinlinc with multisession support you would have to modify further. But in our case here (we only allow one session per user) this perfectly unlocks the right xscreensaver process.

regards,
jens

> Am 01.12.2014 um 14:47 schrieb Torsten Kasch <tk at cebitec.uni-bielefeld.de>:
> 
> Hi Carsten,
> 
> On 29.11.2014 18:10, Carsten Rose wrote:
>> According to
>> 
>> https://www.cendio.com/resources/docs/tag/configuration_customizing_user_session.html
>> 
>> 
>> there is a /opt/thinlinc/etc/sessionreconnect.d/
> 
> Oops, it seems I missed this part of the documentation -- thanks for the pointer!
> 
>> We didn't step deeper into this. Our idea was:
>> 
>> In sessionreconnect.d (vsmserver host) tell the screenlock (vsmagent host) to
>> unlock.
>> 
>> Some approaches:
> [...]
>> Option d)
>> Like (a) but instead of unlock, kill the user screenserver and start a new one
>> (might be easier than doing an unlock.
> 
> Thanks for your input; this indeed comes close to what I had in mind originally.
> Fiddling with xscreensaver-command(1) reveals that the "-deactivate" option does
> unblank the screen but wouldn't unlock it (as documented).
> 
> The Gnome counterpart, OTOH, seems to support this feature via the command line:
> I was able to successfully manually unlock a session via
> 
>    gnome-screensaver-command -d
> 
> on my old FC19 box which I currently have available for testing. I haven't yet
> succeeded in getting this command to work via a script in sessionreconnect.d,
> but I hope to find some more time to look into this later this week...
> 
> But while we're at it: looking at the output of env(1) run from such a
> "reconnect script" shows hardly any info about the session to be connected
> (apart from $USER which reveals the session's owner). Since the script
> apparently isn't called with any arguments I'm wondering if there is some
> official method to identify the user session to be connected? I tried running
> 
>    /bin/su - ${USER} -c "${TLPREFIX}/bin/tl-session-param -a /"
> 
> from the "reconnect script" but that didn't produce any output for me. From
> within the session I do get an appropriate output, though. Did I miss something
> (again)?
> 
> cheers,
> 	Torsten
> 
> _______________________________________________
> Thinlinc-technical mailing list
> Thinlinc-technical at lists.cendio.se
> Manage your subscription:
> http://lists.cendio.se/mailman/listinfo/thinlinc-technical

-- 
Dr. Jens Maus
Helmholtz-Zentrum Dresden-Rossendorf
Institute of Radiopharmaceutical Cancer Research
Department of Positron Emission Tomography
POB 51 01 19, 01314 Dresden, Germany
http://www.hzdr.de/ | +49 351 260 2757

Board of Directors:
Prof. Dr. Dr. h. c. Roland Sauerbrey,
Prof. Dr. Dr. h. c. Peter Joehnk,
VR 1693 beim Amtsgericht Dresden

(Please note a real name change effective since 5.9.2013.
Former name: Jens Langner)

*** Content is authentic only with digital signature  ***

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2358 bytes
Desc: not available
URL: <http://lists.cendio.se/pipermail/thinlinc-technical/attachments/20141201/ee02d443/attachment-0005.p7s>