access to ldb files data?
by Marco Pizzoli
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
12 years, 3 months
Re: [SSSD] Bug in man page of sssd 1.8beta?
by Marco Pizzoli
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 :-)
12 years, 3 months
getent group stuck
by Marco Pizzoli
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
12 years, 3 months
Announcing SSSD 1.8.0 beta 2
by Stephen Gallagher
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
12 years, 3 months
Memory leak BUG warning in sssd_nss.log
by Marco Pizzoli
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
12 years, 3 months
sssd.conf: min_id and max_id validness?
by Marco Pizzoli
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
12 years, 3 months
Problem in starting LDAP domain
by Marco Pizzoli
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
12 years, 3 months
Re: [SSSD] Problem in starting LDAP domain
by Jan Zelený
> 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
12 years, 3 months
pam and nss services not starting
by Marco Pizzoli
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
12 years, 3 months
