On 06/20/2016 03:09 PM, Jakub Hrozek wrote:
On Mon, Jun 20, 2016 at 08:54:18PM +0200, Lukas Slebodnik wrote:
> Attached is a sligtly modified version of Michal's patch.
The same patch is attached twice. Was it by accident or did you mean to
send two patches?
> I fixed few coding style issues + added missing creation of directory
> + spec file change.
You should have sent fixups to get credit, but meh :) Thanks for doing
the work nonetheless.
> You might notice that Michal removed detection of sssd.conf modified time.
> It is because mtime could be obtiained from sssd.conf before parsing.
> However, snippets files are open after parsing sssd.conf and mtime
> of snippet files is ignored in the process.
> We have few options.
> * check mtime directly in sssd
> * add new function to libini_config to get latest mtime before parsing
> (max_mtime(main.conf + alowed snippet files)
> // it's little bit a complication for user of libini_config
> // because user will need to paste regex for allowed snippets twice
> // 1st time in new function for checking mtime and 2nd time in function
> // ini_config_augment
> * modify libini_config to set max mtime while parsing snippet files
> // but we will need to parse files anyway. So I'm not sure what will be
> // benefit of cehcking mtime after parsing.
> * last option is to ignore mtime. (Michal's current version)
> // and remove FIXME :-)
Is there actually any downside to /always/ reading the config file and
always creating the confdb from scratch? I would say that sssd restarts
are a rare operation and the parsing and writes are not too big to slow
down the startup significantly.
I think the whole mtime logic was there only to allow online config
changes, which is something we tried in the past, but could never code
it up properly.
I think as long as we keep the parsing time very short, this is probably not an
issue. However, if we ever move SSSD to a socket-activated behavior, we will
want this to be very fast (or otherwise skippable).
> The main purpose of this mail is to decide wheteer we want change in ding-libs
> or no.
> BTW. We cannot change directory for snippet files from command line.
> Do we want such feature?
> [root@graviton ~]# /usr/sbin/sssd --help
> Usage: sssd [OPTION...]
> -d, --debug-level=INT Debug level
> -f, --debug-to-files Send the debug output to files instead of
> --debug-timestamps=INT Add debug timestamps
> --debug-microseconds=INT Show timestamps with microseconds
> -D, --daemon Become a daemon (default)
> -i, --interactive Run interactive (not a daemon)
> -c, --config=STRING Specify a non-default config file
Can you think of any use for this option? There can be only one sssd on
the system, so I actually wonder if we can remove it..
I think we originally added this thinking of a future in which we might want to
be able to run a live SSSD for automated tests, but we obviously went another
route with it.
The only use I can think of for this would be if someone actually wanted to move
their sssd.conf to a mounted read-only location (since IIRC we actually
explicitly disallow sssd.conf as a symlink).