[SSSD] [sssd PR#105][+Pushed] RESPONDER: Remove dead assignment to the variable ret
URL: https://github.com/SSSD/sssd/pull/105 Title: #105: RESPONDER: Remove dead assignment to the variable ret Label: +Pushed ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#105][comment] RESPONDER: Remove dead assignment to the variable ret
URL: https://github.com/SSSD/sssd/pull/105 Title: #105: RESPONDER: Remove dead assignment to the variable ret jhrozek commented: """ * master: 3d5bf48ac5b8b807facbfda225cdebff2f685cb8 """ See the full comment at https://github.com/SSSD/sssd/pull/105#issuecomment-265709046 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#105][closed] RESPONDER: Remove dead assignment to the variable ret
URL: https://github.com/SSSD/sssd/pull/105 Author: lslebodn Title: #105: RESPONDER: Remove dead assignment to the variable ret Action: closed To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/105/head:pr105 git checkout pr105 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#105][-Accepted] RESPONDER: Remove dead assignment to the variable ret
URL: https://github.com/SSSD/sssd/pull/105 Title: #105: RESPONDER: Remove dead assignment to the variable ret Label: -Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#104][comment] Suppress a confusing error message from timestamp cache updates
URL: https://github.com/SSSD/sssd/pull/104 Title: #104: Suppress a confusing error message from timestamp cache updates jhrozek commented: """ * master: ee576602d8b46b313c4f7ac8324cc31faefae46a """ See the full comment at https://github.com/SSSD/sssd/pull/104#issuecomment-265709337 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#104][-Accepted] Suppress a confusing error message from timestamp cache updates
URL: https://github.com/SSSD/sssd/pull/104 Title: #104: Suppress a confusing error message from timestamp cache updates Label: -Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#104][+Pushed] Suppress a confusing error message from timestamp cache updates
URL: https://github.com/SSSD/sssd/pull/104 Title: #104: Suppress a confusing error message from timestamp cache updates Label: +Pushed ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#104][closed] Suppress a confusing error message from timestamp cache updates
URL: https://github.com/SSSD/sssd/pull/104 Author: jhrozek Title: #104: Suppress a confusing error message from timestamp cache updates Action: closed To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/104/head:pr104 git checkout pr104 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#97][+Pushed] IFP: Remove "ChangeDebugTemporarily" method
URL: https://github.com/SSSD/sssd/pull/97 Title: #97: IFP: Remove "ChangeDebugTemporarily" method Label: +Pushed ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#97][-Accepted] IFP: Remove "ChangeDebugTemporarily" method
URL: https://github.com/SSSD/sssd/pull/97 Title: #97: IFP: Remove "ChangeDebugTemporarily" method Label: -Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#97][closed] IFP: Remove "ChangeDebugTemporarily" method
URL: https://github.com/SSSD/sssd/pull/97 Author: fidencio Title: #97: IFP: Remove "ChangeDebugTemporarily" method Action: closed To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/97/head:pr97 git checkout pr97 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#97][comment] IFP: Remove "ChangeDebugTemporarily" method
URL: https://github.com/SSSD/sssd/pull/97 Title: #97: IFP: Remove "ChangeDebugTemporarily" method jhrozek commented: """ * master: 78b4b7e5ec55861c43775581c08ae1804cd865f0 """ See the full comment at https://github.com/SSSD/sssd/pull/97#issuecomment-265710166 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#99][+Accepted] Prevent use after free in fd_input_available
URL: https://github.com/SSSD/sssd/pull/99 Title: #99: Prevent use after free in fd_input_available Label: +Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#99][closed] Prevent use after free in fd_input_available
URL: https://github.com/SSSD/sssd/pull/99 Author: chlunde Title: #99: Prevent use after free in fd_input_available Action: closed To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/99/head:pr99 git checkout pr99 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#99][comment] Prevent use after free in fd_input_available
URL: https://github.com/SSSD/sssd/pull/99 Title: #99: Prevent use after free in fd_input_available jhrozek commented: """ Fixed upstream: master: 9676b464dd428557ff5a648e1351a3972440396f sssd-1-14: fefdd70237cbe82af7d8845131e45401e73b3b07 sssd-1-13: 07959a61f12cd9e60dff6651f4e1ce05c83c4da7 """ See the full comment at https://github.com/SSSD/sssd/pull/99#issuecomment-265713224 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#99][-Accepted] Prevent use after free in fd_input_available
URL: https://github.com/SSSD/sssd/pull/99 Title: #99: Prevent use after free in fd_input_available Label: -Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#99][comment] Prevent use after free in fd_input_available
URL: https://github.com/SSSD/sssd/pull/99 Title: #99: Prevent use after free in fd_input_available jhrozek commented: """ Since the patch looks good to me, apparently fixes a crash an none of the maintainers have another opinion, I'm ACKing the patch. """ See the full comment at https://github.com/SSSD/sssd/pull/99#issuecomment-265713216 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#99][+Pushed] Prevent use after free in fd_input_available
URL: https://github.com/SSSD/sssd/pull/99 Title: #99: Prevent use after free in fd_input_available Label: +Pushed ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#103][comment] sudo: do not store usn if no rules are found
URL: https://github.com/SSSD/sssd/pull/103 Title: #103: sudo: do not store usn if no rules are found jhrozek commented: """ ACK, thanks for the patch. I will push it once full CI finishes. """ See the full comment at https://github.com/SSSD/sssd/pull/103#issuecomment-265726131 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#103][+Accepted] sudo: do not store usn if no rules are found
URL: https://github.com/SSSD/sssd/pull/103 Title: #103: sudo: do not store usn if no rules are found Label: +Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#102][+Changes requested] Sssctl no case sensitive searches
URL: https://github.com/SSSD/sssd/pull/102 Title: #102: Sssctl no case sensitive searches Label: +Changes requested ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#106][comment] Add a new "files" provider
URL: https://github.com/SSSD/sssd/pull/106 Title: #106: Add a new "files" provider jhrozek commented: """ One suggestion came from simo about using FGETPWENT(3) instead of opening the NSS module directly. """ See the full comment at https://github.com/SSSD/sssd/pull/106#issuecomment-265761268 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#103][comment] sudo: do not store usn if no rules are found
URL: https://github.com/SSSD/sssd/pull/103 Title: #103: sudo: do not store usn if no rules are found jhrozek commented: """ CI: http://sssd-ci.duckdns.org/logs/job/58/31/summary.html The rawhide failure is unrelated.. """ See the full comment at https://github.com/SSSD/sssd/pull/103#issuecomment-265775078 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#103][comment] sudo: do not store usn if no rules are found
URL: https://github.com/SSSD/sssd/pull/103 Title: #103: sudo: do not store usn if no rules are found jhrozek commented: """ master: 46703740e83a66909974a5ee8d47df6a6e5076e7 sssd-1-14: 76e97affaa05ce45709efd59d120595c5992aa21 sssd-1-13: 4e25db79aa514e09c8ad4482c45b24e7a3d4 """ See the full comment at https://github.com/SSSD/sssd/pull/103#issuecomment-265777376 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#103][closed] sudo: do not store usn if no rules are found
URL: https://github.com/SSSD/sssd/pull/103 Author: pbrezina Title: #103: sudo: do not store usn if no rules are found Action: closed To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/103/head:pr103 git checkout pr103 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#103][-Accepted] sudo: do not store usn if no rules are found
URL: https://github.com/SSSD/sssd/pull/103 Title: #103: sudo: do not store usn if no rules are found Label: -Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#103][+Pushed] sudo: do not store usn if no rules are found
URL: https://github.com/SSSD/sssd/pull/103 Title: #103: sudo: do not store usn if no rules are found Label: +Pushed ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#94][comment] Enable {socket,dbus}-activation for responders
URL: https://github.com/SSSD/sssd/pull/94
Title: #94: Enable {socket,dbus}-activation for responders
jhrozek commented:
"""
Hi,
I read the patches, so far I didn't do a whole lot of testing, so maybe some
questions here are invalid, but nonetheless, here is my take on the patchset:
1. currently the patches don't work well if sssd is running with `user=root`
because then the confdb is owned by root and the responders, which always start
as the sssd user cannot read it. I think we could solve this particular problem
by owning the confdb as sssd/sssd from the start -- I don't think there would
be any information leak because the confdb is then only readable to sssd and
root and the sssd user's shell is hopefully` /sbin/nologin`. However, just the
presence of the sssd user is currently conditional (`--with-sssd-user` still
defaults to root). I wonder if it was the easiest to conditionalize the unit
and socket files and expand the sssd user instead of hardcoding sssd there?
1. There seems to be some issue with PAM socket ownership because I can't
authenticate with socket-activated PAM responder:
`Dec 12 11:36:11 client.ipa.test su[29517]: pam_sss(su-l:auth): Request to sssd
failed. Public socket has wrong ownership or permissions.`
1. Would it make any sense to own the sockets by the sssd user as well?
Currently it seems the sockets are owned by the sssd user for services started
by monitor if they are running un-privileged but as root for systemd-activated
services. Because the
1. There were some SELinux denials on my test VM, but granted, I run F-24
there. We need to make sure that no SELinux AVC denials are present in Fedora
later.
1. In the upstream reference specfile, should we use the systemd macros as we
do for services so that all sockets are enabled and started?
1. The documentation should be improved a bit. At least we should say that the
services line is only optional on systemd platforms. I think we should also add
an example that lists how to disable a socket if the admin wants to totally
disable some service.
1. I'm wondering if the restart on-failure is correct. I think it is, but I
would like to discuss it a bit. Currently the restart is done on any return
code other than 0. The only issue I see is that the restart is retried several
times if the service fails to start up, but in general I think it's much safer
than trying to be too smart and only restart with on-abnormal. Do you agree?
That's all for now, I will continue reading the patches and testing them later.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/94#issuecomment-266407528
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#94][+Changes requested] Enable {socket, dbus}-activation for responders
URL: https://github.com/SSSD/sssd/pull/94
Title: #94: Enable {socket,dbus}-activation for responders
Label: +Changes requested
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#106][comment] Add a new "files" provider
URL: https://github.com/SSSD/sssd/pull/106 Title: #106: Add a new "files" provider jhrozek commented: """ On Mon, Dec 12, 2016 at 04:51:31AM -0800, Pavel Březina wrote: > I will try to do some review in this week. Thank you, but please note that I will try to implement Simo's suggestion to use the fgetpwent family of functions. This would allow to simplify the code a bit, at least in the sense that the test module wouldn't have to be built at all. """ See the full comment at https://github.com/SSSD/sssd/pull/106#issuecomment-266443179 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#94][comment] Enable {socket,dbus}-activation for responders
URL: https://github.com/SSSD/sssd/pull/94
Title: #94: Enable {socket,dbus}-activation for responders
jhrozek commented:
"""
On Mon, Dec 12, 2016 at 05:19:18AM -0800, fidencio wrote:
> >Would it make any sense to own the sockets by the sssd user as well?
> >Currently it seems the sockets are owned by the sssd user for services
> >started by monitor if they are running un-privileged but as root for
> >systemd-activated services. Because the
> >
> > Hmm. Probably it does, but I'd like to hear other developers' opinion here
> as well.
> And seems that we missed some part of your explanation.
I don't remembe what exactly did I want to say here :-) I think just
that because the sockets are normally world-writable, except the private
pam one, the permissions don't matter that much, but at least with the
private pam socket care should be taken its permissions are the same as
if sssd created the socket itself.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/94#issuecomment-266442892
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#107][comment] WATCHDOG: Avoid non async-signal-safe from the signal_handler
URL: https://github.com/SSSD/sssd/pull/107 Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler jhrozek commented: """ So..I wonder how much of a hack this is but if the intent here is to reset the watchdog from a signal handler, could we send a signal to self (`kill(getpid(), SIGHUP)`) with a signal that is handled by tevent and in that tevent-driven signal handler, reset the watchdog? """ See the full comment at https://github.com/SSSD/sssd/pull/107#issuecomment-266446340 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#107][comment] WATCHDOG: Avoid non async-signal-safe from the signal_handler
URL: https://github.com/SSSD/sssd/pull/107 Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler jhrozek commented: """ I'm not sure I like the idea of killing a service because the admin runs ntpdate, even if the monitor should restart the service. @simo5 do you have a preference here? I really wonder why doesn't tevent use monotonic clock itself, should we ask on the samba list? """ See the full comment at https://github.com/SSSD/sssd/pull/107#issuecomment-266449652 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#107][comment] WATCHDOG: Avoid non async-signal-safe from the signal_handler
URL: https://github.com/SSSD/sssd/pull/107 Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler jhrozek commented: """ On Mon, Dec 12, 2016 at 06:55:13AM -0800, Simo Sorce wrote: > Yes we should ask, I think we really need to try to use monotonic clocks for > most tasks. Thank you, @simo5, do you also have a preference for how to reset the watchdog from a 'plain' POSIX signal handler where we can't use signal-unsafe functions? My suggestion was to signal 'self' to get into a tevent-managed signal handler, Fabiano suggested to play it safe and just exist and let monitor restart sssd_be. """ See the full comment at https://github.com/SSSD/sssd/pull/107#issuecomment-266458115 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#107][comment] WATCHDOG: Avoid non async-signal-safe from the signal_handler
URL: https://github.com/SSSD/sssd/pull/107 Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler jhrozek commented: """ On Mon, Dec 12, 2016 at 07:30:30AM -0800, Simo Sorce wrote: > well you could have a globalk variable for the watchdog and change it from a > custom signal handler, but the point of the watchdog is to go thorugh the > tevent handler instead so that we are sure the machinery is working and not > stuck somwhere. > Resetting directly from the singal handler would bypass all processing and > therefore render the watchdog useless I guess. The problem here (as I understand it, Pavel or Fabiano can correct me if I'm wrong) is that the watchdog increases the counter inside a POSIX signal handler, but resets the counter in a tevent timer (to make sure the mainloop is being processed). Now, if the time drifts, we still are receiving the monotonic SIGRT signals into the POSIX handlers, but because the tevent timer never gets invoked (it's set to be invoked in a time in the future, because the time drifted), we never reset the counter. We can detect the time has drifted in the POSIX SIGRT handler, the question I'm trying to answer is how should we restart the tevent timer when we receive the SIGRT signal, but we because we are in the POSIX handler, we are quite restriced in what we can do.. """ See the full comment at https://github.com/SSSD/sssd/pull/107#issuecomment-266462611 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#107][comment] WATCHDOG: Avoid non async-signal-safe from the signal_handler
URL: https://github.com/SSSD/sssd/pull/107 Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler jhrozek commented: """ On Tue, Dec 13, 2016 at 02:44:44AM -0800, Simo Sorce wrote: > On Tue, 2016-12-13 at 02:25 -0800, fidencio wrote: > > Pavel, > > > > On Tue, Dec 13, 2016 at 11:20 AM, Pavel Březina > > wrote: > > > > > There are two scenarios: > > > > > >1. timeshift during system boot -- it is very common to be several > > >hours > > >2. timeshift due to an ntp update when booted up -- usually only few > > >seconds, not a big deal > > > > > > The problem with tevent timer is that if we shift backwards the timer > > > remains too far in the future. This applies to all timers, not only for > > > the > > > watchdog. Forward shift is not a problem, it just executes the timers > > > immediately. Resetting the watchdog helps in a way that sssd is not > > > killed, > > > we don't have any capability to reschedule all timed event and we actually > > > can not tell that sssd will be functioning properly (dyndns, sudo refresh, > > > enumeration, domain refresh, even idle timer on socket activation)... all > > > those operations that depends on time() would become unreliable. > > > > > > I think the best thing to do would be restart the process (although the > > > question is how would this affect the boot up) and patch tevent to deal > > > with timeshift either by using monotonic clock or by detecting them and > > > altering timers accordingly. > > > > > > > In the latest version of patch I've just called _exit(1) when the timeshift > > is detected. > > About patching tevent, I've seen some old discussions happening and it > > doesn't seem a trivial thing to do. Would the patch, as it is right now, be > > acceptable and then a work on tevent could be done later (yes, I'd add it > > to my queue and do it as soon as we have an agreement on doing this)? > > This is really a blunt tool (calling exit()), but until tevent can be > fixed the only other option would be to use some wrapper to keep track > of all existing timed events and cancel and restart them all if the > clock changes abruptly. that's why I suggested signaling self to a tevent-driven signal handler from where we can just set up the timer anew. If there is any other way to 'break out' of the POSIX signal handler into somewhere where we can call tevent/talloc (or in general unsafe calls) I'm all ears. > The easiest option is to teach tevent about the existence of monotonic > clocks and allow to set a default clock type to use as well as overrides > for specific timers that want to fire on the actual time not just X > seconds in the future. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > > > -- > You are receiving this because you commented. > Reply to this email directly or view it on GitHub: > https://github.com/SSSD/sssd/pull/107#issuecomment-266706120 """ See the full comment at https://github.com/SSSD/sssd/pull/107#issuecomment-266745077 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#107][comment] WATCHDOG: Avoid non async-signal-safe from the signal_handler
URL: https://github.com/SSSD/sssd/pull/107 Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler jhrozek commented: """ On Tue, Dec 13, 2016 at 07:06:58AM -0800, Simo Sorce wrote: > On Tue, 2016-12-13 at 05:59 -0800, Jakub Hrozek wrote: > > On Tue, Dec 13, 2016 at 02:44:44AM -0800, Simo Sorce wrote: > > > On Tue, 2016-12-13 at 02:25 -0800, fidencio wrote: > > > > Pavel, > > > > > > > > On Tue, Dec 13, 2016 at 11:20 AM, Pavel Březina > > > > > > > > wrote: > > > > > > > > > There are two scenarios: > > > > > > > > > >1. timeshift during system boot -- it is very common to be several > > > > >hours > > > > >2. timeshift due to an ntp update when booted up -- usually only > > > > > few > > > > >seconds, not a big deal > > > > > > > > > > The problem with tevent timer is that if we shift backwards the timer > > > > > remains too far in the future. This applies to all timers, not only > > > > > for the > > > > > watchdog. Forward shift is not a problem, it just executes the timers > > > > > immediately. Resetting the watchdog helps in a way that sssd is not > > > > > killed, > > > > > we don't have any capability to reschedule all timed event and we > > > > > actually > > > > > can not tell that sssd will be functioning properly (dyndns, sudo > > > > > refresh, > > > > > enumeration, domain refresh, even idle timer on socket activation)... > > > > > all > > > > > those operations that depends on time() would become unreliable. > > > > > > > > > > I think the best thing to do would be restart the process (although > > > > > the > > > > > question is how would this affect the boot up) and patch tevent to > > > > > deal > > > > > with timeshift either by using monotonic clock or by detecting them > > > > > and > > > > > altering timers accordingly. > > > > > > > > > > > > > In the latest version of patch I've just called _exit(1) when the > > > > timeshift > > > > is detected. > > > > About patching tevent, I've seen some old discussions happening and it > > > > doesn't seem a trivial thing to do. Would the patch, as it is right > > > > now, be > > > > acceptable and then a work on tevent could be done later (yes, I'd add > > > > it > > > > to my queue and do it as soon as we have an agreement on doing this)? > > > > > > This is really a blunt tool (calling exit()), but until tevent can be > > > fixed the only other option would be to use some wrapper to keep track > > > of all existing timed events and cancel and restart them all if the > > > clock changes abruptly. > > > > that's why I suggested signaling self to a tevent-driven signal handler > > from where we can just set up the timer anew. > > > > If there is any other way to 'break out' of the POSIX signal handler > > into somewhere where we can call tevent/talloc (or in general unsafe > > calls) I'm all ears. > > I guess I need to understand better what exactly you want to do to be > able to advice on something. I can think of a coulpe of options, none of > them particularly elegant :) OK, let me try to explain better. A machine drifts time. Then an SSSD process receives SIGRT in watchdog_handler() and detects the time has drifted, so it avoids increasing the watchdog ticks counter -- this is done in watchdog_detect_timeshift() at the moment. At that point, in the current master, we call teardown_watchdog() and setup_watchdog() to set a new watchdog (the part that is based on tevent timers). This is unsafe to do in a signal handler because it involves malloc and free among others called from tevent. What I'm trying to figure out is how to reset the watchdog when I detect in watchdog_detect_timeshift() the time is out of sync and the tevent timer that resets the ticks will not arrive until the sssd process receives enough SIGRT signals to get itself killed. Does the question make sense now? """ See the full comment at https://github.com/SSSD/sssd/pull/107#issuecomment-266778681 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#107][comment] WATCHDOG: Avoid non async-signal-safe from the signal_handler
URL: https://github.com/SSSD/sssd/pull/107 Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler jhrozek commented: """ On Tue, Dec 13, 2016 at 08:16:33AM -0800, Simo Sorce wrote: > On Tue, 2016-12-13 at 08:02 -0800, Jakub Hrozek wrote: > > On Tue, Dec 13, 2016 at 07:06:58AM -0800, Simo Sorce wrote: > > > On Tue, 2016-12-13 at 05:59 -0800, Jakub Hrozek wrote: > > > > On Tue, Dec 13, 2016 at 02:44:44AM -0800, Simo Sorce wrote: > > > > > On Tue, 2016-12-13 at 02:25 -0800, fidencio wrote: > > > > > > Pavel, > > > > > > > > > > > > On Tue, Dec 13, 2016 at 11:20 AM, Pavel Březina > > > > > > > > > > > > wrote: > > > > > > > > > > > > > There are two scenarios: > > > > > > > > > > > > > >1. timeshift during system boot -- it is very common to be > > > > > > > several > > > > > > >hours > > > > > > >2. timeshift due to an ntp update when booted up -- usually > > > > > > > only few > > > > > > >seconds, not a big deal > > > > > > > > > > > > > > The problem with tevent timer is that if we shift backwards the > > > > > > > timer > > > > > > > remains too far in the future. This applies to all timers, not > > > > > > > only for the > > > > > > > watchdog. Forward shift is not a problem, it just executes the > > > > > > > timers > > > > > > > immediately. Resetting the watchdog helps in a way that sssd is > > > > > > > not killed, > > > > > > > we don't have any capability to reschedule all timed event and we > > > > > > > actually > > > > > > > can not tell that sssd will be functioning properly (dyndns, sudo > > > > > > > refresh, > > > > > > > enumeration, domain refresh, even idle timer on socket > > > > > > > activation)... all > > > > > > > those operations that depends on time() would become unreliable. > > > > > > > > > > > > > > I think the best thing to do would be restart the process > > > > > > > (although the > > > > > > > question is how would this affect the boot up) and patch tevent > > > > > > > to deal > > > > > > > with timeshift either by using monotonic clock or by detecting > > > > > > > them and > > > > > > > altering timers accordingly. > > > > > > > > > > > > > > > > > > > In the latest version of patch I've just called _exit(1) when the > > > > > > timeshift > > > > > > is detected. > > > > > > About patching tevent, I've seen some old discussions happening and > > > > > > it > > > > > > doesn't seem a trivial thing to do. Would the patch, as it is right > > > > > > now, be > > > > > > acceptable and then a work on tevent could be done later (yes, I'd > > > > > > add it > > > > > > to my queue and do it as soon as we have an agreement on doing > > > > > > this)? > > > > > > > > > > This is really a blunt tool (calling exit()), but until tevent can be > > > > > fixed the only other option would be to use some wrapper to keep track > > > > > of all existing timed events and cancel and restart them all if the > > > > > clock changes abruptly. > > > > > > > > that's why I suggested signaling self to a tevent-driven signal handler > > > > from where we can just set up the timer anew. > > > > > > > > If there is any other way to 'break out' of the POSIX signal handler > > > > into somewhere where we can call tevent/talloc (or in general unsafe > > > > calls) I'm all ears. > > > > > > I guess I need to understand better what exactly you want to do to be > > > able to advice on something. I can think of a coulpe of options, none of > > > them particularly elegant :) > > > > OK, let me try to explain better. > > > > A machine drifts time. Then an SSSD process receives SIGRT in > > watchdog_handler() and detect
[SSSD] [sssd PR#109][comment] SSSCTL: fix netgroup-show parsing
URL: https://github.com/SSSD/sssd/pull/109 Title: #109: SSSCTL: fix netgroup-show parsing jhrozek commented: """ ok to test """ See the full comment at https://github.com/SSSD/sssd/pull/109#issuecomment-266973055 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#100][+Accepted] Updation of sssd-ad man page for case when dyndns_refresh_interval < 60 seconds
URL: https://github.com/SSSD/sssd/pull/100 Title: #100: Updation of sssd-ad man page for case when dyndns_refresh_interval < 60 seconds Label: +Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#102][comment] Sssctl no case sensitive searches
URL: https://github.com/SSSD/sssd/pull/102 Title: #102: Sssctl no case sensitive searches jhrozek commented: """ Except for the single question about the first patch to make sure I understand why we needed the change, the patches look good to me. CI is pending. """ See the full comment at https://github.com/SSSD/sssd/pull/102#issuecomment-267002949 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#102][+Changes requested] Sssctl no case sensitive searches
URL: https://github.com/SSSD/sssd/pull/102 Title: #102: Sssctl no case sensitive searches Label: +Changes requested ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#102][comment] Sssctl no case sensitive searches
URL: https://github.com/SSSD/sssd/pull/102 Title: #102: Sssctl no case sensitive searches jhrozek commented: """ Actually, the tests don't pass on RHEL-6, because the subprocess module is too old there: http://sssd-ci.duckdns.org/logs/job/59/14/rhel6/ci-build-debug/ci-make-intgcheck.log I think just using subprocess.call would solve the issue. """ See the full comment at https://github.com/SSSD/sssd/pull/102#issuecomment-267003994 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#109][comment] SSSCTL: fix netgroup-show parsing
URL: https://github.com/SSSD/sssd/pull/109 Title: #109: SSSCTL: fix netgroup-show parsing jhrozek commented: """ Thank you for the patch. Since we already have the full entry object in sysdb_attrs I think it would be better to take a look at the objectclass (`sysdb_attrs_get_string(entry, "objectclass", &oc)`) and only if the class is user or a group, format the name, else print the original name. """ See the full comment at https://github.com/SSSD/sssd/pull/109#issuecomment-267015221 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#109][+Changes requested] SSSCTL: fix netgroup-show parsing
URL: https://github.com/SSSD/sssd/pull/109 Title: #109: SSSCTL: fix netgroup-show parsing Label: +Changes requested ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#100][+Changes requested] Updation of sssd-ad man page for case when dyndns_refresh_interval < 60 seconds
URL: https://github.com/SSSD/sssd/pull/100 Title: #100: Updation of sssd-ad man page for case when dyndns_refresh_interval < 60 seconds Label: +Changes requested ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#100][comment] Updation of sssd-ad man page for case when dyndns_refresh_interval < 60 seconds
URL: https://github.com/SSSD/sssd/pull/100 Title: #100: Updation of sssd-ad man page for case when dyndns_refresh_interval < 60 seconds jhrozek commented: """ Actually, I didn't notice at first the patches are still split into three. if you squash the patches, I'll push them. """ See the full comment at https://github.com/SSSD/sssd/pull/100#issuecomment-267017891 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#100][-Accepted] Updation of sssd-ad man page for case when dyndns_refresh_interval < 60 seconds
URL: https://github.com/SSSD/sssd/pull/100 Title: #100: Updation of sssd-ad man page for case when dyndns_refresh_interval < 60 seconds Label: -Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#102][comment] Sssctl no case sensitive searches
URL: https://github.com/SSSD/sssd/pull/102 Title: #102: Sssctl no case sensitive searches jhrozek commented: """ Thank you, since the only issue in the set was related to the CI failure, I'm acking the set.. """ See the full comment at https://github.com/SSSD/sssd/pull/102#issuecomment-267170164 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#102][+Accepted] Sssctl no case sensitive searches
URL: https://github.com/SSSD/sssd/pull/102 Title: #102: Sssctl no case sensitive searches Label: +Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#102][comment] Sssctl no case sensitive searches
URL: https://github.com/SSSD/sssd/pull/102 Title: #102: Sssctl no case sensitive searches jhrozek commented: """ * 35ecfab87a24031e55798b22975e02832ee0f2ad * 715abb607540945cc82355e94712da7ac9746a67 * d6e875c49d6be650a03fc14f00a680734b23ef66 * 867bb85ecc8117aa8bdde9add0df8857cf87236e """ See the full comment at https://github.com/SSSD/sssd/pull/102#issuecomment-267284828 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#102][closed] Sssctl no case sensitive searches
URL: https://github.com/SSSD/sssd/pull/102 Author: mzidek-rh Title: #102: Sssctl no case sensitive searches Action: closed To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/102/head:pr102 git checkout pr102 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#102][-Accepted] Sssctl no case sensitive searches
URL: https://github.com/SSSD/sssd/pull/102 Title: #102: Sssctl no case sensitive searches Label: -Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#102][+Pushed] Sssctl no case sensitive searches
URL: https://github.com/SSSD/sssd/pull/102 Title: #102: Sssctl no case sensitive searches Label: +Pushed ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#107][+Changes requested] WATCHDOG: Avoid non async-signal-safe from the signal_handler
URL: https://github.com/SSSD/sssd/pull/107 Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler Label: +Changes requested ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#107][comment] WATCHDOG: Avoid non async-signal-safe from the signal_handler
URL: https://github.com/SSSD/sssd/pull/107 Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler jhrozek commented: """ I just set the Changes Requested label so that it's clear to reviewers new patch set is coming up.. """ See the full comment at https://github.com/SSSD/sssd/pull/107#issuecomment-267285051 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#106][+Changes requested] Add a new "files" provider
URL: https://github.com/SSSD/sssd/pull/106 Title: #106: Add a new "files" provider Label: +Changes requested ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#106][comment] Add a new "files" provider
URL: https://github.com/SSSD/sssd/pull/106 Title: #106: Add a new "files" provider jhrozek commented: """ I just set the Changes Requested label so that it's clear to reviewers new patch set is coming up.. """ See the full comment at https://github.com/SSSD/sssd/pull/106#issuecomment-267285088 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#67][comment] UTIL: Unset O_NONBLOCK for ldap connection
URL: https://github.com/SSSD/sssd/pull/67 Title: #67: UTIL: Unset O_NONBLOCK for ldap connection jhrozek commented: """ It looks like this patch has stalled a bit. @lslebodn I think it makes sense to merge it anyway, even if we continue discussing some possible additional changes to libldap...that can be done later. Accepting this patch would make sssd usable for Debian&family again. """ See the full comment at https://github.com/SSSD/sssd/pull/67#issuecomment-267285373 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#110][opened] Add more DEBUG messages to help admins diagnose Kerberos login failures
URL: https://github.com/SSSD/sssd/pull/110
Author: jhrozek
Title: #110: Add more DEBUG messages to help admins diagnose Kerberos login
failures
Action: opened
PR body:
"""
This PR contains two trivial (code-wise) patches that just add one DEBUG
message each. It's quite common for admins to get stuck diagnosing issues
where the krb5_child process exists with system error. Moreover, many
system errors are caused by issues during Kerberos ticket validation where
the second patch tries to help to give some tips.
I hope the first patch should be OK to merge. With the second one, I was
struggling a bit to find some useful debug message. If anyone can think
about a better one, I'm all ears. Also, if the DEBUG message would be too
misleading in the general case, I'm equally fine with dropping the second
patch. At least the first one would help to avoid admins asking for help if all
we would tell them is to go and look into the krb5_child.log anyway -- so IMO it
makes sense to just put that info to a debug message.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/110/head:pr110
git checkout pr110
From 30b97a39f75d676f25fe8cdaf03c41e2b7a97e41 Mon Sep 17 00:00:00 2001
From: Jakub Hrozek
Date: Thu, 15 Dec 2016 11:30:13 +0100
Subject: [PATCH 1/2] KRB5: Advise the user to inspect the krb5_child.log if
the child fails with a System Error
It's often not clear to admins where to look further if the krb5_child
fails with a generic error. This patch just adds a DEBUG message
advising the admin to look into the krb5_child.log for more information.
Related:
https://fedorahosted.org/sssd/ticket/2955
---
src/providers/krb5/krb5_auth.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/providers/krb5/krb5_auth.c b/src/providers/krb5/krb5_auth.c
index a5ecb24..5c74be3 100644
--- a/src/providers/krb5/krb5_auth.c
+++ b/src/providers/krb5/krb5_auth.c
@@ -1023,6 +1023,9 @@ static void krb5_auth_done(struct tevent_req *subreq)
goto done;
default:
+DEBUG(SSSDBG_IMPORTANT_INFO,
+ "The krb5_child process returned an error. Please inspect the "
+ "krb5_child.log file for more information\n");
state->pam_status = PAM_SYSTEM_ERR;
state->dp_err = DP_ERR_OK;
ret = EOK;
From 45b5ec06d3f45a47c9093e4b1f7e3be2ba17692a Mon Sep 17 00:00:00 2001
From: Jakub Hrozek
Date: Thu, 15 Dec 2016 11:30:41 +0100
Subject: [PATCH 2/2] KRB5: Add some debugging tips for the 'Server not
found..' error during validation
Adds some tips for the admin on how to debug the 'Server not found in
Kerberos database' kind of errors returned during validation.
Related:
https://fedorahosted.org/sssd/ticket/2955
---
src/providers/krb5/krb5_child.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/providers/krb5/krb5_child.c b/src/providers/krb5/krb5_child.c
index be31ddb..8420553 100644
--- a/src/providers/krb5/krb5_child.c
+++ b/src/providers/krb5/krb5_child.c
@@ -1177,6 +1177,15 @@ static krb5_error_code validate_tgt(struct krb5_req *kr)
} else {
DEBUG(SSSDBG_CRIT_FAILURE ,"TGT failed verification using key " \
"for [%s].\n", principal);
+if (kerr == KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN) {
+DEBUG(SSSDBG_IMPORTANT_INFO,
+ "The server principal was not found. If the user comes "
+ "from a different domain than the host, please verify "
+ "that Kerberos servers from all domains in the trust "
+ "paths are reachable. Acquiring a ticket using the 'kvno' "
+ "utility for the principal used for verification might "
+ "also be used to debug the issue further\n");
+}
goto done;
}
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#111][comment] BUILD: Find a host-prefixed krb5-config when cross-compiling
URL: https://github.com/SSSD/sssd/pull/111 Title: #111: BUILD: Find a host-prefixed krb5-config when cross-compiling jhrozek commented: """ ok to test """ See the full comment at https://github.com/SSSD/sssd/pull/111#issuecomment-267546737 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#109][comment] SSSCTL: fix netgroup-show parsing
URL: https://github.com/SSSD/sssd/pull/109
Title: #109: SSSCTL: fix netgroup-show parsing
jhrozek commented:
"""
Ah, I didn't realize we don't read the objectclass attribute by default. The
following hunk should fix it:
```
@@ -219,12 +233,14 @@ static const char **sssctl_build_attrs(TALLOC_CTX
*mem_ctx,
/* no op */
}
-attrs = talloc_zero_array(mem_ctx, const char *, count + 1);
+attrs = talloc_zero_array(mem_ctx, const char *, count + 2);
if (attrs == NULL) {
return NULL;
}
-for (i = 0; i < count; i++) {
+attrs[0] = "objectclass";
+
+for (i = 1; i < count; i++) {
```
One other nitpick is that you probably want to assign the original name to
tmp_name by duplicating the memory to avoid a const-warning:
`tmp_name = talloc_strdup(mem_ctx, orig_name);`
Finally, please compare the value of the objectclass with strcmp, not pointer
comparison:
`if ((strcmp(class, SYSDB_USER_CLASS) == 0) || (strcmp(class,
SYSDB_GROUP_CLASS) == 0)) {`
(and split the line into two, so that it fits into the 80-chars limit)
"""
See the full comment at
https://github.com/SSSD/sssd/pull/109#issuecomment-267568893
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#111][+Accepted] BUILD: Find a host-prefixed krb5-config when cross-compiling
URL: https://github.com/SSSD/sssd/pull/111 Title: #111: BUILD: Find a host-prefixed krb5-config when cross-compiling Label: +Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#111][comment] BUILD: Find a host-prefixed krb5-config when cross-compiling
URL: https://github.com/SSSD/sssd/pull/111 Title: #111: BUILD: Find a host-prefixed krb5-config when cross-compiling jhrozek commented: """ ACK, CI: http://sssd-ci.duckdns.org/logs/job/59/21/summary.html (the failure on rawhide is unrelated) """ See the full comment at https://github.com/SSSD/sssd/pull/111#issuecomment-267571038 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#111][+Pushed] BUILD: Find a host-prefixed krb5-config when cross-compiling
URL: https://github.com/SSSD/sssd/pull/111 Title: #111: BUILD: Find a host-prefixed krb5-config when cross-compiling Label: +Pushed ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#111][comment] BUILD: Find a host-prefixed krb5-config when cross-compiling
URL: https://github.com/SSSD/sssd/pull/111 Title: #111: BUILD: Find a host-prefixed krb5-config when cross-compiling jhrozek commented: """ * master: baadb6080be0ec5cee2e351c3d5324d755f86f9c """ See the full comment at https://github.com/SSSD/sssd/pull/111#issuecomment-267571456 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#111][closed] BUILD: Find a host-prefixed krb5-config when cross-compiling
URL: https://github.com/SSSD/sssd/pull/111 Author: dm0- Title: #111: BUILD: Find a host-prefixed krb5-config when cross-compiling Action: closed To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/111/head:pr111 git checkout pr111 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#112][comment] FAILOVER: Improve port status log messages
URL: https://github.com/SSSD/sssd/pull/112 Title: #112: FAILOVER: Improve port status log messages jhrozek commented: """ ok to test """ See the full comment at https://github.com/SSSD/sssd/pull/112#issuecomment-268183489 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#109][-Changes requested] SSSCTL: fix netgroup-show parsing
URL: https://github.com/SSSD/sssd/pull/109 Title: #109: SSSCTL: fix netgroup-show parsing Label: -Changes requested ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#89][comment] nss: rewrite nss responder so it uses cache_req
URL: https://github.com/SSSD/sssd/pull/89 Title: #89: nss: rewrite nss responder so it uses cache_req jhrozek commented: """ @pbrezina @lslebodn is there any more work needed on https://fedorahosted.org/sssd/ticket/1126 or https://fedorahosted.org/sssd/ticket/2320 ? Do we anticipate to work on other responders? The end goal is to support https://fedorahosted.org/sssd/ticket/843 and https://fedorahosted.org/sssd/ticket/3001 """ See the full comment at https://github.com/SSSD/sssd/pull/89#issuecomment-268193885 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#106][comment] Add a new "files" provider
URL: https://github.com/SSSD/sssd/pull/106 Title: #106: Add a new "files" provider jhrozek commented: """ I hope you noticed the earlier comment that says "I just set the Changes Requested label so that it's clear to reviewers new patch set is coming up.." """ See the full comment at https://github.com/SSSD/sssd/pull/106#issuecomment-268356995 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#112][comment] FAILOVER: Improve port status log messages
URL: https://github.com/SSSD/sssd/pull/112 Title: #112: FAILOVER: Improve port status log messages jhrozek commented: """ I have two comments: 1. The new debug message has "louder" debug level than the one that sets the port as non-working. I would suggest to also change the 'not working' debug message to MINOR_FAILURE 1. I'm not sure it's correct to say that there is 'no relationship' between the message and the networking status, but not a 'direct relationship' or '1:1 mapping' I'm not sure how to reword the message better though, do you think it would make sense to say something like 'even if the network port is reachable, the internal port can be marked as not working if sssd is not able to complete the full connection request' """ See the full comment at https://github.com/SSSD/sssd/pull/112#issuecomment-268471510 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#112][+Changes requested] FAILOVER: Improve port status log messages
URL: https://github.com/SSSD/sssd/pull/112 Title: #112: FAILOVER: Improve port status log messages Label: +Changes requested ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#112][comment] FAILOVER: Improve port status log messages
URL: https://github.com/SSSD/sssd/pull/112 Title: #112: FAILOVER: Improve port status log messages jhrozek commented: """ I wonder if @mzidek-rh has any more comments """ See the full comment at https://github.com/SSSD/sssd/pull/112#issuecomment-268471546 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#94][comment] Enable {socket,dbus}-activation for responders
URL: https://github.com/SSSD/sssd/pull/94
Title: #94: Enable {socket,dbus}-activation for responders
jhrozek commented:
"""
Coverity seems to have detected a warning:
Error: CHECKED_RETURN (CWE-252):
sssd-1.14.90/src/responder/autofs/autofssrv_cmd.c:323: check_return: Calling
"sss_cmd_empty_packet" without checking return value (as is done elsewhere 4
out of 5 times).
sssd-1.14.90/src/responder/autofs/autofssrv_cmd.c:1401: example_assign: Example
1: Assigning: "ret" = return value from "sss_cmd_empty_packet(pctx->creq->out)".
sssd-1.14.90/src/responder/autofs/autofssrv_cmd.c:1402: example_checked:
Example 1 (cont.): "ret" has its value checked in "ret != 0".
sssd-1.14.90/src/responder/autofs/autofssrv_cmd.c:1424: example_assign: Example
2: Assigning: "ret" = return value from "sss_cmd_empty_packet(pctx->creq->out)".
sssd-1.14.90/src/responder/autofs/autofssrv_cmd.c:1425: example_checked:
Example 2 (cont.): "ret" has its value checked in "ret != 0".
sssd-1.14.90/src/responder/autofs/autofssrv_cmd.c:1097: example_assign: Example
3: Assigning: "ret" = return value from "sss_cmd_empty_packet(pctx->creq->out)".
sssd-1.14.90/src/responder/autofs/autofssrv_cmd.c:1098: example_checked:
Example 3 (cont.): "ret" has its value checked in "ret != 0".
sssd-1.14.90/src/responder/common/responder_cmd.c:85: example_assign: Example
4: Assigning: "ret" = return value from "sss_cmd_empty_packet(pctx->creq->out)".
sssd-1.14.90/src/responder/common/responder_cmd.c:86: example_checked: Example
4 (cont.): "ret" has its value checked in "ret != 0".
# 321| DEBUG(SSSDBG_TRACE_FUNC, "setautomntent did not find
requested map\n");
# 322| /* Notify the caller that this entry wasn't found */
# 323|-> sss_cmd_empty_packet(pctx->creq->out);
# 324| } else {
# 325| DEBUG(SSSDBG_TRACE_FUNC, "setautomntent found data\n");
I'm not sure if it's legit or if we just passed a threshold of
checked/unchecked ratio, but it would be nice to not add any new warnings with
new commits.
Could you please add a more verbose comment to the commits that enable the
responder socket activation (either the first one, autofs, or just copy to all)
that explain why the BindsTo option was added and what the workflow is for
socket-activated responders and starting and stopping the sssd service?
Similarly, can you please explain in the commit message that adds the
`--unprivileged-start` option that the log files are chowned by the unit file
and the socket files created by sssd in the most common scenario of this
option? I was even wondering if the option would be better named
`--socket-activated-start` but I don't have strong feelings about it.
There is a typo in the commit that changes the PAM responder
`unprivileged_unprivileged_start`, which would be nice to fix in the commit
where it was introduced, so that every commit can be compiled on its own and we
can always use bisect.
I have a bit of trouble reading `client_registration()` after ` MONITOR: Deal
with socket-activated responders`. Could we please change
`client_registration()` so that the ifdefs are a bit less interleaved with the
non-systemd code? Even at the cost of a little code duplication, I think this:
```
#ifdef HAVE_SYSTEMD
systemd_client_registration(args..)
#else
managed_client_registration(args..)
#endif /* HAVE_SYSTEMD */
```
Is IMO preferred over the ifdefs being sprinkled around in the code.
About ` MAN: Mention that the services' list is optional`, are you sure just
enabling the socket is all that is needed? Doesn't the admin also need to
enable the service in addition to the socket?
`MONITOR: Let the responder know whether it was socket-activated`: do you think
this commit is needed? Could the responder learn that it's socket activated
when it goes through `activate_unix_sockets()` or is that too late? Please note
I'm not against this commit per se, I'm just trying to see if we can simplify
the code.
I'm not sure I understand the `time_t` pointer being added to the responder
context. Shouldn't we only care about the requests from the client, like NSS or
D-Bus?
I mostly just read the code, but I'm afraid I'm still having issues with the
socket-activated PAM responder. My sssd.conf is as follows:
```
[sssd]
services = nss
user = sssd
domains = ipa.test
```
I enabled and started the sssd-pam responder socket, then tried to log in as an
IPA user, but I'm getting:
```
Dec 21 09:57:04 client.ipa.test su[30415]: pam_sss(su-l:auth): Request to sssd
failed. Public socket has wrong ownership or permissions
```
The socket was created as:
```
srw-rw-rw
[SSSD] [sssd PR#109][+Accepted] SSSCTL: fix netgroup-show parsing
URL: https://github.com/SSSD/sssd/pull/109 Title: #109: SSSCTL: fix netgroup-show parsing Label: +Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#109][comment] SSSCTL: fix netgroup-show parsing
URL: https://github.com/SSSD/sssd/pull/109 Title: #109: SSSCTL: fix netgroup-show parsing jhrozek commented: """ Thank you, the patch works well. Just please note that after 7b293a5095ef3e63cd2e3f2ff01b7484bf6dcd38 was commited, this patch would only apply for sssd-1-14. That said, I'm not sure if 7b293a5095ef3e63cd2e3f2ff01b7484bf6dcd38 is something we want, so for the time being (and because many developers are already out for the Christmas holidays), I'm just adding the accepted label now but would only push the commit later. """ See the full comment at https://github.com/SSSD/sssd/pull/109#issuecomment-268488768 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#109][comment] SSSCTL: fix netgroup-show parsing
URL: https://github.com/SSSD/sssd/pull/109 Title: #109: SSSCTL: fix netgroup-show parsing jhrozek commented: """ btw I also added a test in PR #113 so that we don't regress again """ See the full comment at https://github.com/SSSD/sssd/pull/109#issuecomment-268489241 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#113][opened] Adds an integration test for sssctl netgroup-show so that we don't regress again like we did in ticket #3267.
URL: https://github.com/SSSD/sssd/pull/113
Author: jhrozek
Title: #113: Adds an integration test for sssctl netgroup-show so that we
don't regress again like we did in ticket #3267.
Action: opened
PR body:
"""
None
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/113/head:pr113
git checkout pr113
From 4b2c0ff9c291f41b9009e5e888a51146f1f6384a Mon Sep 17 00:00:00 2001
From: Jakub Hrozek
Date: Wed, 21 Dec 2016 11:17:42 +0100
Subject: [PATCH] TESTS: Add an integration test for sssctl netgroup-show
---
src/tests/intg/test_sssctl.py | 27 +++
1 file changed, 27 insertions(+)
diff --git a/src/tests/intg/test_sssctl.py b/src/tests/intg/test_sssctl.py
index 1c3b9c8..60e2e68 100644
--- a/src/tests/intg/test_sssctl.py
+++ b/src/tests/intg/test_sssctl.py
@@ -29,6 +29,7 @@
import ldap_ent
import config
from util import unindent
+import sssd_netgroup
LDAP_BASE_DN = "dc=example,dc=com"
@@ -142,6 +143,7 @@ def sanity_rfc2307(request, ldap_conn):
sudo_provider = ldap
ldap_uri= {ldap_conn.ds_inst.ldap_url}
ldap_search_base= {ldap_conn.ds_inst.base_dn}
+ldap_netgroup_search_base = ou=Netgroups,{ldap_conn.ds_inst.base_dn}
""").format(**locals())
create_conf_fixture(request, conf)
create_sssd_fixture(request)
@@ -359,3 +361,28 @@ def test_group_show_basic_fqname_insensitive(ldap_conn,
output = get_call_output(["sssctl", "group-show", "camelcasegroup1@LDAP"])
assert output.find("Name: camelcasegroup1@LDAP") != -1
assert output.find("Cached in InfoPipe: No") != -1
+
+
+@pytest.fixture
+def add_tripled_netgroup(request, ldap_conn):
+ent_list = ldap_ent.List(ldap_conn.ds_inst.base_dn)
+
+ent_list.add_netgroup("tripled_netgroup", ["(host,user,domain)"])
+
+ent_list.add_netgroup("adv_tripled_netgroup", ["(host1,user1,domain1)",
+ "(host2,user2,domain2)"])
+
+create_ldap_fixture(request, ldap_conn, ent_list)
+return None
+
+
+def test_netgroup_show(ldap_conn,
+ sanity_rfc2307,
+ portable_LC_ALL,
+ add_tripled_netgroup):
+res, _, netgrps = sssd_netgroup.get_sssd_netgroups("tripled_netgroup")
+assert res == sssd_netgroup.NssReturnCode.SUCCESS
+assert netgrps == [("host", "user", "domain")]
+
+output = get_call_output(["sssctl", "netgroup-show", "tripled_netgroup"])
+assert output.find("Name: tripled_netgroup") != -1
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#94][+Changes requested] Enable {socket, dbus}-activation for responders
URL: https://github.com/SSSD/sssd/pull/94
Title: #94: Enable {socket,dbus}-activation for responders
Label: +Changes requested
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#110][-Changes requested] Add more DEBUG messages to help admins diagnose Kerberos login failures
URL: https://github.com/SSSD/sssd/pull/110 Title: #110: Add more DEBUG messages to help admins diagnose Kerberos login failures Label: -Changes requested ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#110][synchronized] Add more DEBUG messages to help admins diagnose Kerberos login failures
URL: https://github.com/SSSD/sssd/pull/110
Author: jhrozek
Title: #110: Add more DEBUG messages to help admins diagnose Kerberos login
failures
Action: synchronized
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/110/head:pr110
git checkout pr110
From 03a269380a52f53c1e89bf6b71e8dcef2fff90c4 Mon Sep 17 00:00:00 2001
From: Jakub Hrozek
Date: Thu, 15 Dec 2016 11:30:13 +0100
Subject: [PATCH 1/2] KRB5: Advise the user to inspect the krb5_child.log if
the child fails with a System Error
It's often not clear to admins where to look further if the krb5_child
fails with a generic error. This patch just adds a DEBUG message
advising the admin to look into the krb5_child.log for more information.
Related:
https://fedorahosted.org/sssd/ticket/2955
---
src/providers/krb5/krb5_auth.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/providers/krb5/krb5_auth.c b/src/providers/krb5/krb5_auth.c
index a5ecb24..bdd8e24 100644
--- a/src/providers/krb5/krb5_auth.c
+++ b/src/providers/krb5/krb5_auth.c
@@ -1023,6 +1023,9 @@ static void krb5_auth_done(struct tevent_req *subreq)
goto done;
default:
+DEBUG(SSSDBG_IMPORTANT_INFO,
+ "The krb5_child process returned an error. Please inspect the "
+ "krb5_child.log file or the journal for more information\n");
state->pam_status = PAM_SYSTEM_ERR;
state->dp_err = DP_ERR_OK;
ret = EOK;
From b66f2372803039d390c9c5dede9b4488c79f238b Mon Sep 17 00:00:00 2001
From: Jakub Hrozek
Date: Thu, 15 Dec 2016 11:30:41 +0100
Subject: [PATCH 2/2] KRB5: Add some debugging tips for the 'Server not
found..' error during validation
Adds some tips for the admin on how to debug the 'Server not found in
Kerberos database' kind of errors returned during validation.
Related:
https://fedorahosted.org/sssd/ticket/2955
---
src/providers/krb5/krb5_child.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/providers/krb5/krb5_child.c b/src/providers/krb5/krb5_child.c
index be31ddb..8420553 100644
--- a/src/providers/krb5/krb5_child.c
+++ b/src/providers/krb5/krb5_child.c
@@ -1177,6 +1177,15 @@ static krb5_error_code validate_tgt(struct krb5_req *kr)
} else {
DEBUG(SSSDBG_CRIT_FAILURE ,"TGT failed verification using key " \
"for [%s].\n", principal);
+if (kerr == KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN) {
+DEBUG(SSSDBG_IMPORTANT_INFO,
+ "The server principal was not found. If the user comes "
+ "from a different domain than the host, please verify "
+ "that Kerberos servers from all domains in the trust "
+ "paths are reachable. Acquiring a ticket using the 'kvno' "
+ "utility for the principal used for verification might "
+ "also be used to debug the issue further\n");
+}
goto done;
}
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#107][comment] WATCHDOG: Avoid non async-signal-safe from the signal_handler
URL: https://github.com/SSSD/sssd/pull/107 Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler jhrozek commented: """ Hmm, I'm sorry, I think this is my fault for suggesting we move more stuff out of the POSIX signal handler, but I don't think we can remove the watchdog overflow. Moving the watchdog overflow out of the signal handler and into the tevent loop would effectively disable watchdog, because if sssd is really blocked, the tevent fd handler would never be called and the watchdog would never kill the process.. So I think the only part that should be moved is the re-initializing of the watchdog in case we detect a timeshift.. btw I only realized this when I tried to test that watchdog still works. I set a ridiculously short timeout (2) and a breakpoint in sdap_save_user. I only saw SIGRT incoming, but the process was never killed. """ See the full comment at https://github.com/SSSD/sssd/pull/107#issuecomment-268495109 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#107][+Changes requested] WATCHDOG: Avoid non async-signal-safe from the signal_handler
URL: https://github.com/SSSD/sssd/pull/107 Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler Label: +Changes requested ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#117][+Accepted] Fix compilation with python3.6
URL: https://github.com/SSSD/sssd/pull/117 Title: #117: Fix compilation with python3.6 Label: +Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#117][comment] Fix compilation with python3.6
URL: https://github.com/SSSD/sssd/pull/117 Title: #117: Fix compilation with python3.6 jhrozek commented: """ ACK """ See the full comment at https://github.com/SSSD/sssd/pull/117#issuecomment-269948911 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#106][comment] Add a new "files" provider
URL: https://github.com/SSSD/sssd/pull/106 Title: #106: Add a new "files" provider jhrozek commented: """ OK, ready for review, @pbrezina There is still a commit that generates the default configuration. We already have a PR #108 that reverts this functionality -- I guess it would be best to provide a configure-time option or even a runtime option that would disable the files domain. Otherwise, the files domain would be always enabled and always first. """ See the full comment at https://github.com/SSSD/sssd/pull/106#issuecomment-269988218 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#106][-Changes requested] Add a new "files" provider
URL: https://github.com/SSSD/sssd/pull/106 Title: #106: Add a new "files" provider Label: -Changes requested ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#116][+Accepted] intg: Generate tmp dir with lowercase
URL: https://github.com/SSSD/sssd/pull/116 Title: #116: intg: Generate tmp dir with lowercase Label: +Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#116][comment] intg: Generate tmp dir with lowercase
URL: https://github.com/SSSD/sssd/pull/116 Title: #116: intg: Generate tmp dir with lowercase jhrozek commented: """ ACK. Can you file a ticket to remove this hack once we have a version of python-requests that works? """ See the full comment at https://github.com/SSSD/sssd/pull/116#issuecomment-269989323 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#89][comment] nss: rewrite nss responder so it uses cache_req
URL: https://github.com/SSSD/sssd/pull/89 Title: #89: nss: rewrite nss responder so it uses cache_req jhrozek commented: """ On Mon, Jan 02, 2017 at 01:53:23AM -0800, Pavel Březina wrote: > @jhrozek > * #1126 -- pam, ssh and pac (?) responders needs to be amended, but the > change there is not that huge. OK, then let's keep the ticket open. Do you plan on working on this one or would you prefer if someone else took a look? > * #2320 -- not sure if this is needed anywhere with cache req I agree if other responders start using cache_req, we don't need this anymore. """ See the full comment at https://github.com/SSSD/sssd/pull/89#issuecomment-270023513 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#107][+Changes requested] WATCHDOG: Avoid non async-signal-safe from the signal_handler
URL: https://github.com/SSSD/sssd/pull/107 Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler Label: +Changes requested ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#107][comment] WATCHDOG: Avoid non async-signal-safe from the signal_handler
URL: https://github.com/SSSD/sssd/pull/107 Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler jhrozek commented: """ hmm, it seems I was wrong and at least with systemd (is that the difference?) when we kill the whole process group also the nss and pam responders (that were started explicitly) are killed. So I was wrong. Can you please retest if you see the same? But in general I think we can stick to the previous version, sorry about guiding you down the wrong path. """ See the full comment at https://github.com/SSSD/sssd/pull/107#issuecomment-270622372 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#107][comment] WATCHDOG: Avoid non async-signal-safe from the signal_handler
URL: https://github.com/SSSD/sssd/pull/107 Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler jhrozek commented: """ ACK """ See the full comment at https://github.com/SSSD/sssd/pull/107#issuecomment-270630387 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#107][+Accepted] WATCHDOG: Avoid non async-signal-safe from the signal_handler
URL: https://github.com/SSSD/sssd/pull/107 Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler Label: +Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#107][comment] WATCHDOG: Avoid non async-signal-safe from the signal_handler
URL: https://github.com/SSSD/sssd/pull/107 Title: #107: WATCHDOG: Avoid non async-signal-safe from the signal_handler jhrozek commented: """ btw now I'm wondering if the setpgrp should be a separate patch also for stable branches because I guess the bug was present in sssd for quite a long time? """ See the full comment at https://github.com/SSSD/sssd/pull/107#issuecomment-270637274 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#109][comment] SSSCTL: fix netgroup-show parsing
URL: https://github.com/SSSD/sssd/pull/109 Title: #109: SSSCTL: fix netgroup-show parsing jhrozek commented: """ This patch is OK, but only for sssd-1-14. In master, we already fall back to parsing the name string as short name if parsing the qualified name fails. I’m not thrilled about that, because it can conceal legitimate errors, but it’s needed atm to use cache_req everywhere. So yeah, ack to this patch for sssd-1-14 > On 6 Jan 2017, at 10:59, lslebodn wrote: > > @jhrozek <https://github.com/jhrozek> Have you already decided whether it > would be better to have this patch or 7b293a5 > <https://github.com/SSSD/sssd/commit/7b293a5095ef3e63cd2e3f2ff01b7484bf6dcd38>? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/SSSD/sssd/pull/109#issuecomment-270870268>, or mute the > thread > <https://github.com/notifications/unsubscribe-auth/AArrAj2dX_wtSbPfE5pfLpRJ1ApbWU7wks5rPhCMgaJpZM4LMfe2>. > """ See the full comment at https://github.com/SSSD/sssd/pull/109#issuecomment-270906940 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#109][comment] SSSCTL: fix netgroup-show parsing
URL: https://github.com/SSSD/sssd/pull/109 Title: #109: SSSCTL: fix netgroup-show parsing jhrozek commented: """ > On 6 Jan 2017, at 16:29, lslebodn wrote: > > On (06/01/17 05:52), Jakub Hrozek wrote: > >This patch is OK, but only for sssd-1-14. In master, we already fall back to > >parsing the name string as short name if parsing the qualified name fails. > >I’m not thrilled about that, because it can conceal legitimate errors, but > >it’s needed atm to use cache_req everywhere. > > > >So yeah, ack to this patch for sssd-1-14 > > > Do you think that it would be a problem to backport > 7b293a5095ef3e63cd2e3f2ff01b7484bf6dcd38 into 1.14 > rather that this patch? > > Upstream integration tests passed with it. I haven't tried downstrem > tests. > That would also work. > LS > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/SSSD/sssd/pull/109#issuecomment-270927695>, or mute the > thread > <https://github.com/notifications/unsubscribe-auth/AArrAjMI-4Ngp0iWszBelCCTnwc6bLh3ks5rPl3dgaJpZM4LMfe2>. > """ See the full comment at https://github.com/SSSD/sssd/pull/109#issuecomment-271093554 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#106][+Changes requested] Add a new "files" provider
URL: https://github.com/SSSD/sssd/pull/106 Title: #106: Add a new "files" provider Label: +Changes requested ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#106][comment] Add a new "files" provider
URL: https://github.com/SSSD/sssd/pull/106
Title: #106: Add a new "files" provider
jhrozek commented:
"""
Yes, but as I said in the comment (in the part you quoted out),
assert_passwd_by_name won't work, because it expects dir and uses dir in its
control directory:
```
Traceback (most recent call last):
File "/home/remote/jhrozek/devel/sssd/src/tests/intg/test_files_ops.py", line
55, in test_userdel
ent.assert_passwd_by_name("user1", USER1)
File "/home/remote/jhrozek/devel/sssd/src/tests/intg/ent.py", line 216, in
assert_passwd_by_name
d = _diff(ent, pattern)
File "/home/remote/jhrozek/devel/sssd/src/tests/intg/ent.py", line 111, in
_diff
d = _diff(ent[key], value, item_map)
KeyError: 'directory'
```
"""
See the full comment at
https://github.com/SSSD/sssd/pull/106#issuecomment-271338295
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
