| Summary: | Files (symlinks) in /etc/raddb/mods-enabled/ aren't restored after package reinstallation | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | David Spurek <dspurek> |
| Component: | freeradius | Assignee: | John Dennis <jdennis> |
| Status: | CLOSED NOTABUG | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | dspurek, ebenes, ksrot |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-12-09 15:21:56 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
David Spurek
2013-11-28 09:23:39 UTC
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. |