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

[Endi Sukma Dewata]

On 9/23/2014 6:35 PM, swartz wrote:
> On 9/22/2014 7:59 PM, Ade Lee wrote:
>> If you scroll to the end of the CS.cfg, does it look like it has been
>> truncated?

> I'd have to say no. It doesn't look truncated to me. At least there are
> no obvious signs. But then again I don't know everything that is suppose
> to be there. I know that the line starting  with
> "pkicreate.unsecure_port=" isn't there, that's for sure. Hence why init
> script fails to start PKI-CA.

Hi,

Ade and I looked at the file that you sent, and I sent you an updated 
CS.cfg based on my system (and you indicated that it's working now). I 
noticed that your original file contains the following line:

   cloning.ocsp_signing.dn=CN=OCSP Subsys

where it probably should have been something like this:

   cloning.ocsp_signing.dn=CN=OCSP Subsysstem,O=CS.MYDOMAIN.CA

Also, it's missing the next ~400 lines which seem to have been replaced 
with these lines:

   proxy.securePort=443
   proxy.unsecurePort=80

So we're suspecting that something was adding these proxy parameters 
directly to CS.cfg while the CA is saving configuration changes to 
CS.cfg too. Luckily your original CS.cfg still contains enough 
information to fully restore the file. I guess we need someone who's 
more familiar with the IPA & CA upgrade process to take a look at this 
more closely.

The CS.cfg is actually owned by the CA server, but sometimes people are 
advised to change the file directly, and maybe some codes are written 
that way too. There are some ways to avoid this kind of problems in the 
future:

1. Require CA to be shutdown before changing CS.cfg directly.
2. Prohibit direct access to the file and require the use of tools that 
send the changes to the CA server (e.g. via CLI/REST).
3. Break CS.cfg into user-owned and server-owned parameters, and move 
mostly-static parameters into a separate default file.
4. Replace CS.cfg with LDAP-based configuration.

In the short term we might be limited to #1, but in the long term we 
might be able to implement the other options.

-- 
Endi S. Dewata