replicating accesslog
by Marvin Mundry
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
11 years, 2 months
ACL syntax for delegating a subdomain to a group
by Brian Riffle
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
11 years, 2 months
syncrepl with mirrormode compatible with OpenLDAP version 2.3.43?
by Houston Ray
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
11 years, 2 months
Glueing together backend databases - meta, glue or chain?
by Pieter Baele
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
11 years, 2 months
Private E-Mail Address
by chris_news＠arcor.de
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
11 years, 2 months
syncrepl and attribute order
by Evgeniy Kosov
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
11 years, 2 months
More efficient way to represent local+remote views?
by Kartik Subbarao
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
11 years, 2 months
ppolicy and replication issues
by Guillaume Rousse
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
11 years, 2 months
Tutorial to start ldap replication ?
by Frank Bonnet
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.
11 years, 2 months
