sssd-devel February 2012

sssd-devel@lists.fedorahosted.org

19 participants
122 discussions

access to ldb files data?
by Marco Pizzoli 08 Feb '12

08 Feb '12

Hi guys, as far as I read I have recognized that ldb files are a sort of ldap databases. Can I access this data with a user tool? ldapsearch -H ldapi:/// or similar... My question is motivated only by curiosity. I'm interested in learning "hands on" the data structure. Thanks Marco

4 6

Re: [SSSD] Bug in man page of sssd 1.8beta?
by Marco Pizzoli 08 Feb '12

08 Feb '12

On Wed, Feb 8, 2012 at 2:31 PM, Jan Cholasta <jcholast(a)redhat.com> wrote: > On 8.2.2012 14:16, Marco Pizzoli wrote: > >> >> >> On Wed, Feb 8, 2012 at 2:12 PM, Jan Cholasta <jcholast(a)redhat.com >> <mailto:jcholast@redhat.com>> wrote: >> >> On 8.2.2012 13:58, Marco Pizzoli wrote: >> >> >> >> On Wed, Feb 8, 2012 at 1:50 PM, Jakub Hrozek <jhrozek(a)redhat.com >> <mailto:jhrozek@redhat.com> >> <mailto:jhrozek@redhat.com <mailto:jhrozek@redhat.com>>> wrote: >> >> On Wed, Feb 08, 2012 at 12:47:30PM +0100, Marco Pizzoli wrote: >> > Hi, >> > I'm looking at this man page: >> > >> http://sgallagh.fedorapeople._**_org/sssd/1.8.0/man/sssd.conf.** >> __5.html >> >> <http://sgallagh.fedorapeople.**org/sssd/1.8.0/man/sssd.conf.** >> 5.html <http://sgallagh.fedorapeople.org/sssd/1.8.0/man/sssd.conf.5.html> >> > >> > >> > services >> > >> > Comma separated list of services that are started >> when >> sssd itself >> > starts. >> > >> > Supported services: nss, pam , sudo >> > >> > Is it missing autofs, right? >> > >> >> Yes, it is missing autofs. Autofs should be mentioned >> conditionally the >> same way as sudo is. >> >> Would you like to try and send a patch? I know you expressed >> interest in doing so in some other thread.. >> >> >> Yep. :-) >> Next weekend I'm going to put my hands on git and so I'm >> creating these >> patches. >> >> I filed https://fedorahosted.org/sssd/**__ticket/1183<https://fedorahosted.org/sssd/__ticket/1183> >> >> <https://fedorahosted.org/**sssd/ticket/1183<https://fedorahosted.org/sssd/ticket/1183>> >> so we don't forget to >> fix it. >> >> >> Ok. >> >> Thanks for reporting the issue! >> >> >> Thanks to you guys for answering always my questions! :-) >> >> Marco >> >> >> >> The ssh service should probably be listed as well. >> >> >> Ok, but SSH has to have a "SSH configuration options" section? >> If yes, I cannot be of help by not knowing anything (yet) on this >> subject... >> >> > Nope, there are no SSH-specific configuration options yet. > Ok, this is my job :-)

1 0

Bug in man page of sssd 1.8beta?
by Marco Pizzoli 08 Feb '12

08 Feb '12

Hi, I'm looking at this man page: http://sgallagh.fedorapeople.org/sssd/1.8.0/man/sssd.conf.5.html services Comma separated list of services that are started when sssd itself starts. Supported services: nss, pam , sudo Is it missing autofs, right? -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison

3 3

getent group stuck
by Marco Pizzoli 08 Feb '12

08 Feb '12

Hi, I succeed in listing my users retrieved from the ldap server --> "getent passwd" works I'm failing in listing my groups --> "getent groups" remain stuck after have listed my /etc/group groups. My /etc/nsswitch.conf file: passwd: files sss group: files sss #initgroups: files sss In /var/log/sssd/sssd_my_ldap.log I see my groups seen and saved: [cut] (Wed Feb 8 10:09:40 2012) [sssd[be[my_ldap]]] [sdap_save_groups] (0x4000): Group 116 processed! (Wed Feb 8 10:09:40 2012) [sssd[be[my_ldap]]] [sdap_save_group] (0x2000): This is a posix group (Wed Feb 8 10:09:40 2012) [sssd[be[my_ldap]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original DN [cn=pdbaraf,ou=groups,dc=dont,dc=mind.it] to attributes of [pdbaraf]. (Wed Feb 8 10:09:40 2012) [sssd[be[my_ldap]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp [20110130203138Z] to attributes of [pdbaraf]. (Wed Feb 8 10:09:40 2012) [sssd[be[my_ldap]]] [sdap_save_group] (0x1000): Original USN value is not available for [pdbaraf]. (Wed Feb 8 10:09:40 2012) [sssd[be[my_ldap]]] [sdap_save_group] (0x0400): Storing info for group pdbaraf [cut] If I try to list a specific group, I succeed in: [root@fedora16 sssd]# getent group pdbaraf pdbaraf:*:10107:pdbaraf,pusrrafw With strace I can see this: [cut] connect(4, {sa_family=AF_FILE, path="/var/lib/sss/pipes/nss"}, 110) = 0 fstat(4, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0 poll([{fd=4, events=POLLOUT}], 1, 300000) = 1 ([{fd=4, revents=POLLOUT}]) write(4, "\24\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0", 16) = 16 poll([{fd=4, events=POLLOUT}], 1, 300000) = 1 ([{fd=4, revents=POLLOUT}]) write(4, "\1\0\0\0", 4) = 4 poll([{fd=4, events=POLLIN}], 1, 300000) = 1 ([{fd=4, revents=POLLIN}]) read(4, "\24\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0", 16) = 16 poll([{fd=4, events=POLLIN}], 1, 300000) = 1 ([{fd=4, revents=POLLIN}]) read(4, "\1\0\0\0", 4) = 4 poll([{fd=4, events=POLLOUT}], 1, 300000) = 1 ([{fd=4, revents=POLLOUT}]) write(4, "\20\0\0\0#\0\0\0\0\0\0\0\0\0\0\0", 16) = 16 poll([{fd=4, events=POLLIN}], 1, 300000^C <unfinished ...> Obviously I have my [domain/ldap] section populated with enumerate=true Any help? Thanks a lot as usual Marco -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison

2 1

Announcing SSSD 1.8.0 beta 2
by Stephen Gallagher 07 Feb '12

07 Feb '12

We missed two patches (that had translation string impact) and we weren't building properly on older systems like RHEL 5. As a result, we're releasing beta 2 of 1.8.0 today to correct this. As always, you can download the source at https://fedorahosted.org/sssd Packages for Fedora Rawhide/17 coming later today. == Highlights == * Fix two minor manpage bugs * Include the IPA AutoFS provider == Detailed Changelog == Jakub Hrozek (3): * Fix SSH compilation on RHEL5 * AUTOFS: IPA provider * Two sssd-ldap manual pages fixes Stephen Gallagher (2): * Updating translations * Bumping version to 1.8.0 beta2

1 1

Memory leak BUG warning in sssd_nss.log
by Marco Pizzoli 07 Feb '12

07 Feb '12

Hi, by looking at my logs I found this line on sssd_nss.log. (Tue Feb 7 18:45:35:217396 2012) [sssd[nss]] [sss_dp_get_account_int_done] (0x0010): BUG: a callback did not free its request. May leak memory Is it meaningful to you? If yes, I'm available to provide all my log files. I'm using sssd-1.7.0-5.fc16.x86_64. Marco

2 1

sssd.conf: min_id and max_id validness?
by Marco Pizzoli 07 Feb '12

07 Feb '12

Hi, it's me again :-) Currently I managed to have my ldap server accessed by sssd, but my users are now discarded because of their UID and GID. Being this a test system, I had no issues in changing my min_id and max_id parameters in sssd.conf but I notice that I'm failing in having them specified uniquely for UID and/or GID. I was hoping to be able to set something similar to min_uid_id/max_uid_id and min_gid_id/max_gid_id. Is this a wanted behaviour? If yes, please could you explain to me the rationale? If no, can I submit this as an RFE? Thanks Marco

2 1

Problem in starting LDAP domain
by Marco Pizzoli 07 Feb '12

07 Feb '12

Hi guys, Again I need your help... I'm using and I configured a domain/my_ldap. During the startup I see these logs: [cut] (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [get_server_status] (0x1000): Status of server 'ldap01.dont.mind.it' is 'name not resolved' (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [get_port_status] (0x1000): Port status of port 389 for server 'ldap01.dont.mind.it' is 'neutral' (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 5 seconds (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [get_server_status] (0x1000): Status of server 'ldap01.dont.mind.it' is 'name not resolved' (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [resolv_is_address] (0x4000): [ldap01.dont.mind.it] does not look like an IP address (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [resolv_gethostbyname_step] (0x2000): Querying files (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'ldap01.dont.mind.it' in files (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [set_server_common_status] (0x0100): Marking server 'ldap01.dont.mind.it' as 'resolving name' (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [set_server_common_status] (0x0100): Marking server 'ldap01.dont.mind.it' as 'name resolved' (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [be_resolve_server_done] (0x0100): Found address for server ldap01.dont.mind.it: [192.168.146.128] TTL 7200 (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_uri_callback] (0x0400): Constructed uri 'ldap://ldap01.dont.mind.it:389' (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sss_ldap_init_send] (0x4000): Using file descriptor [24] for LDAP connection. (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://ldap01.dont.mind.it:389/??base] with fd [24]. (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_get_rootdse_send] (0x4000): Getting rootdse (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts] (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl] (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension] (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures] (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedLDAPVersion] (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedSASLMechanisms] (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [defaultNamingContext] (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [highestCommittedUSN] (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 1 (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_process_result] (0x2000): Trace: sh[0x7f6ec4b54440], connected[1], ops[0x7f6ec4b6a610], ldap[0x7f6ec4b579c0] (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_parse_entry] (0x4000): OriginalDN: []. (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_process_result] (0x2000): Trace: sh[0x7f6ec4b54440], connected[1], ops[0x7f6ec4b6a610], ldap[0x7f6ec4b579c0] (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_get_rootdse_done] (0x4000): Got rootdse (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [get_naming_context] (0x0200): Using value from [namingContexts] as naming context. (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_set_search_base] (0x0100): Setting option [ldap_sudo_search_base] to [dc=dont,dc=mind.it]. (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_parse_search_base] (0x0100): Search base added: [SUDO][dc=dont.mind.it][SUBTREE][] (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_get_server_opts_from_rootdse] (0x0200): No known USN scheme is supported by this server! (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_get_server_opts_from_rootdse] (0x0200): Will use modification timestamp as usn! (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'ldap01.dont.mind.it' as 'not working' (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_handle_release] (0x2000): Trace: sh[0x7f6ec4b54440], connected[1], ops[(nil)], ldap[0x7f6ec4b579c0], destructor_lock[0], release_memory[0] (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_id_op_connect_done] (0x0010): *Authentication mechanism not Supported by server* (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_id_op_connect_done] (0x4000): attempting failover retry on op #1 (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [get_server_status] (0x1000): Status of server 'ldap01.dont.mind.it' is 'name resolved' (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [get_port_status] (0x1000): Port status of port 389 for server 'ldap01.dont.mind.it' is 'not working' (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [fo_resolve_service_send] (0x0020): No available servers for service 'LDAP' (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_id_release_conn_data] (0x4000): releasing unused connection (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error]) (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [be_mark_offline] (0x2000): Going offline! (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks. (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_id_op_connect_done] (0x4000): notify offline to op #1 [cut] My LDAP server is OpenLDAP. and I have configured the tls part. [root@fedora16 ~]# netstat -ntlp |grep slapd tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 2951/slapd tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 2951/slapd tcp 0 0 :::636 :::* LISTEN 2951/slapd tcp 0 0 :::389 :::* LISTEN 2951/slapd This is the interesting part of my domain/my_ldap section of sssd.conf [domain/my_ldap] description = LDAP Users domain min_id = 7000 max_id = 8000 timeout = 10 enumerate = TRUE entry_cache_timeout = 5400 cache_credentials = TRUE account_cache_expiration = 0 id_provider = ldap use_fully_qualified_names = FALSE auth_provider = ldap access_provider = permit chpass_provider = ldap lookup_family_order = ipv4_first dns_resolver_timeout = 5 #dns_discovery_domain = #override_gid = case_sensitive = True ldap_uri = ldap://ldap01.dont.mind.it:389 ldap_chpass_uri = ldap://ldap01.dont.mind.it:389 ldap_search_base = dc=dont,dc=mind.it?sub?(objectClass=inetOrgPerson) ldap_schema = rfc2307bis ldap_default_bind_dn = cn=mydn,dc=dont,dc=mind.it ldap_default_authtok_type = pippo #ldap_default_authtok ldap_user_object_class = posixAccount ldap_user_name = uid ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_user_gecos = gecos ldap_user_home_directory = homeDirectory ldap_user_shell = loginShell ldap_user_uuid = entryUUID ldap_user_modify_timestamp = modifyTimestamp ldap_user_shadow_last_change = shadowLastChange ldap_user_shadow_min = shadowMin #### INIZIO - SSL/TLS #### # # Imposto la richiesta e la validazione del certificato ldap_tls_reqcert = demand # #ldap_tls_cacert = ldap_tls_cacertdir = /etc/pki/tls/certs #ldap_tls_cert = #ldap_tls_key = #ldap_tls_cipher_suite = ldap_id_use_start_tls = false #### FINE - SSL/TLS #### Could you help me in understanding what is the cause of the backend discard? Thanks a lot as usual Marco

3 11

Re: [SSSD] Problem in starting LDAP domain
by Jan Zelený 07 Feb '12

07 Feb '12

> On Tue, Feb 7, 2012 at 2:32 PM, Jan Zelený <jzeleny(a)redhat.com> wrote: > > > On Tue, Feb 7, 2012 at 2:10 PM, Stephen Gallagher > > > > <sgallagh(a)redhat.com>wrote: > > > > On Tue, 2012-02-07 at 14:04 +0100, Marco Pizzoli wrote: > > > > > Hi guys, > > > > > Again I need your help... I'm using and I configured a > > > > > domain/my_ldap. During the startup I see these logs: > > > > > > > > > > [cut] > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_id_op_connect_step] (0x4000): beginning to connect > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [fo_resolve_service_send] (0x0100): Trying to resolve service > > > > > 'LDAP' (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [get_server_status] (0x1000): Status of server > > > > > 'ldap01.dont.mind.it' is 'name not resolved' > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [get_port_status] > > > > > (0x1000): Port status of port 389 for server 'ldap01.dont.mind.it' > > > > is > > > > > > > 'neutral' > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set > > > > to > > > > > > > 5 seconds > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [get_server_status] > > > > > (0x1000): Status of server 'ldap01.dont.mind.it' is 'name not > > > > > resolved' > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [resolv_is_address] > > > > > (0x4000): [ldap01.dont.mind.it] does not look like an IP address > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [resolv_gethostbyname_step] (0x2000): Querying files > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A > > > > record > > > > > > > of 'ldap01.dont.mind.it' in files > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [set_server_common_status] (0x0100): Marking server > > > > > 'ldap01.dont.mind.it' as 'resolving name' > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [set_server_common_status] (0x0100): Marking server > > > > > 'ldap01.dont.mind.it' as 'name resolved' > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [be_resolve_server_done] (0x0100): Found address for server > > > > > ldap01.dont.mind.it: [192.168.146.128] TTL 7200 > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_uri_callback] > > > > > (0x0400): Constructed uri 'ldap://ldap01.dont.mind.it:389' > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sss_ldap_init_send] > > > > > (0x4000): Using file descriptor [24] for LDAP connection. > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sss_ldap_init_send] > > > > > (0x0400): Setting 6 seconds timeout for connecting > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to > > > > > [ldap://ldap01.dont.mind.it:389/??base] with fd [24]. > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > [sdap_get_rootdse_send] > > > > > > > (0x4000): Getting rootdse > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > > > > > [(objectclass=*)][]. > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > > > > > [namingContexts] > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > > > > > [supportedControl] > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > > > > > [supportedExtension] > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > > > > > [supportedFeatures] > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > > > > > [supportedLDAPVersion] > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > > > > > [supportedSASLMechanisms] > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > > > > > [defaultNamingContext] > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > > > > > [highestCommittedUSN] > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid > > > > > = 1 > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_process_result] (0x2000): Trace: sh[0x7f6ec4b54440], > > > > > connected[1], > > > > > ops[0x7f6ec4b6a610], ldap[0x7f6ec4b579c0] > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_process_message] (0x4000): Message type: > > > > > [LDAP_RES_SEARCH_ENTRY] > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [sdap_parse_entry] > > > > > (0x4000): OriginalDN: []. > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_process_result] (0x2000): Trace: sh[0x7f6ec4b54440], > > > > > connected[1], > > > > > ops[0x7f6ec4b6a610], ldap[0x7f6ec4b579c0] > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_process_message] (0x4000): Message type: > > > > > [LDAP_RES_SEARCH_RESULT] > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no > > > > > errmsg set > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > [sdap_get_rootdse_done] > > > > > > > (0x4000): Got rootdse > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [get_naming_context] > > > > > (0x0200): Using value from [namingContexts] as naming context. > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_set_search_base] (0x0100): Setting option > > > > > [ldap_sudo_search_base] to > > > > > [dc=dont,dc=mind.it]. > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_parse_search_base] (0x0100): Search base added: > > > > > [SUDO][dc=dont.mind.it][SUBTREE][] > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_get_server_opts_from_rootdse] (0x0200): No known USN scheme > > > > > is supported by this server! > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_get_server_opts_from_rootdse] (0x0200): Will use modification > > > > > timestamp as usn! > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [fo_set_port_status] > > > > > (0x0100): Marking port 389 of server 'ldap01.dont.mind.it' as 'not > > > > > working' > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_handle_release] (0x2000): Trace: sh[0x7f6ec4b54440], > > > > > connected[1], ops[(nil)], ldap[0x7f6ec4b579c0], > > > > > destructor_lock[0], release_memory[0] (Tue Feb 7 13:44:04 2012) > > > > > [sssd[be[my_ldap]]] > > > > > [remove_connection_callback] (0x4000): Successfully removed > > > > connection > > > > > > > callback. > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_id_op_connect_done] (0x0010): Authentication mechanism not > > > > > Supported by server > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_id_op_connect_done] (0x4000): attempting failover retry on op > > > > #1 > > > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_id_op_connect_step] (0x4000): beginning to connect > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [fo_resolve_service_send] (0x0100): Trying to resolve service > > > > > 'LDAP' (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [get_server_status] (0x1000): Status of server > > > > > 'ldap01.dont.mind.it' is 'name resolved' (Tue Feb 7 13:44:04 > > > > > 2012) [sssd[be[my_ldap]]] [get_port_status] (0x1000): Port status > > > > > of port 389 for server 'ldap01.dont.mind.it' > > > > is > > > > > > > 'not working' > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [fo_resolve_service_send] (0x0020): No available servers for > > > > > service 'LDAP' > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_id_release_conn_data] (0x4000): releasing unused connection > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_id_op_connect_done] (0x0020): Failed to connect, going > > > > > offline (5 [Input/output error]) > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [be_mark_offline] > > > > > (0x2000): Going offline! > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] [be_run_offline_cb] > > > > > (0x0080): Going offline. Running callbacks. > > > > > (Tue Feb 7 13:44:04 2012) [sssd[be[my_ldap]]] > > > > > [sdap_id_op_connect_done] (0x4000): notify offline to op #1 > > > > > [cut] > > > > > > > > > > My LDAP server is OpenLDAP. and I have configured the tls part. > > > > > > > > > > [root@fedora16 ~]# netstat -ntlp |grep slapd > > > > > tcp 0 0 0.0.0.0:636 0.0.0.0:* > > > > > LISTEN 2951/slapd > > > > > tcp 0 0 0.0.0.0:389 0.0.0.0:* > > > > > LISTEN 2951/slapd > > > > > tcp 0 0 :::636 :::* > > > > > LISTEN 2951/slapd > > > > > tcp 0 0 :::389 :::* > > > > > LISTEN 2951/slapd > > > > > > > > > > This is the interesting part of my domain/my_ldap section of > > > > sssd.conf > > > > > > > [domain/my_ldap] > > > > > description = LDAP Users domain > > > > > min_id = 7000 > > > > > max_id = 8000 > > > > > timeout = 10 > > > > > enumerate = TRUE > > > > > entry_cache_timeout = 5400 > > > > > cache_credentials = TRUE > > > > > account_cache_expiration = 0 > > > > > id_provider = ldap > > > > > use_fully_qualified_names = FALSE > > > > > auth_provider = ldap > > > > > access_provider = permit > > > > > chpass_provider = ldap > > > > > lookup_family_order = ipv4_first > > > > > dns_resolver_timeout = 5 > > > > > #dns_discovery_domain = > > > > > #override_gid = > > > > > case_sensitive = True > > > > > > > > > > ldap_uri = ldap://ldap01.dont.mind.it:389 > > > > > ldap_chpass_uri = ldap://ldap01.dont.mind.it:389 > > > > > ldap_search_base = > > > > > dc=dont,dc=mind.it?sub?(objectClass=inetOrgPerson)<http://mind.it?s > > > > > ub?%28objectClass=inetOrgPerson%29> > > > > <http://mind.it?sub? > > > > > > > %28objectClass=inetOrgPerson%29> ldap_schema = rfc2307bis > > > > > ldap_default_bind_dn = cn=mydn,dc=dont,dc=mind.it > > > > > ldap_default_authtok_type = pippo > > > > > #ldap_default_authtok > > > > > ldap_user_object_class = posixAccount > > > > > ldap_user_name = uid > > > > > ldap_user_uid_number = uidNumber > > > > > ldap_user_gid_number = gidNumber > > > > > ldap_user_gecos = gecos > > > > > ldap_user_home_directory = homeDirectory > > > > > ldap_user_shell = loginShell > > > > > ldap_user_uuid = entryUUID > > > > > ldap_user_modify_timestamp = modifyTimestamp > > > > > ldap_user_shadow_last_change = shadowLastChange > > > > > ldap_user_shadow_min = shadowMin > > > > > > > > > > #### INIZIO - SSL/TLS #### > > > > > # > > > > > # Imposto la richiesta e la validazione del certificato > > > > > ldap_tls_reqcert = demand > > > > > # > > > > > #ldap_tls_cacert = > > > > > ldap_tls_cacertdir = /etc/pki/tls/certs > > > > > #ldap_tls_cert = > > > > > #ldap_tls_key = > > > > > #ldap_tls_cipher_suite = > > > > > ldap_id_use_start_tls = false > > > > > #### FINE - SSL/TLS #### > > > > > > > > > > Could you help me in understanding what is the cause of the backend > > > > > discard? > > > > > > > > Can you tell us if it works if you do: > > > > > > > > ldapsearch -H ldap://ldap.dont.mind.it -x -w \ > > > > -D cn=mydn,dc=dont,dc=mind.it -b dc=dont,dc=mind.it \ > > > > objectClass=inetOrgPerson > > > > > > Hi, yes it works. Obviously I posted a camoufled binddn, basedn, etc... > > > > I think you should also try the command with -ZZ argument to test if TLS > > initialization isn't getting in your way. Also please check that > > /etc/pki/tls/certs contains hashes (symlinks) of certificates you wish to > > use. > > Good point. Previously I only checked with "openssl s_client -connect" to > check the certificate was correctly published. > I just checked with ldapsearch -ZZ (to do this I needed to populate my > /etc/openldap/ldap.conf with TLS_CACERT directive) and it's working. > > [cut] > # search result > search: 3 > result: 0 Success > > # numResponses: 164 > # numEntries: 163 > > I don't understand what are you saying with "hashes". Please, could you > explain? See man sssd-ldap, this is explained there. > I tried commenting "ldap_tls_cacertdir" and populating "ldap_tls_cacert" > with the path of my cacert (which still remains inside /etc/pki/tls/certs), > obviously restarted sssd... and nothing changes. Ok, if this didn't help, then the problem is probably with establishing of the connection, not with finding the certificate on the disk. You can use ldap_tls_reqcert = allow to rule out that the certificate is broken somehow. > Is it possible to augment the log level for finding out what authentication > mechanism it is not finding? Considering the log messages you posted, I think you already have the highest debug level you can have. Jan

2 1

pam and nss services not starting
by Marco Pizzoli 07 Feb '12

07 Feb '12

Hi, I'm using sssd-1.7.0-5.fc16.x86_64 and during my sssd startup I see this output: [cut] (Tue Feb 7 10:25:16 2012) [sssd] [mark_service_as_started] (0x0100): Now starting services! (Tue Feb 7 10:25:16 2012) [sssd] [start_service] (0x0100): Queueing service nss for startup (Tue Feb 7 10:25:16 2012) [sssd] [start_service] (0x0100): Queueing service pam for startup (Tue Feb 7 10:25:16 2012) [sssd[be[my_ldap]]] [sbus_toggle_watch] (0x4000): 0x7f0043097590/0x7f004309c2a0 (17), -/W (disabled) (Tue Feb 7 10:25:16 2012) [sssd[be[my_ldap]]] [sbus_remove_timeout] (0x2000): 0x7f004309a510 (Tue Feb 7 10:25:16 2012) [sssd[be[my_ldap]]] [sbus_dispatch] (0x4000): dbus conn: 7F0043099BF0 (Tue Feb 7 10:25:16 2012) [sssd[be[my_ldap]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Feb 7 10:25:16 2012) [sssd[be[my_ldap]]] [id_callback] (0x0100): Got id ack and version (1) from Monitor (Tue Feb 7 10:25:16 2012) [sssd] [service_startup_handler] (0x0010): Could not exec sssd_nss, reason: No such file or directory (Tue Feb 7 10:25:16 2012) [sssd] [service_startup_handler] (0x0010): (Tue Feb 7 10:25:16 2012) [sssd] [mt_svc_exit_handler] (0x0040): Child [nss] exited with code [1] (Tue Feb 7 10:25:16 2012) [sssd] [start_service] (0x0100): Could not exec sssd_pam, reason: No such file or directory Queueing service nss for startup (Tue Feb 7 10:25:16 2012) [sssd] [service_startup_handler] (0x0010): (Tue Feb 7 10:25:16 2012) [sssd] [mt_svc_exit_handler] (0x0040): Child [pam] exited with code [1] (Tue Feb 7 10:25:16 2012) [sssd] [start_service] (0x0100): Could not exec sssd_nss, reason: No such file or directory Queueing service pam for startup (Tue Feb 7 10:25:16 2012) [sssd] [service_startup_handler] (0x0010): (Tue Feb 7 10:25:16 2012) [sssd] [mt_svc_exit_handler] (0x0040): Child [nss] exited with code [1] (Tue Feb 7 10:25:16 2012) [sssd] [start_service] (0x0100): Queueing service nss for startup Could not exec sssd_pam, reason: No such file or directory (Tue Feb 7 10:25:16 2012) [sssd] [service_startup_handler] (0x0010): (Tue Feb 7 10:25:16 2012) [sssd] [mt_svc_exit_handler] (0x0040): Could not exec sssd_nss, reason: No such file or directory Child [pam] exited with code [1] (Tue Feb 7 10:25:16 2012) [sssd] [start_service] (0x0100): Queueing service pam for startup (Tue Feb 7 10:25:16 2012) [sssd] [mt_svc_exit_handler] (0x0040): Child [nss] exited with code [1] (Tue Feb 7 10:25:16 2012) [sssd] [start_service] (0x0100): Queueing service nss for startup (Tue Feb 7 10:25:16 2012) [sssd] [service_startup_handler] (0x0010): Could not exec sssd_pam, reason: No such file or directory (Tue Feb 7 10:25:16 2012) [sssd] [mt_svc_exit_handler] (0x0040): Child [pam] exited with code [1] (Tue Feb 7 10:25:16 2012) [sssd] [start_service] (0x0100): Queueing service pam for startup (Tue Feb 7 10:25:16 2012) [sssd] [service_startup_handler] (0x0010): Could not exec sssd_nss, reason: No such file or directory (Tue Feb 7 10:25:16 2012) [sssd] [mt_svc_exit_handler] (0x0040): Child [nss] exited with code [1] (Tue Feb 7 10:25:16 2012) [sssd] [mt_svc_exit_handler] (0x0010): Process [nss], definitely stopped! (Tue Feb 7 10:25:16 2012) [sssd] [service_startup_handler] (0x0010): Could not exec sssd_pam, reason: No such file or directory (Tue Feb 7 10:25:16 2012) [sssd] [mt_svc_exit_handler] (0x0040): Child [pam] exited with code [1] (Tue Feb 7 10:25:16 2012) [sssd] [mt_svc_exit_handler] (0x0010): Process [pam], definitely stopped! [cut] [root@fedora16 sssd]# locate sssd_pam /usr/lib/debug/usr/libexec/sssd/sssd_pam.debug /usr/libexec/sssd/sssd_pam [root@fedora16 sssd]# locate sssd_nss /usr/lib/debug/usr/libexec/sssd/sssd_nss.debug /usr/libexec/sssd/sssd_nss Could you help me in finding the problem? Thanks a lot Marco -- _________________________________________ Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi. Jim Morrison

4 8

← Newer
1
...
5
6
7
8
9
10
11
12
13
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel February 2012