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
signature.asc
Description: Digital signature
-- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam