I'm currently using ppolicy in a replicated 2.3.30 environment. Most things wrt ppolicy work extremely well but I'm having issues with slurpd and ppolicy's internal attributes.
Due to firewall restrictions I'm currently forced to use both syncrepl and slurpd for replication. Problem with slurpd is, that when a user changes her password the pwdHistory attribute gets replicated with an add/delete MOD. All attributes get replicated OK but I still get errors both on the master and on the slave.
the master complains in .rej file with ERROR: No such attribute: modify/delete: pwdHistory: no such value
the slave logs the following to syslog: Jan 12 11:09:58 slave slapd[11335]: conn=1 op=10 MOD dn="cn=ststm,ou=people,dc=example.com" Jan 12 11:09:58 slave slapd[11335]: conn=1 op=10 MOD attr=userPassword pwdChangedTime pwdHistory pwdHistory entryCSN modifiersName modifyTimestamp Jan 12 11:09:58 slave slapd[11335]: conn=2 op=10 MOD dn="cn=ststm,ou=people,dc=example.com" Jan 12 11:09:58 slave slapd[11335]: conn=2 op=10 MOD attr=userPassword pwdChangedTime pwdHistory pwdHistory entryCSN modifiersName modifyTimestamp Jan 12 11:09:58 slave slapd[11335]: conn=2 op=10 RESULT tag=103 err=16 text=modify/delete: pwdHistory: no such value Jan 12 11:09:58 slave slapd[11335]: conn=1 op=10 RESULT tag=103 err=0 text=
To me this looks like the ppolicy overlay and slurpd are both trying to update the pwdHistory attribute at the same time but ppolicy kicks in faster and thus slurpd cannot see the old value and fails.
My issue now is, that even though replication works OK (after replication all attrs are identical on master and slave, pwdHistiory is in sync) the logs are full of errors and the .rej is filling up.
I'aware that the restriction of not being able to define what exactly gets replicated with slurpd is one of the reasons to phase it out, but maybe someone has already come up with a solution. Using 2.4 is also not an option (for now).
-- mike
On Fri, January 12, 2007 11:03 am, Michael Steinmann wrote:
[snip]
To me this looks like the ppolicy overlay and slurpd are both trying to update the pwdHistory attribute at the same time but ppolicy kicks in faster and thus slurpd cannot see the old value and fails.
after patching slurpd to not replicate pwdHistory I ran into the same problem with the accessTo attribute. Both pwdHistory and accessTo are multivalued which led me down another route and I found ITS#3228 which corresponds to what I'm doing (using slurpd with multiple replication agreements to the same slave). Closer analysis of the slave's logs revealed that *two* replications actually took place for every change on the master (as described in above bug).
I've reverted to replicate the subordinate database only and now replication works as expected without errors.
-- mike
On Thursday 18 January 2007 12:43, Michael Steinmann wrote:
On Fri, January 12, 2007 11:03 am, Michael Steinmann wrote:
[snip]
To me this looks like the ppolicy overlay and slurpd are both trying to update the pwdHistory attribute at the same time but ppolicy kicks in faster and thus slurpd cannot see the old value and fails.
after patching slurpd to not replicate pwdHistory I ran into the same problem with the accessTo attribute. Both pwdHistory and accessTo are multivalued which led me down another route and I found ITS#3228 which corresponds to what I'm doing (using slurpd with multiple replication agreements to the same slave).
It would have helped if you had mentioned this ...
Closer analysis of the slave's logs revealed that *two* replications actually took place for every change on the master (as described in above bug).
I've reverted to replicate the subordinate database only and now replication works as expected without errors.
You can still replicate multiple databases, but you must use the workaround where the replica name is unique (by mixing case etc.).
Regards, Buchan
Buchan Milne wrote:
On Thursday 18 January 2007 12:43, Michael Steinmann wrote:
On Fri, January 12, 2007 11:03 am, Michael Steinmann wrote:
[snip]
To me this looks like the ppolicy overlay and slurpd are both trying to update the pwdHistory attribute at the same time but ppolicy kicks in faster and thus slurpd cannot see the old value and fails.
after patching slurpd to not replicate pwdHistory I ran into the same problem with the accessTo attribute. Both pwdHistory and accessTo are multivalued which led me down another route and I found ITS#3228 which corresponds to what I'm doing (using slurpd with multiple replication agreements to the same slave).
It would have helped if you had mentioned this ...
...if only I had known that this was the source of the problem ;-) Completely agree here. I should have provided more data in the first place.
Closer analysis of the slave's logs revealed that *two* replications actually took place for every change on the master (as described in above bug).
I've reverted to replicate the subordinate database only and now replication works as expected without errors.
You can still replicate multiple databases, but you must use the workaround where the replica name is unique (by mixing case etc.).
Regards, Buchan
great tip with the mixed-case hostname, thanks! We're using starttls where other changes to the hostname / IP would not have worked because of slapd's strict certificate requirements.
-- mike
Michael Steinmann said the following on 12/01/07 10:03:
I'm currently using ppolicy in a replicated 2.3.30 environment. Most things wrt ppolicy work extremely well but I'm having issues with slurpd and ppolicy's internal attributes.
Due to firewall restrictions I'm currently forced to use both syncrepl and slurpd for replication. Problem with slurpd is, that when a user changes her password the pwdHistory attribute gets replicated with an add/delete MOD. All attributes get replicated OK but I still get errors both on the master and on the slave.
Have you tried using Syncrepl RefreshOnly to help with firewall issues?
On Thu, January 18, 2007 12:53 pm, Gavin Henry wrote:
Michael Steinmann said the following on 12/01/07 10:03:
I'm currently using ppolicy in a replicated 2.3.30 environment. Most things wrt ppolicy work extremely well but I'm having issues with slurpd and ppolicy's internal attributes.
Due to firewall restrictions I'm currently forced to use both syncrepl and slurpd for replication. Problem with slurpd is, that when a user changes her password the pwdHistory attribute gets replicated with an add/delete MOD. All attributes get replicated OK but I still get errors both on the master and on the slave.
Have you tried using Syncrepl RefreshOnly to help with firewall issues?
Gavin
yes, but according to [1] and other sources the current implementation of refreshAndPersist is not a pure push solution. It's still the slave that initiates the connection. To me it looked as I'd have to wait for 2.4.
Correct me if I'm wrong as I might misinterpret the docs, however. Have you tested this and confirmed it works?
-- mike
[1] http://www.openldap.org/lists/openldap-software/200609/msg00081.html
<quote who="Michael Steinmann">
On Thu, January 18, 2007 12:53 pm, Gavin Henry wrote:
Michael Steinmann said the following on 12/01/07 10:03:
I'm currently using ppolicy in a replicated 2.3.30 environment. Most things wrt ppolicy work extremely well but I'm having issues with slurpd and ppolicy's internal attributes.
Due to firewall restrictions I'm currently forced to use both syncrepl and slurpd for replication. Problem with slurpd is, that when a user changes her password the pwdHistory attribute gets replicated with an add/delete MOD. All attributes get replicated OK but I still get errors both on the master and on the slave.
Have you tried using Syncrepl RefreshOnly to help with firewall issues?
Gavin
yes, but according to [1] and other sources the current implementation of refreshAndPersist is not a pure push solution. It's still the slave that initiates the connection. To me it looked as I'd have to wait for 2.4.
Correct me if I'm wrong as I might misinterpret the docs, however. Have you tested this and confirmed it works?
No, you are right. I misunderstood your requirement for a push based solution.
My apologies.
Out of interest, what are your firewall configurations like? Maybe we are missing some detail?
Thanks.
-- mike
[1] http://www.openldap.org/lists/openldap-software/200609/msg00081.html
Gavin Henry wrote:
yes, but according to [1] and other sources the current implementation of refreshAndPersist is not a pure push solution. It's still the slave that initiates the connection. To me it looked as I'd have to wait for 2.4.
Correct me if I'm wrong as I might misinterpret the docs, however. Have you tested this and confirmed it works?
No, you are right. I misunderstood your requirement for a push based solution.
I need to check, but what 2.4 does is provide a facility for push-like sync-replication; however, the latest 2.3 should allow to proxy syncrepl by means of a regular proxy. Namely, what test045 does should be possible with 2.3 as well, at the cost of an extra instance of slapd for proxying, while what test048 does requires something specific to 2.4.
Again: this needs to be checked, since 2.3 might still miss some details.
p.
Pierangelo Masarati wrote:
Gavin Henry wrote:
yes, but according to [1] and other sources the current implementation of refreshAndPersist is not a pure push solution. It's still the slave that initiates the connection. To me it looked as I'd have to wait for 2.4.
Correct me if I'm wrong as I might misinterpret the docs, however. Have you tested this and confirmed it works?
No, you are right. I misunderstood your requirement for a push based solution.
I need to check, but what 2.4 does is provide a facility for push-like sync-replication; however, the latest 2.3 should allow to proxy syncrepl by means of a regular proxy. Namely, what test045 does should be possible with 2.3 as well, at the cost of an extra instance of slapd for proxying, while what test048 does requires something specific to 2.4.
Again: this needs to be checked, since 2.3 might still miss some details.
p.
thanks for the insights.
What we're currently replicating to the slaves is not vital for the operation of the customer-facing services so I think we'd prefer not to add to the complexity more than what's required. Even though we're using virtualized hosts and adding one or two wouldn't be such a big deal.
We've settled with using slurpd until the next upgrade round. But thanks anyways for the pointers, I'll check those tests out regardless.
-- mike
Pierangelo Masarati wrote:
Gavin Henry wrote:
yes, but according to [1] and other sources the current implementation of refreshAndPersist is not a pure push solution. It's still the slave that initiates the connection. To me it looked as I'd have to wait for 2.4.
Correct me if I'm wrong as I might misinterpret the docs, however. Have you tested this and confirmed it works?
No, you are right. I misunderstood your requirement for a push based solution.
I need to check, but what 2.4 does is provide a facility for push-like sync-replication; however, the latest 2.3 should allow to proxy syncrepl by means of a regular proxy. Namely, what test045 does should be possible with 2.3 as well, at the cost of an extra instance of slapd for proxying, while what test048 does requires something specific to 2.4.
Again: this needs to be checked, since 2.3 might still miss some details.
It should work fine in 2.3, with the constraints you listed.
Gavin Henry wrote:
<quote who="Michael Steinmann">
On Thu, January 18, 2007 12:53 pm, Gavin Henry wrote:
Michael Steinmann said the following on 12/01/07 10:03:
I'm currently using ppolicy in a replicated 2.3.30 environment. Most things wrt ppolicy work extremely well but I'm having issues with slurpd and ppolicy's internal attributes.
Due to firewall restrictions I'm currently forced to use both syncrepl and slurpd for replication. Problem with slurpd is, that when a user changes her password the pwdHistory attribute gets replicated with an add/delete MOD. All attributes get replicated OK but I still get errors both on the master and on the slave.
Have you tried using Syncrepl RefreshOnly to help with firewall issues?
Gavin
yes, but according to [1] and other sources the current implementation of refreshAndPersist is not a pure push solution. It's still the slave that initiates the connection. To me it looked as I'd have to wait for 2.4.
Correct me if I'm wrong as I might misinterpret the docs, however. Have you tested this and confirmed it works?
No, you are right. I misunderstood your requirement for a push based solution.
My apologies.
no problem. After reading the description I myself was under the impression that I could do syncrepl in both directions (firewall-wise).
Out of interest, what are your firewall configurations like? Maybe we are missing some detail?
The master is in an internal net, the slave is in a DMZ (tcp/389, starttls, iptables fw, only outbound connections, nothing special). 'Business' rule is: all connections must be initiated from the inside to the DMZs, no incoming new connections from a DMZ to an internal net.
We're replicating part of the tree from the master to the 'primary' slave in the DMZ. There's a second slave in the DMZ that does syncrepl with the primary slave. The slaves do authentication for web/app servers.
-- mike
<quote who="Michael Steinmann">
Gavin Henry wrote:
<quote who="Michael Steinmann">
On Thu, January 18, 2007 12:53 pm, Gavin Henry wrote:
Michael Steinmann said the following on 12/01/07 10:03:
I'm currently using ppolicy in a replicated 2.3.30 environment. Most things wrt ppolicy work extremely well but I'm having issues with slurpd and ppolicy's internal attributes.
Due to firewall restrictions I'm currently forced to use both syncrepl and slurpd for replication. Problem with slurpd is, that when a user changes her password the pwdHistory attribute gets replicated with an add/delete MOD. All attributes get replicated OK but I still get errors both on the master and on the slave.
Have you tried using Syncrepl RefreshOnly to help with firewall issues?
Gavin
yes, but according to [1] and other sources the current implementation of refreshAndPersist is not a pure push solution. It's still the slave that initiates the connection. To me it looked as I'd have to wait for 2.4.
Correct me if I'm wrong as I might misinterpret the docs, however. Have you tested this and confirmed it works?
No, you are right. I misunderstood your requirement for a push based solution.
My apologies.
no problem. After reading the description I myself was under the impression that I could do syncrepl in both directions (firewall-wise).
I think we are both wrong now:
http://www.openldap.org/lists/openldap-software/200701/msg00176.html http://www.openldap.org/lists/openldap-software/200701/msg00181.html
Out of interest, what are your firewall configurations like? Maybe we are missing some detail?
The master is in an internal net, the slave is in a DMZ (tcp/389, starttls, iptables fw, only outbound connections, nothing special). 'Business' rule is: all connections must be initiated from the inside to the DMZs, no incoming new connections from a DMZ to an internal net.
Understood. If the worst came to worse, you could only allow IPSEC tunnels in and out, cert based etc. Then your firewall only lets NEW IPSEC connections out. That should be still secure.
We're replicating part of the tree from the master to the 'primary' slave in the DMZ. There's a second slave in the DMZ that does syncrepl with the primary slave. The slaves do authentication for web/app servers.
The primary slave being the slurpd pushed to one?
-- mike
openldap-software@openldap.org
-
Buchan Milne -
Gavin Henry -
Howard Chu -
Michael Steinmann -
Pierangelo Masarati