This is the exact use case for ELAPI shoudl we use it instead?

I honestly don't care how they get to the syslog, but they need to be there. Currently, an administrator has no way other than running the sssd in interactive mode to determine what's wrong with the configuration.

My point is that starting next week we should be able to take advantage of ELAPI so I do not see a value in doing the work twice. We have already a scheduled task to do the work. I am arguing that ticket #151 and this one is the same thing.

I guess this also depends on whether the ELAPI integration will be the only logging facility used in SSSD or if there will be something like --without-elapi/--with-elapi. If we allow SSSD to be configured without ELAPI, we certainly need a plain ol' syslog as fallback.

status: new => assigned

The whole point was for it to be always with ELAPI. ELAPI is going to be the dispatcher of the vents. In the basic case the events will go into file or syslog. There is no need to duplicate the work.

Fixed with 8c50bd085c0efe5fde354deee2c8118887aae29d

fixedin: => 0.6.0
resolution: => fixed
status: assigned => closed

Fields changed

testsupdated: 0 => 1

Fields changed

rhbz: => 0

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1213

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.