openldap-technical July 2012

openldap-technical@openldap.org

69 participants
71 discussions

replicating accesslog
by Marvin Mundry 18 Jul '12

18 Jul '12

Hello everybody, I am trying to replicate an accesslog database (cn=accesslog) from a provider to 2 consumers. The replication works fine except that old accesslog entries that get removed via "logpurge 07+00:00 01+00:00" on the provider do not get removed from the replicas. over time the accesslog databases on the consumers get rather huge. a workaround seems to be running a script from time to time that identifies and removes old accesslog entries via ldap. deletions in cn=accesslog made via ldap get replicated correctly. is there a way to have the deletions by logpurge replicated as well? bests, Marvin

2 1

ACL syntax for delegating a subdomain to a group
by Brian Riffle 18 Jul '12

18 Jul '12

I am struggling to find documentation on how to use the cn=config syntax for delegating a subdomain to a group of users. In my situation, I have an OU setup for customer accounts. (ou=subdomain,ou=People,dc=example,dc=com). I can currently edit that if I log in as a user that is our admin OU, ou=admins,dc=example,dc=com. However, I don't want to give our front facing support that much access. basically, I want the following: - any user can update their info. - anyone in ou=admin can update anything - anybody in group cn=cust_support,ou=group,dc=example,dc=com can do anything to anyone in the ou=subdomain,ou=People OU. (create/edit/update/delete) However, I am struggling to get the syntax right. I have tried many permutations, and the most recent example was to use these rules for setting olcAccess in the o=config database: {0}to attrs=userPassword by self write by anonymous auth by dn.children="ou=admins,dc=example,dc=com" write by group.exact="cn=cust_support,ou=group,dc=example,dc=com" write by * none {1}to dn.subtree="ou=subdomain,ou=People,dc=example,dc=com" by self write by dn.children="ou=admins,dc=example,dc=com" write by group.exact="cn=cust_support,ou=group,dc=example,dc=com" write by * read {2}to * by self write by dn.children="ou=admins,dc=example,dc=com" write by * read I have tried making cn=cust_support,ou=group,dc=example,dc=com both a posixGroup, and a groupOfNames. Both of them, when I go to save a new users, I get "insufficient access" If anyone could guide me in the correct direction, it would be greatly appreciated.. thanks! Brian

2 1

syncrepl with mirrormode compatible with OpenLDAP version 2.3.43?
by Houston Ray 18 Jul '12

18 Jul '12

I have setup my slapd.conf file with the directives for syncrepl with mirrormode on. This seems to cause issues with any write operations that occur after setup. (syncrepl does work with the provider/consumer setup but so far not with mirrormode) I am now guessing that mirrormode is in fact NOT available in version prior to 2.4 I have searched for an answer, but have yet to find any clear statement saying that it is not supported. thanks in advance to anyone who can confirm or deny that syncrepl with * mirrormode* is or is not supported in version 2.3.43 -h

2 1

Glueing together backend databases - meta, glue or chain?
by Pieter Baele 18 Jul '12

18 Jul '12

Hi, I have several backend databases on my master servers, and need to present a combined view to clients on slaves (Unix authentication) I think this a common question/issue... Scenario: 5 backend DB's, 2 of these are needed on each slave server Each of these has an ou=Groups,ou=Nodes, ou=People etc. --- dc=common,dc=example,dc=org --- dc=shared,dc=example,dc=org --- dc=companyA,dc=example,dc=org --- dc=companyB,dc=example,dc=org --- dc=companyC,dc=example,dc=org So one of the slaves uses companyA, common and shared another one uses companyB, commmon and shared and the last one companyC, common and shared all slaves represent this as "dc=example,dc=org" The easiest way seems using meta backend, but I've the feeling this has drawbacks??? You can't use cn=config, performance? Maybe there is an approach with chain or glue? I can change my DIT if necessary. Sincerely, Pieter

3 5

Re: Glueing together backend databases - meta, glue or chain?
by Francois Gnu 18 Jul '12

18 Jul '12

Hello Aaron, You say that: > One method also worth putting on the table is hosting the single backend > "dc=example,dc=org" on your master and selectively replicating appropriate > portions of the DIT using appropriate filters. (Howard recently posted to > the list on the best practices to execute this.) Can you put the link of the Howard's post, please? Thank you very much. Librement, ------ Francois Trachez (kiko) Team Fedora|Lyon (France) http://stg.fedoraproject.org/fr/ http://stg.fedoraproject.org/es/

2 1

Private E-Mail Address
by chris_news＠arcor.de 18 Jul '12

18 Jul '12

Hi, whereis the best place to store the private e-mail address of an inetOrgPerson? Is the order of the attribute's values fixed? So I could save the business address as first value and the private as second? May the first value be empty? Would an auxiliary class be better? Which one? Thank you in advance. - Chris

2 1

syncrepl and attribute order
by Evgeniy Kosov 18 Jul '12

18 Jul '12

Hi there, First of all, I'm new to this list, so, please, forgive me if this is a wrong place for the questions below, and feel free to redirect me wherever is more appropriate. The issue I'm facing as stated above is regarding the syncrepl and attribute order. I'm writing a Perl module to be used with back_perl and noticed behaviour that seems strange. Making some modifications on the master server (provider) and looking on the relevant modifications on the slave I saw that they didn't quite match. There were some extra REPLACE operations made by syncrepl. Later investigation showed that the cause of those REPLACE's was different attribute order on the master and slave nodes. synrepl.c says that: /* We assume that attributes are saved in the same order * in the remote and local databases. So if we walk through * the attributeDescriptions one by one they should match in * lock step. If not, look for an add or delete. */ Which seems strange to me. As a result syncrepl makes a REPLACE for every attribute whuch is "misplaced" in the local object. This is probably not an issue if master and slave both use the same back-end module. Which is not true in my case. So, the questions are: Is that replacing of "misplaced" attributes by syncrepl is expected behaviour or just a side effect of its syncrepl_diff_entry diff'ing algorithm? Does attribute order matter? Is it specified somehow (sorted by modification time?)? Should this issue be reported as bug? Thank you. -- Regards, Evgeniy Kosov

3 8

More efficient way to represent local+remote views?
by Kartik Subbarao 17 Jul '12

17 Jul '12

I'm currently using the following configuration for an application-specific LDAP directory to present a unified view of its local data (ou=localapp) and remote data (ou=people), all under dc=example,dc=com: database hdb suffix ou=localapp,dc=example,dc=com # ... database meta suffix dc=example,dc=com uri ldapi:///ou=localapp,dc=example,dc=com uri ldap://remoteldap.example.com/ou=people,dc=example,dc=com The idea being that clients of this directory can simply set the base DN to dc=example,dc=com without needing to know which parts are local and which parts are pulled in remotely. My understanding is that this approach incurs some overhead in going through the ldapi interface for each operation that ends up being performed on the local backend. Is it possible to eliminate that overhead through an alternate approach? I looked at back_relay, but couldn't get it to do what I wanted. I don't want to rewrite any of the suffixes -- I just want it to do exactly as above in the back-meta configuration, but replace "ldapi:///" with "internal-backend-api:///", as mentioned in this part of the back-relay docs: "back-relay bypasses the real database frontend operations by short-circuiting operations through the internal backend API". Thanks, -Kartik

2 2

ppolicy and replication issues
by Guillaume Rousse 16 Jul '12

16 Jul '12

Hello list. I'm planning to deploy ppolicy on our directory, but I'm facing a problem with replication, as I only control the master server, and not the slaves configuration for the moment. Despite being only active on the master server, a local experiment told me than the slaves need the following items: - the ppolicy schema, for replicating policies objects - the ppolicy overlay, for replicating operational attributes of user objects The first requisite is quite easy to achieve, as it is just a file I need other admins to add in their configuration. The second is a bit more difficult, as it is an additional binary, and given the lack of consistency between servers, I'm not sure it is available for each installation... So, is there some way of either configuring ppolicy or the replication, to avoid the need for the ppolicy overlay on the slaves, while I don't have full control over all the servers ? -- A system software crash will cause hardware to act strangely and the programmers will blame the customer engineer. -- Murphy's Laws of Computer Programming n°6

2 3

Tutorial to start ldap replication ?
by Frank Bonnet 16 Jul '12

16 Jul '12

Hello All is in the subject ! I need to start a replication server. Actually I run only one server and would like to start another one just in case the main stop/crash. Both machines runs FreeBSD , slapd is installed from FreeBSD ports on both machines, OpenLDAPversion is the same. Thanks for any pointers/links.

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2012