How to fully disable automatic checking for updates in OMV7

villeneuve · Sep 9th 2024

Hi,

none of my OMV-systems has critical security requirements so automatic updates are undesired for several reasons. On OMV6 I managed to disable automatic updates but on OMV7 I have not managed to do so. So what's the most clean way to disable automatic checking for updates and therefor also automatic installation of updates? Manually checking and installing updates should still work afterwards of course.

Thanks & greets!

ryecoaaron · Sep 9th 2024

Quote from villeneuve

none of my OMV-systems has critical security requirements so automatic updates are undesired for several reasons.

No offense but installing security updates (which is all the automatic updates does) should be desired on all systems unless the system is not on a network (makes little sense for a NAS which is a network device). I would be interested to see the reasons.

As for disabling it, I think OMV 6 and 7 are the same in that you set OMV_CRON_APT_ENABLED to "no" . You will have to search for how to set OMV environment variables if you don't know how.

votdev · Sep 9th 2024

Quote from ryecoaaron

As for disabling it, I think OMV 6 and 7 are the same in that you set OMV_CRON_APT_ENABLED to "no"

That does not work on OMV7 because there unattended upgrades and apticron is used. From the OMV side there was no plan to support users to deactivate that. You are on your own to configure unattended-upgrades and apticon to not download and install upgrades. OMV is following the Debian style of configuring services that support that via custom conf files. So it should be no problem to override the default and OMV configs.

ryecoaaron · Sep 9th 2024

Quote from votdev

That does not work on OMV7 because there unattended upgrades and apticron is used

Ah, I forgot about that. I should've looked at the code.

donh · Sep 9th 2024

Auto update equals automatic breakage. Yes auto upgrade works most of the time but ask cloudflair what can happen. A better option would be to send a notification and let the admin decide to apply it or not. I take snap shots before applying updates just in case.

Thanks.

Cloud struck not cloud flare. Memory error.

ryecoaaron · Sep 9th 2024

Quote from donh

Auto update equals automatic breakage. Yes auto upgrade works most of the time but ask cloudflair what can happen. A better option would be to send a notification and let the admin decide to apply it or not. I take snap shots before applying updates just in case.

That might apply to Windows maybe. In six years of having auto updates on all repos (not just the security repo) for over 2k Ubuntu VMs, we haven't had a single breakage. OMV is just updating security updates which should be very minimal. If you backup the OS or use timeshift, there is little to worry about. I would say a large percentage of OMV users are not linux experts and have no admin skills to properly determine if an update should be applied or not. People complained when they didn't have a way to auto-update docker images.

donh · Sep 9th 2024

It still should be an option. Debian and omv are good but not perfect,

ryecoaaron · Sep 9th 2024

Quote from donh

It still should be an option.

People want everything to be an option lately. I don't have those options on anything I work on at work unless I write it. Making some things optional requires a lot of work. To me, it isn't worth it if a very small percentage of users want the option and additional code has to be maintained. It might be different if people were offering to help with the work/code.

villeneuve · Sep 12th 2024

Thanks very much for the replies! Would be great if OMV could add one on/off toogle for auto updates, but in the meantime I'll try to deal with it on the terminal.

I had already tried the following settings in /etc/apt/apt.conf.d/20auto-upgrades:

Code

APT::Periodic::Update-Package-Lists "0";
APT::Periodic::Unattended-Upgrade "0";

Both those entries were set to 1 by the default in OMV. However, it was still installing updates automatically and spamming me with e-mails about it.

I've now resorted to DuckDuckGo's AI Chat which told me to also check for apt related systemd timers via

Code

systemctl list-timers --all

and then disable them, which in my case meant these:

Code

systemctl disable apt-daily.timer
systemctl disable apt-daily-upgrade.timer

Hopefully the AI was right, I'll see...

donh · Sep 13th 2024

Thanks. I will try that also. We will hope updates don't reset those.

villeneuve · Sep 18th 2024

Hi, it seems that what I did was still not enough since today that OMV system I'm trying this on sent me an E-Mail "1 package update(s) available". It's content mentions that apticron has found that update. apticron's usual config file is /etc/apticron/apticron.conf, but when opening it on the OMV system it contains a content that the user should not edit that file since changes will get lost. I guess deinstalling apticron goes too far since I can imagine that causing troube for OMV. DuckDuckGo's AI chat told me to use

Code

crontab -e

to disable the apticron service, but doing so also brings up a comment "Lines below are managed by Salt, do not edit.

I've got no clue whatsoever about salt and but some more questions to the AI also resulted in mentioning the file /etc/cron.d/apticron in which I've now commented out the one line which calls /usr/sbin/apticron.

I hope this finally does it.

Participate now!