sssd-devel December 2011

sssd-devel@lists.fedorahosted.org

27 participants
59 discussions

Start a nNew thread

[PATCH] LDAP provider: Error while setting the nocanon option should not be fatal
by Jakub Hrozek 08 Dec '11

08 Dec '11

https://fedorahosted.org/sssd/ticket/1100

2 2

[PATCH] Always attempt to connect in sdap_async_sys_connect_done
by Jakub Hrozek 07 Dec '11

07 Dec '11

The attached patch syncs up with Samba commit 50e30afa608dfdeae8a260730ead9761ed424dad

3 2

[PATCH] Pass the correct private data into Data Provider callback
by Jakub Hrozek 07 Dec '11

07 Dec '11

This was causing segfaults in netgroups processing.

2 1

uid with @(at) sign
by Stefan Lesicnik 06 Dec '11

06 Dec '11

Hi, I'm hoping someone can help. I am using RHEL 6.1 and trying to use sssd to authenticate to our ldap server. Our ldap server uses the uid=name@domain as the uid. sssd seems to pass the name part only. Below is the extract from log. This is generated by running getent passwd stefan(a)lsd.com Originally I had the issue where the @ part of the search was looking for a specific sssd provider. I changed my domain to lsd.com. This lets me search but as you can see below, passes the filter of uid=stefan and not uid=stefan(a)lsd.com Thanks in advance, Stefan ==> slapd trace Dec 5 12:51:58 ecstasy slapd[15262]: conn=1327 op=4 SRCH base="ou=lsd,ou=users,dc=lsd,dc=co,dc=za" scope=2 deref=0 filter="(&(uid=stefan)(objectClass=posixAccount))" Dec 5 12:51:58 ecstasy slapd[15262]: conn=1327 op=4 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock ==> sssd_nss.log <== (Mon Dec 5 12:55:40 2011) [sssd[nss]] [accept_fd_handler] (4): Client connected! (Mon Dec 5 12:55:40 2011) [sssd[nss]] [sss_cmd_get_version] (5): Received client version [1]. (Mon Dec 5 12:55:40 2011) [sssd[nss]] [sss_cmd_get_version] (5): Offered version [1]. (Mon Dec 5 12:55:40 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [stefan] from [lsd.com] (Mon Dec 5 12:55:40 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): Requesting info for [stefan(a)lsd.com] (Mon Dec 5 12:55:40 2011) [sssd[nss]] [sss_dp_send_acct_req_create] (4): Sending request for [lsd.com][4097][1][name=stefan] ==> sssd_lsd.com.log <== (Mon Dec 5 12:55:40 2011) [sssd[be[lsd.com]]] [be_get_account_info] (4): Got request for [4097][1][name=stefan] (Mon Dec 5 12:55:40 2011) [sssd[be[lsd.com]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success ==> sssd_nss.log <== (Mon Dec 5 12:55:40 2011) [sssd[nss]] [sss_dp_get_reply] (4): Got reply (0, 0, Success) from Data Provider (Mon Dec 5 12:55:40 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): Requesting info for [stefan(a)lsd.com] ==> sssd_lsd.com.log <== ==> sssd_nss.log <== (Mon Dec 5 12:55:40 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (2): No results for getpwnam call (Mon Dec 5 12:55:40 2011) [sssd[nss]] [client_recv] (5): Client disconnected!

3 4

[PATCH] Allow using Glib for UTF8 support
by Stephen Gallagher 05 Dec '11

05 Dec '11

Currently, SSSD only supports using libunistring to manage unicode strings. There are some platforms out there (such as RHEL 5) that do not have libunistring available. With this patch, we add an optional flag to autoconf to allow SSSD to link against Glib and use its unicode functionality.

3 5

[PATCH] Fixed an error in macro for merging double linked lists
by Jan Zelený 05 Dec '11

05 Dec '11

This might be contributing to some segfaults in the failover code: https://fedorahosted.org/sssd/ticket/1037 Thanks Jan

3 2

IMPORTANT: Your input requested: SSSD LDAP Provider vs Winbind
by Stephen Gallagher 05 Dec '11

05 Dec '11

When we originally designed SSSD, we looked at it as a solution for dealing with LDAP and Kerberos identity and authentication for Linux and UNIX clients. With our initial approach, we decided to include only marginal support for Microsoft's Active Directory as a source of user information (only supporting it when it is enabled for use with posixAccount and posixGroup object classes). Our original assumption was that for complicated deployments relying on Active Directory, users would prefer to continue using Winbind. It has a very long history and is specifically designed around managing the peculiarities of Microsoft's LDAP implementation. Of late, it has become apparent that many users are opting to "jump ship" from winbind to SSSD for use with Active Directory. This has been shown by a sharp uptick in community bug reports with Active Directory servers. Up until now, our plans around Active Directory have circulated around including a "Winbind Provider" into SSSD, similar to the LDAP provider but making use of the original winbind features found in the Samba project. However, it's beginning to seem like users are expressing an interest to move AWAY from that solution. This may result in a change in our strategy going forward. I'm looking for users to describe to us the reasons why they're choosing SSSD (in its current incarnation) over winbind. What I'm trying to sort out is whether there are specific *issues* with winbind that SSSD is solving for users. In other words, I'm trying to determine whether our decision to write and support a winbind provider backend is misplaced. It may be that if SSSD's LDAP provider is offering a significant advantage over winbind, we will consider dropping (or deferring) our efforts to integrate winbind and instead put that effort into adding Active Directory-specific features into the LDAP provider. For example, we might reprioritize bugs https://fedorahosted.org/sssd/ticket/995 and https://fedorahosted.org/sssd/ticket/996 So please, share with us your stories for why you prefer SSSD over winbind and help us choose our direction for SSSD's future.

7 7

FC16 - how to get ExecStop= to be executed at shutdown?
by Josh Geisser 04 Dec '11

04 Dec '11

Hi all I succeeded with auto login and auto start of my Virtual Boxes, but could not get them to do a proper shutdown. Because of the nature of the VM processes I want to send them a proper ACPI shutdown button instead of terminating the process, which is done through my old rc-script. The VirtualBoxes process are started AFTER X11 is up, but must also be shutdown BEFORE the display-manager is exited. How do I configure this in the service file? My /lib/systemd/system/vbox.service: [Unit] Description=Virtual Box Machines After=vboxdrv.service network.target display-manager.service [Service] Type=forking ExecStart=/home/vmuser/./rc.virtualboxes start | /usr/bin/logger ExecStop=/home/vmuser/./rc.virtualboxes stop | /usr/bin/logger [Install] WantedBy=graphical.target Cheers & thx Josh -- ---- ASG at hnet

2 2

RFC: sudo cache behaviour
by Jakub Hrozek 02 Dec '11

02 Dec '11

Hi, As we work on the Sudo integration with Pavel, I'm thinking about how should we handle our cache. On one hand, I think our cache should be complete and possibly up to date to allow seamless offline operation. In the first prototype we have now, we just download the whole tree during every request. That's not going to scale, obviously. There can be many rules and downloading them all can get expensive. I think we can use the following mechanism: 1) the backend would schedule a periodic task to download all rules, much like the current enumeration task. There may be an option to fine tune how often should the task start. 2) when a request comes, we would update the cache that affects the user only(*). We keep an in-memory timeout per user so that subsequent requests from the same user are handled fast. Does that sound OK? * even native sudo only searches for "(|(sudoUser=ALL)(sudoUser=username)(sudoUser=%group1)(sudoUser=%group2))" so we can limit the online update the same way

5 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel December 2011