2:13 a.m.
First of: I know it's old, we ARE going to upgrade at the next service
interval in a few weeks!
But in the meantime, is there any way to know/figure out if the master
and it's slave(s) are in
sync?
One idea, of using a special object which is written to every x minute
and then checked for consistency
came up... Of course it's not a nice solution, but it is A solution...
The reason for this is that yesterday our secondary LDAP server (the
primary read server) stopped
returning queries (might be a file lock or open filehandles problem -
exact reason unknown for the
moment). And for some reason, the primary LDAP server (the one we use
for writes, the sync master)
had an old version of the database - we THINK it happened at the last
power failure in that
serverroom. It brought up an old version (bdb problems possibly).
So the failover to the master worked, but it was to old. And i didn't
manage to do a recover on
the failed bdb database. Luckily we had a SECOND replica in another
city (which was in sync with
the changes we did just a few hours earlier), so I did a dump of that
database and loaded the
primary replica (the one that failed/hung/crashed) with that.
But the fact that the replica master and the slaves where out of sync
worries us a little. This will
be fixed correctly with an upgrade, but until then we would like to
have at least _some_ way of
checking the status of the sync...
Any ideas for a quick hack?
--
... but you know as soon as Oracle starts waving its wallet at a
Company it's time to run - fast.
/illumos mailing list
2:44 a.m.
On 24/5/2012 12:13 μμ, Turbo Fredriksson wrote:
But in the meantime, is there any way to know/figure out if the
master
and it's slave(s) are in
sync?
This was discussed only yesterday!
Supposing you are replicating the full DIT: slapcat both ends, use the
ldifsort utility to sort the outputs, then use diff to check for any
differences.
Nick
4:46 a.m.
On Thu, May 24, 2012 at 12:44:04PM +0300, Nick Milas wrote:
>But in the meantime, is there any way to know/figure out if the
>master and it's slave(s) are in
>sync?
This was discussed only yesterday!
Supposing you are replicating the full DIT: slapcat both ends, use
the ldifsort utility to sort the outputs, then use diff to check for
any differences.
You only ned to do that if you are worried about a replication
protocol failure or a database failure. In normal operation it should
be enough to read the contextCSN attribute from the root of the
replicated subtree on each server:
#!/bin/sh
#
# check-replication
PATH=/usr/local/bin:/usr/bin:/bin
export PATH
for host in ermine.example.org trude.example.org
do
echo $host
ldapsearch -LLL -x -H ldap://$host/ -b 'dc=example,dc=org' -s base
contextCSN
done
If the servers are in sync then the values you see will be identical
on all servers. If any of the values differ you can parse them to work
out how far out-of-date each server is.
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
5:13 a.m.
2012/5/25 Andrew Findlay <andrew.findlay(a)skills-1st.co.uk>:
On Thu, May 24, 2012 at 12:44:04PM +0300, Nick Milas wrote:
> >But in the meantime, is there any way to know/figure out if the
> >master and it's slave(s) are in
> >sync?
>
> This was discussed only yesterday!
>
> Supposing you are replicating the full DIT: slapcat both ends, use
> the ldifsort utility to sort the outputs, then use diff to check for
> any differences.
You only ned to do that if you are worried about a replication
protocol failure or a database failure. In normal operation it should
be enough to read the contextCSN attribute from the root of the
replicated subtree on each server:
#!/bin/sh
#
# check-replication
PATH=/usr/local/bin:/usr/bin:/bin
export PATH
for host in ermine.example.org trude.example.org
do
echo $host
ldapsearch -LLL -x -H ldap://$host/ -b 'dc=example,dc=org' -s base
contextCSN
done
If the servers are in sync then the values you see will be identical
on all servers. If any of the values differ you can parse them to work
out how far out-of-date each server is.
If you are looking for a Nagios script, you can find one here:
http://ltb-project.org/wiki/documentation/nagios-plugins/check_ldap_syncr...
Clément.
3:06 a.m.
On Fri, 25 May 2012 12:46:50 +0100, Andrew Findlay wrote:
In normal operation it should
be enough to read the contextCSN attribute from the root of the
replicated subtree on each server:
Ok, most of the servers are now upgraded, but unfortunatly there's
two that can't (for various reasons) not be upgraded at this time.
The sync seems to work quite nice between the 2.4.23 and the 2.3.43
servers.
However, the contextCSN missmatches and after examining, it's the
password policy object that won't sync...
paragon: 20120616082046.474977
leonis: 20120616082046.474977
leporis: 20120616082046.474977
kelvin: 20120616081559.003550
inbgdxrambo: 20120616081559.003550
The first three is 2.4 (paragon is the provider) and kelvin and
rambo is 2.3...
I've included the ppolicy.schema in all the servers, schemachecking=off
on the consumers but still no policy object...
I do however, now when I look closer, get an error/warning in the log:
Jun 16 15:29:21 rambo slapd[28729]: syncrepl_message_to_entry: rid
444 mods check (pwdAttribute: value #0 invalid per syntax)
Jun 16 15:29:21 rambo slapd[28729]: do_syncrepl: rid 444 retrying
I tried to take ppolicy.schema from paragon (the original one was
version 1.2.2.5 and paragons is 1.7.2.5) but that didn't help.
7:41 a.m.
Turbo Fredriksson wrote:
On Fri, 25 May 2012 12:46:50 +0100, Andrew Findlay wrote:
> In normal operation it should
> be enough to read the contextCSN attribute from the root of the
> replicated subtree on each server:
Ok, most of the servers are now upgraded, but unfortunatly there's
two that can't (for various reasons) not be upgraded at this time.
The sync seems to work quite nice between the 2.4.23 and the 2.3.43
servers.
However, the contextCSN missmatches and after examining, it's the
password policy object that won't sync...
paragon: 20120616082046.474977
leonis: 20120616082046.474977
leporis: 20120616082046.474977
kelvin: 20120616081559.003550
inbgdxrambo: 20120616081559.003550
The first three is 2.4 (paragon is the provider) and kelvin and
rambo is 2.3...
I've included the ppolicy.schema in all the servers, schemachecking=off
on the consumers but still no policy object...
ppolicy.schema only defines the user attributes. The operational attributes
are implemented in the ppolicy overlay. The overlay must be configured on
every server for the operational attributes to be replicated.
I do however, now when I look closer, get an error/warning in the
log:
Jun 16 15:29:21 rambo slapd[28729]: syncrepl_message_to_entry: rid
444 mods check (pwdAttribute: value #0 invalid per syntax)
Jun 16 15:29:21 rambo slapd[28729]: do_syncrepl: rid 444 retrying
I tried to take ppolicy.schema from paragon (the original one was
version 1.2.2.5 and paragons is 1.7.2.5) but that didn't help.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8:04 a.m.
On Sat, 16 Jun 2012 07:41:19 -0700, Howard Chu wrote:
The overlay must be configured on every server for the operational
attributes to be
replicated.
Ah, ok. Thanx. That's a problem then, because CentOS 5.x don't seem to
have that
compiled in...
Ah, well. We're not going to use ppolicy on those servers/sites anyway.
--
... but you know as soon as Oracle starts waving its wallet at a
Company it's time to run - fast.
/illumos mailing list
8:49 a.m.
On Sat, 16 Jun 2012 07:41:19 -0700, Howard Chu wrote:
Turbo Fredriksson wrote:
> paragon: 20120616082046.474977
> kelvin: 20120616081559.003550
The overlay must be
configured on every server for the operational attributes to be
replicated.
After monitoring a colleagues batch modifications, I now see that the
contextCSN now match:
paragon: 20120616153755.474331
kelvin: 20120616153755.474331
This, BESPITE that the actual ppolicy does NOT exist on kelvin!
Isn't this somewhat of a problem? If these values matches, but the
DB doesn't, can contextCSN actually be used for this (monitoring
syncing)?
--
... but you know as soon as Oracle starts waving its wallet at a
Company it's time to run - fast.
/illumos mailing list
10:02 a.m.
On Sat, 16 Jun 2012 17:49:07 +0200, Turbo Fredriksson wrote:
After monitoring a colleagues batch modifications, I now see that
the
contextCSN now match:
paragon: 20120616153755.474331
kelvin: 20120616153755.474331
This, BESPITE that the actual ppolicy does NOT exist on kelvin!
And even worse: Some modifications does not propagate to the slaves!
Sometimes. Running his script again, the changes seems to be there..
--
... but you know as soon as Oracle starts waving its wallet at a
Company it's time to run - fast.
/illumos mailing list
10:27 a.m.
That makes me wonder what his script is doing... Sounds like the script is handling some
part of the replication.
Also:
Cent6.2 has been out for quite a while, with OpenLDAP 2.4.23 binaries. Considered old and
'unsupported' by the OpenLDAP crew, but still working flawlessly in our simple
setup (used for just system auth for ssh, sudo, svn, etc.). We are using ppolicy, but
found the syncing password failures AND having a user's actual password be checked
(making the password failure sync useless) turned out to not be doable (I won't say
possible as I'm open to our configs being off, but haven't heard any
suggestions).
In short, I understand not wanting to compile and support your own binaries, but Cent6.2
is a pretty easy upgrade (opt for sssd vs pam_ldap).
- chris
Chris Jacobs
Systems Administrator, Technology Services Group
Apollo Group | Apollo Marketing & Product Development | Aptimus, Inc.
1501 4th Ave | Suite 2500 | Seattle, WA 98101
direct 206.839.8245 | cell 206.601.3256 | Fax 206.644.0628
email: chris.jacobs(a)apollogrp.edu
----- Original Message -----
From: openldap-technical-bounces(a)OpenLDAP.org
<openldap-technical-bounces(a)OpenLDAP.org>
To: openldap-technical(a)openldap.org <openldap-technical(a)openldap.org>
Sent: Sat Jun 16 10:02:10 2012
Subject: Re: Monitoring 2.3.43?
On Sat, 16 Jun 2012 17:49:07 +0200, Turbo Fredriksson wrote:
After monitoring a colleagues batch modifications, I now see that
the
contextCSN now match:
paragon: 20120616153755.474331
kelvin: 20120616153755.474331
This, BESPITE that the actual ppolicy does NOT exist on kelvin!
And even worse: Some modifications does not propagate to the slaves!
Sometimes. Running his script again, the changes seems to be there..
--
... but you know as soon as Oracle starts waving its wallet at a
Company it's time to run - fast.
/illumos mailing list
This message is private and confidential. If you have received it in error, please notify
the sender and remove it from your system.
10:44 a.m.
On Sat, 16 Jun 2012 10:27:55 -0700, Chris Jacobs wrote:
That makes me wonder what his script is doing... Sounds like the
script is handling some part of the replication.
Nope, nothing fancy. 15-20 lines of bash code. I helped him write it
:).
Just an ldapmodify with some error checking before and after in a loop.
I've since been tuning the syncrepl-* and retry options and can't
duplicate the issue. He's going to do another big batch update
tomorrow, and then I'll be monitoring more closely...
Cent6.2 has been out for quite a while, with OpenLDAP 2.4.23
binaries. Considered old and 'unsupported' by the OpenLDAP crew
Yeah, I mentioned that fact when we were planing the upgrades, but
I never pushed the issue (I'm leaving at the end of the month) because
no one have the knowledge/time to maintain a homebuilt package.
--
... but you know as soon as Oracle starts waving its wallet at a
Company it's time to run - fast.
/illumos mailing list
4127
days inactive
4150
days old
openldap-technical@openldap.org
10 comments
6 participants
participants (6)
-
Andrew Findlay -
Chris Jacobs -
Clément OUDOT -
Howard Chu -
Nick Milas -
Turbo Fredriksson