SYntax for Proxy addresses and attribute to be defined for proxy addresess in LDIF file
Dear folks: If any one has the syntax for adding proxy addresses in the LDIF file along with the normal mail attribute that will be really appreciated if you can share the Syntax or the link and also the modifications to schema files with the details. Cheers!! Ram Req: Sample LDIF file with proxy addresses along with mail attribute Cheers!! RAM
Re: Error 18: Solaris 10 Native LDAP-Client
Hi diego,
thanks for you advise. I created two new Overlays as you said and
tried to set the attribute-set that I googled from some other guys.
These are probably wrong. Finally, that solved the messages that
appeared in the slapd log, but didn't solve the problem on the solaris
hosts.
Too bad. :/
While reading to the log file once again, I find it quite strange,
that the client is asking for specific objectClasses and Attributes
that doesn't exist in my DIT.
I've imported the solaris.schema while preparing the DIT and setup the
nisDomainObject in the root Object, because the Client asked for
that in the autoconfig-process.
But the rest is from duaconfig.schema. By looking through the
solaris.schema, the requested obj and attr below are in there. But
this is all in all just guess work.
for example:
Oct 16 19:15:00 examplehost slapd[24946]: conn=1026 op=102 SRCH
base=ou=people,dc=example,dc=de scope=2 deref=3
filter=((objectClass=NisKeyObject)(uidNumber=3))
Oct 16 19:15:00 examplehost slapd[24946]: conn=1026 op=102 SRCH
attr=nisPublickey nisSecretkey
Oct 16 19:15:00 examplehost slapd[24946]: conn=1026 op=103 SRCH
base=ou=people,dc=example,dc=de scope=2 deref=3
filter=((?objectClass=SolarisUserAttr)(uid=sys))
Oct 16 19:15:00 examplehost slapd[24946]: conn=1026 op=103 SRCH
attr=uid SolarisUserQualifier SolarisAttrReserved1
SolarisAttrReserved2 SolarisAttrKeyValue
Oct 16 19:15:00 examplehost slapd[24946]: conn=1026 op=104 SRCH
base=ou=projects,dc=example,dc=de scope=2 deref=3
filter=((?objectClass=SolarisProject)(?=undefined))
Oct 16 19:15:00 examplehost slapd[24946]: conn=1026 op=104 SRCH
attr=SolarisProjectName SolarisProjectID description memberUid
memberGid SolarisProjectAttr
LDIFs of the overlays:
version: 1
dn: olcOverlay={4}sssvlv,olcDatabase={1}hdb,cn=config
objectClass: olcSssVlvConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {4}sssvlv
=
version: 1
dn: olcOverlay={5}valsort,olcDatabase={1}hdb,cn=config
objectClass: olcValSortConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {5}valsort
olcValSortAttr: memberuid ou=groups,dc=example,dc=de alpha-ascend
olcValSortAttr: uid ou=people,dc=example,dc=de alpha-ascend
Actually these seems to be a question to the Solaris LDAP Mailinglist,
am I right?
But if you have an further hints, these are much appreciated.
Thanks and kind regards, Benjamin.
On Fri, Oct 15, 2010 at 18:41, Diego Lima li...@diegolima.org wrote:
Hi Benjamin,
It looks like your LDAP client is asking the server to return ordered
results from looking at this line:
tag=101 err=18 nentries=0 text=serverSort control: No ordering rule
You may want to take a look at the server-side sorting overlay
(slapo-sssvlv) and/or the value sorting overlay (slapo-valsort) and
see if activating them on the server will fix your problems.
--
Diego Lima
http://www.diegolima.org
--
To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To
be is to do -- Sartre | Do be do be do -- Sinatra
ppolicy causing slapcat to segfault
For reference, this is a slightly older installation (2.4.17 on Ubuntu). I was recently informed that we had to implement the ppolicy overlay ASAP for compliance reasons in this environment. I don't have time to upgrade this particular cluster at the moment, so I'm trying to work with what I've got. The following pastie shows my config (or rather, the LDIFs I used to create the config), and a partial trace of the slapcat that segfaults: http://pastie.org/1223869 Interestingly, someone else had an identical issue with 2.4.15 on Ubuntu: http://pastie.org/600973 Unfortunately, no solution was ever posted, and I haven't gotten to the bottom of it myself. I'm not quite sure what the problem is, but it seems to be specific to ppolicy, and as far as I can tell by reviewing the CVS log for commits to ppolicy.c, no changes have been made in any revisions since that would fix a segmentation fault (I'm using 1.75.2.27, and there have been only two unrelated ITS's since then as it pertains to ppolicy.c). I'm open to suggestions as to what might be causing slapcat to segfault after the entries in my pastie above are added. I've tried using no default ppolicy, an empty default ppolicy, and with no custom pwdCheckModule, all to no avail. TIA, Ryan
Possible bug in ldap_get_values_len?
Hello all, I was mucking around with OpenLDAP and noticed that ldap_get_values_len was returning NULL without setting a corresponding error code. Intruiged by this behavior, I did some debugging, and found that it was doing so on nsslapd-referral as generated by a Fedora 1.2.5 or 1.2.6 directory server for the cn=config entry (I haven't checked anywhere else yet). Here is a fragment of the byte sequence in ber_buf that was causing this: 000140410nsslapd-referral1000190412password I checked some other code, ldapvi works around this by checking if the return value of ldap_get_values_len is NULL before using it, but it doesn't seem to do so consistently, and an old version of the code had this to say: struct berval **values = ldap_get_values_len(ld, entry, ad); struct berval **ptr; if (!values) continue; /* weird server */ I've also posted to 389-users [1], in Fedora Directory Server spitting out malformed data. But in that case, OpenLDAP should give me an error code, or work around it, or something. Cheers, Edward [1] http://lists.fedoraproject.org/pipermail/389-users/2010-October/012320.html
Re: Possible bug in ldap_get_values_len?
Edward Z. Yang wrote: Hello all, I was mucking around with OpenLDAP and noticed that ldap_get_values_len was returning NULL without setting a corresponding error code. Intruiged by this behavior, I did some debugging, and found that it was doing so on nsslapd-referral as generated by a Fedora 1.2.5 or 1.2.6 directory server for the cn=config entry (I haven't checked anywhere else yet). Here is a fragment of the byte sequence in ber_buf that was causing this: 000140410nsslapd-referral1000190412password I checked some other code, ldapvi works around this by checking if the return value of ldap_get_values_len is NULL before using it, but it doesn't seem to do so consistently, and an old version of the code had this to say: struct berval **values = ldap_get_values_len(ld, entry, ad); struct berval **ptr; if (!values) continue; /* weird server */ I've also posted to 389-users [1], in Fedora Directory Server spitting out malformed data. But in that case, OpenLDAP should give me an error code, or work around it, or something. Looking at the code and your data snippet, this is because your BER sequence says it's got a set of zero values. In this case, ber_scanf doesn't bother to allocate any memory to store the values, since there would be no point. Technically there's no error here; sets are allowed to be empty. (E.g., if you had done an attrsOnly search then all of the attributes would have zero sets for their values.) So no, it's not a bug that libldap returns NULL instead of a pointer. And no, libldap shouldn't report an error code here either. But it's certainly stupid for the server to attach the attribute to the response with no values, since this is obviously NOT an attrsOnly search response. Sounds like you ought to file a bug report against the Fedora Directory Server. Cheers, Edward [1] http://lists.fedoraproject.org/pipermail/389-users/2010-October/012320.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Configuring OpenLDAP 2.2 with gdbm
Hello, I am trying to build OpenLDAP version 2.2.17 with the gdbm back end. The platform is Solaris 10 on SPARC. However, the configure script fails with the following error: ./configure --enable-ldbm --with-ldbm-api=gdbm --enable-shell --enable-crypt --disable-bdb ... checking for GDBM library... checking for gdbm_open... no checking for gdbm_open in -lgdbm... no no checking for gdbm.h... yes checking for db... no configure: warning: could not find suitable LDBM backend configure: error: select appropriate LDBM options or disable Does anyone know how to fix it? Thanks in advance. Piotr
Re: ppolicy causing slapcat to segfault
On Friday 15 October 2010 20:45:11 Ryan Steele wrote: For reference, this is a slightly older installation (2.4.17 on Ubuntu). I was recently informed that we had to implement the ppolicy overlay ASAP for compliance reasons in this environment. I don't have time to upgrade this particular cluster at the moment, so I'm trying to work with what I've got. The following pastie shows my config (or rather, the LDIFs I used to create the config), and a partial trace of the slapcat that segfaults: http://pastie.org/1223869 Interestingly, someone else had an identical issue with 2.4.15 on Ubuntu: http://pastie.org/600973 Unfortunately, no solution was ever posted, and I haven't gotten to the bottom of it myself. I'm not quite sure what the problem is, but it seems to be specific to ppolicy, and as far as I can tell by reviewing the CVS log for commits to ppolicy.c, no changes have been made in any revisions since that would fix a segmentation fault (I'm using 1.75.2.27, and there have been only two unrelated ITS's since then as it pertains to ppolicy.c). I'm open to suggestions as to what might be causing slapcat to segfault after the entries in my pastie above are added. I've tried using no default ppolicy, an empty default ppolicy, and with no custom pwdCheckModule, all to no avail. Please try reproducing you problem with the latest release (2.4.23) or CVS HEAD. If it still fails with that, open a bug report through the ITS (http://www.openldap.org/its) containing the relevant information (configs, stack backtrace of the segfault, steps to reproduce, ...). -- Ralf
Re: Configuring OpenLDAP 2.2 with gdbm
Hello Piotr, you should consider updating your ancient OpenLDAP-Server. :) Bye, Benjamin. On Mon, Oct 18, 2010 at 14:14, KALINOWSKI, Piotr (Piotr) piotr.kalinow...@alcatel-lucent.com wrote: Hello, I am trying to build OpenLDAP version 2.2.17 with the gdbm back end. The platform is Solaris 10 on SPARC. However, the configure script fails with the following error: ./configure --enable-ldbm --with-ldbm-api=gdbm --enable-shell --enable-crypt --disable-bdb ... checking for GDBM library... checking for gdbm_open... no checking for gdbm_open in -lgdbm... no no checking for gdbm.h... yes checking for db... no configure: warning: could not find suitable LDBM backend configure: error: select appropriate LDBM options or disable Does anyone know how to fix it? Thanks in advance. Piotr -- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra
Re: Error 18: Solaris 10 Native LDAP-Client
Update: the serverSort thing was a false-positive this morning, I
guess the client was still caching.
...
Oct 18 15:52:23 examplehost slapd[24946]: conn=9373 op=168 SEARCH
RESULT tag=101 err=18 nentries=0 text=serverSort control: No ordering
rule
Oct 18 15:52:23 examplehost slapd[24946]: conn=9373 op=168 do_search:
get_ctrls failed
Oct 18 15:52:52 examplehost slapd[24946]: conn=10575 fd=28 ACCEPT from
IP=10.0.0.1:35464 (IP=0.0.0.0:389)
Oct 18 15:52:52 examplehost slapd[24946]: conn=10575 op=0 BIND
dn=cn=proxyuser,ou=system,ou=people,dc=example,dc=de method=128
Oct 18 15:52:52 examplehost slapd[24946]: = bdb_entry_get: found
entry: cn=proxyuser,ou=system,ou=people,dc=example,dc=de
Oct 18 15:52:52 examplehost slapd[24946]: = bdb_entry_get: found
entry: cn=default,ou=pwdpolicy,dc=example,dc=de
Oct 18 15:52:52 examplehost slapd[24946]: = access_allowed: result
not in cache (userPassword)
Oct 18 15:52:52 examplehost slapd[24946]: = access_allowed: auth
access to cn=proxyuser,ou=system,ou=people,dc=example,dc=de
userPassword requested
Oct 18 15:52:52 examplehost slapd[24946]: = acl_get: [1] attr userPassword
Oct 18 15:52:52 examplehost slapd[24946]: = acl_mask: access to entry
cn=proxyuser,ou=system,ou=people,dc=example,dc=de, attr
userPassword requested
Oct 18 15:52:52 examplehost slapd[24946]: = acl_mask: to value by , (=0)
Oct 18 15:52:52 examplehost slapd[24946]: = check a_dn_pat:
cn=ldapadm,dc=example,dc=de
Oct 18 15:52:52 examplehost slapd[24946]: = check a_dn_pat:
cn=proxyuser,ou=system,ou=people,dc=example,dc=de
Oct 18 15:52:52 examplehost slapd[24946]: = check a_dn_pat: anonymous
Oct 18 15:52:52 examplehost slapd[24946]: = acl_mask: [3] applying
auth(=xd) (stop)
Oct 18 15:52:52 examplehost slapd[24946]: = acl_mask: [3] mask: auth(=xd)
Oct 18 15:52:52 examplehost slapd[24946]: = slap_access_allowed: auth
access granted by auth(=xd)
Oct 18 15:52:52 examplehost slapd[24946]: = access_allowed: auth
access granted by auth(=xd)
Oct 18 15:52:52 examplehost slapd[24946]: conn=10575 op=0 BIND
dn=cn=proxyuser,ou=system,ou=people,dc=example,dc=de mech=SIMPLE
ssf=0
Oct 18 15:52:52 examplehost slapd[24946]: = bdb_entry_get: found
entry: cn=proxyuser,ou=system,ou=people,dc=example,dc=de
Oct 18 15:52:52 examplehost slapd[24946]: conn=10575 op=0 RESULT
tag=97 err=0 text=
Oct 18 15:52:52 examplehost slapd[24946]: conn=10575 op=1 SEARCH
RESULT tag=101 err=18 nentries=0 text=serverSort control: No ordering
rule
Oct 18 15:52:52 examplehost slapd[24946]: conn=10575 op=1 do_search:
get_ctrls failed
Oct 18 15:52:52 examplehost slapd[24946]: conn=10575 op=2 UNBIND
Oct 18 15:52:52 examplehost slapd[24946]: conn=10575 fd=28 closed
...
Is someone able to tell me what specific attributes I have to set for
simple passwd/group/sudoers listing/sorting?
Thank you.
On Mon, Oct 18, 2010 at 09:45, Benjamin Griese der.dar...@gmail.com wrote:
Hi diego,
thanks for you advise. I created two new Overlays as you said and
tried to set the attribute-set that I googled from some other guys.
These are probably wrong. Finally, that solved the messages that
appeared in the slapd log, but didn't solve the problem on the solaris
hosts.
Too bad. :/
While reading to the log file once again, I find it quite strange,
that the client is asking for specific objectClasses and Attributes
that doesn't exist in my DIT.
I've imported the solaris.schema while preparing the DIT and setup the
nisDomainObject in the root Object, because the Client asked for
that in the autoconfig-process.
But the rest is from duaconfig.schema. By looking through the
solaris.schema, the requested obj and attr below are in there. But
this is all in all just guess work.
for example:
Oct 16 19:15:00 examplehost slapd[24946]: conn=1026 op=102 SRCH
base=ou=people,dc=example,dc=de scope=2 deref=3
filter=((objectClass=NisKeyObject)(uidNumber=3))
Oct 16 19:15:00 examplehost slapd[24946]: conn=1026 op=102 SRCH
attr=nisPublickey nisSecretkey
Oct 16 19:15:00 examplehost slapd[24946]: conn=1026 op=103 SRCH
base=ou=people,dc=example,dc=de scope=2 deref=3
filter=((?objectClass=SolarisUserAttr)(uid=sys))
Oct 16 19:15:00 examplehost slapd[24946]: conn=1026 op=103 SRCH
attr=uid SolarisUserQualifier SolarisAttrReserved1
SolarisAttrReserved2 SolarisAttrKeyValue
Oct 16 19:15:00 examplehost slapd[24946]: conn=1026 op=104 SRCH
base=ou=projects,dc=example,dc=de scope=2 deref=3
filter=((?objectClass=SolarisProject)(?=undefined))
Oct 16 19:15:00 examplehost slapd[24946]: conn=1026 op=104 SRCH
attr=SolarisProjectName SolarisProjectID description memberUid
memberGid SolarisProjectAttr
LDIFs of the overlays:
version: 1
dn: olcOverlay={4}sssvlv,olcDatabase={1}hdb,cn=config
objectClass: olcSssVlvConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {4}sssvlv
=
version: 1
dn: olcOverlay={5}valsort,olcDatabase={1}hdb,cn=config
objectClass: olcValSortConfig
objectClass:
Re: Configuring OpenLDAP 2.2 with gdbm
On Mon, 18 Oct 2010, KALINOWSKI, Piotr (Piotr) wrote: Hello, I am trying to build OpenLDAP version 2.2.17 with the gdbm back end. The platform is Solaris 10 on SPARC. However, the configure script fails with the following error: ./configure --enable-ldbm --with-ldbm-api=gdbm --enable-shell --enable-crypt --disable-bdb ... checking for GDBM library... checking for gdbm_open... no checking for gdbm_open in -lgdbm... no no checking for gdbm.h... yes checking for db... no configure: warning: could not find suitable LDBM backend configure: error: select appropriate LDBM options or disable Does anyone know how to fix it? Thanks in advance. Piotr You are setting yourself for immense pain; the gdbm backend in that version will almost certainly suffer from (possibly irreparable) corruption. The only valid reason to do this would be if you found a six year old server and wanted to see what data was on it, read-only off the network... With that said, take a glance through config.log. You'll probably need to make your own gdbm build as a prerequisite, for that matter; once that is available on the system set CPPFLAGS/LDFLAGS appropriately when re-running OpenLDAP configure.
Re: Possible bug in ldap_get_values_len?
On 10/18/10 12:48 PM, Howard Chu wrote: But it's certainly stupid for the server to attach the attribute to the response with no values, since this is obviously NOT an attrsOnly search response. What about an AttributeType with an OctetString syntax ? It may have an empty value... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Configuring OpenLDAP 2.2 with gdbm
KALINOWSKI, Piotr (Piotr) wrote: I am trying to build OpenLDAP version 2.2.17 with the gdbm back end. You should not use OpenLDAP 2.2.x (set to historic years ago) and you should definitely not use gdbm-based backend. You won't get any help on the mailing lists. Ciao, Michael.
RE: Configuring OpenLDAP 2.2 with gdbm
-Original Message- From: Aaron Richton [mailto:rich...@nbcs.rutgers.edu] Sent: Monday, October 18, 2010 5:03 PM You are setting yourself for immense pain; the gdbm backend in that version will almost certainly suffer from (possibly irreparable) corruption. The only valid reason to do this would be if you found a six year old server and wanted to see what data was on it, read-only off the network... Good to know it. I think we eventually switch to some more reliable backend. With that said, take a glance through config.log. You'll probably need to make your own gdbm build as a prerequisite, for that matter; once that is available on the system set CPPFLAGS/LDFLAGS appropriately when re-running OpenLDAP configure. I looked at it and there was nothing new - gdbm_open was missing. It turned out that GDBM must be installed, not only built to build OpenLDAP. Now it seems to work. Thanks! Piotr
RE: Configuring OpenLDAP 2.2 with gdbm
-Original Message- From: Michael Ströder [mailto:mich...@stroeder.com] Sent: Monday, October 18, 2010 5:52 PM I am trying to build OpenLDAP version 2.2.17 with the gdbm back end. You should not use OpenLDAP 2.2.x (set to historic years ago) and you should definitely not use gdbm-based backend. You won't get any help on the mailing lists. Thanks for advice :) I needed to rebuild the old version with just one switch added, not to upgrade it to the newest one... Piotr
Re: Possible bug in ldap_get_values_len?
Excerpts from Howard Chu's message of Mon Oct 18 15:23:02 -0400 2010: The function would return a zero-length berval in that case. There's a difference between no values, and one value of zero length. Sure, but for the programmer, there is definitely a difference between p == NULL and *p == NULL. :-) Cheers, Edward
Re: Configuring OpenLDAP 2.2 with gdbm
KALINOWSKI, Piotr (Piotr) wrote: I am trying to build OpenLDAP version 2.2.17 with the gdbm back end. You should not use OpenLDAP 2.2.x (set to historic years ago) and you should definitely not use gdbm-based backend. You won't get any help on the mailing lists. Thanks for advice :) I needed to rebuild the old version with just one switch added, not to upgrade it to the newest one... This one switch added could trigger a problem you did not have before. Off course you're free to do whatever you think is right. But don't expect anybody here to help you in case of trouble. Ciao, Michael.
Re: Possible bug in ldap_get_values_len?
Edward Z. Yang wrote: Excerpts from Howard Chu's message of Mon Oct 18 15:23:02 -0400 2010: The function would return a zero-length berval in that case. There's a difference between no values, and one value of zero length. Sure, but for the programmer, there is definitely a difference between p == NULL and *p == NULL. :-) Of course. And again, that's a one-to-one mapping to the difference between no values (p == NULL) and one value of zero-length. Since both conditions are legal in the ASN.1 data, as a programmer you must handle both. (Even though it's nonsensical in this context, and the server is clearly broken.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
