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

[Martin Kosek]

On 08/09/2013 04:13 PM, Anthony Messina wrote:
> 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

Hello Anthony,

>From your post above, I did not understand what is the actual problem with
FreeIPA vs. small-time admins. I personally think that FreeIPA is usable for
both small-timers and bigger deployments (sorry for having to undergo the
manual migration procedure).

If you see that this is not true in some part of FreeIPA, please comment or
file tickets/RFEs/Bugzillas which we can process and act on to amend the
situation.

Thanks in advance,
Martin