openldap-technical

openldap-technical@openldap.org

3 participants
9898 discussions

Empty directory memory consumption
by Ivan Kurnosov 18 Oct '17

18 Oct '17

Hi, I have found, that just installed slapd (2.4.42+dfsg-2ubuntu3.2) on ubuntu 16.04 consumes 730MB+ or resident memory (RSS). It's an empty database (with `cn=config` only and whatever comes by default), is it supposed to consume so much memory? -- With best regards, Ivan Kurnosov

1 0

Re: Admin roles by group membership per OU
by Quanah Gibson-Mount 16 Oct '17

16 Oct '17

--On Monday, October 16, 2017 6:05 PM +0200 Ervin Hegedüs <airween(a)gmail.com> wrote: >> Hm, yes, that's correct. You'll need to do something like utilize by * >> break appropriately, or have multiple "access to userPassword" ACLs by >> group, then a catchall after that. > > I'm sorry - could you give me an example? Sure, no problem. :) One way to do it is to have an access line per subtree for those attributes, adding the group permission, with a final access to just userPassword itself limiting off all other access for anything outside of those trees: dn: olcDatabase={1}mdb,cn=config olcAccess: {0}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write ... Addtional subtree ACLs with groups for userPassword/shadowLastChange access... olcAccess: {#}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read olcAccess: {#}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by self write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read olcAccess: {#}to * by * read The other option is to use "by * break", which tells slapd to continue processing additional rules. If you do that, you'll need to be particularly careful not to give access beyond what you intended. For that purpose, I added a final ACL rule that says zero access to userPassword prior to the "* by * read" ACL. dn: olcDatabase={1}mdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by * break olcAccess: {1}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by self write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read ... Additional subtree ACLs with groups ... olcAccess: {#} to userPassword by * none olcAccess: {#}to * by * read --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Admin roles by group membership per OU
by Quanah Gibson-Mount 16 Oct '17

16 Oct '17

--On Monday, October 16, 2017 5:55 PM +0200 Ervin Hegedüs <airween(a)gmail.com> wrote: > without any real testing, I'm afraid that the rule{0} gives the > write access to cn=groupabcadmin to _all_ db, not just the ou=ABC > Cumstomer subtree. > > Em I right? Hm, yes, that's correct. You'll need to do something like utilize by * break appropriately, or have multiple "access to userPassword" ACLs by group, then a catchall after that. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Admin roles by group membership per OU
by Quanah Gibson-Mount 16 Oct '17

16 Oct '17

--On Monday, October 16, 2017 11:45 AM +0200 Ervin Hegedüs <airween(a)gmail.com> wrote: > dn: olcDatabase={1}mdb,cn=config > olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by > anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by * none > olcAccess: {1}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by > self write by group.exact="cn=groupabcadmin,ou=ABC > Customer,dc=core,dc=hdt,dc=hu" write by > dn="uid=repuser,dc=core,dc=hdt,dc=hu" read olcAccess: {2}to * by * read > > > and a member of cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu > can modify any attributes at any users under the ou=ABC Customer, > EXCEPT the userPassword - when I want to modify that, I get > permission error: That would be expected, given your ACLs. > How can I combine the attrs and group permissions? Should I list > all attributes in rule? You need to add a rule in the userPassword ACL to allow the group to write to the attribute. ACLs are processed in the order they are listed, and STOP at the first match. This is clearly documented in the slapd.access(5) man page. I.e., you would need: dn: olcDatabase={1}mdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write olcAccess: {1}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by self write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read olcAccess: {2}to * by * read I would note again that "by * none" is implicit on any ACL, there's no need to specifically list it. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Initialize ldap with mdb
by Howard Chu 16 Oct '17

16 Oct '17

Michael Ströder wrote: > rammohan ganapavarapu wrote: >> You mean we can resize db any time? > > You can increase but *not decrease* maxsize later. > >> Wouldn't it be nice to have no max >> limit and grow db dynamically? > > Not possible with a memory-mapped DB. > Others can explain better in detail why. "No limit" is kind of a pointless phrase. The physical limit will always be the size of free space in your filesystem. Aside from that you can simply do what the documentation says - configure a huge size and let the DB grow dynamically within that size. Use 64TB or whatever, and forget about 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/

1 0

Re: Admin roles by group membership per OU
by Quanah Gibson-Mount 16 Oct '17

16 Oct '17

--On Thursday, October 12, 2017 6:32 PM +0200 Ervin Hegedüs <airween(a)gmail.com> wrote: > rules: > > olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by > anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read by * none > olcAccess: {1}to dn.base="" by * read > olcAccess: {2}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by > self write by group.exact="cn=groupabcadmin,ou=ABC > Customer,dc=core,dc=hdt,dc=hu" write by self write by anonymous auth by > dn="uid=repuser,dc=mycompany,dc=hu" read olcAccess: {3}to * by * read Your olcAccess: {1} value does not belong in your back-MDB database. That rule goes in the {-1}frontend,cn=config portion of the database as a global access rule. You probably also want a rule that reads: to dn.base="cn=subschema" by * read in the {-1}frontend,cn=config database as well. So for your back-mdb database, what one would expect is more something like: olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read olcAccess: {1}to dn.children="ou=ABC Customer,dc=core,dc=hdt,dc=hu" by self write by group.exact="cn=groupabcadmin,ou=ABC Customer,dc=core,dc=hdt,dc=hu" write by dn="uid=repuser,dc=core,dc=hdt,dc=hu" read olcAccess: {2}to * by * read --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

Ensure uniqueness over multiple attributes?
by Karsten Heymann 13 Oct '17

13 Oct '17

Hi, does the unique overlay support checking multiple values for a single uniqueness check? Our clients can use emails in two attributes (think mail and mailAlias) and addresses have to be unique in regard to both fields, which means an address that is used in either of them cannot be used in any other of them. Is that possible? +Karsten

3 4

Re: [ldapmodify] multiple entries of the same attibute
by Quanah Gibson-Mount 13 Oct '17

13 Oct '17

--On Friday, October 13, 2017 6:06 PM +0200 richard lucassen <mailinglists(a)lucassen.org> wrote: > How do I tell ldapmodify just to delete 1 particular item with > AttributeValue=X, and not all of them? You do a delete+add, just like Dieter said. What you did in your example was a replace op. I.e., you'd do something like: dn: <whatever> changetype: modify delete: mail mail: my-value - add: mail mail: my-value --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Small tip to speed up large imports with ldapadd
by Quanah Gibson-Mount 13 Oct '17

13 Oct '17

--On Friday, October 13, 2017 5:44 PM +0200 Karsten Heymann <karsten.heymann(a)gmail.com> wrote: > > Hi Quanah, > > > > 2017-10-13 16:15 GMT+02:00 Quanah Gibson-Mount <quanah(a)symas.com>: > > Why not just set dbnosync option as documented in the > slapd-mdb(5)/slapd-bdb(5)/slapd-hdb(5) man pages? > > > > > I tried that as well, and it made the import faster, but at least in my > setup using eatmydata still was a *lot* faster. > > > Another option, which I didn't think about when building my test setup, > would have been to put the data directory into a ram disk during the > import and move it to disk afterwards. > > > Either way, each variant seem quite similiar with regard to what effort > they take, so I'm quite happy with my setup. If you're using back-mdb, you could play with the writemap environment flag as well. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Small tip to speed up large imports with ldapadd
by Karsten Heymann 13 Oct '17

13 Oct '17

Hi Quanah, 2017-10-13 16:15 GMT+02:00 Quanah Gibson-Mount <quanah(a)symas.com>: > > Why not just set dbnosync option as documented in the > slapd-mdb(5)/slapd-bdb(5)/slapd-hdb(5) man pages? > I tried that as well, and it made the import faster, but at least in my setup using eatmydata still was a *lot* faster. Another option, which I didn't think about when building my test setup, would have been to put the data directory into a ram disk during the import and move it to disk afterwards. Either way, each variant seem quite similiar with regard to what effort they take, so I'm quite happy with my setup. BR Karsten

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical