[Date Prev][Date Next] [Chronological] [Thread] [Top]

Ang. Re: Ang. RE: Bdb defaults - WAS: problem importing entries.




I fully agree with Buchans remarks about commented default config files. this is the first space of interaction for most beginners
pierangelo has a point about defaults hiding knowledge - I just believe that this is something all (reasonable) users take into account when going with defaults

but the openldap space is certainly big, and certainly no default configuration file or examples can cover it all.

hence one could think of a segmentation of the big openldap space into the following areas:

1) pre-openldap-stable releases
     leave it to third party vendors (redhat, apple, sun etc) to configure and document their packages as necessary
2) openldap-stable-release
     provide sensible "works for most to get started" default configfiles and describe example configurations with appropriate disclaimers and pointers to further documents.
3) post-openldap-stable or cvs versions
     firmly refer to the docs, the man pages and the mailinglist

e.g. over the past months, the "bdb vs ldbm" question seems to have been resolved once and for all
yet, to my knowledge, we still don't have a clear sign anywhere saying
"unless you know better, use openldap with bdb backend (and compile bdb 4.2.52 with the latest two patches)"

it is these known-to-be-true things that most people starting with openldap have a difficult time finding out
by sifting through mailing list archives e.g. it is hard for beginners to determine these answers - how shoulds you weigh different replies from people that you dont know of?

openldap-sanctioned default config files and easy to follow examples configurations could be a valuable guide around these stumbling blocks



Buchan Milne <bgmilne@obsidian.co.za>

04-06-15 12.57

Till
ando@sys-net.it
Kopia
Frank Hoffsummer <frank.hoffsummer@svt.se>, openldap-software@OpenLDAP.org
Ärende
Re: Ang. RE: Bdb defaults - WAS: problem importing entries.





-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pierangelo Masarati wrote:
| You see, one approach I sometimes favour (and I've been working towards
| this in ACLs, for instance) is not to have any defaults.  All legal
| parameters MUST be present in a configuration file, and implementations
| shoudl bail out if any is absent; issues may arise when parameters are
| incompatible, but some crafting should allow this to be worked out (e.g.
| allowing a value of "undefined" for those that are incompatible).  Of
| course, users should be given up-to-date templates to start with, so they
| don't really have to read ALL about ANY parameter to be able to simply
| "give it a try".  I think defaults really make things tricky, because they
| hide a lot of knowlegde about what can be important and even about how
| things behave, and then one always needs to remember (or look up) default
| values; this approach would really make things simpler, because everything
| would be in the slapd.conf.  Would you consider this a better approach?
|

I don't think Frank meant that there should be compiled-in defaults, but
that the config files should have good defaults.

We ship a default slapd.access.conf which we include into slapd.conf,
with some comments on it, so that at least:
- -users/admins don't end up with no ACLs protecting passwords (I have
seen this far too often on servers running other distros ... including
servers set up by colleagues)
- -users/admins see the features available with regex-based ACLs etc
- -can learn more easily how they work

In many cases, a user's first interaction with the available parameters
is in the default config file ... so it needs to cover all the critical
parameters (checkpointing, indexing and ACLs I think qualify)

Currently, the slapd.conf provided with the source distribution doesn't
have any active ACLs (and,it seems that ACLs outside the database
definition don't work anymore, and the example ACLs that are commented
out are outside database definitions) or a checkpoint entry in the
single example bdb database.

Regards,
Buchan

- --
Buchan Milne                      Senior Support Technician
Obsidian Systems                  http://www.obsidian.co.za
B.Eng                                RHCE (803004789010797)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAztY1rJK6UGDSBKcRAu+EAJsH8zbuM8OiIpxB10eZhvUpuezDAwCdHoCh
sKmTU2D3FlaLG6MpdM3w1Ak=
=4SVv
-----END PGP SIGNATURE-----