Bug 1431198

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.

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?

(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.

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

(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

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?

(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?

(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?

%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

(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
```

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