check_apt's future

[Robie Basak]

Hi,

(I looked to include the nagios-plugins fork in this email also, but was
unable to find a suitable mailing list)

For people following the Ubuntu Server list, note that this relates to
our nagios-plugins source package.

I submitted
https://github.com/monitoring-plugins/monitoring-plugins/pull/1260 a few
days ago. Since then there has been some discussion on IRC, and I am
wondering where to go from here, wearing my Ubuntu hat.

Before I address the pull request itself and its implications, I'd first
like to talk about check_apt maintenance from a wider perspective.

A bigger issue is that check_apt has gone unmaintained for a while. The
main issue for Ubuntu is this bug:
https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/1031680

This affects two successive LTS releases of Ubuntu, with no fix on the
horizon. The problem is the fundamental mechanism used to detect
updates, which (inadvertently) makes assumptions about pockets. Since
Ubuntu has separate -updates and -security pockets, check_apt fails to
differentiate between regular and security updates correctly, since apt
may choose to install a security update from an -updates pocket.

I think we're all agreed that the solution is to replace check_apt
entirely with a new code base.

Ubuntu already ships a tool with the update-manager-common package
in /usr/lib/update-notifier/apt-check. This does pretty much exactly the
right thing, except that its CLI is different to the expected standard
for monitoring tools.

In the bug, Simon Déziel has kindly written and published a replacement
shell wrapper that just calls apt-check for the required information.
He has provided it with a liberal license. As far as I can see, this
does exactly the right thing.

From a distribution perspective, this is perfect since it's a simple,
tiny and easy to review shell wrapper, and only has a direct dependency
on update-manager-common, which in Ubuntu anyway.

I understand that this is not suitable for upstream monitoring-plugins
since it's written in shell and uses python-apt, and you have a policy
of accepting C and Perl only.

I also understand that as a consequence you want check_apt rewritten in
C and to use libpkg-apt directly. But nobody has stepped up to do this
work in two years, and there seems to be little point in this (from a
distribution perspective) since an alternative is already available.

Finally, with my pull request, I understand that you had some
reservations in accepting the patch, since it's distribution-specific.
But check_apt itself is distribution specific.

So what I'd like to propose is:

1. Remove check_apt from the upstream codebase entirely, since it's
broken and unmaintained. Upstream will then not have to maintain the
broken plugin any more. If in the future it gets rewritten to your
standards, then it could be reintroduced easily enough.

1b. If you don't want to do this, then I'd like to consider removing
check_apt in an Ubuntu-specific patch, since it's broken on Ubuntu and
may mislead users into believing that their systems are up-to-date
security-wise.

1c. For Debian, I guess it's up to Jan. He could do what we do (below),
or patch check_apt back in, since the bug doesn't quite affect Debian in
the same way. At least this way, distribution-specific stuff
can stay in a distribution-specific place, which I think is what
upstream want?

2. Recommend use of Simon's replacement instead. I can put this into
Ubuntu's release notes.

3. Consider hosting Simon's replacement in some package in the
distribution. Then you won't have to worry about maintaining
distribution-specific upstream. For Ubuntu, maybe we could shove Simon's
code into update-manager-common, to go side-by-side with check-apt
itself. For Debian, it might make sense to move check-apt and Simon's
code into a package elsewhere (and for Ubuntu to follow suit). As far as
I can see the only dependency these two scripts have are on python-apt,
so I think should be straightforward if we can decide where it should
go.

3b. Or perhaps I should patch Simon's replacement into our
nagios-plugins source package? I would definitely not want to name it
check_apt to prevent confusion of course. With this being a new file,
there would be no upstream to have to maintain the patch against, so
there shouldn't be much of a maintenance burden for me here.

4. If we do make Simon's code available in-distro, then we can update
our recommendation to point users to it.


Next I'd like to address my pull request.

The issue here is that there's a higher level distribution thing going
on here, that is at a layer in the stack higher than apt. So "check_apt"
itself is a bit of a misnomer; what would be more useful for users is
"check_for_distro_updates", IYSWIM, and I hope you can consider this in
any check_apt rewrite.

If you decline the pull request for this reason, then I'm reluctant to
introduce a distribution patch for this functionality. It'll make the
maintenance situation worse than it is right now, could confuse users
because of a difference in behaviour between upstream and the
distribution package, and additionally get in the way of user support
because you won't necessarily be able to tell easily if a user's issue
is due to the distribution patch or not.

And check_apt is expected to be rewritten at some point, which clearly
will break any distribution patch. So I don't want to have to deal with
this a second time when that happens.

Instead, I'd prefer to start with Simon's code, agree where
distributions should place it, rename it to "check_distro_updates" or
something, and then start patching that to alert with additional non-apt
update notifications.

For the immediate situation with Ubuntu HWE EOL notifications then, once
we remove check_apt from our development release nagios-plugins package,
then we can still choose to backport my pull request to Precise and to
Trusty as a one-off, without having to worry about any future
maintenance burden. Future notifications can take place through the
check_distro_updates replacement.


How does this all sound? I'm particularly interested in:

1) Upstream's view on removing check_apt.

2) Simon's view on us recommending his code, or incorporating it
in-distro.

3) Michael's view on maybe putting Simon's wrapper into
update-manager-common, or moving apt-check out of update-manager.

4) Jan's view on the Debian perspective here.

5) Any other comments, from anyone?

Thanks,

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20140619/3ffb3e8e/attachment.sig>