Passing the torch
by Stephen Gallagher
It is with a heavy heart that I write this email. I've spent a large
part of my engineering career working on the System Security Services
Daemon - longer, in fact, than I've worked on any other single project.
Furthermore, I've been here since the very beginning, having written
some of the first lines of code committed to the git repository.
I've been heavily-involved with the project ever since, designing and
implementing the SBUS interface and service monitor code, then later
taking on the role of the public face of the project. I pushed for its
inclusion into Fedora as the default mechanism for managing centralized
user data. I drove it through several Fedora Test Days. I went to
conferences and lectured on the advantages that SSSD provides.
I have invested a lot of my professional life into this project, and I'd
like to believe that it shows. SSSD today is a successful, growing
project that is included in many popular Linux distributions including
Red Hat Enterprise Linux, Fedora, Debian, Ubuntu and Gentoo.
I could not have done this on my own, however. The SSSD development team
is comprised of many of the finest engineers that I've ever had the
privilege to work with. One such engineer is the magnificent Jakub
Hrozek, who has been for the last two years SSSD's most prolific
developer and my right-hand man.
So, as I prepare to make my way into other places and other projects, I
cannot think of anyone better to take my place as SSSD project lead than
Jakub. His Herculean efforts at driving SSSD 1.9.0 into today's
feature-complete state have proven to me without a doubt that he is the
right person for the job.
I'd like to invite our community to welcome Jakub Hrozek as the new SSSD
project lead, and to help him as he finds his feet in this new
responsibility. Congratulations, and good luck!
11 years, 8 months
SSSD - too many communication failures, giving up
by Ondrej Valousek
Hi,
I have just tried to use a configuration I am currently using in Prague (small site, one AD DC) in Dublin as well (large site, many DCs).
I am using DNS SRV lookups for everything (service auto discovery), but in Dublin it is failing for some reason, giving the error below:
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'dcduba.dublin.ad.s3group.com' as
'working'
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [set_server_common_status] (0x0100): Marking server 'dcduba.dublin.ad.s3group.com' as 'working'
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_id_op_connect_done] (0x2000): Old USN: 76274476, New USN: 31508106
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_id_op_connect_done] (0x4000): notify connected to op #1
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_users_next_base] (0x0400): Searching for users with base
[dc=dublin,dc=ad,dc=s3group,dc=com]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
[(&(uid=ondrjev)(objectclass=user))][dc=dublin,dc=ad,dc=s3group,dc=com].
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixHomeDirectory]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPrincipalName]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 5
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_id_op_connect_done] (0x4000): caching successful connection after 1 notifies
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: sh[0x1e9eca0], connected[1], ops[0x1ea0df0],
ldap[0x1eadc50]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to
[ldap://DomainDnsZones.dublin.ad.s3group.com/DC=DomainDnsZones,DC=dublin,D...] with fd [35].
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_rebind_proc] (0x0020): ldap_sasl_interactive_bind_s failed (-2)[Local error]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_rebind_proc] (0x1000): Failed to bind to
[ldap://DomainDnsZones.dublin.ad.s3group.com/DC=DomainDnsZones,DC=dublin,D...].
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_ldap_connect_callback_del] (0x4000): Closing LDAP connection with fd [35].
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: sh[0x1e9eca0], connected[1], ops[0x1ea0df0],
ldap[0x1eadc50]
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing!
(Thu Aug 2 14:19:42 2012) [sssd[be[default]]] [sdap_get_generic_done] (0x0100): sdap_get_generic_ext_recv failed [110]: Connection timed out
(Thu Aug 2 14:19:42 2012) [sssd[be[default]]] [sdap_id_op_done] (0x0200): communication error on cached connection, moving to next server
(Thu Aug 2 14:19:42 2012) [sssd[be[default]]] [sdap_id_op_done] (0x4000): too many communication failures, giving up...
(Thu Aug 2 14:19:42 2012) [sssd[be[default]]] [sdap_id_op_done] (0x4000): releasing operation connection
(Thu Aug 2 14:19:42 2012) [sssd[be[default]]] [sdap_id_release_conn_data] (0x4000): releasing unused connection
(Thu Aug 2 14:19:42 2012) [sssd[be[default]]] [sdap_handle_release] (0x2000): Trace: sh[0x1e9eca0], connected[1], ops[(nil)],
ldap[0x1eadc50], destructor_lock[0], release_memory[0]
(Thu Aug 2 14:19:42 2012) [sssd[be[default]]] [remove_connection_callback] (0x4000): Successfully removed connection callback.
(Thu Aug 2 14:19:42 2012) [sssd[be[default]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,110,User lookup failed
Does anyone know what could be wrong? I have a faint feeling Jakub managed to resolve this one it the past for me, but I can not find the
mail, any longer.
Note that DomainDnsZones.dublin.ad.s3group.com returns many servers, some of them might be no longer accessible, but there is certainly at
least one of them which is working fine.
Many thanks.
Ondrej
11 years, 8 months
Caches and timeouts
by Pieter Baele
Hi,
How can I set the refresh interval for netgroup membership in sssd?
I've tried using
entry_cache_netgroup_timeout
entry_cache_timeout
and
ldap_enumeration_refresh_timeout ?
enum_cache_timeout ?
For now, I deleted the caches...
Sincerely, PieterB
11 years, 8 months
sssd_sudo - no such file or directory
by Pieter Baele
Hi,
With sssd 1.8.0 32.el6, sudo with sssd is failing
Isn't this supported from 1.8 onwards?
(Tue Jul 31 15:54:51 2012) [sssd] [service_startup_handler] (0x0010):
Could not exec /usr/libexec/sssd/sssd_sudo --debug-to-files, reason:
No such file or directory
(Tue Jul 31 15:54:51 2012) [sssd] [service_startup_handler] (0x0010):
Could not exec /usr/libexec/sssd/sssd_sudo --debug-to-files, reason:
No such file or directory
(Tue Jul 31 15:54:51 2012) [sssd] [service_startup_handler] (0x0010):
Could not exec /usr/libexec/sssd/sssd_sudo --debug-to-files, reason:
No such file or directory
(Tue Jul 31 15:54:51 2012) [sssd] [mt_svc_exit_handler] (0x0010):
Process [sudo], definitely stopped!
Sincerely,
PieterB
11 years, 8 months
