What to do with NethServer.repo and NethForge.repo rpmnew files

NethServer Version: 7.6

Having updated my system to the latest 7.6, I did a check to see what configuration files had un-applied updates:

[root@Nethserver ~]# find / -xdev -name \*.rpmnew
/etc/yum.repos.d/NethForge.repo.rpmnew
/etc/yum.repos.d/NethServer.repo.rpmnew
/etc/httpd/conf.d/ssl.conf.rpmnew
/etc/collectd.conf.rpmnew
/etc/chrony.keys.rpmnew
/etc/smartmontools/smartd.conf.rpmnew
/etc/nsswitch.conf.rpmnew
/etc/unbound/unbound.conf.rpmnew
/etc/vsftpd/vsftpd.conf.rpmnew
/etc/tor/torrc.rpmnew
/etc/freshclam.conf.rpmnew
/var/lib/machines/nsdc/etc/yum.repos.d/NethForge.repo.rpmnew
/var/lib/machines/nsdc/etc/yum.repos.d/NethServer.repo.rpmnew
/var/lib/machines/nsdc/etc/nsswitch.conf.rpmnew
/var/lib/machines/nsdc/etc/krb5.conf.rpmnew
/var/lib/unbound/root.key.rpmnew
[root@Nethserver ~]#

I know that for the .conf files built via the template system I should leave well alone and ignore the rpmnew version.

I know that for .conf files I added/updated myself I can work out the correct action.

But what about the others, especially the NethServer and NethForge repo files.

Then there are others, that NS has created outside of the template system, like krb5.conf, which when reading are obviously NS created. Which leaves files like nsswitch.conf where I have no real way of knowing if the differences are due to NS or rpm updates.

Cheers.

Yes it’s right. The e-smith template expansion also removes the corresponding .rpmnew and .rpmsave file.

However, a template expansion is triggered by a “nethserver-something” package update. If just “something” is updated the .rpmnew is left in place.

In old e-smith based systems the template expansion was triggered also by a system boot, so .rpmnew files were cleaned up more frequently.

Our repo files were changed for 7.6 to support repo GPG checks, as explained by the Release Notes: Release notes 7 — NethServer 7 Final

Furthermore, the NethServer.repo is going to be turned to a template too. There’s an open PR for that.

AFAIK, it’s a template too now.

It’s handled by the distro authconfig command

Ignore this path: it’s the NSDC container prefix for Samba AD.

This is the only one we can’t ignore I guess… What do you think @filippo_carletti?