I’ve been messing around with monitoring all my servers (icinga2 for the curious) and decided to throw my RPI in the mix just for the hell of it. Since OSMC is currently based on raspbian-stretch the icinga2 agent actually installs and works fine, but the problem comes when it wants to run check_apt in order to check for missing updates.
OSMC has a replacement Bash script for /usr/bin/apt-get which checks if you’re passing the upgrade command and exits if so. I know you can do apt-get nowarn-upgrade to bypass the warning, but check_apt is hardcoded to both the original path AND the upgrade command. As such, there’s no way to accomplish monitoring missing packages without an edit somewhere.
The full command line check_apt uses is apt-get -o 'Debug::NoLocking=true' -s -qq upgrade, which is just a simulation (run as a non-root user to begin with) and hence it’s perfectly safe. So perhaps it’s acceptable for OSMC to check for $EUID -ne 0 and allow the command if true, since non-root users don’t have any write permissions for /var/lib anyways. Then any of those users can freely run simulations, while root is still prohibited in general from doing apt-get upgrade to prevent breaking everything/anything.
You may wonder why I’m requesting a modification/fix from OSMC and not the plugin writer. OSMC is actually “at fault” here because it replaces apt-get, something you’re not really supposed to do. In the meantime, I’ve edited the Bash script to include my proposed edit so I can at least continue setting up my monitoring.
Sure, here you go. I also added a check for the /var/lib/apt dir not being writeable (which is probably enough to ensure stability) but I left the check for EUID in there as well, to further minimise the chances of funky stuff happening.
There actually are some legitimate cases for using upgrade instead of dist-upgrade though. ;]
As Sam mentions its actually based on Debian on all devices except the original Pi1 / Pi 0.
Are you able to compile the plugin from source ? The sourcecode shows the path within an #ifndef and only sets a hard coded path if one isn’t provided during the build process. So if you are building from source you should be able to edit the Makefile to change this relatively easily by defining PATH_TO_APTGET. I haven’t checked, but if it uses something like autoconfig you may even be able to specify it on a ./configure line.
As for ‘upgrade’ being hard coded, the source also shows dist-upgrade as being a possible test immediately below this. Why not configure it to use this instead ? It will also give you a more accurate assement of what packages need updating in certain circumstances, and the same result in other circumstances. (When there are no dependency changes)
Running both apt-get -s upgrade and apt-get -s dist-upgrade is redundant when the first will be either equal to or a subset of the second.
While not running as root will prevent harm from running upgrade to be honest I’m quite reluctant to add additional code to “special case” a very narrow use case where in my opinion the plugin should be more flexible in what commands it runs to suit different systems. Not all Debian based systems behave identically to Debian, otherwise they would just be Debian. The apt-get wrapper has been in osmc for 3 years now and as far as I’m aware you’re the first person to have an issue because of this.
I have to take issue with this. How is our wrapper script something we’re “not really supposed to do” ? OSMC is it’s own thing made for the specific purpose of being a mediacenter, and while the core Linux system it is based on is Debian (or Raspbian which is itself a Debian derivative with customisations of its own) that does not mean it does or should adhere to every specific trait of Debian or maintain 100% compatibility with every random piece of 3rd party software out there. If it did, it would just be Debian instead of OSMC, which is specifically customised to meet the needs of a mediacenter system.
We also don’t use Debian kernels and package and upgrade our kernels in a completely different way to Debian or Raspbian. Should we not do that either in case it breaks compatibilty with some kernel utility somewhere ?
The wrapper is there for a very good reason. Running upgrade on an osmc system will break kernel updates at the very least due to the way new kernels are brought in through dependency changes, and can cause other breakage as well if we make significant changes to dependencies - which we do from time to time.
A lot of people inadvertently broke their systems in sometimes subtle ways running apt-get upgrade by blindly following tutorials on the intenet which all recomend running apt-get upgrade despite Debian’s advice for years being to only use dist-upgrade. Trying to diagnose the problems caused by running upgrade was a support burden hence the decision to wrap the command to warn people in no uncertain terms that they shouldn’t be doing this and that if they do they’re on their own.
Such as ? Please explain why and when you think upgrade should be used instead of dist-upgrade, on OSMC. Debian within a release cycle does not rely much on package dependency changes, however we rely on it heavily in OSMC, this is why only dist-upgrade can be used without causing major problems with our monthly updates.
OSMC is a customised mediacenter distribution first and foremost and a mostly Debian compatible operating system second.
The most important difference is that dist-upgrade also resolves dependencies, which skews the statistics. I want to know if the currently installed packages have updates or not.
Since OSMC still has a proper/compatible Debian system underneath it’s perfectly possible to install packages not under OSMC control, which is actually one of the reasons I went with OSMC over say OpenELEC. These packages (not justnagios-plugins) may be relying on certain standard configuration, which yes is a caveat of its own but there’s nothing inherently wrong with that. apt-get is a pretty essential/standard tool so you don’t just expect its behaviour to have drastically changed to begin with.
I’ve worked with plenty of Debian-based distros and none of them replaced apt-get. As for nobody reporting having an issue with it, perhaps they just didn’t want to bother and applied their own fix silently. I know plenty of people who would do it like that rather than figure out a proper permanent fix.
I could, but I hope you realise how ridiculous it is to propose an alternative where I have to check out the entire source tree, install development libraries and then figure out how to compile just that one module.
Yes, I know there’s a good reason to have the wrapper in the first place. That’s why I’m not saying to remove it altogether but rather figure out a way to improve compatibility with various configurations.
I was referring to Sam’s “any Debian system”, not OSMC. You can probably figure out why you may want just upgrade on certain other Debian systems.
It’s hard to comment when we don’t understand why you’re trying to gather these statistics and what you’re trying to do with them. EG, what is the point of all this ?
Suffice to say that upgrade will not give the full picture on whether a system is out of date or not, and ultimately that is what matters. When we publish a new kernel we upgrade the xxx-kernel-osmc package and as part of that we change the depends in that package to point to a new kernel image package. Going by upgrade alone you would not be aware of what the new waiting kernel version is because its a completely new package that is not on the system yet.
We also rely a lot on inter package dependencies within OSMC packages such that many OSMC packages are only installed because they are a dependency of another package. A good example are the xxx-device-osmc packages, such as:
There is a laundry list of dependencies in that one package alone, and at any time we may (and have previously) changed the list of dependencies quite significantly, pulling in completely new packages, and discarding old ones. Knowing that rbp2-device-osmc has an update available is not helpful information without knowing what dependencies may have changed.
So I’m struggling to see how the information from upgrade is useful on OSMC.
Of course you can install packages outside of OSMC control on your system. We have never said you can’t, and I have many installed on my own system as do a lot of people. However we don’t guarentee 100% compatibility because we have chosen to make certain customisations that deviate from default Debian practice. Wrapping apt-get is one such choice but there are many others, including changes to the sudo config, policy kit, default user permissions for the osmc user etc…
Well it has been changed - but not drastically as you imply. It refuses to run upgrade without the user typing nowarn-upgrade, and advises them that they shouldn’t be doing it in the first place, in accordance with Debian advice. upgrade is a legacy option of apt-get which should not be used, so the purpose of the wrapper is to protect users from themselves.
Again, wrapping apt-get was a concious and deliberate choice we made, for good reasons. If you don’t like it, you can edit the script yourself to behave how you would like it to which you have no doubt already done.
The issue is whether all this extra code checking for the UID should be added to this wrapper on millions of systems to account for a very narrow corner case, and we’re reluctant to do that. Any bug in this code which resulted in apt-get failing to work properly would be devastating and difficult to recover from if it prevented users downloading a further update to get a fix. We are always extremely cautious when making changes to anything related to upgrading, because if you break the upgrade system in any way then your users are screwed without reinstalling or being walked through how to manually fix the problem, which means for most people they end up stuck on that version forever or have to do a fresh install.
Similarly rediculous to wanting a workaround added to a critical wrapper script used by millions of installations to allow upgrade to run as non-root so one person can use nagios in a specific configuration without editing a script ?
My advice would be to simply edit the script to your liking and make that permanent by changing extended attributes on the file. Or copy a replacement for the file at boot time via /etc/rc.local. Something like that.
No I can’t. There is no good reason to use upgrade over dist-upgrade on any modern Debian system. Still waiting to hear what your reason is.
If you have configured a backports repo, running dist-upgrade might replace packages with their backported variants. This is usually not something you want. Just the fact that backports still exist for the latest version of Debian stable shows there’s clearly a need for them, so it’s not as simple as “just remove the repo definition”.
Furthermore, if you need consistency/predictability it might be better to use upgrade. It never removes a package nor does it install entirely new ones. It ensures the entire system remains complete, while dist-upgrade has the potential to wreck stuff pretty badly. I’ve had some good fun with an update for mysql-common conflicting with mariadb-server and dist-upgrade wanting to remove all server packages. You should just not run a good old upgrade to rake in those nice security patches and keep your MySQL server working?
Plenty of reasons, you just have to want to see them.
As I said, I’ve decided to monitor my servers and outdated packages is a pretty basic/standard check. I only care about actual updates (especially security ones), new dependencies don’t count as that.
If you configure a backports repository, it’s usually advised to install any packages needed (–install will also --upgrade) and then remove the repository.
This is against Debian policy however and is not recommended
Didn’t know Debian had a policy that says I’m not allowed to decide what stats I want to see.
Anyways, the topic is hardly about the original request anymore. It doesn’t seem like you’ll change your mind either so I’ll just figure out something else.
Hi. I’m reading here that apt-get upgrade is legacy and advised against by debian. Can you point me to an article of debian where this is stated? Because in the upgrade procedures from e.g. stretch to buster on debian.orghttps://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.html apt-get upgrade is an advised step in the process.
Thank you for your quick response. I found the document, but it isn’t searchable. Rough idea where to find it? By the looks of it it is a few hundred pages…
@ActionA: Ok you are right: that document doesn’t mention apt-get upgrade, but on the other hand it points to the releasenotes which state in section 4.4.4 to do a minimal upgrade first.
Should I interprete this as: ‘an apt-get upgrade is acceptable when it is followed by an apt-get dist-upgrade shortly after’?
