contextCSN of subordinate syncrepl DBs
by Rein Tollevik
I've been trying to figure out why syncrepl used on a backend that is
subordinate to a glue database with the syncprov overlay should save the
contextCSN in the suffix of the glue database rather than the suffix of
the backend where syncrepl is used. But all I come up with are reasons
why this should not be the case. So, unless anyone can enlighten me as
to what I'm missing, I suggest that this be changed.
The problem with the current design is that it makes it impossible to
reliably replicate more than one subordinate db from the same remote
server, as there are now race conditions where one of the subordinate
backends could save an updated contextCSN value that is picked up by the
other before it has finished its synchronization. An example of a
configuration where more than one subordinate db replicated from the
same server might be necessary is the central master described in my
previous posting in
http://www.openldap.org/lists/openldap-devel/200806/msg00041.html
My idea as to how this race condition could be verified was to add
enough entries to one of the backends (while the consumer was stopped)
to make it possible to restart the consumer after the first backend had
saved the updated contextCSN but before the second has finished its
synchronization. But I was able to produce it by simply add or delete
of an entry in one of the backends before starting the consumer. Far to
often was the backend without any changes able to pick up and save the
updated contextCSN from the producer before syncrepl on the second
backend fetched its initial value. I.e it started with an updated
contextCSN and didn't receive the changes that had taken place on the
producer. If syncrepl stored the values in the suffix of their own
database then they wouldn't interfere with each other like this.
There is a similar problem in syncprov, as it must use the lowest
contextCSN value (with a given sid) saved by the syncrepl backends
configured within the subtree where syncprov is used. But to do that it
also needs to distinguish the contextCSN values of each syncrepl
backend, which it can't do when they all save them in the glue suffix.
This also implies that syncprov must ignore contextCSN updates from
syncrepl until all syncrepl backends has saved a value, and that
syncprov on the provider must send newCookie sync info messages when it
updates its contextCSN value when the changed entry isn't being
replicated to a consumer. I.e as outlined in the message referred to above.
Neither of these changes should interfere with ordinary multi-master
configurations where syncrepl and syncprov are both use on the same
(glue) database.
I'll volunteer to implement and test the necessary changes if this is
the right solution. But to know whether my analysis is correct or not I
need feedback. So, comments please?
--
Rein Tollevik
Basefarm AS
13 years, 6 months
contextCSN interaction between syncrepl and syncprov
by Rein Tollevik
The remaining errors and race condition that test058 demonstrates cannot
be solved unless syncrepl is changed to always store the contextCSN in
the suffix of the database where it is configured, not the suffix of its
glue database as it does today.
Assuming serverID 0 is reserved for the single master case, syncrepl and
syncprov can in that case only be configured within the same database
context if syncprov is a pure forwarding server I.e, it will not update
any CSN value and syncrepl have no need to fetch any values from it.
In the multi-master case it is only the contextCSN whose SID matches the
current serverID that syncprov maintains, the other are all received by
syncrepl. So, the only time syncrepl should need an updated CSN from
syncprov is when it is about to present it to its peer, i.e when it
initiates a refresh phase. Actually, a race condition that would render
the state of the database undetermined could occur if syncrepl fetches
an updated CSN from syncprov during the initial refresh phase. So, it
should be sufficient to read the contextCSN values from the database
before a new refresh phase is initiated, independent of whether syncprov
is in use or not.
Syncrepl will receive updates to the contextCSN value with its own SID
from its peers, at least with ITS#5972 and ITS#5973 in place. I.e, the
normal ignoring of updates tagged with a too old contextCSN value will
continue to work. It should also be safe to ignore all updates tagged
with a contextCSN or entryCSN value whose SID is the current servers
non-zero serverID, provided a complete refresh cycle is known to have
taken place. I.e, when a contextCSN value with the current non-zero
serverID was read from the database before the refresh phase started, or
after the persistent phase have been entered.
The state of the database will be undetermined unless an initial refresh
(i.e starting from an empty database or CSN set) have been run to
completion. I cannot see how this can be avoided, and as far as I know
it is so now too. It might be worth mentioning in the doc. though
(unless it already is).
Syncprov must continue to monitor the contextCSN updates from syncrepl.
When it receives updates destined for the suffix of the database it
itself is configured it must replace any CSN value whose SID matches its
own non-zero serverID with the value it manages itself (which should be
greater or equal to the value syncrepl tried to store unless something
is seriously wrong). Updates to "foreign" contextCSN values (i.e those
with a SID not matching the current non-zero serverID) should be
imported into the set of contextCSN values syncprov itself maintain.
Syncprov could also short-circuit the contextCSN update and delay it to
its own checkpoint. I'm not sure what effect the checkpoint feature
have today when syncrepl constantly updates the contextCSN..
Syncprov must, when syncrepl updates the contextCSN in the suffix of a
subordinate DB, update its own knowledge of the "foreign" CSNs to be the
*lowest* CSN with any given SID stored in all the subordinate DBs (where
syncrepl is configured). And no update must take place unless a
contextCSN value have been stored in *all* the syncrepl-enabled
subordinate DBs. Any values matching the current non-zero serverID
should be updated in this case too, but a new value should probably not
be inserted.
These changes should (unless I'm completely lost that is..) create a
cleaner interface between syncrepl and syncprov without harming the
current multi-master configurations, and make asymmetric multiple
masters configurations like the one in test058 work. Comments please?
Rein
13 years, 6 months
NUMA-aware tcmalloc
by Howard Chu
For those of you running multi-socket Opteron servers (and eventually,
multi-socket Nehalem servers), AMD published a whitepaper last week on their
work adapting Google's tcmalloc to be NUMA-aware. The whitepaper includes
links to their source code / diffs. It appears to be quite a performance boost
in their (very artificial) benchmark. I'll be trying it out soon myself.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years
configurable keepalive setting through libldap?
by Ralf Haferkamp
Hi,
since quite some time libldap enables tcp-keepalive, e.g. to detected dangling
syncrepl connections. However the default timeout of two hours that most
systems are using might be a bit too long for some applications (e.g. I had a
problem lately were nscd didn't answer queries anymore because nss_ldap was
blocking in SSL_read() while the underlying connection has been cut off). On
the other hand messing with the system wide settings might no be a good idea
either. On Linux it is possible to configure the keepalive settings on a per
socket basis through the TCP_KEEP* socket options.
Would it be worth adding ldap_set_option() support for those, even if they are
not really portable?
--
regards,
Ralf
14 years
Re: commit: ldap/contrib/slapd-modules/nssov README nssov.c nssov.h pam.c
by Howard Chu
hyc(a)OpenLDAP.org wrote:
> Update of /repo/OpenLDAP/pkg/ldap/contrib/slapd-modules/nssov
>
> Modified Files:
> README 1.5 -> 1.6
> nssov.c 1.10 -> 1.11
> nssov.h 1.6 -> 1.7
> pam.c 1.7 -> 1.8
>
> Log Message:
> More for sessions, working. TODO: configure list of sessions to record
For anyone interested, this is essentially code-complete. It works for me, but
there are several areas I want to tweak still. Feedback on usability would be
helpful at this point. If anyone wants to jump in and get a real manpage
started, that would be nice too.
The main objective here was to eliminate the libldap dependencies/clashes that
the current pam_ldap/nss_ldap solutions all suffer from. A secondary objective
was to allow for the possibility of more sophisticated caching than nscd
provides. (E.g., run slapd back-ldap + pcache on each node.) Of course, you
can also completey eliminate cache staleness considerations by running a
regular database with syncrepl.
And of course, another major objective was to allow all security policy to be
administered centrally via LDAP, instead of having fragile rules scattered
across multiple flat files. As such, there is no client-side configuration at
all for the pam/nss stub libraries. (They talk to the server via a Unix domain
socket whose path is hardcoded to /var/run/nslcd/). As a side benefit, this
can finally eliminate the perpetual confusion over /etc/ldap.conf vs
/etc/openldap/ldap.conf.
User authentication is performed by internal simple Binds. User authorization
leverages the slapd ACL engine, which offers much more power and flexibility
than the simple group/hostname checks in the old pam_ldap code.
At this point some cleanup is probably still needed, and merging the nslcd
bits back into Arthur de Jong's code base is still underway. (Which means this
code will be showing up in Debian soon, and I will be recommending it to the
Ubuntu guys next month as well.)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years
ITS#4829, creating olcDbDirectory
by Howard Chu
I thought I had a good idea for this, although upon further reflection it
still has holes. But it may still be a good starting point for discussion:
For backends that support the olcDbDirectory keyword, we should also define a
write-only olcDbMkdir attribute. If it's provided when ldapadd'ing an
olcDatabase entry, or when ldapmodifying, then its values are treated as
pathnames that we will attempt to create before processing any other parts of
the request. This attribute would not be persisted in the cn=config backing
store, so it will only take effect on dynamic operations, not when reloading
the config on a subsequent startup.
If the target directory already exists and is owned by the current uid, then
it's a no-op. If the owner doesn't match, or the target pathname is not a
directory, the request will fail. Otherwise, we try the mkdirs and proceed if
they succeed. No cleanup will be performed on a failure - it would be pretty
rude to "rm -rf" an existing database here.
It may still be worthwhile to provide a global setting defining the filesystem
locations that are allowed to be used. (Of course, anyone with back-config's
rootdn credentials can set it to anything they want, anyway.)
Comments?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 1 month
Re: ITS#4829, creating olcDbDirectory
by ghenry＠OpenLDAP.org
----- "Howard Chu" <hyc(a)symas.com> wrote:
> I thought I had a good idea for this, although upon further reflection
> it
> still has holes. But it may still be a good starting point for
> discussion:
>
> For backends that support the olcDbDirectory keyword, we should also
> define a
> write-only olcDbMkdir attribute. If it's provided when ldapadd'ing an
>
> olcDatabase entry, or when ldapmodifying, then its values are treated
> as
> pathnames that we will attempt to create before processing any other
> parts of
> the request. This attribute would not be persisted in the cn=config
> backing
> store, so it will only take effect on dynamic operations, not when
> reloading
> the config on a subsequent startup.
>
> If the target directory already exists and is owned by the current
> uid, then
> it's a no-op. If the owner doesn't match, or the target pathname is
> not a
> directory, the request will fail. Otherwise, we try the mkdirs and
> proceed if
> they succeed. No cleanup will be performed on a failure - it would be
> pretty
> rude to "rm -rf" an existing database here.
>
> It may still be worthwhile to provide a global setting defining the
> filesystem
> locations that are allowed to be used. (Of course, anyone with
> back-config's
> rootdn credentials can set it to anything they want, anyway.)
So if slapd is run as root, the uid is 0 then the olcDbMkdir can create a dir
anywhere on the file system? The obvious thing to do there then is not run slapd
as root and as an ldap user and make this very clear in the docs.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
14 years, 1 month
Re: Build farm central node
by ghenry＠OpenLDAP.org
----- "Howard Chu" <hyc(a)symas.com> wrote:
> Gavin Henry wrote:
> > Hi all,
> >
> > I now have admin privs on the projects build box, so what do we need
> in a build farm?
> >
> > I like the Samba model with the drop down to view things:
> >
> >
> http://build.samba.org/?host=SerNet-solaris8&tree=ldb&compiler=gcc-4.2&fu...
> > http://build.samba.org/about.html
> >
> > And I like that users can add their arch too:
> >
> > http://build.samba.org/instructions.html
> >
> > Code is at:
> >
> > http://cvs.samba.org/cgi-bin/cvsweb/build_farm/
> >
> > I'm happy to get everything setup but I need to know what we want.
> My
> > first
> thoughts were to have lots of VMs on the big build box we've got,
> bring the
> VMs up and down when needed and compile HEAD, RE24 periodically, but
> that
> smoke testing would just make noise.
> >
> > We'll need a frontend to browse results anyway and maybe an admin
> panel to
> issue builds or just some admin commandline tools for pre-release
> testing.
> E-mails could go to a new openldap-builds(a)openldap.org list or
> similar. We'll
> also need a tool for users to register their system/host with the
> build master
> to collect results and show them. And we'll need some set of standard
> build
> options to be uniform across platforms?
>
> These frontends aren't already part of the samba build farm package?
I think some of them are yes. I'll download it and check.
>
> I think a first pass would be to get all the infrasructure up with a
> single VM
> as a target. And I think adding non-Linux VMs is an obvious next step
> -
> FreeBSD, OpenSolaris, etc.
Yes, good plan.
> If QEMU was further along I'd investigate that route too for non-x86
> testing
> but unfortunately it seems to be fairly limited in that respect.
> (E.g., QEMU
> Sparc emulation still can't boot Solaris.)
Yes, true. Once the right infrastructure is complete, we should hopefully get these platforms
donated etc.
> > Lastly, there is also:
> >
> > http://gcc.gnu.org/wiki/CompileFarm
>
> It may be worth asking. I personally don't have access to any Alpha or
> MIPS
> systems any more, but can generally get to the others when needed.
> Running
> "make test" on my G1 phone is entertaining...
;-)
Will check.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
14 years, 1 month
3rd party apps for building/testing?
by ghenry＠OpenLDAP.org
Hi,
I'm wondering what we should do for picking this. Do we go with bdb 4.7.25 with patches and whatever each distro provides for OpenSSL, GnuTLS etc. that we test on. Do we test various versions or just have some options in our initial build scripts to specify these? Do we pick versions we recommend for production or just something that will work for testing or do we only test an exact set of package versions with our build options?
I say we pick our versions with our build options and allow these to be set by either the person contributing the build box or us in the script. I think we can leave each distro to do the testing of the version of OpenLDAP they provide and whatever that distro uses as build reqs.
Thoughts?
Gavin.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
14 years, 1 month
