Re: OpenLDAP duplication

[Quanah Gibson-Mount]

--On Monday, September 30, 2013 1:39 PM +0400 25Dollar Tech 
<25dollartechh...@gmail.com> wrote:




Hello Team,


I just want to know the below


According to my understanding, LDAP authenticates (binds) with DN
(distinguish name) and password. E.g. CN=bob, OU=Users,DC=test,DC=com.



So OpenLDAP allows the same CN in a different OU.


 Is there any option to prevent it. ?


As a side note, building DNs off of cn for users is a generally a really 
bad idea.


--Quanah

--

Quanah Gibson-Mount
Lead Engineer
Zimbra Software, LLC

Zimbra ::  the leader in open source messaging and collaboration

Re: ldapsearch: wildcard search do not list all entries

[Quanah Gibson-Mount]

--On Monday, September 30, 2013 11:57 AM +0200 Birgit Ohlenbusch 
 wrote:



On 27.09.2013 20:58, Quanah Gibson-Mount wrote:


Also, you noted you are using RHEL6.4.  I assume you are not running
their broken packages but something current that is sanely built? ;)



Oh, we are running the packages from the original RHEL repository. I
didn't know that's a problem. Do you know a repository with sanely built
openldap packages for RHEL 6 which you can recommend?





--

Quanah Gibson-Mount
Lead Engineer
Zimbra Software, LLC

Zimbra ::  the leader in open source messaging and collaboration

Re: Antw: Kudos to all who contributed to MDB

[Howard Chu]

Ulrich Windl wrote:

 >>> Brent Bice  schrieb am 18.09.2013 um 22:01 in Nachricht
<523a068f.1000...@sgi.com>:

I've started testing an LDAP server here using MDB and ran across a
few caveats that might be of use to others looking into using it.  But
first off, let me say a hearty THANKS to anyone who's contributed to it.
In this first OpenLDAP server I've converted over to MDB it's
*dramatically* faster and it's definitely nice to not worry about having
to setup script/s to occasionally (carefully) commit/flush DB logs, etc.

 One caveat that might be worth mentioning in release notes
somewhere...  Not all implementations of memory mapped I/O are created
equal.  I ran into this a long time back when I wrote a multi-threaded
quicksort program for a friend to had to sort text files bigger than 10
gigs and didn't want to wait for the unix sort command. :-)  The program
I banged together for him used memory mapped I/O and one of the things I
found was that while Solaris would let me memory map a file bigger than
I had physical or virtual memory for, linux wouldn't.  It appeared that


I doubt that Solaris allows you to mmap() a file to an area larger than
the

virtual address space, however you can mmap() a file area larger than RAM+swap
when a demand paging strategy is used. However once you start modifying the
mapped pages you may run out of memory, so thing twice.

No OS can let you mmap a single region larger than the address space. But 
mapping a file larger than RAM is no problem, the OS will swap pages in and 
out as needed.



some versions of the 2.x kernels wouldn't let me memory-map a file
bigger than the total *virtual* memory size, and I think MDB is running
into the same limitation.  On a SLES11 system, for instance with the
2.6.32.12 kernel, I can't specify a maxsize bigger than the total of my
physical memory and swap space.  So just something to keep in mind if


Also be aware that in SLES11 SP2 the kernel update release some weeks ago

strengthened the checks for mmap()ed areas: I had a program that started to
fail when I tried to change one byte after the end of the file, while this
worked with the kernel before.

Irrelevant for LMDB since we never do such a thing.


you're using MDB on the 2.x kernels - you may need a big swap area even
though the memory mapped I/O routines in the kernel seem to be smart
enough to avoid swapping like mad.


I'd like to object: AFAIR, MDB used mmap()ed areas in strictly read-only

fashion, so the backing store is the original file, being demand paged. When
data is write()n, the system will dirty buffers in real RAM that are
eventually written back to the file blocks. I see no path where dirty buffers
should be swapped unless the mapping is PRIVATE.

Correct; since LMDB uses an mmap'd file it will *never* use swap space.

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

Antw: Kudos to all who contributed to MDB

[Ulrich Windl]

>>> Brent Bice  schrieb am 18.09.2013 um 22:01 in Nachricht
<523a068f.1000...@sgi.com>:
> I've started testing an LDAP server here using MDB and ran across a 
> few caveats that might be of use to others looking into using it.  But 
> first off, let me say a hearty THANKS to anyone who's contributed to it. 
> In this first OpenLDAP server I've converted over to MDB it's 
> *dramatically* faster and it's definitely nice to not worry about having 
> to setup script/s to occasionally (carefully) commit/flush DB logs, etc.
> 
> One caveat that might be worth mentioning in release notes 
> somewhere...  Not all implementations of memory mapped I/O are created 
> equal.  I ran into this a long time back when I wrote a multi-threaded 
> quicksort program for a friend to had to sort text files bigger than 10 
> gigs and didn't want to wait for the unix sort command. :-)  The program 
> I banged together for him used memory mapped I/O and one of the things I 
> found was that while Solaris would let me memory map a file bigger than 
> I had physical or virtual memory for, linux wouldn't.  It appeared that 

I doubt that Solaris allows you to mmap() a file to an area larger than the 
virtual address space, however you can mmap() a file area larger than RAM+swap 
when a demand paging strategy is used. However once you start modifying the 
mapped pages you may run out of memory, so thing twice.

> some versions of the 2.x kernels wouldn't let me memory-map a file 
> bigger than the total *virtual* memory size, and I think MDB is running 
> into the same limitation.  On a SLES11 system, for instance with the 
> 2.6.32.12 kernel, I can't specify a maxsize bigger than the total of my 
> physical memory and swap space.  So just something to keep in mind if 

Also be aware that in SLES11 SP2 the kernel update release some weeks ago 
strengthened the checks for mmap()ed areas: I had a program that started to 
fail when I tried to change one byte after the end of the file, while this 
worked with the kernel before.

> you're using MDB on the 2.x kernels - you may need a big swap area even 
> though the memory mapped I/O routines in the kernel seem to be smart 
> enough to avoid swapping like mad.

I'd like to object: AFAIR, MDB used mmap()ed areas in strictly read-only 
fashion, so the backing store is the original file, being demand paged. When 
data is write()n, the system will dirty buffers in real RAM that are eventually 
written back to the file blocks. I see no path where dirty buffers should be 
swapped unless the mapping is PRIVATE.


> 
> On a newish ubuntu system with a 3.5 kernel this doesn't seem to be 
> an issue - tell OpenLDAP to use whatever maxsize you want and it just 
> works.  :-)
> 
> I'd also only use MDB on a 64 bit linux system. One of the other 
> headaches I remember running into with memory mapped I/O was adding in 
> support for 64 bit I/O on 32 bit systems.  Best to avoid that whole mess 
> and just use a 64 bit OS in the first place.

For 32bit remember that the thread's stacks also consume virtual address space. 
So the maximum database size may be significantly below 4GB.

> 
> Lastly... At the risk of making Howard and Quanah cringe... :-)  The 
> OpenLDAP DB I've been testing this with is the back-end to an email 
> tracking tool I setup several years ago.  More as an excuse to 
> edjimicate myself on the java API for LDAP than anything else, I wrote a 
> quick bit of java that watches postfix and sendmail logs and writes 
> pertinent bits of info into an LDAP database, and a few PHP scripts to 
> then query that database for things like to/from addresses, queue IDs, 
> and message IDs.  'Makes it easy for junior admins to quickly search 
> through gigabytes of logs to see what path an email took to get from 
> point A to point B, who all received it (after it went through one or 
> more list servers and a few aliases got de-ref'd, etc).
> 
> Yeah, it's an utter abuse of LDAP which is supposed to be 
> write-rarely and read-mostly, especially as our postfix relays handle 
> anywhere from 1 to 10 messages per second on average. :-)  But what the 
> heck, it works fine and was a fun weekend project.  It's also served as 
> a way to stress-test new versions of OpenLDAP before I deploy them 
> elsewhere. :-)
> 
> Anyway, thanks again to everyone who contributed to MDB. It's lots 
> faster than BerkeleyDB in all of my testing so far. 'Looking forward to 
> gradually shifting more of my LDAP servers over to it.
> 
> Brent

Antw: building SLES packages on openSuSE Build Service

[Ulrich Windl]

Hi!

I think SUSE has updates the build servers not too long ago...Did you check 
announcements?

Ulrich

>>> Marc Patermann  schrieb am 18.09.2013 um
13:05 in Nachricht <52398902.9090...@ofd-z.niedersachsen.de>:
> Hi,
> 
> I used to build newer versions of openldap on openSuSE Build Service 
> derived from the ones at network:ldap (from Ralf Haferkamp; which is 
> stuck at .33). I did this for 2.4.33, .34 and .35.
> 
> When I tried to build 2.4.36 something changed (at the build service?) 
> and now my builds - even the older ones, which built fine before - fail 
> with the following errors:
> 
> [  399s] E: openldap2 64bit-portability-issue dn2id.c:738
> [  399s] E: openldap2 64bit-portability-issue id2entry.c:123
> 
> What may have caused this?
> 
> 
> Marc

Re: OpenLDAP duplication

[Andrew Findlay]

On Mon, Sep 30, 2013 at 01:39:03PM +0400, 25Dollar Tech wrote:

> According to my understanding, LDAP authenticates (binds) with DN (distinguish
> name) and password. E.g. CN=bob, OU=Users,DC=test,DC=com.
> 
> So OpenLDAP allows the same CN in a different OU.

Yes of course - that is how LDAP and X.500 are designed.

>  Is there any option to prevent it. ?

Use the 'unique' overlay:

http://www.openldap.org/doc/admin24/overlays.html#Attribute%20Uniqueness

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: separate login/password for several services?

[Andrew Findlay]

On Fri, Sep 27, 2013 at 10:16:43PM +0200, Michael Ströder wrote:

> Did not follow this thread closely. But one should be aware of ITS#6825 when
> planning to use slapo-unique for a more complex setup.
> 
> unique_uri filter reaching beyond its intended target
> http://www.openldap.org/its/index.cgi?findid=6825

Good point. We started with these ACLs:

> > overlay unique
> > unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SMTP)
> > unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=IMAP)
> > unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=POP3)
> > unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=XMPP)
> > unique_uri ldap:///ou=People,dc=org?uid?sub?(authorizedService=SSH)

so that bug will prevent modifications to the authority entries even though adds
will be processed OK. I cannot think of an easy workaround in this case :-(

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: OpenLDAP duplication

[Peter Gietz]

Am 30.09.2013 11:39, schrieb 25Dollar Tech:

Hello Team,

I just want to know the below

According to my understanding, LDAP authenticates (binds) with DN 
(distinguish name) and password. E.g. |CN=bob, OU=Users,DC=test,DC=com.|

|
|
|So OpenLDAP allows the same CN in a different OU.|
|
|
| Is there any option to prevent it. ?
|

You can use the unique overlay to enforce  the cn attribute to be 
unique. See man slapo-unique.


Cheers,

Peter



--
*Thanks & Regards,
25dollarTech Team
https://sites.google.com/site/25dollartech/*
*Email: 25dollartechh...@gmail.com *



--

Peter Gietz, CEO

DAASI International GmbH
Europaplatz 3
D-72072 Tübingen
Germany

phone: +49 7071 407109-0
fax:   +49 7071 407109-9
email: peter.gi...@daasi.de
web:   www.daasi.de

Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz

Re: ldapsearch: wildcard search do not list all entries

[Birgit Ohlenbusch]

On 27.09.2013 20:58, Quanah Gibson-Mount wrote:


Also, you noted you are using RHEL6.4.  I assume you are not running their 
broken packages but something current that is
sanely built? ;)



Oh, we are running the packages from the original RHEL repository. I didn't know that's a problem. Do you know a 
repository with sanely built openldap packages for RHEL 6 which you can recommend?




smime.p7s
Description: S/MIME Cryptographic Signature

OpenLDAP duplication

[25Dollar Tech]

Hello Team,

I just want to know the below

According to my understanding, LDAP authenticates (binds) with DN
(distinguish name) and password. E.g. CN=bob, OU=Users,DC=test,DC=com.

So OpenLDAP allows the same CN in a different OU.

 Is there any option to prevent it. ?


-- 
*Thanks & Regards,
25dollarTech Team
https://sites.google.com/site/25dollartech/*
*Email: 25dollartechh...@gmail.com*