From: steven.bambling@sunrocket.com Subject: Issue with changes using updateref Date: April 9, 2007 6:57:43 PM EDT To: openldap-software@openldap.org
All,
I've been racking my brain for a while googling and reading like mad. I've come to a wall. I have 2 OpenLdap servers setup 1 as a master and the other as a slave.
This are now working about 50%. When I make a change on the master is is replicated down to the slave without a problem. Yet when I make a change on the slave it doesn't seem to carry back up to the master.
I've tried changing the userpassword manually through a ldap browser and get this effect
On the Master server I have the following configuration
replica host=jupiter2.company.com:389 suffix="dc=sunrocket,dc=com" binddn="cn=copycat2,dc=company,dc=com" credentials=deargod2 bindmethod=simple tls=yes
On the Slave Server I have
####################################################################### # BDB database definitions #######################################################################
database bdb checkpoint 1024 5 cachesize 1000000 suffix "dc=sunrocket,dc=com" rootdn "cn=copycat2,dc=sunrocket,dc=com" # Slave data updatedn "cn=copycat2,dc=sunrocket,dc=com"
# Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw "deargod2"
Any suggestions to point me in the correct direction?
Thanks, STEVE
--On Monday, April 09, 2007 8:09 PM -0400 Steven Bambling steven.bambling@sunrocket.com wrote:
From: steven.bambling@sunrocket.com Subject: Issue with changes using updateref Date: April 9, 2007 6:57:43 PM EDT To: openldap-software@openldap.org
All,
I've been racking my brain for a while googling and reading like mad. I've come to a wall. I have 2 OpenLdap servers setup 1 as a master and the other as a slave.
This are now working about 50%. When I make a change on the master is is replicated down to the slave without a problem. Yet when I make a change on the slave it doesn't seem to carry back up to the master.
You do understand that the idea of replication is that only masters take modifications? That's why one is a "master" and one is a "replica". You don't make changes to the replicas and expect them to show up on the master. Now, you can do things like setup back-chain to *forward* modification requests to the replica up to the master, so things work right...
--Quanah
-- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
Yes I understand the concept of replication. My understanding is the updateref line should point the client to make changes on the master server. The original post that was denied told of the setup in further detail. When changing the password via smbpasswd it doesn't seem to refer samba to make changes to the master server.
Thanks, STEVE
On Apr 9, 2007, at 8:54 PM, Quanah Gibson-Mount wrote:
--On Monday, April 09, 2007 8:09 PM -0400 Steven Bambling steven.bambling@sunrocket.com wrote:
From: steven.bambling@sunrocket.com Subject: Issue with changes using updateref Date: April 9, 2007 6:57:43 PM EDT To: openldap-software@openldap.org
All,
I've been racking my brain for a while googling and reading like mad. I've come to a wall. I have 2 OpenLdap servers setup 1 as a master and the other as a slave.
This are now working about 50%. When I make a change on the master is is replicated down to the slave without a problem. Yet when I make a change on the slave it doesn't seem to carry back up to the master.
You do understand that the idea of replication is that only masters take modifications? That's why one is a "master" and one is a "replica". You don't make changes to the replicas and expect them to show up on the master. Now, you can do things like setup back- chain to *forward* modification requests to the replica up to the master, so things work right...
--Quanah
-- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
--On Monday, April 09, 2007 9:01 PM -0400 Steven Bambling steven.bambling@sunrocket.com wrote:
Yes I understand the concept of replication. My understanding is the updateref line should point the client to make changes on the master server. The original post that was denied told of the setup in further detail. When changing the password via smbpasswd it doesn't seem to refer samba to make changes to the master server.
Well, if your replica is actually taking changes, then it is misconfigured. In any case, 99% of clients out there don't actually understand referrals. That's why I'd suggest using back-chain. In any case, I'll note you are also using the deprecated "slurpd" method of replication, which is going away (will not be present in OpenLDAP 2.4). It is recommended to use "syncrepl" in OpenLDAP 2.3.
--Quanah
-- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
--On Monday, April 09, 2007 6:06 PM -0700 Quanah Gibson-Mount quanah@stanford.edu wrote:
--On Monday, April 09, 2007 9:01 PM -0400 Steven Bambling steven.bambling@sunrocket.com wrote:
Yes I understand the concept of replication. My understanding is the updateref line should point the client to make changes on the master server. The original post that was denied told of the setup in further detail. When changing the password via smbpasswd it doesn't seem to refer samba to make changes to the master server.
Well, if your replica is actually taking changes, then it is misconfigured. In any case, 99% of clients out there don't actually understand referrals. That's why I'd suggest using back-chain. In any
Err, slapo-chain, not back-chain.
--Quanah
-- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
On Tuesday 10 April 2007, Steven Bambling wrote:
From: steven.bambling@sunrocket.com Subject: Issue with changes using updateref Date: April 9, 2007 6:57:43 PM EDT To: openldap-software@openldap.org
All,
I've been racking my brain for a while googling and reading like mad. I've come to a wall. I have 2 OpenLdap servers setup 1 as a master and the other as a slave.
This are now working about 50%. When I make a change on the master is is replicated down to the slave without a problem. Yet when I make a change on the slave it doesn't seem to carry back up to the master.
So what you mean here is that: -the ldap client is not chasing a referral to the master -which could be because it is not being provided with an update referral
I've tried changing the userpassword manually through a ldap browser and get this effect
On the Master server I have the following configuration
replica host=jupiter2.company.com:389 suffix="dc=sunrocket,dc=com" binddn="cn=copycat2,dc=company,dc=com" credentials=deargod2 bindmethod=simple tls=yes
On the Slave Server I have
####################################################################### # BDB database definitions #######################################################################
database bdb checkpoint 1024 5 cachesize 1000000 suffix "dc=sunrocket,dc=com" rootdn "cn=copycat2,dc=sunrocket,dc=com" # Slave data updatedn "cn=copycat2,dc=sunrocket,dc=com"
It is not recommended to re-use the slave's rootdn as updatedn (rather add a one-line ACL providing write access to the updatedn), as you may have some weird effects ...
# Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw "deargod2"
Where is the updateref entry ?
Regards, Buchan
This is a re-transmission of a message I sent yesterday, but seems did not get through.
I am sure having a tough time sorting out what, I think, are truly basic and fundamental isses!
I just want to create an ldap database which will house a uniqueIdentifier for a user, and an associated userPassword. I simply want to authenticate users (not system users, as in /etc/passwd) with their password. I cannot get the database configured so slapd will even come up.
Here is my database configuration, which I have simply appended to the default slapd.conf file that normally resides in /etc/openldap on my linux machine:
database bdb
suffix "dn=clearerDB"
rootdn "cn=clearerDBmgr, dn=clearerDB"
rootpw myPassword
directory /var/ldapDBs/clearerDB
index objectClass eq
index uniqueIdentifier eq
index userPassword eq
# Other attributes used in this database:
# displayName
# businessCategory
Actually, I have this full config file in my root's directory (I am logged in as root). So when I run this command
/usr/lib/openldap/slapd -f /root/slapd.conf
slapd fails to come up. When I comment out my additional database configuration text, it does come up okay.
BYW, the database directory does already exist; i.e., I have created those directories prior to attempting to bring up slapd.
So ... I have these questions:
1) What am I doing wrong?
2) What will cause the password for a specific uniqueIdentifier to be associated with one another?
3) Surely, slapd is reporting out to some log a record of what he is doing when he comes up, or attempts to come up. What log file? Where?
Thanks for your time and help.
----------------------------------------- The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer.
There's not enough information (i.e. the whole slapd.conf) here to tell for sure, but my crystal ball guess would be that your previous slapd.conf has a context that conflicts with this new "appended" context.
Try slaptest -d config (sounds like -d config -f /root/slapd.conf in your case?) to get a better idea of what's going on.
Crystal ball guesses can be bad; include a full sanitized slapd.conf if you're going to follow up.
On Tue, 10 Apr 2007, Marcum, Bob wrote:
This is a re-transmission of a message I sent yesterday, but seems did not get through.
I am sure having a tough time sorting out what, I think, are truly basic and fundamental isses!
I just want to create an ldap database which will house a uniqueIdentifier for a user, and an associated userPassword. I simply want to authenticate users (not system users, as in /etc/passwd) with their password. I cannot get the database configured so slapd will even come up.
Here is my database configuration, which I have simply appended to the default slapd.conf file that normally resides in /etc/openldap on my linux machine:
database bdb
suffix "dn=clearerDB"
rootdn "cn=clearerDBmgr, dn=clearerDB"
rootpw myPassword
directory /var/ldapDBs/clearerDB
index objectClass eq
index uniqueIdentifier eq
index userPassword eq
# Other attributes used in this database:
# displayName
# businessCategory
Actually, I have this full config file in my root's directory (I am logged in as root). So when I run this command
/usr/lib/openldap/slapd -f /root/slapd.conf
slapd fails to come up. When I comment out my additional database configuration text, it does come up okay.
BYW, the database directory does already exist; i.e., I have created those directories prior to attempting to bring up slapd.
So ... I have these questions:
What am I doing wrong?
What will cause the password for a specific
uniqueIdentifier to be associated with one another?
Surely, slapd is reporting out to some log a record
of what he is doing when he comes up, or attempts to come up. What log file? Where?
Thanks for your time and help.
The information in this message may be proprietary and/or
confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer.
Aaron,
You comments were a great help ... steering me to slaptest, firstly. I have solved my [this one] problem. The problem was a syntax error in the suffix line (found by slaptest). I have changed that line to "dc=muckydomain, dc=com" and it likes that okay. Thanks for taking the time to respond.
-----Original Message----- From: Aaron Richton [mailto:richton@nbcs.rutgers.edu] Sent: Tuesday, April 10, 2007 11:40 AM To: Marcum, Bob Cc: openldap-software@openldap.org Subject: Re: database configuration questions
There's not enough information (i.e. the whole slapd.conf) here to tell for sure, but my crystal ball guess would be that your previous slapd.conf has a context that conflicts with this new "appended" context.
Try slaptest -d config (sounds like -d config -f /root/slapd.conf in your case?) to get a better idea of what's going on.
Crystal ball guesses can be bad; include a full sanitized slapd.conf if you're going to follow up.
On Tue, 10 Apr 2007, Marcum, Bob wrote:
This is a re-transmission of a message I sent yesterday, but seems did not get through.
I am sure having a tough time sorting out what, I think, are truly
basic
and fundamental isses!
I just want to create an ldap database which will house a uniqueIdentifier for a user, and an associated userPassword. I simply want to authenticate users (not system users, as in /etc/passwd) with their password. I cannot get the database configured so slapd will
even
come up.
Here is my database configuration, which I have simply appended to the default slapd.conf file that normally resides in /etc/openldap on my linux machine:
database bdb
suffix "dn=clearerDB"
rootdn "cn=clearerDBmgr, dn=clearerDB"
rootpw myPassword
directory /var/ldapDBs/clearerDB
index objectClass eq
index uniqueIdentifier eq
index userPassword eq
# Other attributes used in this database:
# displayName
# businessCategory
Actually, I have this full config file in my root's directory (I am logged in as root). So when I run this command
/usr/lib/openldap/slapd -f /root/slapd.conf
slapd fails to come up. When I comment out my additional database configuration text, it does come up okay.
BYW, the database directory does already exist; i.e., I have created those directories prior to attempting to bring up slapd.
So ... I have these questions:
What am I doing wrong?
What will cause the password for a specific
uniqueIdentifier to be associated with one another?
Surely, slapd is reporting out to some log a
record
of what he is doing when he comes up, or attempts to come up. What
log
file? Where?
Thanks for your time and help.
The information in this message may be proprietary and/or
confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer.
openldap-software@openldap.org