Jira (PUP-3204) Find LDAP users and groups created mid-transaction.

14 views
Skip to first unread message

Geoff Nichols (JIRA)

unread,
Jun 7, 2017, 10:37:06 AM6/7/17
to puppe...@googlegroups.com
Geoff Nichols updated an issue
 
Puppet / New Feature PUP-3204
Find LDAP users and groups created mid-transaction.
Change By: Geoff Nichols
Summary: Users Find LDAP users  and groups created mid-transaction  are not found .
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
Atlassian logo

Owen Rodabaugh (JIRA)

unread,
Aug 10, 2017, 4:48:02 PM8/10/17
to puppe...@googlegroups.com
Owen Rodabaugh updated an issue
Change By: Owen Rodabaugh
CS Priority: Needs Priority Normal
CS Impact: This is related to how the OS process management caches LDAP data. This is to some extent an OS level problem because the puppet process doesn't know about the updated LDAP data. 

The only way we can think of to solve this in Puppet is around fully restarting the puppet service to deal with this such as a postrun command or running puppet via cron.
CS Severity: 3 - Serious
CS Business Value: 3 - $$$$
CS Frequency: 3 - 25-50% of Customers

Russell Knighton (JIRA)

unread,
Aug 3, 2018, 5:49:04 AM8/3/18
to puppe...@googlegroups.com
Russell Knighton commented on New Feature PUP-3204
 
Re: Find LDAP users and groups created mid-transaction.

It's a long shot, but perhaps PuppetLabs could use a bit of their commercial power/popularity and get the above RedHat ticket reopened, or create a replacement one that petitions for this to be properly fixed at the glibc level?

That original bug report was closed with the answer:

That file will never be automatically reloaded. The file is not
supposed to be changed after the initial configuration and if it does,
better reboot and restart all relevant programs. I will not add any
code which penalizes normal operations.

All this can in general be avoided by using nscd. If nscd is used
only this one program needs to be restarted for the new setting to be
used. If you need to use change the nsswitch.conf setting for
services other than passwd, group, and hosts then this is something
else. The solution then might be to add support for these other
services to nscd.

So in summary, us nscd and never let programs directly use NSS services.

which may have been true/applicable/satisfactory 14 years ago in 2004, but it's now 2018. Tools of the like of puppet were barely conceived back then. Hardware is an order of magnitude more powerful now, so what sort of penalty would normal operations really under go now-a-days? As for the suggested NSCd, well, it has been pretty much entirely replaced by SSSd, but neither of these solve that the ticket was originally for.

Clearly, this isn't something that just affects puppet, so for the benefit of all OSes that use glibc, it would surely be better that this is fixed properly, once and for all. I appreciate that, even if this was ever implemented by the overlords of glibc, it would take a long time to make it into released distros, but at least we'd be on the right path to a real fix, even if it means we'd still need and be relying on a hacky workaround in the meantime.

This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Atlassian logo

Maheswaran Shanmugam (JIRA)

unread,
Sep 26, 2018, 11:53:05 PM9/26/18
to puppe...@googlegroups.com

Jacob Henner (JIRA)

unread,
Nov 28, 2018, 10:12:02 PM11/28/18
to puppe...@googlegroups.com
Jacob Henner commented on New Feature PUP-3204

This is affecting my organization as well. Centrify authentication is enabled by the same run that attempts to set the permissions on several file resources, and extracts archives using the archive module with user/group specified. In both cases, the process will fail until the next run. We worked around the issue with a combination of chown execs and custom extract_command[s], but this is obviously undesirable.

Trevor Vaughan and I discussed this in the community Slack today, and he's left a comment upstream at https://bugzilla.redhat.com/show_bug.cgi?id=132608, hopefully something comes of it.

Josh Cooper (JIRA)

unread,
Oct 1, 2019, 1:08:06 AM10/1/19
to puppe...@googlegroups.com

Austin Boyd (Jira)

unread,
Sep 22, 2020, 6:50:03 AM9/22/20
to puppe...@googlegroups.com
Austin Boyd updated an issue
Change By: Austin Boyd
Zendesk Ticket Count: 3 4
Zendesk Ticket IDs: 17574,24477, 24914, 32160
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Atlassian logo

Austin Boyd (Jira)

unread,
Sep 22, 2020, 6:50:04 AM9/22/20
to puppe...@googlegroups.com
Austin Boyd updated an issue
Change By: Austin Boyd
Zendesk Ticket Count: 1 2
Zendesk Ticket IDs: 17574, 32160

Austin Boyd (Jira)

unread,
Sep 22, 2020, 6:50:04 AM9/22/20
to puppe...@googlegroups.com
Austin Boyd updated an issue
Change By: Austin Boyd
Zendesk Ticket Count: 1
Zendesk Ticket IDs: 32160

Austin Boyd (Jira)

unread,
Sep 22, 2020, 6:50:04 AM9/22/20
to puppe...@googlegroups.com
Austin Boyd updated an issue
Change By: Austin Boyd
Zendesk Ticket Count: 2 3
Zendesk Ticket IDs: 17574, 24477, 32160

Austin Boyd (Jira)

unread,
Apr 27, 2021, 1:54:01 PM4/27/21
to puppe...@googlegroups.com
Austin Boyd updated an issue
Change By: Austin Boyd
Labels: help_wanted jira_escalated redmine
This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97)
Atlassian logo

Austin Boyd (Jira)

unread,
Apr 27, 2021, 1:54:02 PM4/27/21
to puppe...@googlegroups.com
Austin Boyd updated an issue
Change By: Austin Boyd
Zendesk Ticket Count: 4 5
Zendesk Ticket IDs: 17574,24477,24914,32160 ,44128
Reply all
Reply to author
Forward
0 new messages