apt run via shell asks for user decision on changed configuration files including the ones managed by OMV - apt config possible to prevent this?

  • This is a question requiring very deep technical knowledge!


    Background:

    to prepare for testing of new feature "automatic security patch installation" I installed OMV for RPi4 on a new SD card and performed at one stage "apt update; apt upgrade"


    Message received:

    Preparing to unpack .../monit_1%3a5.26.0-1_armhf.deb ...

    Unpacking monit (1:5.26.0-1) over (1:5.25.2-3) ...

    Setting up monit (1:5.26.0-1) ...

    Configuration file '/etc/monit/monitrc'

    ==> Modified (by you or by a script) since installation.

    ==> Package distributor has shipped an updated version.

    What would you like to do about it ? Your options are:

    Y or I : install the package maintainer's version

    N or O : keep your currently-installed version

    D : show the differences between the versions

    Z : start a shell to examine the situation

    The default action is to keep your current version.

    *** monitrc (Y/I/N/O/D/Z) [default=N] ? y

    Installing new version of config file /etc/monit/monitrc ..


    Later I noticed that this was the wrong choice because the configuration is to be maintained by OMV.

    Hence I'm wondering if apt would allow a configuration to prevent these decisions from being made by a user (as users tend to make errors when they lack context.)


    https://wiki.debian.org/PackageManagement/Preseed would suggest a solution but I'm lacking a good example


    Anyone have a suggestion?

    omv 5.6.13-1 (usul) on RPi4/4GB with Kernel 5.10.17 and WittyPi 3 V2 RTC HAT

    2x 6TB HDD formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

  • Later I noticed that this was the wrong choice because the configuration is to be maintained by OMV.

    Hence I'm wondering if apt would allow a configuration to prevent these decisions from being made by a user (as users tend to make errors when they lack context.)


    https://wiki.debian.org/PackageManagement/Preseed would suggest a solution but I'm lacking a good example


    Anyone have a suggestion?

    If you would've run omv-update instead, you wouldn't have made the wrong decision. omv-update knows to preserve the config file. The web interface would've done the correct thing as well. So, users who don't know what they are doing should keep using the web interface.

    omv 5.6.13 usul | 64 bit | 5.11 proxmox kernel | omvextrasorg 5.6.2 | kvm plugin 5.1.6
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Unfortunately other tools don't know about omv and it's special update command, hence run apt directly (i.e. raspi-config) or ask in their documentation to run the standard shell commands for this purpose (i.e. WittyPi RTC HAT).

    Murphy's law: "what can go wrong, will go wrong" applies.

    Therefore "use the OMV web interface" is not an appropriate answer to prevent the issue as other forum posts proof :(

    omv 5.6.13-1 (usul) on RPi4/4GB with Kernel 5.10.17 and WittyPi 3 V2 RTC HAT

    2x 6TB HDD formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

  • Unfortunately other tools don't know about omv and it's special update command, hence run apt directly (i.e. raspi-config) or ask in their documentation to run the standard shell commands for this purpose (i.e. WittyPi RTC HAT).

    omv-update is just a wrapper around apt-get - https://github.com/openmediava…t/usr/sbin/omv-update#L32


    If you are doing things outside of OMV and you mess up your system, that is your fault. There is NO way to fix that in OMV.


    Murphy's law: "what can go wrong, will go wrong" applies.

    And if you break YOUR system, you own both halves.


    Therefore "use the OMV web interface" is not an appropriate answer to prevent the issue as other forum posts proof

    That isn't proof of anything that is preventable by OMV. OMV runs on Debian. Of course, you can break your system. If you choose to follow other forum guides that aren't about OMV, that is your fault.


    You can always run omv-update where other forums tell you to run apt-get update/upgrade.

    omv 5.6.13 usul | 64 bit | 5.11 proxmox kernel | omvextrasorg 5.6.2 | kvm plugin 5.1.6
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • maybe you'd have an idea?

    Nice that you think I don't know how "fix" your issue. What are you looking for? Preseed is used for creating/customizing Debian ISOs. Sure you can set other settings in /etc/apt/apt.conf.d/ but that isn't the right approach. If someone chooses to use the command line, they choose to accept the risks associated with it.

    omv 5.6.13 usul | 64 bit | 5.11 proxmox kernel | omvextrasorg 5.6.2 | kvm plugin 5.1.6
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Later I noticed that this was the wrong choice because the configuration is to be maintained by OMV

    ryecoaaron has pointed that out in his response

    Hence I'm wondering if apt would allow a configuration to prevent these decisions from being made by a user

    So you're asking if it's possible to prevent apt from doing apt update/apt upgrade using the package management wiki you have referred too.


    The question is why has this been brought to the forum when this is an enhancement to OMV and has been raised on github, you yourself have said more than once that this sort of discussion should be on github.

    Raid is not a backup! Would you go skydiving without a parachute?

  • The question is why has this been brought to the forum when this is an enhancement to OMV and has been raised on github, you yourself have said more than once that this sort of discussion should be on github.

    And to add to that, if you force all apt decisions to "try" to prevent bad decisions, you can break other things and/or make other things a pain in the ass to do. I very much oppose setting system wide settings.

    omv 5.6.13 usul | 64 bit | 5.11 proxmox kernel | omvextrasorg 5.6.2 | kvm plugin 5.1.6
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Nice that you think I don't know how "fix" your issue

    Good that #6 had an answer to the original question.


    A last attempt to explain the real issue.


    Many documents for RPI (including official OMV docs) state to run "apt upgrade; apt update"


    The result is many times a partially damaged OMV installation.


    Because these standard commands are "common wisdom" (but not desired for a system running OMV!) running them is a case of "human error" that can't be prevented with the current OMV setup.

    Therefore I was wondering if "safeguards" against this human error can be established by configuring apt in a certain way.

    With "certain way" I mean specifically not to ask the user to overwrite OMV maintained config file (i.e. /etc/monit/monitrc)


    Is it now better described?

    If in doubt please ask for clarifications as assumptions don't help.


    Current understand based on #6

    Preseed is used for creating/customizing Debian ISOs. ... but that isn't the right approach.

    omv 5.6.13-1 (usul) on RPi4/4GB with Kernel 5.10.17 and WittyPi 3 V2 RTC HAT

    2x 6TB HDD formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

  • Many documents for RPI (including official OMV docs) state to run "apt upgrade; apt update"

    First, I don't give a shit what RPi docs tell you. If they aren't about OMV, you take the risk. And you didn't read the official docs, did you? They say they basically do an apt-get update && apt-get upgrade. Then in the box underneath, they tell you what they really do

    apt-get update && apt-get –yes –force-yes –fix-missing –auto-remove –allow-unauthenticated –show-upgraded –option DPkg::Options::=“–force-confold” dist-upgrade

    Notice the --force-confold part? That is what tells apt to keep the old config if it is there and prevents you from changing the default of the upgrade (N to upgrade config file) and fucking something up (like you did). Fix the docs if they aren't noob friendly.

    Therefore I was wondering if "safeguards" against this human error can be established by configuring apt in a certain way.

    As I mentioned above, omv-update is the safeguard. It is bad to change system wide settings for something that is caused by someone choosing the advanced option and not educating themselves. Is it possible to set force-confold at the system level and prevent your mistake? Yes. Is that a good idea and won't break other things? No. Are you going to ask for all system files to be safe from bad deletes or chown/chmod commands next? Those are more dangerous than a config file that could easily be fixed. If you fire up the registry editor on Windows, there is nothing stopping you from destroying the system by deleting a registry key.

    Is it now better described?

    I understood your question in the first post. You just didn't like my answer and thought I didn't have the knowledge to tell you how to implement the bad safeguard.


    If in doubt please ask for clarifications as assumptions don't help.

    I didn't assume anything. Just because you made the mistake doesn't mean we need to lockdown OMV's OS to be less usable.

    omv 5.6.13 usul | 64 bit | 5.11 proxmox kernel | omvextrasorg 5.6.2 | kvm plugin 5.1.6
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

    Edited once, last by ryecoaaron ().

  • And you didn't read the official docs, did you? They say they basically do an apt-get update && apt-get upgrade.

    well I did and there is absolutely no word of warning NOT to use them as you explained above!



    this is the text I see:

    "

    Using CLI

    apt-get

    If you want to update/upgrade in the console you can use apt-get update then apt-get upgrade."


    votdev

    I always wondered why so many people managed to break their OMV installation, the current documentation seems to be one of the reasons.


    Would it be ok to change above to:

    The standard package management commands " apt-get update; apt-get upgrade" and its variations can damage OMV in certain situations. Replacement for them is the command "omv-update"


    As OMV "declares" itself as a distribution, maybe even further steps should be taken to prevent running standard package management commands by accident (i.e non-OMV documents & tutorials)?

    ideas: set an alias for these commands that displays above text too and asks for confirmation?

    omv 5.6.13-1 (usul) on RPi4/4GB with Kernel 5.10.17 and WittyPi 3 V2 RTC HAT

    2x 6TB HDD formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

  • well I did and there is absolutely no word of warning NOT to use them as you explained above!

    Does it tell you not to sudo rm -rf / either? Most people don't change the defaults when running those commands. I can't remember the last time (other than you) someone did that and caused a problem.

    so many people managed to break their OMV installation, the current documentation seems to be one of the reasons.

    So many?? Show me another post where this happened.


    As OMV "declares" itself as a distribution, maybe even further steps should be taken to prevent running standard package management commands by accident (i.e non-OMV documents & tutorials)?

    NO! OMV is meant to use the web interface. Stop trying to change the underlying OS that power users enjoy.


    : set an alias for these commands that displays above text too and asks for confirmation?

    This is ridiculous. Not only would the user have to have it in their profile to be of any use, plenty of people might change it or call the full path of the command. You are trying to change standard Debian behavior that some people like myself have been using for 15+ years. Why don't you work on documentation and education of noobs instead of "fixing" something that isn't broken.

    omv 5.6.13 usul | 64 bit | 5.11 proxmox kernel | omvextrasorg 5.6.2 | kvm plugin 5.1.6
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • I don't want to read through all this:


    https://debian-handbook.info/b…debar.questions-conffiles -> handling configuration file related question


    If a configuration file is replaced by the one from the package, it is renamed to <confffile>.dpkg-old. If one chooses to keep the old configuration file instead, the new file is installed as <confffile>.dpkg-new. So no file is overwritten or lost. All you old configuration files are still there and have the suffix .dpkg-old. All you would have to do is: Rename them and remove the suffix. But don't do that blindly, just do it for the ones you replaced by the configuration files shipped with the packages.


    Also OMV in earlier releases was able to restore the configuration files it tries to handle as well. I don't know if this is still possible with the salt-variant of handling configuration files. In every case: your old configurations are still there.


    Preseeding of debconf can be used to avoid debconf prompts. However, this is a very powerful tool und usually not used by inexperienced users. My scripts for example use it to handle some situations. OMV avoids these prompts by simply disabling the debconf frontend via DEBIAN_FRONTEND=noninteractive.

  • I don't want to read through all this:

    I tried to summarize the learning from replies in #10



    https://debian-handbook.info/b…debar.questions-conffiles -> handling configuration file related question

    Thanks this was the content I was looking for ;)


    The open question is:

    Can OMV installation be hardened against unintentional modification of its configuration files by standard package mgmt commands (i.e apt, dpkg) ?


    Current understanding is, not feasible because features to exempt specific config files are missing. Currently exceptions are handled only on the level all or nothing.


    What is you view on this understanding?


    old configuration files are still there and have the suffix .dpkg-old.

    Using this feature would perhaps allow for easier troubleshooting of errors

    omv 5.6.13-1 (usul) on RPi4/4GB with Kernel 5.10.17 and WittyPi 3 V2 RTC HAT

    2x 6TB HDD formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

  • The open question is:

    Can OMV installation be hardened against unintentional modification of its configuration files by standard package mgmt commands (i.e apt, dpkg) ?

    THIS DOES NOT BELONG ON THIS FORUM TAKE IT TO GITHUB YOU HAVE STATED MORE THAN ONCE THAT CHANGES TO OMV SHOULD BE MADE THERE AND NOT HERE


    This is a polite warning, continued pursuance of this, in this thread or anywhere on the forum will be deleted!!

    Raid is not a backup! Would you go skydiving without a parachute?

  • I'm trying to figure out why you hit Y? I know it's not technically correct, but the message right there ca

    It already is, if you follow the user manual.


    Use omv-update instead of apt-update (and for what it's worth, actually read what you're doing before hitting "Y" when asked).


    How much more "hardening" do you want?

    Air Conditioners are a lot like PC's... They work great until you open Windows.


  • The open question is:

    Can OMV installation be hardened against unintentional modification of its configuration files by standard package mgmt commands (i.e apt, dpkg) ?


    Current understanding is, not feasible because features to exempt specific config files are missing. Currently exceptions are handled only on the level all or nothing.

    Well, OMV could use this: https://debathena.mit.edu/conf…20is%20ever%20uninstalled.


    Basically use dpkg-divert for the configuration files OMV handles. This will create a diversion for the actual configuration file of the package (e.g. samba) and package updates will only handle the diversion and not interfere with the configuration file created and maintained by OMV. When OMV is removed from the system, the diversions must be removed of course. votdev Would you consider using dpkg-divert for the configuration files you try to handle via OMV? I actually think it might be worth a shot and apt will not interfere anymore with these configuration files.

  • For most config files that OMV owns, they will be re-written with saltstack. There are a few config files that OMV touches once and not again. This allows users to customize them. I see adding this as harmful to power users and only protective of noobs trying to be power users.

    For configuration files handled by OMV (recreated, rewritten, etc.) this actually seems to be the correct technical solution. It is the technical equivalent of saying: This configuration file is not handled by the package itself anymore. It doesn't interfere with your ability to customize the configuration file as power user. Why do you consider this to be "hamful"? Can you provide an example?

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!