Hey there. The proposed solution is not really correct.

The systemd file dirsrv will ship will retain the EnvironmentFile=-/etc/sysconfig/dirsrv-%i line, and there is no plan to remove it in the near future at all. The difference is that our lib389 setup tools will not longer create that file by default. As a result, this only affects new IPA installs, and in that case, all IPA needs to do is create the /etc/sysconfig/dirsrv-%i file themselves, and they can populate it whatever data they like.

However, if they are going to create a file for environment, it may be better for IPA to just create systemd drop in's such as:

# /etc/systemd/system/dirsrv@<instancename>.d/ipa-env.conf
Environment=KRB5_KTNAME=/foo

This is probably a better long term solution to the problem, that is properly distribution independent.

Hope this clears up the misunderstanding of the change for the IPA team, and I think this is a pretty small bit of work (changes should only be in https://pagure.io/freeipa/blob/master/f/ipaserver/install/dsinstance.py#_1321 )

Drop-in file is what I suggested anyway. We also need to change upgrade code to move on to always create the drop-in file on upgrade or otherwise we'll end up with a different setup going forward and that's not what we want.

For implementers, systemd.unit(5) says that

Along with a unit file foo.service, a "drop-in" directory foo.service.d/ may exist. All files with the suffix ".conf" from this directory will be parsed after the unit file itself is parsed. This is useful to alter or add configuration settings for a unit, without having to modify unit files. Drop-in files must contain appropriate section headers. For instantiated units, this logic will first look for the instance ".d/" subdirectory (e.g. "foo@bar.service.d/") and read its ".conf" files, followed by the template ".d/" subdirectory (e.g. "foo@.service.d/") and the ".conf" files there. Moreover for units names containing dashes ("-"), the set of directories generated by truncating the unit name after all dashes is searched too. Specifically, for a unit name foo-bar-baz.service not only the regular drop-in directory foo-bar-baz.service.d/ is searched but also both foo-bar-.service.d/ and foo-.service.d/. This is useful for defining common drop-ins for a set of related units, whose names begin with a common prefix. This scheme is particularly useful for mount, automount and slice units, whose systematic naming structure is built around dashes as component separators. Note that equally named drop-in files further down the prefix hierarchy override those further up, i.e. foo-bar-.service.d/10-override.conf overrides foo-.service.d/10-override.conf.

As result, the path should be /etc/systemd/system/dirsrv@<instancename>.service.d/ipa-env.conf and the file should have all specific headers like [Service]. We have an example of how it is done with /etc/systemd/system/httpd.service.d/ipa.conf already (see configure_httpd_service_ipa_conf in ipaplatform/redhat/tasks.py), I think we should be doing it exactly the same way. A good example how to do that is a combination of commits 586fee293f42388510fa5436af19460bbe1fdec5 and 64db0592490493a060c7983acdfdf9100d9ea813 (the latter is needed because the former was using wrong location for a systemd unit snippet).

master:

• 3cb1ccb3b0a4f361d4d3ef667c60d5b6f4a23333 Add option to remove lines from a file
• e4621f1204c8ffc3e1279cea2a897292d560a48c Add tasks.systemd_daemon_reload()
• 1dfac4f5b7e9986e1217d6979b854b94de094aae Move DS's Kerberos env vars to unit file

Awesome! Thanks @cheimes

ipa-4-7:

• f9f01f524311d334c32fb7e404526723decd22a7 Add option to remove lines from a file
• f9b3fc1fc21ee7ec7333e147f5861e63feb87e35 Add tasks.systemd_daemon_reload()
• b6c810e921a42003083aa251eab01c055c1e6f78 Move DS's Kerberos env vars to unit file

Well we released 389-ds-base-1.4.1.2-2.fc30 which had our change it. There was some miscommunication on this one and I was not aware we needed to synchronize builds, so now upgrades are broken from F29 to F30.

https://bugzilla.redhat.com/show_bug.cgi?id=1695297

I'm assuming/hoping this did not make it into a build yet? Any ETA on the next FreeIPA build for F30?

@mreynolds I'm working on the Fedora package updates today. There are more patches needed than just this one as Samba 4.10 also broke us.

@abbra & @cheimes - looks like on RHEL 8 we need to add our fix, which means we need you to add this fix to RHEL 8 (for 0 day). Just a heads up...

@abbra & @cheimes - looks like on RHEL 8 we need to add our fix, which means we need you to add this fix to RHEL 8 (for 0 day). Just a heads up...

Looks like there might have been a mix up with QE as they accidentally tested 8.1, not 8.0... I will confirm later today....