Re: Antw: Re: All entries belong to the top object class?

[dE]

On 04/28/15 13:22, Christian Kratzer wrote:

Hi,

On Mon, 27 Apr 2015, Quanah Gibson-Mount wrote:

--On Tuesday, April 28, 2015 10:58 AM +0530 dE  
wrote:


Yes, so subclasses do not define MAY; it's defined by the MAY of the 
top

object class.


The "top" objectClass does not contain *any* MAY attributes.  I 
wonder if you are confused in thinking of "top" as a generic term.  
It is not.  "top" is a very specific objectClass that is explicitly 
defined as noted previously.  It contains a single MUST attribute.


one of my customers has an enterprise provisioning tool from a well 
known large supplier of such systems.


The developers of that tool insist that they want to see an explit 
"objectClass: top" in all objects.


It hurts every single time I have to look at that specific directory.

Greetings
Christian



Thank you everyone for the help!

I under now.

Re: HP-UX: mdb_txn_commit and MDB_WRITEMAP

[Howard Chu]

Kristian Amlie wrote:

We have enabled MDB_WRITEMAP on our HP-UX 11.23 Itanium after previous
discussions on the list, and that worked nicely for the most part.

However now we face a different issue: Occasionally, mdb_txn_commit will
return "Resource temporarily unavailable". I have not been able to
determine exactly which resource it's talking about; I suspected shared
memory limits, but raising this limit did not solve the problem. This
issue did not occur without MDB_WRITEMAP.

Any idea what else it could be? I can probably insert debug code into
LMDB if that's needed.

The only thing that can return that error is a syscall, and the only 
syscall performed with WRITEMAP is msync(). I suggest you start looking 
there.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

query across ou

[Chuck Theobald]

Is there a way to perform a single query an LDAP database such that I 
can retrieve the group name (cn) from a user's full name (cn). My 
structure holds user accounts in ou=People and groups in ou=Group. I 
know I can ask for gidNumber from the People tree, then reference the 
group in the Group tree, but with an SQL background, I would like a 
single query.


Thanks,

--
Chuck Theobald
System Administrator
The Robert and Beverly Lewis Center for Neuroimaging
University of Oregon
P: 541-346-0343
F: 541-346-0345

getent passwd only catch local user passwd

[Yingbo Li]

Hi,

I am new to LDAP.  The company's IT own LDAP server, I tried to configure 
openldap client but failed. My OS is CentOS 7, openldap is 2.4.39.

I configured ldap and ldaps. I can use ldapsearch to find out full ldap info of 
my LDAP account. I configured with authconfig-tui. I also modified 
/etc/pam.d/system-auth and password-auth, change pam_sss.so to pam_ldap.so. 
While when I tried getent passwd, I can only find local users. I cannot su to 
my LDAP account. Why?

I google online it looks like CentOS 7 has problem to configure ldap client. 
Cent0S 7 does not have pam_ldap module. But I can find pam_ldap.so in the 
system. What should I do to fix it? Switch to CentOS 6.6?

Your help is really appreciated! Thank you!

Yingbo

HP-UX: mdb_txn_commit and MDB_WRITEMAP

[Kristian Amlie]

We have enabled MDB_WRITEMAP on our HP-UX 11.23 Itanium after previous
discussions on the list, and that worked nicely for the most part.

However now we face a different issue: Occasionally, mdb_txn_commit will
return "Resource temporarily unavailable". I have not been able to
determine exactly which resource it's talking about; I suspected shared
memory limits, but raising this limit did not solve the problem. This
issue did not occur without MDB_WRITEMAP.

Any idea what else it could be? I can probably insert debug code into
LMDB if that's needed.

-- 
Kristian

Re: uidNumber=4294967295 is being appearing in the log frequently

[Majid Khan]

Thanks Howard.
Best regards,

  From: Howard Chu 
 To: Majid Khan ; "openldap-technical@openldap.org" 
 
 Sent: Tuesday, April 28, 2015 12:35 PM
 Subject: Re: uidNumber=4294967295 is being appearing in the log frequently
   
Majid Khan wrote:
> Dear Techies,
>
> I'm not sure if this is the right forum to discuss this but I am getting
> the following from some of the clients machine I'm not sure why some of
> them sending this info otherwise my authentication and login all is
> working fine but I'm concern why its happening and my log is full of the
> following kind of message:
>
> If this is not the right forum then I apologies and please direct me to
> that right group:

Since the query is coming from SSSD, you should be asking in a forum for 
SSSD support. This has nothing to do with OpenLDAP.

For the record, this is a pretty stupidly constructed LDAP search 
filter. Their LDAP support appears to be pretty clunky.


>
> Apr 28 05:58:44 server1 slapd[23003]: conn=5235 op=22 SRCH
> base="dc=example,dc=com" scope=2 deref=0
> filter="(&(uidNumber=4294967295)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0"
> Apr 28 05:58:44 server1 slapd[23003]: conn=5235 op=22 SRCH
> attr=objectClass uid userPassword uidNumber gidNumber gecos
> homeDirectory loginShell krbPrincipalName cn modifyTimestamp
> modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning
> shadowInactive shadowExpire shadowFlag krbLastPwdChange
> krbPasswordExpiration pwdAttribute authorizedService accountExpires
> userAccountControl nsAccountLock host loginDisabled loginExpirationTime
> loginAllowedTimeMap
>
> Server info: CentOS release 6.6
> LDAP version: openldap-2.4.40
>
> Client info: CentOS release 6.2
> Client using SSSD: sssd-1.11.6

-- 
  -- Howard Chu
  CTO, Symas Corp.          http://www.symas.com
  Director, Highland Sun    http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/



  

Re: Antw: Re: Slapd running very slow

[Geoff Swan]

On 2015-04-28 7:51 PM, Andrew Findlay wrote:
> Did you get to the bottom of this?
Yes.
>
> On Thu, Apr 23, 2015 at 08:29:48PM +1000, Geoff Swan wrote:
>
>> On 2015-04-23 5:56 PM, Howard Chu wrote:
>>> In normal (safe) operation, every transaction commit performs 2
>>> fsyncs. Your 140MB/s throughput spec isn't relevant here, your disk's
>>> IOPS rate is what matters. You can use NOMETASYNC to do only 1 fsync
>>> per commit.
> Decent SAS disks spin at 10,000 or 15,000 RPM so unless there is a 
> non-volatile
> memory cache in there I would expect at most 15000/60 = 250 fsyncs per second 
> per
> drive, giving 125 transaction commits per second per drive.
These are Enterprise SAS drives with onboard read and write cache systems.

>
>> OK. I ran a reduced version of test script (20 processes each performing
>> 40 read/write operations) with normal (safe) mode of operation on a test
>> server that has 32GB RAM, and everything else identical to the server
>> with 128GB.
> So that is just 800 operations taking 60s?
>
>> A quick test using vmstat at 1s intervals gave the following output
>> whilst it was running.
>>
>> procs ---memory-- ---swap-- -io
>> -system-- --cpu-
>>  r  b swpd free buffcache   si   sobibo   in  
>> cs us sy id wa st
>> 20  00 32011144   167764   33041600 115   40  
>> 56  0  0 99  1  0
>>  0  00 31914848   167764   33042400 0  1560 2594
>> 2130  2  1 97  0  0
>>  0  00 31914336   167764   33042400 0  1708  754
>> 1277  0  0 100  0  0
>>  0  00 31914508   167772   33042000 0  2028  779
>> 1300  0  0 99  1  0
>> The script took about 60s to complete, which is a lot longer than
>> expected. It appears almost all I/O bound, at a fairly slow rate (1500
>> blocks in a second is 6MB/s).
> As you say, it is IO bound (wa ~= 100%). Stop worrying about MB/s: the data 
> rate is
> irrelevant, what matters is synchronous small-block writes and those are 
> limited by
> rotation speed.
>
> Are you absolutely certain that the disks are SAS? Does your disk controller
> believe it? I had big problems with an HP controller once that refused to run 
> SATA
> drives at anything like their full speed as it waited for each transaction to
> finish and report back before queuing the next one...
Yes, they are SAS drives and the driver recognises them as such,
connected to a C600 controller.

>
> Andrew

Did a lot of testing over the last week or so.
It appears to be fundamentally a linux block layer problem. An fsync
operation appears to set the FUA flag on the scsi command to force it to
bypass the write cache. This is a real problem since it bypasses the
intelligence built into a scsi controller to handle the write cache. So
consequently we see a seek time in each 4K block transaction. Seems to
be hard wired and buried in the block layer. It would be nice to have a
mount option to prevent this from happening on certain mounted volumes.

However, there was some significant improvement in the 3.19.5 kernel,
where multi-queues can be enabled for scsi operations. Seems to still
bypass the write cache on the scsi drive, however the performance is
much better.

Another area that also improved things was in the vm tuning, however
this is fairly sensitive (like a high-Q bandpass filter). Reducing the
vm.dirty_expire_centisecs value from 30s to 15s improved things in this
environment, which can have a buildup of written pages. Making them
expire a bit sooner allows for less bumpy cache flushing.

Re: OpenLDAP keeps on dying sporadically

[Quanah Gibson-Mount]

--On Tuesday, April 28, 2015 2:14 PM +0200 Leander Schäfer 
 wrote:



Looks like your liblber was installed without debug symbols. Most of
these stack traces look invalid.

What does this mean? How did you see this / what indicated this to you?
Is it required to fix this liblber issue for a better debug result, or is
it ok for first diagnosis?


It means either or both of:

You didn't compile with CFLAGS="-g" (debugging) and/or when you did 
install, you didn't do:


make install STRIP=""

so that the debugging symbols don't get stripped out.

I generally recommend compiling slapd with:

CFLAGS="-g -O0"

I.e., debugging symbols, and no attempts at optimizing the code.  Generally 
my experience with various compilers has shown that at least in the 
OpenLDAP Case, higher optimization levels are not beneficial and simply 
make debugging significantly harder.


--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration

Re: Ldap challenge

[Michael Ströder]

Ludovic Poitou wrote:

The memberOf attribute name was used by Microsoft Active Directory with
specific semantic. There is no LDAP representation of the attribute
definition, but details, including OID, can be found here:
. It was
also used by a Sun product (Delegated Administration) with another
definition and semantic.


Also FreeIPA IMO abuses 'memberOf' with different semantics.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: OpenLDAP keeps on dying sporadically

[Leander Schäfer]

Also, I just checked. It looks like slapd is successfully linked to 
"libthr.so.3"


root@FreeBSD [~]$ ldd /usr/local/libexec/slapd
/usr/local/libexec/slapd:
libldap_r-2.4.so.2 => /usr/local/lib/libldap_r-2.4.so.2 
(0x8009a7000)

liblber-2.4.so.2 => /usr/local/lib/liblber-2.4.so.2 (0x800bf5000)
libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x800e03000)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x80100c000)
libwrap.so.6 => /usr/lib/libwrap.so.6 (0x80122c000)
libssl.so.7 => /usr/lib/libssl.so.7 (0x801435000)
libcrypto.so.7 => /lib/libcrypto.so.7 (0x8016a)
libthr.so.3 => /lib/libthr.so.3 (0x801a93000)
libc.so.7 => /lib/libc.so.7 (0x801cb8000)

root@FreeBSD [~]$ ls -lach /lib/libthr.so.3
-r--r--r--  1 root  wheel   103K 18 Jan 15:36 /lib/libthr.so.3


So as all the other Applications using "libthr.so.3" slapd should also 
be able to use it?! I'm not 100% convinced yet, that this diagnosis is 
going into the right direction here. I think I'll provide a second gdb 
output, since it always seems to break down at a different point and action.






Am 28.04.15 um 02:49 schrieb Howard Chu:

Howard Chu wrote:

Howard Chu wrote:

Assuming you compiled the latest snapshot, the SEGV at
back-mdb/search.c:404 makes not much sense, it's a return statement.

Also, as back-mdb didn't exist 5 years ago, this cannot be the same
issue you've been running into all the time.

Perhaps you've hit a stack overrun. Generally slapd uses 8MB stacks on
64bit machines. It seems from your ulimit output that 8MB should be
fine, so that also seems unlikely.


Ah, yes, this is a known issue with FreeBSD.

http://www.openldap.org/lists/openldap-bugs/200506/msg00174.html


Furthermore, in the intervening 10 years, the FreeBSD developers have 
not yet fixed this issue.


http://lists.freebsd.org/pipermail/freebsd-current/2014-August/051646.html 

Re: About RDN values starting with #

[Howard Chu]

Pofelski, Lech wrote:

Hello Mr Chu,

Thanks for the pointer. Now we understand why the RDNs like cn=#80 are

not supported in the current version of openldap.


However, we have a very particular use case, specific to the telecom

network usage of LDAP (something similar to TerraCortex presentation in
Paris at LDAPCon2013) that we must support: this is the case when the
attribute type of the RDN has the syntax Octet String. For that use
case, we can't see any other method than # to enable us to
put the content of the Octet String attribute required by the
application in the RDN, keeping DN size, and performance intact.


In that specific case, far more restrictive than the general LDAP
RFC

use case, the attribute used in RDN has a, per application, mandatory
syntax of Octet String, and the BER encoding is restricted to Universal
Class Tag "OctetString".


For all to understand, one example of RDN that must be supported is

 x.y.v.z=#0403466f6f

i.e. x.y.v.z is the OID of an Octet String attribute and 0403466f6f
is

the BER with the Octet String tag (04) (the case 2.5.4.3=#040180 (
cn=#80) will still be kept not supported).


If we enable, under specific config flag control, the ability to

decode RDN similar to example given just above, in a modified openLDAP,
we should not fall in the pitfall described in the openLDAP ITS 6570
(https://www.openldap.org/its/index.cgi/Software%20Bugs?id=6570).


For the specific syntax OctetString, there is no normalization, nor

verification. Thus the risk to inject a bad DN values in this way is
very, very limited, as any value, including empty content, #80,
arbitrary content.. are already allowed.

Not quite. The # prefix means the following hex string must be a valid 
BER encoding of whatever value. Thus, while the octetString value may be 
arbitrary, including zero length, it must still have a valid BER tag and 
length.



Moreover, it may be possible to allow also the other syntax, far more user 
friendly

 myoctstringattr=#466f6f ( no BER, just direct hexa, and short name, 
not OID)

Once again, the functionality is allowed ONLY for the syntax Octet String, i.e. 
cn=#80 STILL not allowed.

This change could make openldap more LDAP v3 compliant.


Does someone have any idea of a theoretical side effect of enabling such 
functionality ?


You're welcome to submit a patch enabling hex format for attributes of 
octetString syntax, but it cannot simply pass thru any hex string. The 
decoded hex string must still conform to BER.


Internally, we would expect the normalized form to be stored in binary, 
not hex. (UUIDs are also treated this way already.) But the text/hex 
form would be given back to clients.


Have to say, using octetString syntax for naming attributes is rather 
user-unfriendly. You should reconsider your app design.


Regards,

Lech POFELSKI


-Original Message-
From: Howard Chu [mailto:h...@symas.com]
Sent: Sunday, April 26, 2015 7:26 AM
To: Pofelski, Lech; openldap-technical@openldap.org
Subject: Re: About RDN values starting with #

Pofelski, Lech wrote:

Hello openLDAP gurus,

According to the RFC 4514, an RDN value may start with # and to be
followed by a number of "hex pair" (pairs of hexadecimal values),
representing octets of some binary value.

There are two use cases involving such RDN syntax:

*Case 1, where the RDN is of the form:

=#

*Case 2, where the RDN is of the form:

=#

Case 1 is explicitly illustrated in the RFC 4514 by the example:

1.3.6.1.4.1.1466.0=#04024869

Although Case 2 is not explicitly illustrated in the RFC4514, it is
implicitly correct, as it is in the conformity with the RDN syntax
provided by this RFC.


It is explicitly rejected by OpenLDAP.

https://www.openldap.org/its/index.cgi/Software%20Bugs?id=6570


*If this is a known limitation in openLDAP.

*If there is already a plan to fix the problem. If not, I'd be glad to
contribute to fixing it.





--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: OpenLDAP keeps on dying sporadically

[Leander Schäfer]

Am 28.04.15 um 02:32 schrieb Howard Chu:

Leander Schäfer wrote:

Ok, here is the first result running the debugging mode with gdb(1)

 >> Procedure overview:
(gdb) run
(gdb) bt full
(gdb) thread apply all bt
(gdb) generate-core-file


No need for a core file if you're just running slapd inside gdb.
I thought the core file would be required to have a better base of 
knowledge about the internal happening?! But ofcourse I'm happy if it is 
not required, cause it doesn't seem to create it properly in the first 
place.



 >> This came up:
candidates = Error accessing memory address 0x7eafb6f0: Bad address.

# == #

root@FreeBSD [~]$ gdb --args /usr/local/libexec/slapd -d -1 -f
/usr/local/etc/openldap/slapd.conf -u ldap -g ldap -h
"ldapi://%2fvar%2frun%2fopenldap%2fldapi/ ldap:/// ldaps:///"
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for 
details.

This GDB was configured as "amd64-marcel-freebsd"...
(gdb) run
Starting program: /usr/local/libexec/slapd -d -1 -f
/usr/local/etc/openldap/slapd.conf -u ldap -g ldap -h
ldapi://%2fvar%2frun%2fopenldap%2fldapi/\ ldap:///\ ldaps:///
[New LWP 101138]
[New Thread 802806400 (LWP 101138/slapd)]

[...]

553e8a87 conn=1006 op=2 SRCH attr=mailAlias
553e8a87 send_ldap_result: err=0 matched="" text=""
   0010:  51 bd aa 7d 3f 1c 50 fb  25 f8 59 9e 9d 9a ba 0f 
Q..}?.P.%.Y.
   0020:  d0 07 aa 95 ac 1c e7 3e  81 f6 e6 0b 6d 09 94 9b 
...>m...
   0730:  1b 51 e3 08 4b 38 ec f1  ee 8c 0f 35 cd 55 eb 80 
.Q..K8.5.U..

553e8a87 ==> limits_get: conn=1006 op=2 self="[anonymous]"
this="ou=accounts,ou=mail,dc=mydomain,dc=local"
   0740:  83 e2 3b b5 13 fd 08 51  13 25 d9 7d 57 9f 6b e9 
..;Q.%.}W.k.

[New Thread 943c11800 (LWP 100198/slapd)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 943c11800 (LWP 100198/slapd)]
mdb_search (op=0x94581c400, rs=0x7ebfbb60) at search.c:404
404 search.c: No such file or directory.
 in search.c
Current language:  auto; currently minimal
(gdb) bt full
#0  mdb_search (op=0x94581c400, rs=0x7ebfbb60) at search.c:404
 mdb = (struct mdb_info *) 0x80290a000
 id = 0
 cursor = 0
 nsubs = 128
 ncand = 0
 cscope = 0
 lastid = 18446744073709551615
 candidates = Error accessing memory address 0x7eafb6f0: Bad
address.
(gdb) thread apply all bt
[New Thread 943c15000 (LWP 101255/slapd)]
[New Thread 943c14c00 (LWP 101213/slapd)]
[New Thread 943c14800 (LWP 101202/slapd)]
[New Thread 943c14400 (LWP 100898/slapd)]
[New Thread 943c14000 (LWP 100884/slapd)]
[New Thread 943c13c00 (LWP 100647/slapd)]
[New Thread 943c13800 (LWP 100619/slapd)]
[New Thread 943c13400 (LWP 100577/slapd)]
[New Thread 943c13000 (LWP 100531/slapd)]
[New Thread 943c12c00 (LWP 100515/slapd)]
[New Thread 943c12800 (LWP 100347/slapd)]
[New Thread 943c12400 (LWP 100311/slapd)]
[New Thread 943c12000 (LWP 100296/slapd)]
[New Thread 943c11c00 (LWP 100268/slapd)]
[New Thread 943c11400 (LWP 100165/slapd)]
[New Thread 802807800 (LWP 100103/slapd)]

Thread 19 (Thread 802807800 (LWP 100103/slapd)):
#0  0x000801aa78cc in __error () from /lib/libthr.so.3
#1  0x000801aa27f4 in pthread_mutex_destroy () from /lib/libthr.so.3
#2  0x000801dfc237 in flockfile () from /lib/libc.so.7
#3  0x000801dd7e64 in fputs () from /lib/libc.so.7
#4  0x000800bfd48f in lutil_debug () from
/usr/local/lib/liblber-2.4.so.2
#5  0x0043b96f in slapd_daemon_task (ptr=0x8028afb08) at
daemon.c:2530
#6  0x000801a9c4f5 in pthread_create () from /lib/libthr.so.3



Seems like something went wrong here. Am I using gdb wrong?


Looks like your liblber was installed without debug symbols. Most of 
these stack traces look invalid.
What does this mean? How did you see this / what indicated this to you? 
Is it required to fix this liblber issue for a better debug result, or 
is it ok for first diagnosis?



Am 27.04.15 um 19:04 schrieb Michael Ströder:

Leander Schäfer wrote:

Can you please provide me a link, cause I wasn't able to find
"current RE24" on the official website nor on the FTP mirror.


Use git or this link to checkout snapshot of the RE24 branch:

http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/heads/OPENLDAP_REL_ENG_2_4;sf=tgz 



Assuming you compiled the latest snapshot, the SEGV at 
back-mdb/search.c:404 makes not much sense, it's a return statement.


Also, as back-mdb didn't exist 5 years ago, this cannot be the same 
issue you've been running into all the time.
^ Pretty much possible. But again - the exit points are always 
different. I could do the same thing with BDB and yet it would exit on 
different poi

RE: About RDN values starting with #

[Pofelski, Lech]

Hello Mr Chu, 

Thanks for the pointer. Now we understand why the RDNs like cn=#80 are not 
supported in the current version of openldap.

However, we have a very particular use case, specific to the telecom network 
usage of LDAP (something similar to TerraCortex presentation in Paris at 
LDAPCon2013) that we must support: this is the case when the attribute type of 
the RDN has the syntax Octet String. For that use case, we can't see any other 
method than # to enable us to put the content of the Octet String 
attribute required by the application in the RDN, keeping DN size, and 
performance intact.

In that specific case, far more restrictive than the general LDAP RFC use case, 
the attribute used in RDN has a, per application, mandatory syntax of Octet 
String, and the BER encoding is restricted to Universal Class Tag "OctetString".

For all to understand, one example of RDN that must be supported is  

x.y.v.z=#0403466f6f   

i.e. x.y.v.z is the OID of an Octet String attribute and 0403466f6f is the BER 
with the Octet String tag (04) (the case 2.5.4.3=#040180 ( cn=#80) will still 
be kept not supported).

If we enable, under specific config flag control, the ability to decode RDN 
similar to example given just above, in a modified openLDAP, we should not fall 
in the pitfall described in the openLDAP ITS 6570 
(https://www.openldap.org/its/index.cgi/Software%20Bugs?id=6570).

For the specific syntax OctetString, there is no normalization, nor 
verification. Thus the risk to inject a bad DN values in this way is very, very 
limited, as any value, including empty content, #80, arbitrary content.. are 
already allowed.

Moreover, it may be possible to allow also the other syntax, far more user 
friendly 

myoctstringattr=#466f6f ( no BER, just direct hexa, and short name, not 
OID)

Once again, the functionality is allowed ONLY for the syntax Octet String, i.e. 
cn=#80 STILL not allowed.

This change could make openldap more LDAP v3 compliant.


Does someone have any idea of a theoretical side effect of enabling such 
functionality ?

Regards,

Lech POFELSKI


-Original Message-
From: Howard Chu [mailto:h...@symas.com] 
Sent: Sunday, April 26, 2015 7:26 AM
To: Pofelski, Lech; openldap-technical@openldap.org
Subject: Re: About RDN values starting with #

Pofelski, Lech wrote:
> Hello openLDAP gurus,
>
> According to the RFC 4514, an RDN value may start with # and to be 
> followed by a number of "hex pair" (pairs of hexadecimal values), 
> representing octets of some binary value.
>
> There are two use cases involving such RDN syntax:
>
> *Case 1, where the RDN is of the form:
>
> =# encoded attribute value in form of a sequence of hex pairs >
>
> *Case 2, where the RDN is of the form:
>
> =#
>
> Case 1 is explicitly illustrated in the RFC 4514 by the example:
>
> 1.3.6.1.4.1.1466.0=#04024869
>
> Although Case 2 is not explicitly illustrated in the RFC4514, it is 
> implicitly correct, as it is in the conformity with the RDN syntax 
> provided by this RFC.

It is explicitly rejected by OpenLDAP.

https://www.openldap.org/its/index.cgi/Software%20Bugs?id=6570

> *If this is a known limitation in openLDAP.
>
> *If there is already a plan to fix the problem. If not, I'd be glad to 
> contribute to fixing it.

-- 
   -- Howard Chu
   CTO, Symas Corp.   http://www.symas.com
   Director, Highland Sun http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Antw: Re: Slapd running very slow

[Andrew Findlay]

Did you get to the bottom of this?

On Thu, Apr 23, 2015 at 08:29:48PM +1000, Geoff Swan wrote:

> On 2015-04-23 5:56 PM, Howard Chu wrote:
> > In normal (safe) operation, every transaction commit performs 2
> > fsyncs. Your 140MB/s throughput spec isn't relevant here, your disk's
> > IOPS rate is what matters. You can use NOMETASYNC to do only 1 fsync
> > per commit.

Decent SAS disks spin at 10,000 or 15,000 RPM so unless there is a non-volatile
memory cache in there I would expect at most 15000/60 = 250 fsyncs per second 
per
drive, giving 125 transaction commits per second per drive.

> OK. I ran a reduced version of test script (20 processes each performing
> 40 read/write operations) with normal (safe) mode of operation on a test
> server that has 32GB RAM, and everything else identical to the server
> with 128GB.

So that is just 800 operations taking 60s?

> A quick test using vmstat at 1s intervals gave the following output
> whilst it was running.
> 
> procs ---memory-- ---swap-- -io
> -system-- --cpu-
>  r  b swpd free buffcache   si   sobibo   in  
> cs us sy id wa st
> 20  00 32011144   167764   33041600 115   40  
> 56  0  0 99  1  0
>  0  00 31914848   167764   33042400 0  1560 2594
> 2130  2  1 97  0  0
>  0  00 31914336   167764   33042400 0  1708  754
> 1277  0  0 100  0  0
>  0  00 31914508   167772   33042000 0  2028  779
> 1300  0  0 99  1  0

> The script took about 60s to complete, which is a lot longer than
> expected. It appears almost all I/O bound, at a fairly slow rate (1500
> blocks in a second is 6MB/s).

As you say, it is IO bound (wa ~= 100%). Stop worrying about MB/s: the data 
rate is
irrelevant, what matters is synchronous small-block writes and those are 
limited by
rotation speed.

Are you absolutely certain that the disks are SAS? Does your disk controller
believe it? I had big problems with an HP controller once that refused to run 
SATA
drives at anything like their full speed as it waited for each transaction to
finish and report back before queuing the next one...

Andrew
-- 
---
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/+44 1628 782565 |
---

Re: All entries belong to the top object class?

[Andrew Findlay]

On Tue, Apr 28, 2015 at 10:21:25AM +0530, dE wrote:

> >No. 'top' is defined in RFC4512:
> >
> > ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
> >
> >so every entry MUST contain an objectclass attribute.
> >It does not say anything about any other attributes.
> 
> Yeah, so that's the question, can any attribute which is in the MAY
> of the top object class be added to any entry in the DIT regardless
> of what object class it belongs to?

The top object class does not have any MAY attributes. If it did then yes you 
could
use them in any entry in the DIT as all normal entries are members of top.

Andrew
-- 
---
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/+44 1628 782565 |
---

Re: top object class contains all possible attributes?

[Emmanuel Lecharny]

This is certainly not the right place. This maling list is for suestion
related to OpneLDAP.

Le mardi 28 avril 2015, dE  a écrit :

> On 04/28/15 11:18, Dario Zanzico wrote:
>
>> On Tue, Apr 28, 2015, at 07:21 AM, dE wrote:
>>
>>>   From https://tools.ietf.org/html/rfc4512
>>>
>>>  it
>>>  can be said that an object class inherits the sets of *allowed*
>>>  and
>>>  required attributes from its superclasses
>>>
>>> Therefore the top object class contains all possible attributes? OR
>>>
>> no
>>
>>  A subclasses cannot contain any attribute which is not included in it's
>>> superclass?
>>>
>> no
>>
>> A subclass contains definitions for
>> all the MAY attributes that the superclass contains as MAY attributes,
>> and
>> all the MUST attributest that the superclass contains as MUST
>> attributes.
>>
>> therefore, an entry including our inheriting subclass:
>> MUST contain all the MUST attributes included in the superclass(es)
>> MUST contain all the MUST attributes included in our subclass
>> MAY contain all the MAY attributes included in the superclass(es)
>> MAY contain all the MAY attributes included in our subclass
>>
>> as an example:
>>
>> given this objectClasses 'tree':
>> objectClasses: ( 0.0.0.0 NAME 'myparent' MUST cn MAY uid )
>> objectClasses: ( 0.0.0.1 NAME 'mysub' SUP myparent MUST mail MAY mobile
>> )
>>
>> an entry containing the sub objectClass mysub
>> MUST contain: cn (inherited from myparent), mail
>> MAY contain: uid (inherited from myparent), mobile
>>
>> hope this helps
>>
>> bye,
>> dario
>>
>>
> Ok, now I get this.
>
> Thank you! There is no such IETF mailing list to question RFCs, so this
> appears to be the best place.
>
>

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: uidNumber=4294967295 is being appearing in the log frequently

[Howard Chu]

Majid Khan wrote:

Dear Techies,

I'm not sure if this is the right forum to discuss this but I am getting
the following from some of the clients machine I'm not sure why some of
them sending this info otherwise my authentication and login all is
working fine but I'm concern why its happening and my log is full of the
following kind of message:

If this is not the right forum then I apologies and please direct me to
that right group:


Since the query is coming from SSSD, you should be asking in a forum for 
SSSD support. This has nothing to do with OpenLDAP.


For the record, this is a pretty stupidly constructed LDAP search 
filter. Their LDAP support appears to be pretty clunky.


Apr 28 05:58:44 server1 slapd[23003]: conn=5235 op=22 SRCH
base="dc=example,dc=com" scope=2 deref=0
filter="(&(uidNumber=4294967295)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0"
Apr 28 05:58:44 server1 slapd[23003]: conn=5235 op=22 SRCH
attr=objectClass uid userPassword uidNumber gidNumber gecos
homeDirectory loginShell krbPrincipalName cn modifyTimestamp
modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning
shadowInactive shadowExpire shadowFlag krbLastPwdChange
krbPasswordExpiration pwdAttribute authorizedService accountExpires
userAccountControl nsAccountLock host loginDisabled loginExpirationTime
loginAllowedTimeMap

Server info: CentOS release 6.6
LDAP version: openldap-2.4.40

Client info: CentOS release 6.2
Client using SSSD: sssd-1.11.6


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

uidNumber=4294967295 is being appearing in the log frequently

[Majid Khan]

Dear Techies,
I'm not sure if this is the right forum to discuss this but I am getting the 
following from some of the clients machine I'm not sure why some of them 
sending this info otherwise my authentication and login all is working fine but 
I'm concern why its happening and my log is full of the following kind of 
message:

If this is not the right forum then I apologies and please direct me to that 
right group:

Apr 28 05:58:44 server1 slapd[23003]: conn=5235 op=22 SRCH 
base="dc=example,dc=com" scope=2 deref=0 
filter="(&(uidNumber=4294967295)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0"Apr
 28 05:58:44 server1 slapd[23003]: conn=5235 op=22 SRCH attr=objectClass uid 
userPassword uidNumber gidNumber gecos homeDirectory loginShell 
krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin 
shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange 
krbPasswordExpiration pwdAttribute authorizedService accountExpires 
userAccountControl nsAccountLock host loginDisabled loginExpirationTime 
loginAllowedTimeMap
Server info: CentOS release 6.6LDAP version: openldap-2.4.40
Client info: CentOS release 6.2Client using SSSD: sssd-1.11.6
Thanks.
Best regards,
Majid.

Re: top object class contains all possible attributes?

[lucas castro]

What defines the required and all possibles attributes are the objectclass
of the entry,
and if the used objectclass is inherited from another one, all the required
and possible parent attributes will be presents there too.

On Tue, Apr 28, 2015 at 2:21 AM, dE  wrote:

>  From https://tools.ietf.org/html/rfc4512
>
> it
>can be said that an object class inherits the sets of *allowed* and
>required attributes from its superclasses
>
> Therefore the top object class contains all possible attributes? OR
>
> A subclasses cannot contain any attribute which is not included in it's
> superclass?
>
> I'm running Apache directory studio, and I don't see that happening.
>



-- 
contatos:
Celular: ( 99 ) 9143-5954 - Vivo
skype: lucasd3castro
msn: lucascastrobor...@hotmail.com

Re: All entries belong to the top object class?

[Howard Chu]

dE wrote:

On 04/26/15 23:37, Michael Ströder wrote:

You should really read RFC 4512 more carefully and look at existing
subschema. I give up now to explain.


That's the source of all confusion.

There is no IETF mailing list to discuss these issues.


General LDAP discussion occurs on l...@umich.edu

We generally expect you to already know LDAP before coming to the 
OpenLDAP mailing lists.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: LMDB:Transaction across multiple enviroments

[Howard Chu]

Daniel, Sabu wrote:

Hi,

I am trying to use LMDB and I would like to know if there a way to
define a transaction across multiple environments?


Currently no. I've been thinking about adding 2-phase commit, which 
could support that sort of usage, but definitely won't be in 0.9. For 
now you would have to manage this entirely in your own application code.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: Antw: Re: All entries belong to the top object class?

[Christian Kratzer]

Hi,

On Mon, 27 Apr 2015, Quanah Gibson-Mount wrote:


--On Tuesday, April 28, 2015 10:58 AM +0530 dE  wrote:


Yes, so subclasses do not define MAY; it's defined by the MAY of the top
object class.


The "top" objectClass does not contain *any* MAY attributes.  I wonder if you 
are confused in thinking of "top" as a generic term.  It is not.  "top" is a 
very specific objectClass that is explicitly defined as noted previously.  It 
contains a single MUST attribute.


one of my customers has an enterprise provisioning tool from a well known large 
supplier of such systems.

The developers of that tool insist that they want to see an explit "objectClass: 
top" in all objects.

It hurts every single time I have to look at that specific directory.

Greetings
Christian

--
Christian Kratzer   CK Software GmbH
Email:   c...@cksoft.de   Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0   D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9   HRB 245288, Amtsgericht Stuttgart
Mobile:  +49 171 1947 843   Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/

Re: Ldap challenge

[Ludovic Poitou]

Interesting how this question is hitting a number of different mailing lists…

Here’s an edited extract of an email I’ve sent yesterday on OpenDJ mailing list:

The memberOf attribute name was used by Microsoft Active Directory with 
specific semantic. There is no LDAP representation of the attribute definition, 
but details, including OID, can be found here: 
. 
It was also used by a Sun product (Delegated Administration) with another 
definition and semantic. 

This is why we choose in Sun Directory Server, OpenDS and now OpenDJ to have a 
properly defined attribute with a different name: isMemberOf, operational and 
read-only.

My 2 cents,

Ludo


-- 
Ludovic Poitou
http://ludopoitou.com


From: Michael Ströder 
Reply: Michael Ströder >
Date: 27 Apr 2015 at 22:43:41
To: Andrew Findlay >
Cc: openldap-technical@openldap.org >
Subject:  Re: Ldap challenge  

Andrew Findlay wrote:  
> On Mon, Apr 27, 2015 at 06:27:39PM +, Ross, Daniel B. wrote:  
>  
>> ismemberof does not exist we have to use memberof  
>  
> Memberof is fairly common. I don't think I have ever found a system  
> that used 'ismemberof'.  

'isMemberOf' is used on Sun/Oracle DSSE, Netscape/Fedora/389-DS and 
OpenDS/OpenDJ.  

'memberOf' was originally defined in MS Active Directory and is used as  
default in slapo-memberof. It's configurable though.  

Ciao, Michael.  

Re: top object class contains all possible attributes?

[dE]

On 04/28/15 11:18, Dario Zanzico wrote:

On Tue, Apr 28, 2015, at 07:21 AM, dE wrote:

  From https://tools.ietf.org/html/rfc4512

 it
 can be said that an object class inherits the sets of *allowed*
 and
 required attributes from its superclasses

Therefore the top object class contains all possible attributes? OR

no


A subclasses cannot contain any attribute which is not included in it's
superclass?

no

A subclass contains definitions for
all the MAY attributes that the superclass contains as MAY attributes,
and
all the MUST attributest that the superclass contains as MUST
attributes.

therefore, an entry including our inheriting subclass:
MUST contain all the MUST attributes included in the superclass(es)
MUST contain all the MUST attributes included in our subclass
MAY contain all the MAY attributes included in the superclass(es)
MAY contain all the MAY attributes included in our subclass

as an example:

given this objectClasses 'tree':
objectClasses: ( 0.0.0.0 NAME 'myparent' MUST cn MAY uid )
objectClasses: ( 0.0.0.1 NAME 'mysub' SUP myparent MUST mail MAY mobile
)

an entry containing the sub objectClass mysub
MUST contain: cn (inherited from myparent), mail
MAY contain: uid (inherited from myparent), mobile

hope this helps

bye,
dario



Ok, now I get this.

Thank you! There is no such IETF mailing list to question RFCs, so this 
appears to be the best place.