Split "package-level" and "user-level" settings in shib.conf to limit effect of RPM upgrades.
Basics
Technical
Logistics
Basics
Technical
Logistics
Description
Automated rpm upgrades from the security:shibboleth repository replace /etc/httpd/conf.d/shib.conf, even though that file has been customized for the customer's application.
The desired behavior is for the rpm to leave the current file intact, but this does not happen because there are new changes to the packaged shib.conf file each time an upgrade takes place, and those changes cause rpm to replace the file according to the rule explained here: http://www.rpm.org/max-rpm/ch-rpm-upgrade.html
The changes to shib.conf for each upgrade are two alias lines for the logo image and css:
— shib.conf.R 2010-07-23 13:26:17.000000000 -0400 +++ shib.conf 2010-12-14 17:09:19.000000000 -0500 @@ -19,8 +19,8 @@ <Location /shibboleth-sp> Allow from all </Location>
Alias /shibboleth-sp/main.css /usr/share/doc/shibboleth-2.3.1/main.css
Alias /shibboleth-sp/logo.jpg /usr/share/doc/shibboleth-2.3.1/logo.jpg + Alias /shibboleth-sp/main.css /usr/share/doc/shibboleth-2.4/main.css + Alias /shibboleth-sp/logo.jpg /usr/share/doc/shibboleth-2.4/logo.jpg </IfModule>
Those lines always contain the new version number, so rpm always sees this file as needing to replace the current config file, which breaks our customized config file each time we upgrade.
Packaging changes checked into development branch.
bcodding@uvm.edu August 22, 2011 at 2:05 PM
Thanks for the test packages.. the update works on RHEL5 i386. The <Location /secure> shib.conf is created as shib.conf.new, so it doesn't stomp on us, and Aliases are moved to a version independent location.
I am not surprised that you are hosed whatever you do.
Personally I don't insist on anything, other than that you fix the comments if you keep the current behavior. All my servers have been broken and fixed now so it's academic for me anyway.
Scott Cantor August 9, 2011 at 6:52 PM
I think I can solve the breaking upgrade scenario by switching filenames and marking the old config as (replace) with a dummy no-op file. So that's probably covered if it ever came to that.
Automated rpm upgrades from the security:shibboleth repository replace /etc/httpd/conf.d/shib.conf, even though that file has been customized for the customer's application.
The desired behavior is for the rpm to leave the current file intact, but this does not happen because there are new changes to the packaged shib.conf file each time an upgrade takes place, and those changes cause rpm to replace the file according to the rule explained here: http://www.rpm.org/max-rpm/ch-rpm-upgrade.html
The changes to shib.conf for each upgrade are two alias lines for the logo image and css:
— shib.conf.R 2010-07-23 13:26:17.000000000 -0400
+++ shib.conf 2010-12-14 17:09:19.000000000 -0500
@@ -19,8 +19,8 @@
<Location /shibboleth-sp>
Allow from all
</Location>
Alias /shibboleth-sp/main.css /usr/share/doc/shibboleth-2.3.1/main.css
Alias /shibboleth-sp/logo.jpg /usr/share/doc/shibboleth-2.3.1/logo.jpg
+ Alias /shibboleth-sp/main.css /usr/share/doc/shibboleth-2.4/main.css
+ Alias /shibboleth-sp/logo.jpg /usr/share/doc/shibboleth-2.4/logo.jpg
</IfModule>
Those lines always contain the new version number, so rpm always sees this file as needing to replace the current config file, which breaks our customized config file each time we upgrade.