On Tue, 2011-09-13 at 16:33 +0300, Alexander Bokovoy wrote: > On Tue, 13 Sep 2011, Stephen Gallagher wrote: > > > > File "/usr/lib/python2.7/site-packages/SSSDConfig.py", line 1207, in > > > > import_config > > > > fd = open(configfile, 'r') > > > > IOError: [Errno 2] No such file or directory: '/etc/sssd/sssd.conf' > > > Right, we need to fallback to new sssd.conf in case of any exception, > > > not only for ParsingError. > > Actually, that's not necessarily true. Do we want to fall back on > > permission error, for instance? This could result in clobbering an > > existing file (if for example the existing sssd.conf's SELinux context > > is wrong, preventing reading, but when we create a new one and save it > > in place later we have the right context and it replaces the old one). > Let's define what we want to see here. > > 1. There is no sssd.conf -> create new one (unlikely for existing SSSD > installation -- if we went to this path, we already found SSSD > installed)
Actually, this is fairly likely in future releases. There's so much noise in the example configuration that I've decided that we're going to install it as %doc instead of %config. So a raw installation of the SSSD package will have no sssd.conf in place. We obviously need to consider this. > 2. There is sssd.conf -> modify existing one > 2.1. Can't open for write -> report error Agreed. > 2.2. Can't open and read due to parsing error -> create new one > ... There are two issues here. Failure to open for reading and ParseError on read. That said, I think they should be handled the same way (see below). Unfortunately, we have additional issues here... The SSSDConfig API is more strict with options than the SSSD itself is. Specifically, the SSSD will ignore unknown options entirely, but the SSSDConfig will through a ParseError on unknown options. The long-term goal is for SSSD to be more strict about this, but we don't currently have a way to do this. So as I see it, we have three choices for dealing with ParseError: 1) Back up the existing sssd.conf and replace it with a completely new one for FreeIPA. Pros: sssd.conf is guaranteed to parse cleanly. FreeIPA client install completes successfully. Cons: existing configuration (which may have worked) is not preserved. 2) Be restrictive on ParseError and throw an error telling them to fix their config file. Pros: we don't break an existing setup. Cons: FreeIPA installation has been broken. 3) Default to one of the above but provide a command-line flag to behave the other way. This is probably our best bet. I'd suggest defaulting to replacing the config file on ParseError (with a loud message at the END of ipa-client-install pointing to the backed-up file). > > What are other cases? > > > > Admittedly, it's a contrived example, but where contrived examples > > exist, so can real issues. > True. >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
