Hide Forgot
Description of problem: Files (symlinks) in /etc/raddb/mods-enabled/ aren't restored after package reinstallation Version-Release number of selected component (if applicable): freeradius-3.0.0-4.el7 How reproducible: always Steps to Reproduce: 1.rm -rf /etc/raddb/mods-enabled/* 2.yum reinstall freeradius 3. Actual results: files should be restored Expected results: files aren't restored Additional info: [root@mypc ~]# ls /etc/raddb/mods-enabled/ always detail.log echo linelog passwd soh attr_filter dhcp exec logintime preprocess sradutmp cache_eap digest expiration mschap radutmp unix chap dynamic_clients expr ntlm_auth realm utf8 detail eap files pap replicate [root@mypc ~]# rm -rf /etc/raddb/mods-enabled/* [root@mypc ~]# ls /etc/raddb/mods-enabled/ [root@mypc ~]# rpm -qf /etc/raddb/mods-enabled/ freeradius-3.0.0-4.el7.x86_64 [root@mypc ~]# yum reinstall freeradius Loaded plugins: product-id, subscription-manager This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. Resolving Dependencies --> Running transaction check ---> Package freeradius.x86_64 0:3.0.0-4.el7 will be reinstalled --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Reinstalling: freeradius x86_64 3.0.0-4.el7 rhel7 900 k Transaction Summary ================================================================================ Reinstall 1 Package Total download size: 900 k Installed size: 2.9 M Is this ok [y/d/N]: y Downloading packages: freeradius-3.0.0-4.el7.x86_64.rpm | 900 kB 00:01 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : freeradius-3.0.0-4.el7.x86_64 1/1 Verifying : freeradius-3.0.0-4.el7.x86_64 1/1 Installed: freeradius.x86_64 0:3.0.0-4.el7 Complete! [root@mypc ~]# ls /etc/raddb/mods-enabled/
The same problem is with files in /etc/raddb/sites-enabled/ directory
David, is this different from the behavior on RHEL-6? I can imagine that enabled modules can be observed as a "configuration customization" and as a such won't be overrided during the reinstall/update (similarly to config files).
Symlinks for enabled modules are not used on rhel6, there is different setup for enabling of modules. Symlinks for sites-enabled are used on rhel6 and there is behavior as I expected. On rhel6: #ls -l /etc/raddb/sites-enabled/ total 0 lrwxrwxrwx. 1 root radiusd 33 Dec 4 04:39 control-socket -> ../sites-available/control-socket lrwxrwxrwx. 1 root radiusd 26 Dec 4 04:39 default -> ../sites-available/default lrwxrwxrwx. 1 root radiusd 31 Dec 4 04:39 inner-tunnel -> ../sites-available/inner-tunnel #rm -rf /etc/raddb/sites-enabled/* # ls -l /etc/raddb/sites-enabled/ total 0 #yum reinstall freeradius #ls -l /etc/raddb/sites-enabled/ total 0 lrwxrwxrwx. 1 root radiusd 33 Dec 4 04:39 control-socket -> ../sites-available/control-socket lrwxrwxrwx. 1 root radiusd 26 Dec 4 04:39 default -> ../sites-available/default lrwxrwxrwx. 1 root radiusd 31 Dec 4 04:39 inner-tunnel -> ../sites-available/inner-tunnel
The symlinks are part of FreeRADIUS's configuration setup. You create a symlink to enable a feature, you remove a symlink to disable a feature. Also, keeping the actual configuration files out of the directory the server looks for configuration files in prevents the server from attempting to load .rpmsave and .rpmnew files (because they are in a different directory) which had been a problem in the past and the target of several bug reports. The symlink behaviour for mods-enabled and sites-enabled is by design and expected. If you look in the spec file you'll see that these files are marked as %config(missingok) That means they are config files but RPM won't recreate them, this is not an accident, this is they way it's supposed to work. Why? Because an upgrade must not re-enable features which had been explicitly disabled by an admin. This is akin to .rpmnew files created during an upgrade. The existing config is not modified but the admin can see by looking at the .rpmnew file what changed. Unfortunately there is no mechanism for dealing with symlinks serving an equivalent purpose, hence the missingok flag. When I updated the spec file for 3.0 I had a conversation with Panu Matilainen <pmatilai> our Red Hat RPM maintainer with regards to how best to handle these symlinks. I had come to the conclusing missingok was the right way to treat these and then independently Panu confirmed missingok was the preferred approach and since Panu is the RPM guru I was confident this was the right behaviour.