For more than a month, my primary task at SecureDrop land is to make the project ready for a distribution update. The current system runs on Ubuntu Xenial, and the goal is to upgrade to Ubuntu Focal. The deadline is around February 2021, and we will also disable Onion service v2 in the same release.
Tracking issue
There is a tracking issue related to all the changes for Focal. After the initial Python language-related updates, I had to fix the Debian packages for the same. Then comes the Ansible roles for the whole system, setting up the rebase + full integration tests for the system in CI. A lot of new issues were found when we managed to get Focal
based staging instances in the CI.
OSSEC test failure
This particular test is failing on Focal staging. It checks for the port 1514
listening on UDP on the monitor
server via OSSEC. The first thing we noticed that the output of the command is different in Xenial
and on Focal
. While looking at the details, we also noticed that the OSSEC
service is failing on Focal. Now, this starts via a sysv
script in the /etc/init.d/
directory. My initial try was to follow the solution mentioned here. But, the maild
service was still failing most of the time. Later, I decided to move to a more straightforward forking
based service file. Works well for the OSSEC monitoring service. So, I decided to have the same systemd service file for the agent in the app server.
But, the installation step via Ansible failed before any configuration. When we install the .deb packages, our configuration provider package tries to restart the service via the post-installation script. And that fails with a complaint that /var/ossec/etc/client.keys
is not found. If I try to start the service manually, I get the same error with an exit code 1
.
At this moment, I was trying to identify how was it working before, we are using the same codebase + the sysv
on Xenial
, but package installation works. The systemd generates the following service file:
# Automatically generated by systemd-sysv-generator
[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/ossec
Description=LSB: Start daemon at boot time
After=remote-fs.target
[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/ossec start
ExecStop=/etc/init.d/ossec stop
After digging for hours, I noticed exit 0 at the end of the old sysv
script. This file was last modified by late James Dolan around seven years ago, and we never had to touch the same.
Now I am planning to have 1
in the SuccessExitStaus=
line of the service file for the agent. This will keep the behavior the same as the old sysv
file.
[Unit]
Description=OSSEC service
[Service]
Type=forking
ExecStart=/var/ossec/bin/ossec-control start
ExecStop=/var/ossec/bin/ossec-control stop
RemainAfterExit=True
SuccessExitStatus=1
[Install]
WantedBy=multi-user.target
from Planet Python
via read more
No comments:
Post a Comment