Because the config file is listening on *:80 and *.443 and OMV maintains that config file, it isn't possible from the nginx level. And this isn't something 99.99% of OMV users need. So, it makes little sense to add it. I would say firewall is your best option. If it was added, it would waterfall into asking for every service to only listen on one network interface.
well tbh the next thing will be do bind specific services to specific interface,
so you're saying that right now I'll be on my own and will need to handle this manually?
None of the plugins (other than wireguard and minidlna via environment variable) allow you to bind the service to an individual network interface. You will be fighting an ugly battle.
Just out of curiousity, why do you need this? I understand vlans in the home but multiple NICs for physical network segregation is way beyond the scope of OMV. I would just run OMV in a VM if you need this.
For samba, you could add the following to extra options (obviously change eth0 to your network interface);
bind interfaces only = yes
interfaces = lo eth0And I was wrong about nginx, there are two environment variable for what it listens on:
OMV_NGINX_SITE_WEBGUI_LISTEN_IPV4_ADDRESS
OMV_NGINX_SITE_WEBGUI_LISTEN_IPV6_ADDRESS
This page will tell you how to use them - https://docs.openmediavault.org/en/5.x/various/advset.html (yes, omv 5.x is the same as 6.x for this).
yeah thanks for the hints still it would be great to have this in the gui some day 
it would be great to have this in the gui some day
Personally, I disagree because people will do dumb things with it and wonder why they can't get to their web interface to change it back. Volker will tell you that not every setting will have a knob to turn in the web interface.
Volker will tell you that not every setting will have a knob to turn in the web interface.
This is correct because the philosophie of OMV is to keep it simple.
Personally, I disagree because people will do dumb things with it
then we should disallow people to poses knives. As the media shows, people do dumb things with them.
I'm sorry but I couldn't resist as this argument is totally invalid. I do understand that authors of OMV want the UI to be simple - perfectly fine, then these sort of things can be hidden under "advanced mode". Of course we now have advanced settings visible, but for example Home Assistant made this configurable, this would still provide simple UI for most people and advanced ones would also benefit from it.
then we should disallow people to poses knives. As the media shows, people do dumb things with them.
I'm sorry but I couldn't resist as this argument is totally invalid
wtf... I hate laws restricting people from owning things but what I said has nothing to do with doing dumb things in general. It has everything to do with people doing dumb things on OMV and then me having to support them.
I do understand that authors of OMV want the UI to be simple - perfectly fine, then these sort of things can be hidden under "advanced mode". Of course we now have advanced settings visible, but for example Home Assistant made this configurable, this would still provide simple UI for most people and advanced ones would also benefit from it.
There is only one author of OMV. I just write plugins. Volker has an overall design in his mind that focuses on a select use case. If you want more, submit a pull request with the changes. Not sure what else to tell you. I am an advanced user and I just drop to the command line for the things I can't do from the web interface and don't think twice about it. Even windows has advanced settings only changeable by editing the registry.
Hi
lolek don't forget that Openmediavault is free software and has support.
Volker and Ryecoaaron have enough work.
I do understand that authors of OMV want the UI to be simple - perfectly fine, then these sort of things can be hidden under "advanced mode".
I would say environment vars is the hidden advanced mode. The GUI is for noobs and/or daily tasks. If there was a vote I would be against the option in the gui.
Then there should be some option in the gui to check if the config wasn't modified by hand and if so, issue a warning before applying changes with option to reject or overwrite changes.
Example:
I'm making changes by hand, year later I figure - oh I need to add something, then I go to the gui and change it forgetting there was a manual change done in the files.
How would you detect this? Even if you ran saltstack in a noop mode to try to detect changes, some changes build on others and wouldn't be detected. We struggle with this exact problem with Puppet at work. We had code to detect manual changes IF someone removed the header comments but people would forget to remove the header. OMV has environment variables to do some overrides but obviously it won't meet the needs of extreme changes. It does seem most of your wants could be done with a firewall keeping everything in the web interface at the expense of being more complicated.
The prob is that right now there's not much choice in regards of GUI for NAS.
webmin would also be a candidate.
How would you detect this? Even if you ran saltstack in a noop mode to try to detect changes, some changes build on others and wouldn't be detected.
The simple thing for me is that after writing a config, omv would also calculate md5 of a config file.
Next time it's trying to update the file, it calculates again the md5 of a config and compare, if it's different - well.. display info if it's not.. update and after updating, generate and again store md5.
The thing is that you don't care what has been changed by a user but only if it has been modified at all.
The simple thing for me is that after writing a config, omv would also calculate md5 of a config file.
Next time it's trying to update the file, it calculates again the md5 of a config and compare, if it's different - well.. display info if it's not.. update and after updating, generate and again store md5.The thing is that you don't care what has been changed by a user but only if it has been modified at all.
Saltstack has many methods like that if you maintaining the whole file but many parts of OMV and the plugins only maintain part of the file (like fstab) or delete all files in a directory then recreate. I know I don't have time or desire to add this to all plugins.
I know I don't have time or desire to add this to all plugins.
nobody ask to do this all at once, you can do this incrementally, step by step.
And even if you modify only part of the file, still that information can be a saver.
nobody ask to do this all at once, you can do this incrementally, step by step.
That's nice. Same amount of work. And the fact that almost no one is asking for this tells me it is not an effective use of my time.
And even if you modify only part of the file, still that information can be a saver.
I've been on the configuration management team (we use puppet mainly with some ansible) at work for seven years and don't need this. What is in configuration management is supposed to be the source of truth. Not changing something because it has been manually changed is exactly what configuration management was meant to fix.
nobody ask to do this all at once, you can do this incrementally, step by step.
And even if you modify only part of the file, still that information can be a saver.
No. There will be no change how configuration management is done with Salt in OMV. Dot.
If the current behavior does not fit your requirements please choose a different solution that fits better.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
