Cleanly terminated ssh sessions on Debian without using systemd control group hierarchy

26 03 2019

In a Debian 9 server, if you disable “Register user sessions in the systemd control group hierarchy” with “pam-auth-update” or you remove the package “libpam-systemd”, the ssh sessions doesn’t terminate correctly at restart or shutdown.

To fix it, enable the ssh cleanup session service unit:
cp /usr/share/doc/openssh-client/examples/ssh-session-cleanup.service /etc/systemd/system/
systemctl enable ssh-session-cleanup.service
systemctl start ssh-session-cleanup.service

And desactivate the registration of the user sessions under the systemd control group hierarchy:
sed -i '/pam_systemd/s/^/#/g' /etc/pam.d/common-session



Functional testing of Debian packages with autopkgtest and lxc

18 01 2019

These are the steps to test a .deb package with autopkgtest and lxc under Sid (future Buster).

First of all, take a fresh install of Debian Sid and install lxc:
# apt-get install lxc

Edit “/etc/default/lxc” and modify this line:

Edit “/etc/lxc/default.conf” and set the following content: = veth = lxcbr0 = up = 00:16:3e:33:22:11

Restart service to enable net and check that the “lxcbr0” is up:
# systemctl restart lxc-net
# brctl show lxcbr0
bridge name bridge id STP enabled interfaces
lxcbr0 8000.00163e000000 no

Install AppArmor to avoid a nasty bug:

lxc-start: autopkgtest-sid: lxccontainer.c: wait_on_daemonized_start: 842 Received container state “ABORTING” instead of “RUNNING”
lxc-start: autopkgtest-sid: tools/lxc_start.c: main: 330 The container failed to start
lxc-start: autopkgtest-sid: tools/lxc_start.c: main: 333 To get more details, run the container in foreground mode
lxc-start: autopkgtest-sid: tools/lxc_start.c: main: 336 Additional information can be obtained by setting the –logfile and –logpriority option

# apt-get install apparmor
# systemctl restart lxc

Create a suitable debootstrap-based container for Debian Sid:
autopkgtest-build-lxc debian sid

Now is time for the package, get the sources of it. As example, I take “gzip”:
# apt-get source gzip

Check that it have the “test” folder:
# cd gzip-1.9
# ls debian/tests/
control simple-gzip

Install a few dependencies prior building:
# apt-get install texinfo mingw-w64

Build the package:
# dpkg-buildpackage -us -uc

And finally, launch the test:
# autopkgtest ./*changes -- lxc --ephemeral autopkgtest-sid

It will finish with the following messages:
autopkgtest [00:34:20]: test simple-gzip: - - - - - - - - - - results - - - - - - - - - -
simple-gzip PASS
autopkgtest [00:34:20]: @@@@@@@@@@@@@@@@@@@@ summary
simple-gzip PASS

More info:

Display system uptime in a website

15 06 2018

Here are the steps to set up a simple website which shows the uptime values of a system.

First of all, install the requirements. Tuptime for monitor the system, apache as web server and php for the web. The web server can be nginx as well, their only requirement is that has to be able to work with php.
apt-get install tuptime apache2 php

Go to the document root location of the webserver and download the web file from the offical repo:
cd /var/www/html/
wget -O tuptime.php

That’s all, use a web browser to open the following url and view it:

Uptime web

Add autopkgtest to .deb package

25 01 2018

These are the example steps for add a very simple autopkgtest test to an existing Debian package:

  • Add to debian/control the following line:
Testsuite: autopkgtest
  • Create the folder debian/tests
  • Add the control file under debian/tests/control with the following content:
Tests: smoke
Depends: @
  • Create a simple script using the name of the test debian/tests/smoke:
  • Create the package as usual (maybe with dpkg-buildpackage -us -uc) and run the test:
autopkgtest --output-dir /tmp/output-dir1 -B my_program*.changes -- null

Note: Usefull examples in
More info:

Check SLA uptime in a linux server

13 01 2018

When a new server is up, usually from a remote provider, their reliability is covered under a Service License Agreement. In that document is reflected the garanteed uptime of the machine, a percentage value close to 100% which assure the time that the server have to be up.

There can be other clauses with the network uptime, storage uptime, what ever other service we had uptime that will aso have to be taken into account to the global uptime of our service. But now we are only going to focus exclusively on the operating system uptime. To know what is the value from our side, these are the steps:

When you have the access to the new server, as soon as posible, install the Tuptime package:

# apt-get install tuptime

Increase the sync interval. By default it save the time on disc each 5 minutes, which is ok for a normal user, but to have it as detailed proof of service, it can be done each minute. Change in “/etc/cron.d/tuptime” from:

*/5 * * * * tuptime if [ -x /usr/bin/tuptime ]; then /usr/bin/tuptime -x > /dev/null; fi


* * * * * tuptime if [ -x /usr/bin/tuptime ]; then /usr/bin/tuptime -x > /dev/null; fi

Or more agressive, assure the sync operation to disc too:

* * * * * tuptime if [ -x /usr/bin/tuptime ]; then /usr/bin/tuptime -x && sync > /dev/null; fi

Now it’s done, wait a few days or weeks and check how are things going.

Check the uptime for the last month. As one month (30 days) are 2592000 seconds, get the last n seconds from date:

# tuptime --tsince -2592000
System startups: 3 since 15:17:42 14/12/17
System shutdowns: 1 ok - 1 bad
System uptime: 97.3 % - 29 days, 4 hours, 35 minutes and 7 seconds
System downtime: 2.7 % - 19 hours, 24 minutes and 53 seconds
System life: 30 days, 0 hours, 0 minutes and 0 seconds

Check the uptime for the last year. As a year have 31536000 seconds:

# tuptime --tsince -31536000
System startups: 6 since 15:20:03 13/01/17
System shutdowns: 1 ok - 4 bad
System uptime: 94.39 % - 344 days, 12 hours, 33 minutes and 46 seconds
System downtime: 5.61 % - 20 days, 11 hours, 26 minutes and 14 seconds
System life: 1 year, 0 days, 0 hours, 0 minutes and 0 seconds>

The output give us a clear report of the uptime percentage. Even, it is possible to see the exact date and time if the “-t” table or “-l” option are passed to the command.

This is a good option to check the garanteed value without using any graph or pannel provided by the server provider. We have a strong view of how good or bad are service, any strange restart, even those that happen at intimely hours, will be registered and counted in the tuptime report.

If is required in the report an uptime / downtime percentage larger than two decimals, which is the default, use “–decp” option with the desired lenght.

More info:

Test haproxy 1.8 seamless reload

10 01 2018

How to test the seamless reload option in Haproxy 1.8.

Add into the configuration file under global section the following line:
stats socket /var/run/haproxy.sock level admin expose-fd listeners process 1

Create a reload loop for the service:
# while true ; do systemctl reload haproxy ; sleep 3 ; done

Send request while service is reloading:
# ab -r -c 20 -n 100000

Check that the report doesn’t cotains any “Failed requests”.

More info:

Fix random hangs in Debian 9 with Nouveau Nvidia graphic module

7 12 2017

With and old Nvidia graphic card, like GeForce 6150SE nForce 430, and a new Debian with the latest Nouveau module, it is common to get hangs of the kernel produced by a bad beaviour of the graphic driver.

To mitigate it, add to the file “/etc/default/grub” the following content: