ScreenLock on Jessie's systemd

Something I was used to and which came as standard on wheezy if you installed acpi-support was screen locking when you where suspending, hibernating, ...

This is something that I still haven't found on Jessie and which somebody had point me to solve via /lib/systemd/system-sleep/whatever hacking, but that didn't seem quite right, so I gave it a look again and this time I was able to add some config files at /etc/systemd and then a script which does what acpi-support used to do before

Edit: Michael Biebl has sugested on my google+ post that this is an ugly hack and that one shouldn't use this solution and instead what we should use are solutions with direct support for logind like desktops with built in support or xss-lock, the reasons for this being ugly are pointed at this bug

Edit (2): I've just done the recommended thing for LXDE but it should be similar for any other desktop or window manager lacking logind integration, you just need to apt-get install xss-lock and then add @xss-lock -- xscreensaver-command --lock to .config/lxsession/LXDE/autostart or do it through lxsession-default-apps on the autostart tab. Oh, btw, you don't need acpid or the acpi-support* packages with this setup, so you can remove them safely and avoid weird things.

The main thing here is this little config file: /etc/systemd/system/screenlock.service

[Unit] Description=Lock X session Before=sleep.target [Service] Type=oneshot ExecStart=/usr/local/sbin/screenlock.sh [Install] WantedBy=sleep.target

This config file is activated by running: systemctl enable screenlock

As you can see that config file calls /usr/local/sbin/screenlock.sh which is this little script:

#!/bin/sh # This depends on acpi-support being installed # and on /etc/systemd/system/screenlock.service # which is enabled with: systemctl enable screenlock test -f /usr/share/acpi-support/state-funcs || exit 0 . /etc/default/acpi-support . /usr/share/acpi-support/power-funcs if [ x$LOCK_SCREEN = xtrue ]; then . /usr/share/acpi-support/screenblank fi

The script of course needs execution permissions. I tend to combine this with my power button making the machine hibernate, which was also easier to do before and which is now done at /etc/systemd/logind.conf (doesn't the name already tell you?) where you have to set: HandlePowerKey=hibernate

And that's all.

Hello Debian Planet and Jessie's question

This was just meant to say hello to the Debian Planet readers, but I'll end it with a Jessie related question, so...

Intro

For those who don't know me, I was born in Betanzos, A Coruña, Galicia, in the North-West of Spain and I currently live on A Coruña. I've been a Debian developer since year 2000 when I was quite more involved than currently (live changes), but I'm always expecting to be able to dedicate more time to the project, I hope this will happen when my two children grow up a little bit.

I had been wanting to send my blog's Debian related posts to the planet but always failed to do so, yesterday I found the planet wiki page and I said... it's so easy that I don't have any excuse not to do it, so here I am.

Oh, BTW... if I ever comment on Debian's anniversary (16th of August) that at Betanzos we are launching a really huge paper balloon, it is not to commemorate Debian's date but in honour of San Roque, even though maybe we should talk to the Pita family to have Debian's logo on it for our 25th anniversary :-)

Jessie's question

In Jessie we no longer have update-notifier-common which had the /etc/kernel/postinst.d/update-notifier script that allowed us to automatically reboot on a kernel update, I have apt-file searched for something similar but I haven't found it, so... who is now responsible of echoing to /var/run/reboot-required.pkgs on a kernel upgrade so that the system reboots itself if we have configured unattended-upgrades to do so?

I really miss this stuff, I don't know if it should be on the kernel, on unattended-upgrades or where, but now that we have whatmaps... we need this feature to round it all.

End

Well, to finish I just want to say that I'm very happy to be a part of the Debian community and that I enjoy reading you guys on the planet. Thanks a lot to all the Debian folks for making Debian not only a great OS, but also a great community.

Hard asterisk times (or how sip made me unhappy till I fixed this peer definition)

It must be that I no longer touch asterisk like I used to do that it took me a while to write a type=peer section this last days.

At my first attempt copying the entry from an old peer definition I was getting a "404 Not Found" message with the asterisk server not even trying to authenticate to the peer when I was trying to make a phone call. I thought it was a problem with my asterisk not wanting to authenticate but it wasn't. What should had happen is that the asterisk should have gotten a "401 Unauthorized" message, and then it would try to authenticate.

After reading a lot I came to the solution by myself comparing asterisk messages with a csipsimple client that I had running, my asterisk was saying something like...

From: "Anonymous" ;tag=xxxx

While the csipsimple client has the server (IP or hostname) specified instead of anonymous.invalid. This first problem was solved with a fromdomain=whateveryourpeerexpects line on the peer definition.

So, I then got the 401 message and the asterisk was trying to authenticate, but this server was expeting to have an authuser on the registration (what is also called the digest username, ...) and even though on asterisk sip.conf doc there are examples on how to use authuser on "register" commands there is none explaining how to do that on a peer definition, I got to a lot of doc explaining how to do that with ways that people was saying that weren't working, patches for asterisk, ... I tested and tested and nothing worked.

I was almost going to go to bed again without fixing this (and it is about time 2AM already) when I started to test things by myself and found that it was defaultuser where I shoud specify this authuser, in fact I had tested this already but it was when I was having the 404 error, so it wouldn't work until I fixed that.

If you read the sip.conf doc, you'll find that:
;defaultuser=yourusername ; Authentication user for outbound proxies
which is quite clear and it's why I had tested it at first, but getting the 404 message made it not work, so in the end my peer looks like this:
[thepeer] type=peer host=thehostip nat=no disallow=all allow=ulaw allow=alaw fromdomain=thehostip defaultuser=theauthuser fromuser=theotheruser secret=thepassword :-)