Permanently enable additional YUM repositories

A bit off topic

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:

  1. enable nethforge by default
  2. e-smith db property to permanently enable nethforge, has to be done on the command line
  3. Option to do the above (2) in the software center.
4 Likes

and to prevent this

So to overcame the limitation (this will be lost on next cron run):

I would prefer a permanent solution

1 Like

@davidep what do you think? Could be easy to implement options 1 or 2 from proposed my Mark?

2 Likes

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…

I’d go with 2: it’s just a step far from the template-custom approach. Repository configuration needs special care in the restore use case.

I’d like a generic prop that fits also other custom repositories, e.g:

subscription=configuration
    EnableRepoList=nethforge,myrepo
3 Likes

A comma separate list was actually my thinking :blush: thought let’s do a “save” proposal : "at least nethforg"

1 Like

I like the idea!

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

1 Like

@giacomo & @davidep are you going to discuss this feature within @nethesis ?

At the end I’v always considered the subscription module a bit outside of the scope of the nethserver-community at large…

1 Like

The change has been approved also by the support team.
We will implement it :wink:

5 Likes

thats great! Thank you.

Nice!

while you are at it you may review eorepo.conf and pkginfo.conf I think it is dead code, they are templated now in nethserver-base and -subscription.

That’s why the documentation is not completely accurate and we should update it ; to some extend this feature was present in the past.

EDIT:
Reading the below back i’d like to reformulate :grinning:

That why the doc @dnutan refered to in this thread is not completely accurate

That’s why the documentation is not completely accurate and we should update it

3 Likes

You’re right they are always overwritten by the template expansion. However I’d preserve them because they are owned by the nethserver-base RPM.

[root@vm1 ~]# rpm -V nethserver-base
S.5....T.  c /etc/nethserver/eorepo.conf
S.5....T.  c /etc/nethserver/pkginfo.conf

I’m not sure I understood: how do you want to change it?

1 Like

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.

1 Like

Until a (possible) permanent solution is in place, it’s easy enough to create a template override to add repositories to eorepo.conf:

[root@Nethserver ~]# cat /etc/e-smith/templates-custom/etc/nethserver/eorepo.conf/99custom
# Add my repositories in
jdoss-wireguard
nordvpn
PlexRepo
stephdl
tor
[root@Nethserver ~]#

Cheers.

3 Likes

The feature is ready to be tested thanks to @stephdl!

4 Likes

@EddieA @mark_nl @capote @pike anyone want to try the new implementation?

1 Like

Yes, I would.

1 Like

I dit it:

config setprop subscription ExtraRepositories nethforge,nethforge-testing
signal-event software-repos-save

outcome:

[root@nethserver ~]# cat /etc/nethserver/pkginfo.conf
<snip>
# One repository identifier per line
#
sb-nethserver-updates
<snip>
[root@nethserver ~]# cat /etc/nethserver/eorepo.conf
<snip>
# Blank lines and lines beginning with "#" are ignored
#
sb-base
sb-updates
sb-epel
sb-extras
sb-centos-sclo-rh
sb-centos-sclo-sclo
sb-nethserver-base
sb-nethserver-updates
stephdl

…also with reload

It seems not working. :thinking:

Are you sure the package has been updated from testing?

I’ll pass this one, sorry