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

Zitat von mi-hol

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.

Zitat von mi-hol

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.

Zitat von mi-hol

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

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

Zitat von mi-hol

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.

Zitat von mi-hol

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.

Zitat von mi-hol

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

Zitat von mi-hol

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.

Zitat von geaves

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.

Zitat von ryecoaaron

things a pain in the ass to do

and there's me thinking you were doing an Ace Ventura

Zitat von mi-hol

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.

Zitat von mi-hol

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.

Zitat von mi-hol

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.

Zitat von mi-hol

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.

Zitat von mi-hol

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.

Zitat von mi-hol

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.

Zitat von mi-hol

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.

Zitat von mi-hol

: 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.

mi-hol MISTER I KNOW IT ALL, DON'T PM AND TELL ME YOU DON'T WANT TO RECEIVE REPLIES FROM ME TO YOUR QUESTIONS

'COS TOUGH SHIT I'M REPLYING

Zitat von mi-hol

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!!

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

Zitat von mi-hol

I tried to summarize the learning from replies in #10

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) ?

Alles anzeigen

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?