[Date Prev][Date Next]
Re: (ITS#3737) Patch to passwd backend
> On Fri, 20 May 2005, Pierangelo Masarati wrote:
>> What about having (inetOrg)person + posixAccount instead? My concern is
>> account + posixAccount does not allow some of the attributes previously
>> present in back-passwd (e.g. sn, which was actually required by person)
>> thus could break existing deployments. person + posixAccount would only
>> attributes without breking the objectClass inheritance chain with
>> respect to
>> the currently released software.
> That sounds like a good idea, and is the way that I should have done it.
>> The posixAccount extras could be associated
>> to the presence of a configure switch (and posixAccount could simply
>> the uidObject class).
> Are you saying that a configure option would select between returning
> posixAccount and uidObject?
Something like that, following the idea of not risk breaking existing
stuff (or returning extra stuff to those that are happy with existing
functionality; I wonder how many are there)
> I suppose I should patch against HEAD instead of 2.2.26, as this is an
Yes. Despite what one could expect, during some reworking of the code
back-passwd has been modified a bit in HEAD/2.3. Now AttributeDescription
pointers are pre-fetched at startup. This implies that slapd can safely
detect if the appropriate schema has been loaded yet.
In any case, apart from requiring a bit of reworking, your change should
be essentially straightforward. I suggest you use
attr_merge_normalize_one() instead of attr_mergeit(). Instead of
optionally using uidObject in the baseline code, one could directly move
to inetOrgPerson, possibly documenting that this requires loading
inetorgperson.schema; with the optional posixAccount, one will need to
load nis.schema. Or, a generic comment about the need to check that the
required schema items are loaded should suffice.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497