Update Ubuntu from 22.04 LTS to 24.04 LTS

[wolframroesler]

No description provided.

[wolframroesler]

Thanks for merging #167, here's another one, a bit more complex than simply updating a version number somewhere.

Building the Nagios container works fine even without netcat and the MySQL/MariaDB library. I suppose these are included to be used by plug-ins and/or end users?

[tronyx]

I am not anywhere remotely close to being a Python developer, but while building this myself I am seeing an issue with the VENV that Plugins do not see the modules that were installed via PIP. Not sure what needs to be done here to maintain the correct approach or if using the --break-system-packages option is the best way to go. Perhaps adding something to source the .venv/bin/activate file on startup?

Also, pymssql is listed twice in the pip install line.

[wolframroesler]

Debian 12 and recent Ubuntu mandate using venv and discourage installing Python packages system-wide, so working without venv isn't actually an option these days I'm afraid ... . /opt/.venv/bin/activate is the right way to go for plugins that don't set up their own venv.

Not sure what you mean by --break-system-packages, can't see it being used anywhere.

Double pymssql removed.

[tronyx]

Right, I understand that, but what script would that go in to activate it for the Nagios user for all plugins container-wide?

You can use pip with the --break-system-packages flag to install modules system-wide, which is what I did with my testing and everything works as it should. I am simply trying to determine how to achieve the "proper way", using a VENV, inside the container.

[wolframroesler]

I see what you mean now. Don't know if there's a way to activate a venv system-wide; don't think there is because that would kind of defeat the purpose of having a venv in the first place.

The "proper way" as of Debian 12 is to run every Python application in a venv. --break-system-packages has a scary name for a reason I guess. On desktop and server systems I no longer try to work around that. In a container, things of course may be different ... if it gets the job done, or if it solves a problem that has no other good solution, --break-system-packages may be the way to go.

I understand you've got Nagios plug-ins that no longer work with the venv-based Python installation? That would be a reason to use --break-system-packages instead of the venv. If it causes problems in the future (e. g. because two Nagios plug-ins require incompatible versions of a Python module, the problem that venvs are trying to solve), we can still revert to a venv-based solution.

So, your choice :-) venv or not?

[JasonRivers]

Using --break-system-packages is probably safe in the container, as it's not being used for anything other than nagios anyway, That's a little more risky if you're running on-metal with other services, but in this case it's likely an OK workaround. I'm not sure how we would activate the venv for the plugins, if anything this is probably OK short-term while working out a better way to handle venv "the right way".

[tronyx]

Ok, that's what I thought too. The installation of pymssql is performed in the VENV which means that none of the Plugins that require it will work unless you use the --break-system-packages flag with pip when performing the installation or you find some way of activating it for the Plugins. Building the image as-is right now the pymssql module is not visible when performing a pip list. It is only shown once you activate the VENV.

[wolframroesler]

Ok, will remove the venv and use --break-system-packages instead.

[wolframroesler]

Done. Any further wishes, or can it be merged?

[wolframroesler]

Hello, when is this going to be merged?

[wolframroesler]

Hello, is anyone reading this? Is this repo still being maintained?