Updated patches for exchange setup support
abartlet at samba.org
Wed Jun 13 16:33:37 MDT 2012
On Wed, 2012-06-13 at 18:16 -0400, simo wrote:
> On Wed, 2012-06-13 at 11:34 -0700, Matthieu Patou wrote:
> > On 06/13/2012 10:50 AM, simo wrote:
> > > On Tue, 2012-06-12 at 23:28 -0700, Matthieu Patou wrote:
> > >> Andrew, Simo, Matthias,
> > >>
> > >> I've updated my patches here:
> > >>
> > >> http://gitweb.samba.org/?p=mat/samba.git;a=shortlog;h=refs/heads/schema
> > >>
> > >> They involves:
> > >>
> > >> * removing the automatic reload of the schema
> > >> * adding periodic of the schema (like in Microsoft implementation)
> > >> * finish handling of schemaUpdateNow so that it really cause the schema
> > >> to be reloaded right now (or at the end of the transaction)
> > >> * add a signaling between process so that if one process had to reload
> > >> the schema due to schemaUpdateNow or due to DRS replication then other
> > >> process dealing with the samdb are aware of it and reload the schema.
> > >> * fix utc/generalized time attributes (we used to treat them as synonyms
> > >> but there aren't)
> > >> * return the timestamp of the last modified attribute/class as the
> > >> modifyTimestamp attribute of CN=Aggregate,<SCHEMA_DN>
> > >> * fix crackname
> > >>
> > >> Can you have a look ?
> > > I do not understand why you are trying to access directly the underlying
> > > tdb.
> > Because metadata.tdb is not an ldb database, it was introduced by amitay
> > in order to have a cross partition serial number.
> > > This sounds completely wrong for various reasons, including the
> > > fact it breaks the ldb abstraction (we could decide to move and use a
> > > different backend, for example ntdb or something else in future).
> > No because metadata is not an LDB, so you can choose to move LDB to ntdb
> > and keep metadata to tdb, of course if you want to move metadata to ntdb
> > then you have to update the calls so that they reflect the new API.
> Right, which is why it makes little sense to use a different backend for
> the metadata.
Simo, this isn't new. Indeed, it's quite old at this point.
> > > But I also do not see why you need that at all.
> > Because you need to have a way for the process that is doing LDAP to
> > tell the process that is running the DCE-RPC that the schema was
> > reloaded on an explicit demand (schemaUpdateNow) and that it should do
> > so also otherwise you can end up with DRS not being able to send replica
> > update records that have just been created via LDAP.
> I know why you need the serial for reloading, what I do not understand
> is why you or Amitay decided to use a tdb therefore making code depend
> directly no the tdb api instead of using the appropriate abstraction
> layer that is LDB. Can you explain that ?
The metadata.tdb was originally created such the the global sequence
number could be updated by bind, which is given access to the DNS
partitions and metadata.tdb only, but not the full sam. Keeping in in
(say) the base sam.ldb was not desired from a separation point of view.
> > > Why can't you simply lookup an LDB entry to save/read out the current
> > The thing is that it's very very costly even if didn't looks like it,
> very very costly ?
> A base search in LDB has the same cost of a TDB lockup, what is costly ?
Sadly this isn't the case. I've actually profiled this, and the parsing
of the ldb record was one of the dominant costs as shown by perf.
That's why we gain 4-10 mins on a make test run (and that on it's own is
a very good reason to do this).
There are other things we can do to avoid loading the schema too often,
and I hope to do that on top on of this work.
> Right, and in this specific case you probably wan to use an even faster
> mechanism than writing to a TDB and having all processes need to
> constantly poll it. A better way on Linux could be to use inotify on a
> special file and have all procsses intersting in schema update check for
> changes. When a schema update now command comes in, you 'touch' the file
> and all other processes will be notified that said file was touched
> signaling they need to check if it is time to update the schema.
I don't think we wish to add additional very platform-dependent
mechanisms when we can easily work with what we have here.
> > Apart from this should I conclude that the pure ldb related patches are OK ?
> On a cursory look I didn't see anything grossly wrong.
Thanks for looking this over.
I think these patches are ready to autobuild!
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
More information about the samba-technical