Bug 1431198 - automatically add 'includedir /etc/krb5.conf.d/' to krb5.conf on update
Summary: automatically add 'includedir /etc/krb5.conf.d/' to krb5.conf on update
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: krb5
Version: 7.3
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: Robbie Harwood
QA Contact: Patrik Kis
Aneta Šteflová Petrová
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 1433083
TreeView+ depends on / blocked
 
Reported: 2017-03-10 15:06 UTC by Petr Vobornik
Modified: 2018-04-10 08:42 UTC (History)
6 users (show)

(edit)
Application configuration snippets in `/etc/krb5.conf.d/` are now automatically read in existing configurations

Previously, Kerberos did not automatically add support for the `/etc/krb5.conf.d/` directory to existing configurations. Consequently, application configuration snippets in `/etc/krb5.conf.d/` were not read unless the user added the include statement for the directory manually. This update modifies existing configurations to include the appropriate `includedir` line pointing to `/etc/krb5.conf.d/`. As a result, applications can rely on their configuration snippets in `/etc/krb5.conf.d`.

Note that if you manually remove the `includedir` line after this update, successive updates will not add it again.
Clone Of:
: 1433083 (view as bug list)
(edit)
Last Closed: 2018-04-10 08:41:43 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:0666 None None None 2018-04-10 08:42 UTC

Description Petr Vobornik 2017-03-10 15:06:25 UTC
Description of problem:

Copied from: https://pagure.io/freeipa/issue/6589 based on triage from 2017-03-07.

On freeipa-users someone reported an install error where the temporary krb5.conf would fail because it included /etc/krb5.conf.d. This directory is apparently provided by krb5-libs on RHEL 7.3 but not 7.2 (in his case CentOS) so the install would blow up.

Either the Requires needs to handle this or a specific check should be made on this directory existence or given this is a temporary krb5.conf are includes necessary at all?

IPA triage result was: krb5-libs does not automatically add 'includedir /etc/krb5.conf.d/' to  krb5.conf on update - this should be fixed in krb5-libs rather than ipa

Comment 1 Robbie Harwood 2017-03-10 15:49:25 UTC
This isn't a krb5 bug.  Adding krb5.conf.d on update in krb5-libs is safe because we create that directory at install time.  We are also not going to get rid of including this directory: it was explicitly requested, and several applications now make use of it (see https://bugzilla.redhat.com/show_bug.cgi?id=1146945 and https://bugzilla.redhat.com/show_bug.cgi?id=1145808 )

I believe the problem you are seeing is that the person is trying to install rhel-7.3 IPA against rhel-7.2 kerberos.  IPA completely overwrites /etc/krb5.conf and adds krb5.conf.d there.  See here: https://github.com/freeipa/freeipa/blob/master/install/share/krb5.conf.template

We tend to upgrade IPA and krb5 versions in tandem; I recommend not supporting this configuration.  I also wish freeipa would put its snippets in /etc/krb5.conf.d instead of making its own, separately included, directory for this purpose, but I understand that freeipa upstream does not agree with me on that.

Comment 2 Petr Vobornik 2017-03-10 16:14:26 UTC
IPA is tight with major version of krb5 so it should not happen that IPA would be updated without krb5. 

What dir and snippets to you mean in the last paragraph?

Comment 3 Robbie Harwood 2017-03-10 18:46:57 UTC
(In reply to Petr Vobornik from comment #2)
> IPA is tight with major version of krb5 so it should not happen that IPA
> would be updated without krb5. 

The bug you link says that they are trying to install against rhel-7.2 kerberos.

freeipa either needs to pay more attention to the system krb5.conf, or require >= el7.3's krb5-libs.

> What dir and snippets to you mean in the last paragraph?

Again, https://github.com/freeipa/freeipa/blob/master/install/share/krb5.conf.template

This is what IPA makes krb5 look like during install, overriding whatever configuration I provide in krb5-libs.  I wish IPA would not override the configuration, and I also wish IPA would not make a *second* place to put snippets in the process.

Comment 4 Jan Cholasta 2017-03-14 14:11:34 UTC
Robbie, the issue is orthogonal to whatever IPA does. You can reproduce the bug even without IPA installed:

1. install RHEL 7.2
2. make modifications to /etc/krb5.conf
3. upgrade to RHEL 7.3
4. you now have a system which has /etc/krb5.conf.d but no 'includedir /etc/krb5.conf.d' in /etc/krb5.conf

Comment 5 Robbie Harwood 2017-03-14 16:26:14 UTC
(In reply to Jan Cholasta from comment #4)
> Robbie, the issue is orthogonal to whatever IPA does. You can reproduce the
> bug even without IPA installed:
> 
> 1. install RHEL 7.2
> 2. make modifications to /etc/krb5.conf
> 3. upgrade to RHEL 7.3
> 4. you now have a system which has /etc/krb5.conf.d but no 'includedir
> /etc/krb5.conf.d' in /etc/krb5.conf

That's intended.  There is a new file created - /etc/krb5.conf.rpmnew - that contains the new configuration.  Because you have made changes to krb5.conf, I cannot overwrite your configuration because I risk breaking your system.

Dropping down a level, my two choices for config files are to mark them %config or to mark them %config(noreplace).  I (actually previous maintainer, but I agree with them) chose the latter.  For a good chart of what this does, see: http://people.ds.cam.ac.uk/jw35/docs/rpm_config.html

Comment 6 Jan Cholasta 2017-03-14 16:44:33 UTC
In the "%triggerun libs" scriptlet in krb5.spec the existing /etc/krb5.conf is updated AFAICT - why is it OK to overwrite user configuration and risk breaking the user's system in this case and not in the /etc/krb5.conf.d case?

Comment 7 Robbie Harwood 2017-03-14 18:11:53 UTC
(In reply to Jan Cholasta from comment #6)
> In the "%triggerun libs" scriptlet in krb5.spec the existing /etc/krb5.conf
> is updated AFAICT - why is it OK to overwrite user configuration and risk
> breaking the user's system in this case and not in the /etc/krb5.conf.d case?

That's a fair point.  Do you know how I can do this without deleting the existing trigger, given that RPM doesn't allow for overlapping triggers?

Comment 8 Robbie Harwood 2017-03-15 15:41:34 UTC
(In reply to Robbie Harwood from comment #7)
> (In reply to Jan Cholasta from comment #6)
> > In the "%triggerun libs" scriptlet in krb5.spec the existing /etc/krb5.conf
> > is updated AFAICT - why is it OK to overwrite user configuration and risk
> > breaking the user's system in this case and not in the /etc/krb5.conf.d case?
> 
> That's a fair point.  Do you know how I can do this without deleting the
> existing trigger, given that RPM doesn't allow for overlapping triggers?

I talked to RPM developers, and there isn't a clear way around this.  Specifically, "the only way round it having just one trigger that does the right thing depending on the circumstances"; unfortunately, there isn't a way that I can see to distinguish the case where default ccache has been configured and subsequently delted by the admin.

So my two options are, as I see them, to (1) write the default ccache again even if it's been deleted and add in krb5.conf.d as missing or (2) leave things as they are and not auto-add krb5.conf.d to krb5.conf when the admin has changed it.  What do you think?

Comment 9 Jan Cholasta 2017-03-16 07:10:53 UTC
%triggerun is executed before the target package is uninstalled, so I guess you should be able to determine the previous krb5-libs version inside the scriptlet and do the right thing based on this information:


%triggerun libs -- krb5-libs
# determine the previous krb5-libs version number
oldver=$(rpm -q --qf '%%{VERSION}' krb5-libs)
# determine the previous krb5-libs release number
oldrel=$(rpm -q --qf '%%{RELEASE}' krb5-libs}
# we are interested only in the first part of the release number
oldrel=${oldrel%%.*}

%if 0%{?configure_default_ccache_name}
# [[ ]] knows how to compare version numbers
if [[ $oldver < 1.11.3 || ( $oldver = 1.11.3 && $oldrel < 16 ) ]]; then
    # update default_ccache_name
fi
%endif

if [[ $oldver < 1.14.1 || ( $oldver = 1.14.1 && $oldrel < 8 ) ]]; then
    # add includedir /etc/krb5.conf.d
fi

Comment 10 Robbie Harwood 2017-04-13 19:56:40 UTC
(In reply to Jan Cholasta from comment #9)
> %triggerun is executed before the target package is uninstalled, so I guess
> you should be able to determine the previous krb5-libs version inside the
> scriptlet and do the right thing based on this information:

Approximately, yes.  There's a slight subtlety here in that RPM considers both the old version and the new version installed at this point in time, so I ended up having to do something like

```
old_ver=$(rpm -q --qf '%%{VERSION}\n' krb5-libs | sort -V | head -n 1 | tr -d '\n')

old_rel=$(rpm -q --qf '%%{RELEASE}\n' krb5-libs | sort -V | head -n 1 | tr -d '\n')
old_rel=${old_rel%%.*}
```

in order to get the right version numbers out.  Otherwise it sets variables as if:

```
$old_ver=1.15.11.15.1
$old_rel=3.fc275
```

Comment 21 errata-xmlrpc 2018-04-10 08:41:43 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:0666


Note You need to log in before you can comment on or make changes to this bug.