[Freeipa-users] PKI-CA fails to start (broken config after update?)

[Ade Lee]

On Wed, 2014-09-24 at 16:33 -0400, Ade Lee wrote:
> On Wed, 2014-09-24 at 16:24 -0400, Rob Crittenden wrote:
> > Dmitri Pal wrote:
> > > On 09/24/2014 03:29 PM, Rob Crittenden wrote:
> > >> Dmitri Pal wrote:
> > >>> On 09/24/2014 02:07 PM, swartz wrote:
> > >>>> On 9/24/2014 9:05 AM, Ade Lee wrote:
> > >>>>> Forwarding to a couple of colleagues of mine who will be taking
> > >>>>> point on
> > >>>>> this.
> > >>>>>
> > >>>>>   From what I can see, the CS.cfg is truncated.  Fortunately, I
> > >>>>> believe it
> > >>>>> is reparable.
> > >>>>>
> > >>>>> Ade
> > >>>> I've been in contact with Endi and Ade. It was a truncated config file
> > >>>> as per msg above.
> > >>>> Endi had emailed me a restored config.
> > >>>>
> > >>>> I can happily say that my IPA instance is back in operation.
> > >>>>
> > >>>> Thank you all.
> > >>>>
> > >>>> For anyone else reading this:
> > >>>> For me this config truncation happened after a 'yum update'.
> > >>>> Perhaps shutting down the IPA stack before doing package updates might
> > >>>> be more advisable.
> > >>>>
> > >>>>
> > >>> Is there any chance to detect which package caused this truncation?
> > >>>
> > >> It was almost certainly related to IPA, if not ipa-upgradeconfig
> > >> directly. For any number of reasons it may write directly to CS.cfg
> > >> without stopping the service first. It may also call the dogtag-provided
> > >> pki-setup-proxy which also doesn't stop the service before touching
> > >> CS.cfg.
> > >>
> > >> The upgrader will then determine if any changes were made and restart
> > >> the service.
> > >>
> > >> rob
> > > So is it a race condition? Something does not sound right.
> > > 
> > 
> > What I don't understand is: if dogtag always writes CS.cfg on exit, why
> > does this work the majority of the time?
> 
> Dogtag does not write CS.cfg on exit (like 389).  Rather, if there are
> changes to CS.cfg, they will be committed and the file will be changed
> and the in-memory version of CS.cfg will be written at that time.
> 
> I think what we're seeing is two different things modifying the CS,cfg
> at the same time (or at least within the time frame of whatever file
> buffering is going on).  In other cases where I've seen this, I see
> CS.cfg end up the size of n * file buffer.
> 
> Shutting down CA before changing CS.cfg is a way of preventing access by
> more than one source at the same time.
> 
In the long term of course, we need to provide an interface to dogtag to
allow these types of changes by the dogtag server.

> > 
> > But anyway, it sounds like we need to shut down dogtag every time we
> > touch CS.cfg which isn't a big deal but it will change the way we do
> > some things.
> > 
> > rob
> > 
> 
>