LDB_SCOPE_ONELEVEL without full traversal?

[tridge at samba.org]

Volker,

 > Simple: I want a registry key per [smbshare] definition, and
 > I want all parameters in that share definition (i.e.
 > registry values). And if you look at for example the
 > lanmanserver\shares key in a real windows registry, you will
 > see a secdesc as binary value per share. So putting all
 > values into a single tdb record just will not work.

Sorry if I'm being dumb, but I don't understand the last part of this
logic. Why is a SD per share a problem?

I looked at lanmanserver\shares\security (which is the only part of
lanmanserver\shares populated on my w2k3 box) and it is a single
registry record, containing a SD for each share. That seems fine to
me, but why does it prevent us making each share a ldb record?

 > The data model Jelmer has chosen and which I find quite sane
 > looks like:

umm, I don't think "quite sane" describes that well - "quite insane" I
think fits better :-)

 > And so on. You get the idea. So we have to do a onelevel
 > search on
 > cn=regshare,cn=smbconf,cn=samba,cn=software,cn=hklm to get
 > all the smb.conf values that belong to the registry key that
 > represents [regshare].

This will be slow regardless of what ldap server you use, and
regardless of its fancy onelevel indexing you have.

If a share has N parameters set, then you are guaranteeing that the
ldap server has to fetch at least N records from disk. That is N disk
blocks, N lookups and N lots of record decoding.

If you put all the paramters for a share in a single record you just
need one lookup to fetch the lot.

I'd suggest we use a structure like this (in ldif form):

dn: cn=share1,cn=smbconf,cn=samba,cn=software,cn=hklm
parmReadOnly: yes
parmPath: /home/foo/test

What do we need to do with shares that won't work that way? It allows
an entire share to be loaded with 1 ldb search, and doesn't even need
any indexing to be blindingly fast. 

Cheers, Tridge