[Freeipa-devel] DNSSEC support design considerations: key material handling

[Anthony Messina]

On Friday, August 09, 2013 08:49:29 AM Simo Sorce wrote:
> > Dmitri, Martin and me discussed this proposal in person and the new plan
> > is: - Elect one super-master which will handle key generation (as we do
> > with special CA certificates)
> 
> I guess we can start this way, but how do you determine which one is
> master ?
> I do not really like to have all this 'super roles', it's brittle and
> admins will be confused which means one day their whole infrastructure
> will be down because the keys are expired and all the clients will
> refuse to communicate with anything.
> 
> I think it is ok as a first implementation, but I think this *must not*
> be the final state. We can and must do better than this.

I've been "listening in" on the DNSSEC discussion and do not mean to derail 
the course of this thread, however...

>From a sysadmin's perspective, I agree with Simo's comments insofar as they 
relate to "not all masters being created equal".  Administratively, unequal 
masters have the potential to create single points of failure which may be 
difficult to resolve, especially on upgrade between minor versions and between 
replicas.

Small-time sysadmins like myself who may only run one (maybe two) FreeIPA 
instances incur a significant about of trouble when that already limited 
resource isn't working properly after some issue with file ownership or 
SELinux during a yum upgrade.

In addition, I realize FreeIPA wasn't probably designed with small-ish 
installs as the target use case.  But I would argue that since FreeIPA *is* so 
unified in how it handles Kerberos, LDAP, Certifiates, and DNS, it is a viable 
choice for small-timers (with the only exception being no real way to "back 
up" an instance without an "always-on" multi-master replica).

As a user who has just completed a "manual" migration/upgrade to F19 (after 
realizing that there really was no way to migrate/upgrade when the original 
install began on F17 2.1 on bare metal with the split slapd processes and 
Dogtag 9, through F18, to F19), I would like to see FreeIPA move forward but 
continue to deliver the above-mentioned services to the small-timers, who, 
without FreeIPA's unification, would never be able to manage or offer all of 
those services independently, like the big-timers might be able to.

Thanks.  -A

-- 
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130809/bc92365b/attachment.sig>