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

[Anthony Messina]

On Monday, August 12, 2013 09:34:19 AM Martin Kosek wrote:
> 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

Martin, I *do* think FreeIPA is an excellent choice for small-time admins, 
especially with the increased effort on improving documentation, the upcoming 
ipa-client-advise tool, and the ipa-backup/restore tools.  I merely wanted to 
state that 1) I agreed with Simo's comments, and point out that 2) unequal 
masters with regard to DNSSEC  has the potential to be a single point of 
failure and an area of concern for small-time admins who may for example, 
already be coping with the, albeit solid, recommendations to run multiple 
concurrent masters in virtualized environments with duplicates of those 
environments available simply for testing upgrades (a fair amount of 
administrative overhead for a small-timer).

In short, I was voicing a sysadmin's opinion that FreeIPA should continue to 
evolve in a way that supports small-time admins as well.  I do not think there 
is a problem with "FreeIPA vs. small-time admins" and am hoping it stays that 
way.

As far as the manual migration...  This was likely an issue with documentation 
and/or release notes: 2.2 said it was ok to upgrade from 2.1, 3.0 said it was 
ok to upgrade from 2.2, etc.  This is likely all true, unless your original 
2.2 was based on a 2.1 with Dogtag9.  At that point in time, I had one FreeIPA 
master on bare metal.  I have since upgraded my infrastructure and "started 
over" to have two FreeIPA masters in VMs hosted on separate machines.  
Hopefully, this amount of redundancy will afford me some upgrade protection 
for the future.

Thanks again.  -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/20130812/c9da2aff/attachment.sig>