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 > > > > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project