On 08/01/2013 02:58 PM, Martin Kosek wrote:
On 08/01/2013 02:54 PM, Petr Viktorin wrote:
On 07/31/2013 11:51 AM, Ana Krivokapic wrote:
On 07/30/2013 06:24 PM, Petr Viktorin wrote:
On 07/30/2013 10:27 AM, Ana Krivokapic wrote:
This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3783.
Thanks for the patch, I have a concern below:
diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig
@@ -894,6 +895,7 @@ def main():
configured_constants = dogtag.configured_constants()
sub_dict = dict(
+ SUBJECT_BASE=str(DN(('O', api.env.realm))),
When certmap.conf.template's version changes again, this will rewrite the
subject to the default. Don't we want to use the subject base also here?
You are right. The updated patch uses the current value of subject base from
LDAP to update certmap.conf during upgrades.
When ipa-upgradeconfig is run while the DS is down, this results in a small
warning, and very bad configuration:
certmap ipaca CN=Certificate Authority,None
I'm not sure how this should be handled. I'm adding Rob to the loop.
Rob, can we start the DS in ipa-upgradeconfig? That sounds quite heavy-handed
for a RPM upgrade script.
Maybe if the DS is unavailable, we should use the old value from the config
Values can be stored/restored using a sysupgrade module.
The problem is that (AFAIK) old instances won't have this particular
value stored. Upgrading from 3.1 to a future version where certmap.conf
is modified again would fail.
I would not be so
afraid of starting the DS module, we already do that exercise in
ipa-ldap-updater, so adding it in ipa-upgradeconfig too does not change much.
Question is, what should we do what DS cannot be started or cannot be read
(e.g. when upgrade is run in fedup's chrooted environment) - we must make sure
we don't mess the configuration up.
Again AFAIK, if the server is down, certmap.conf is the only place where
this value is available. I didn't check thoroughly, though.
Freeipa-devel mailing list