We seen this Issue more than once here;
On some occasions with the unpleasant side effect package installed from nethforg not receiving updates after a user subscribes their system.
This being said I like to propose a easy procedure to (permanently) enable at least nethforge on subscriptions systems. Especially because more than once the users hit with this issue subscribe their systems out-of good will: appreciation for the nethserver project.
IMHO there are 3 options:
enable nethforge by default
e-smith db property to permanently enable nethforge, has to be done on the command line
Option to do the above (2) in the software center.
Which makes sense in some situations, avoiding routing problems.
I’m asking you if possible to have some best practices about docker into a “server only” machine and correlation between gateway.
Maybe could ease a lot of loopholes…
Not really. I’m very happy about the work done by the community on the docker stuff, but I never deeply studied how it works and I never considered it as constraint for the platform development.
So if I will need to do changes on firewall part (which is present in all installations), I promise I will try to not break the docker integration. But if I have decide between fixing a bug in the iptables chains and preserve docker feature, I would definitively go with the bug fix.
Still, I think we will not have such breaking changes during NS 7 lifecycle, so docker feature should be safe until 2024!
The /etc/e-smith/events/actions/nethserver-subscription-eorepo action configures YUM repositories based on subscription. The behavior of the script can be changed using /etc/nethserver/eorepo.conf file which may contain the list of repositories to be enabled.
IMHO the above suggest a user can edit this file to (permanently) change the behavior… Nowaday’s this file is templated and the changes do not survive a software-repos-save event. Moverover the only link to the nethserver-subscription-eorepo action I can find is in the subscription package @system-init. (can have missed something here).
The above made me believe the documentation and the originally intended behavior was a user can make permanent changes regarding the enabled repositories.