cn=Connection 0,cn=Connections,cn=Monitor?!?
by Michael Ströder
HI!
on one platform on various servers I see strange entries in back-monitor (see
below). It's an installation of RE24 committ-id
22ee28752e3e0d2a6910a22922fc69befd78578a self-compiled on RHEL 6.2 x86_64
linked to BDB, SASL and OpenSSL shipped with RHEL.
We have two custom overlays in this setup but disabling them did not make this
monitor entries disappear.
On my local test system on openSUSE 11.4 x86_64 I don't see this.
Any idea under which condition such monitor entries can appear and where to
look in my configuration?
Ciao, Michael.
--------------------------------- snip ---------------------------------
dn: cn=Connection 0,cn=Connections,cn=Monitor
structuralObjectClass: monitorConnection
creatorsName:
modifiersName:
createTimestamp: 19700101000000Z
modifyTimestamp: 19700101000000Z
monitorConnectionNumber: 0
monitorConnectionProtocol: 0
monitorConnectionOpsReceived: 0
monitorConnectionOpsExecuting: 0
monitorConnectionOpsPending: 0
monitorConnectionOpsCompleted: 0
monitorConnectionGet: 0
monitorConnectionRead: 0
monitorConnectionWrite: 0
monitorConnectionMask: L
monitorConnectionListener:
monitorConnectionPeerDomain: unknown
monitorConnectionPeerAddress: unknown
monitorConnectionLocalAddress:
monitorConnectionStartTime: 19700101000000Z
monitorConnectionActivityTime: 19700101000000Z
entryDN: cn=Connection 0,cn=Connections,cn=Monitor
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE
dn: cn=Connection 0,cn=Connections,cn=Monitor
structuralObjectClass: monitorConnection
creatorsName:
modifiersName:
createTimestamp: 19700101000000Z
modifyTimestamp: 19700101000000Z
monitorConnectionNumber: 0
monitorConnectionProtocol: 0
monitorConnectionOpsReceived: 0
monitorConnectionOpsExecuting: 0
monitorConnectionOpsPending: 0
monitorConnectionOpsCompleted: 0
monitorConnectionGet: 0
monitorConnectionRead: 0
monitorConnectionWrite: 0
monitorConnectionMask: L
monitorConnectionListener:
monitorConnectionPeerDomain: unknown
monitorConnectionPeerAddress: unknown
monitorConnectionLocalAddress:
monitorConnectionStartTime: 19700101000000Z
monitorConnectionActivityTime: 19700101000000Z
entryDN: cn=Connection 0,cn=Connections,cn=Monitor
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE
11 years, 7 months
[pasword Policy Control]How to use it in java
by Jacquot, Pierre
Hello everyone,
I'm new on OpenLdap and I discover it since 2 or 3 month. Actually I'm working on using of password policies, and I encounter some problems when I try to get the password Policy control on my Java Application.
In my case, I use JNDI connection and I make my connection like this :
Control controls[]={new BasicControl("1.3.6.1.4.1.42.2.27.8.5.1")};
ld= new InitialLdapContext(env, controls); // env contains url connection, Credential, password and kind of authentification
javax.naming.ldap.Control[] controls = ld.getResponseControls();
In result of this action, I receive one control object, but I don't know how to use it to obtains the control message associated to my user (account blocked for example or number of grace that I can use etc.).
Do you know a good tutorial that explain how can I use password policies control in my application, or something else like that ?
Thanks for your time spent on my message :)
Cordially
Pierre JACQUOT
Think green - keep it on the screen.
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
11 years, 7 months
making a full replica: slapd -c "rid=xxx" doesn't seem to work
by Jephte CLAIN
hello,
I'm new on this list.
I use OpenLDAP 2.4.23 on debian squeeze
I'm currently testing full replication with the small configuration seed
on the consumer side, but the replication is not complete.
Let me explain in details:
so, the consumer starts with no data at all (I wipe /etc/ldap/slapd.d/*
files, and /var/lib/ldap/*)
Based on the test049, I do 'slapadd -F /etc/ldap/slapd.d -b cn=config -l
initial.ldif' with initial.ldif as:
------------- 8< -------------
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcPidFile: /var/run/slapd/slapd.pid
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcSyncrepl: {0}rid=0 provider="ldap://master.tld/"
searchbase=cn=config
bindmethod=simple binddn=cn=config credentials=password
type=refreshAndPersist retry="60 10 300 +" schemachecking=off
------------- 8< -------------
on the provider side, cn=config is the rootdn of cn=config
so the database cn=config is replicated, except for the above objects.
Indeed, the logs says:
dn_callback : new entry is older than ours cn=config ours
20120127114737.207735Z#000000#000#000000, new
20120127112957.179717Z#000000#000#000000
dn_callback : new entry is older than ours
olcDatabase={0}config,cn=config ours
20120127114737.207985Z#000000#000#000000, new
20120127112953.813862Z#000000#000#000000
and this makes sense. I searched the archives, and found a message from
Howard Chu made on 19 Apr 2011:
------------- 8< -------------
>The problem I now face is that the initial cn=config entries used to do
>the first sync do not get overwritten by the data from the master. So
>the install password doesn't get replaced nor do the updated retry
>timeouts for olcSyncRepl, because, I'm assuming, the 'stub' entries
>have newer timestamps than those on the master.
>
>How can this be overcome from the perspective of the slave server.
>Updating the entries on the master triggers the update as you would
>expect. Is there a way to put the stub entries onto the slave with a
>timestamp in the past so that they get overwritten during the first
>sync? Or is there another way to trigger them to be updated?
Use slapd -c. Read the slapd(8) manpage.
------------- 8< -------------
The manpage says:
------------- 8< -------------
-c cookie
(...) Use only the rid part to force a full reload.
------------- 8< -------------
So I tried '/usr/sbin/slapd -c "rid=0" -d 16384 ...' but I got the
message above about the entry not overwritten because of the timestamp.
I wonder what I am doing wrong...
I'd prefer not to have to use a more recent version, because debian
already does a good job following the patches and keeping the whole
thing stable :-) But If this is a known issue, what are my options?
I mean, my goal is to replicate schemas, indexes, limits, acls and Authz
definitions. I thought that a whole replica would the easiest.
how do you guys do this?
thanks in advance for your inputs. best regards,
Jephté Clain
Direction des Systèmes d'Information
et des Usages Numériques - 2IG
Tél. 0262 93 86 31
Fax. 0262 93 81 06
11 years, 7 months