Re: LDAP logging
Dieter Kluenter wrote:
Ivan Ordonez iordo...@berkeley.edu writes:
Edward Capriolo wrote:
On Tue, Jan 26, 2010 at 12:17 PM, Ivan Ordonez iordo...@berkeley.edu
wrote:
Dieter Kluenter wrote:
Ivan Ordonez iordo...@berkeley.edu writes:
Hi,
I want to create logging for LDAP (version 2.4.19-r1) using syslog-ng
on Gentoo box.
Hope someone here can point me in the right direction. I'm lost
here.
slapd logs to local4.
filter f_local4 {facility(local4); };
destination slapd { file(/var/log/slapd); };
log {source(src); filter(f_local4); destination(slapd); };
-Dieter
I still can't get the logging to work. I followed both suggestions
(Dieter
and Jorge) to no avail. The syslog-ng daemon starts fine but when I
check
the ldap log, it's empty. The cron and auth logging is working
perfectly
fine. Please advise.
Thanks in advance.
Check how the package was built.
If the configuration argument
--enable-debug=yes
was not given, you get no logging.
It was logging before without issue. I can see the log in /var/log/messages
file. The
problem started hen I emerge or install the new version of openldap (version
2.4.19-r1).
Since then the LDAP logging disappeared in /var/log/messages file. All I
want to do is to
see where the logs go or have the ability to access it.
As I mentioned in my previous post, slapd logs to local4, check your
syslog-ng.conf wether there are other filters with a facility local4.
-Dieter
And if you're using gentoo, compile openldap with the syslog use flag :-)
Cheers,
Olivier
cn=config config problem
Hi I have setup a multimaster setup and some slave nodes, using cn=config. I am looking at trying to create a user in the cn=config space i have test.ldif that looks like dn: cn=test,cn=config objectClass: simpleSecurityObject objectClass: organizationalRole cn: test userPassword: test description: test structuralObjectClass: organizationalRole and I use ldapadd -D cn=config -w T25src1Rbe65RR6vwd53VTrB1x6EszFGMjhh7m8OOPjNyJ9h7nJO97p00lHMn08m -f test.ldif I get adding new entry cn=test,cn=config ldap_add: Server is unwilling to perform (53) additional info: shadow context; no update referral Which from my investigation tells me my ldap server doesn't know where to send the update, which is strange because I can make other changes to cn=config - add a olcsyncrepl and make changes to loglevel Alex signature.asc Description: Digital signature
Re: cn=config config problem
Alex Samad wrote: Hi I have setup a multimaster setup and some slave nodes, using cn=config. I am looking at trying to create a user in the cn=config space The config database does not support user entries, it only handles config entries. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: cn=config config problem
On Tue, Jan 26, 2010 at 07:23:51PM -0800, Howard Chu wrote:
Alex Samad wrote:
Hi
I have setup a multimaster setup and some slave nodes, using cn=config.
I am looking at trying to create a user in the cn=config space
The config database does not support user entries, it only handles config
entries.
Okay, maybe you can suggest a best practice approach for my setup.
I have 2 master nodes setup in multiple master
and a few (3-4) slave nodes.
In it previous incarnation I used slapd.conf + tls to authorise access,
I mapped x509 dns to a replica dn, so the base was dc=samad,dc=com,dc=au
and the replica dn was cn=replia,ou=roles,dc=samad,dc=com,dc=au
now I want to do the same thing, map x509 certs to roles and give the
roles access to certain parts of cn=config and dc=samad,dc=com,dc=au.
I can understand putting roles in the dc=samad,dc=com,dc=au for
dc=samad,dc=com,dc=au, but I don't really see putting roles in
dc=samad,dc=com,dc=au to manage/access cn=config and I would rather not
be always using the cn=config rootdn/rootpw
should I create a cn=manager db and use that ?
My other question on this setup is replicating dc=samad,dc=com,dc=au,
means replicating olcDatabase={2}hdb,cn=config and below, which means I
also replicate the olcsyncRepl. Should I either block this on the
masters and create it on the consumers or somehow when i create the
initial consumer tell it not to replicate this attribute.
My issue right now is that it has rootdn/rootpw. and I am looking at
moving to tls/certs - re the above question
Alex
signature.asc
Description: Digital signature
