openldap-technical August 2013

openldap-technical@openldap.org

70 participants
88 discussions

DB_Config and log files
by jeevan kc 08 Aug '13

08 Aug '13

Hello thereMy DB_CONFIG looks like this set_cachesize 0 716800 0set_lg_bsize 2097512set_lg_dir /usr/local/var/openldap-logsset_flags DB_LOG_AUTOREMOVE Recently , we have few batch processes running in the LDAP server for Datawarehouse groups and other apps and this is causing DB logs to grow . When I do a ls -l the size of the logs are almost 4GB in size. This is causing trouble and we don't want this many logs. How do I limit the log size so that it doesn't exceed lets say 1 GB . These DB logs are of very little importance to us. We periodically do a backup using slapcat and we can use this in case we have a fatal crash .Please throw some light on how to limit these DB logs . Thanks

1 0

group name of a user
by zeya badar 08 Aug '13

08 Aug '13

Hi I am very new to openldap so i need some help on that suppose i created one group and added users as a member but when i am searching a user i am unable to find user's group name? in which attribute we can find user's group name can anyone help me to get group name of a user? Thanks & Regards Zeya Alam Badar

2 1

[OT] is there any theory behind (|) being false?
by Zhang Weiwu 08 Aug '13

08 Aug '13

Quote from RFC 4526: > An 'and' filter with zero elements always evaluates to True. An 'or' > filter with zero elements always evaluates to False. My question is, is there any theory this decision is based on, or is it randomly chosen? Why not (&) being false, and (|) being true? Or more specifically, we know 'FALSE && NULL' is FALSE, we know 'TRUE || NULL' is TRUE, but is there reason 'NULL && NULL' being true and 'NULL || NULL' being false? Thanks:)

2 1

Replicating Schema, olcAccess and olcLimits
by Andrew Devenish-Meares 07 Aug '13

07 Aug '13

Hi List, I'm attempting to set up replication of schema, olcAccess and olcLimits. It appears replicating the schema works, but the olcAccess and olcLimits do not appear to replicate under olcDatabase={2}bdb,cn=config. (Additionally the DIT under dc=une,dc=edu,dc=au is also replicated without issue). The syncprov overlay is in place root@ldap-master-dev [DEV] ~/ldap-config/# ldapsearch -Y EXTERNAL -H ldapi:// -LL -b olcOverlay={0}syncprov,olcDatabase={0}config,cn=config SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 version: 1 dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov The SyncUser has access to read the cn=schema,cn=config and olcDatabase={2}bdb,cn=config branches: root@ldap-master-dev [DEV] ~/ldap-config/# ldapsearch -Y EXTERNAL -H ldapi:// -LL -b olcDatabase={0}config,cn=config olcAccess SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 version: 1 dn: olcDatabase={0}config,cn=config olcAccess: {0}to dn.subtree="cn=schema,cn=config" by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn="cn=SyncUser,dc=une,dc=edu,dc=au" read by * none olcAccess: {1}to dn.subtree="olcDatabase={2}bdb,cn=config" by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn="cn=SyncUser,dc=une,dc=edu,dc=au" read by * none olcAccess: {2}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config On the consumer side, I've added the following two olcSyncRepl enteries to the olcDatabase={2}bdb,cn=config: root@ldap-slave-dev-00 [DEV] ~/ldap-slave-config/# ldapsearch -Y EXTERNAL -H ldapi:/// -LL -b olcDatabase={0}config,cn=config olcSyncRepl SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 version: 1 dn: olcDatabase={0}config,cn=config olcSyncrepl: {0}rid=001 provider=ldap://ldap-master-dev.server.une.edu.au bindmethod=simple binddn="cn=SyncUser,dc=une,dc=edu,dc=au" credentials="PASSWORD" searchbase="cn=schema,cn=config" type=refreshAndPersistinterval=00:00:00:10 retry="5 5 300 5" timeout=1 olcSyncrepl: {1}rid=003 provider=ldap://ldap-master-dev.server.une.edu.au bindmethod=simple binddn="cn=SyncUser,dc=une,dc=edu,dc=au" credentials="PASSWORD" searchbase="olcDatabase={2}bdb,cn=config" attrs="olcDbIndex,olcDbConfig,olcAccess,olcLimits" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 5" timeout=1 I don't follow why this doesn't work. Any suggestions? Thanks -- Andrew Devenish-Meares Solutions Analyst Information Technology University of New England Armidale NSW 2351 e: adevenis(a)une.edu.au p: 02 6773 4098 w: http://une.edu.au/itd

2 3

Replicate translucent ldap
by Zoli Szemelyesen 07 Aug '13

07 Aug '13

Greetings, I have an unusual setup and would like to hear opinions about it. We have an AD in a central office. I have to replicate an ou portion of it once a day to a remote location. (Using the remote AD is technically not an option here and a daily update is sufficient.) I add new attributes locally in a translucent setup. These attributes are used only locally and meddling with the AD is not an option either. Access to this is ok, but I need to have copies of the overlayed ldap. (Reasons: Local redundancy is important to keep SLA with automated systems using ldap and also have another local office nearby with slow/bad connection so a local copy is needed there as well). Reading docs and googling around I couldn't find a good and working solution for the local copies. - Doing dumps and copy them over could work but it's a crappy solution imho. - Replicating the 'AD portion' and the local db separately and doing 'local overlay' on the backup nodes might work but I'd prefer to use an already set up db instead of dynamically rebuild it in multiple locations). - Doing 'classic' replication is not possible afaik. Ideas or experience with similar scenario? Thanks in advance McLoud

1 0

Editing Schema
by Bram Cymet 06 Aug '13

06 Aug '13

Hi, I am wondering the best way to edit a schema after it is loaded. I would like to change the syntax OID for an object type. I have tried using Apache Directory Studio to do this and it just causes OpenLDAP to segfault. Is this possible? How would I do it? Do I need to remove all entries currently referencing the schema? Thanks, -- Bram Cymet Software Developer Canadian Bank Note Co. Ltd. 613-608-9752

2 1

Whenchanged or modifyTimestamp filter
by Sébastien MALHEIRO 06 Aug '13

06 Aug '13

Hi, I want to configure openldap to work as a proxy for Active Directory. I have : A ldap database section to connect to active directory a dbd database to store local ldap A relay database to map Active Directory OU on a local OU This work fine but I have a problem with this type of filter : - ldapsearch -x -D "cn=manager,dc=openldap,dc=priv" -W "(&(objectClass=*)(whenChanged>=20080812000000.0Z))" - ldapsearch -x -D "cn=manager,dc=openldap,dc=priv" -W "(&(objectClass=*)(modifyTimestamp>=20080812000000.0Z))" => I have no result But with this type of filter : ldapsearch -x -D "cn=manager,dc=opencg21,dc=priv" -W "(&(objectClass=*)(uid=MyUsername))" => I can see the whenChanged and modifyTimestamp attributes. Can someone help me? I don't know how to have an error code to see where is the pb Thanks a lot. ---------------------------------------------- here is my slapd.conf -------------------------------------------- # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema include /etc/openldap/schema/microsoft-minimal.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Load dynamic backend modules # - modulepath is architecture dependent value (32/64-bit system) # - back_sql.la overlay requires openldap-server-sql package # - dyngroup.la and dynlist.la cannot be used at the same time # modulepath /usr/lib/openldap # modulepath /usr/lib64/openldap # moduleload accesslog.la # moduleload auditlog.la # moduleload back_sql.la # moduleload chain.la # moduleload collect.la # moduleload constraint.la # moduleload dds.la # moduleload deref.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload memberof.la # moduleload pbind.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la moduleload rwm.la # moduleload seqmod.la # moduleload smbk5pwd.la # moduleload sssvlv.la # moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la moduleload back_ldap moduleload rwm # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by running # /usr/libexec/openldap/generate-server-cert.sh. Your client software may balk # at self-signed certificates, however. TLSCACertificatePath /etc/openldap/certs TLSCertificateFile "\"OpenLDAP Server\"" TLSCertificateKeyFile /etc/openldap/certs/password # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! # enable on-the-fly configuration (cn=config) database config access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none # enable server status monitoring (cn=monitor) database monitor access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.exact="cn=Manager,dc=opencg21,dc=priv" read by * none ############################################################ #LDAP ############################################################ database ldap suffix "OU=MYOU,DC=MYDC,DC=PRIV" uri ldap://mydc.cg21.priv rebind-as-user acl-bind bindmethod=simple binddn="CN=****,DC=PRIV" credentials="***" idassert-bind bindmethod=simple binddn="CN=****,DC=PRIV" credentials="***" mode=none lastmod on idassert-authzFrom * access to * by * read ############################################################ #RELAY ############################################################ database relay suffix "ou=myOU,dc=openldap,dc=priv" relay "ou=myOU,dc=mydc,dc=priv" subordinate overlay rwm rwm-rewriteEngine on rwm-rewriteContext default rwm-rewriteRule "(.+,)?ou=myOU,dc=openldap,dc=priv$" "$1ou=myOU,dc=mydc,dc=priv" ":" rwm-rewriteContext searchEntryDN rwm-rewriteContext searchAttrDN rwm-rewriteRule "(.+,)?dc=openldap,dc=priv$" "$1dc=openldap,dc=priv" ":" rwm-rewriteContext searchFilter rwm-rewriteContext referralAttrDN rwm-rewriteContext referralDN rwm-map attribute uid sAMAccountName rwm-map attribute modifyTimestamp modifyTimestamp #rwm-map objectclass inetOrgPerson * rwm-map objectclass groupOfNames group rwm-normalize-mapped-attrs yes ############################################################# #DATABASE PRINCIPALE ############################################################ database bdb suffix "dc=openldap,dc=priv" checkpoint 1024 15 rootdn "cn=Manager,dc=openldap,dc=priv" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA}qGb9L/sewV24o10bQNynt3Kb2Uyv0Ac8 # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap lastmod on # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub #index samaccountname # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM Ce message (pièces jointes comprises) est protégé par des règles relatives au secret des correspondances ; il peut en outre contenir des informations à caractère confidentiel ; il est établi à destination exclusive de son destinataire. Toute divulgation, utilisation, diffusion ou reproduction (totale ou partielle) de ce message, ou des informations qu'il contient, doit être préalablement autorisée. Tout message électronique est susceptible d'altération et son intégrité ne peut être assurée. Le Conseil Général de la Côte d'Or décline toute responsabilité au titre de ce message, s'il a été modifié ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur de l'erreur de distribution et de la destruction du message. Toute opinion contenue dans ce message appartient à son auteur : pour qu'il engage la responsabilité de l'institution, il doit être confirmé par un écrit et son auteur doit être dûment habilité.

1 0

Re: add rich data into attribute type definition possible?
by Ulrich Windl 06 Aug '13

06 Aug '13

Sorry, the list doesn't set the proper reply-to, so I forgot to send to the list... See attached message

3 2

Difference between ldap searches
by radiatejava 05 Aug '13

05 Aug '13

I am trying to understand the difference between these 2 ldap searches, can anyone explain ? ldapsearch --hostname localhost --baseDN "ou=Groups,dc=example,dc=com" "(objectclass=*)" @groupOfUniqueNames ldapsearch --hostname localhost --baseDN "ou=Groups,dc=example,dc=com" "(objectclass=groupOfUniqueNames)" What do we primarily mean by using @<objectclass> format ? Thanks

4 3

Re: N-Way Master replication no contextcsn
by espeake＠oreillyauto.com 05 Aug '13

05 Aug '13

Okay so I down loaded tar and followed these instructions. http://www.openldap.org/software/release/install.html It says that everything was okay and I received no errors. I restarted the slapd service and it still shows that it is the old version. I guess I'm still missing something. Eric Speake Web Systems Administrator O'Reilly Auto Parts From: Christian Kratzer <ck(a)cksoft.de> To: espeake(a)oreillyauto.com Cc: openldap-technical(a)openldap.org, openldap-technical-bounces(a)OpenLDAP.org Date: 08/02/2013 10:09 AM Subject: Re: N-Way Master replication no contextcsn Hi, On Fri, 2 Aug 2013, espeake(a)oreillyauto.com wrote: > As a noob upgrading appears to easier said than done. I am running on > Ubuntu 10.04 on my master and I have tried to create packages from the code > I downloaded from the web site and the install just doesn't work. So I > found an RPM and and converted it via alien to a deb file and used dpkg to > try and install and even with --force it erred out trying to overwrite the > slapd.d folder. Is there and easy way to build the package as a deb file > so I can install it and also add it to my repo for the other servers. you could try just fetching the official tarball and building and installing from that. also take a backup of you config and your data with: slapcat -n0 -l > config.ldif slapcat -l data.ldif Greetings Christian > > Thanks, > Eric Speake > Web Systems Administrator > O'Reilly Auto Parts > > > > From: Christian Kratzer <ck-lists(a)cksoft.de> > To: espeake(a)oreillyauto.com > Cc: openldap-technical(a)openldap.org > Date: 07/29/2013 10:44 AM > Subject: Re: N-Way Master replication no contextcsn > Sent by: openldap-technical-bounces(a)OpenLDAP.org > > > > Hi, > > On Fri, 26 Jul 2013, espeake(a)oreillyauto.com wrote: > >> >> Trying a different method of replication to suit or need and I set up two >> test servers for n-way master mirroring servers. Both servers have the >> same configuration being fed to them through puppet. In the logs I can > see >> them bind and check cookies but I get CSN too old, ignoring >> 20110608165005.984980Z#000000#000#000000 (olcOverlay= >> {4}syncprov,olcDatabase={1}hdb,cn=config) THen the last slapd entry in > the >> log is rid=002 >> cookie=rid=002,sid=002,csn=20110915141524.047299Z#000000#000#000000 and >> then nothing else happens. If I make a change to user it never syncs to >> the other server. >> >> At this point I don't know what to look at or what you might want to look >> at to help diagnose the problem. I followed the documentation in the > admin >> guide to set this up. >> >> Any and all help is appreciated. > > 1. You are using an ancient openldap version 2.4.28 compiled by your > distribution. Please start by updating to a current 2.4.35 build from > sources. > > 2. You say both servers have the same configuration through puppet ? I see > you are using cn=config. How are you distributing this configuration. You > should not write any files to slapd.d via puppet or other means. Use > slapcat/slapadd -n0 to export and import configurations. > > Greetings > Christian > > -- > Christian Kratzer CK Software GmbH > Email: ck(a)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 > Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer > > > -- > This message has been scanned for viruses and dangerous content, > and is believed to be clean. > Message id: 07A406006FB.AF9AA > > > > > This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS ? 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you. > -- Christian Kratzer CK Software GmbH Email: ck(a)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 Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer -- This message has been scanned for viruses and dangerous content, and is believed to be clean. Message id: C01E4600DDE.A423A This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.

2 2

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical August 2013