Leo O via FreeIPA-users wrote:
> E.g. it forces to use a radio-box. The fixes from PR 6294 would
be needed to use plain 'checkbox' type.
okay, I will leave it for now as checkbox, as the underlying ldap structure is more
important to me atm than the UI.
> You only need one class to allow an attribute. If you want to add either Account or
Forward, it would probably be driven by a
> different logic -- e.g. whether the user entry would be a primary one or only a mail
forward. I cannot help here -- it is pretty
> much your plugin's logic what to use here.
Hm, I don't know, to be honest. It is not obvious to me what that actually means,
what the consequences are. So I can't do any logic decisions here. I mean the ldap
schema is not something I created. It's a common postfix-book schema. The only
modifications I made was to lowercase the first letters of the objectClasses (just that
the naming style matches the other entries, shouldn't have any effect anyways) and
commented out "mailQuota" and "mailForwardingAddress" attributeTypes
as they exist already. I think I will remove the second
"add_missing_object_class(ldap, u'postfixbookmailforward', dn)"
completely from "mailalias.py". Somehow it doesn't feel correct.
> Use lambda or a function for a default_from attribute of the parameter.
Lambda it is. It's enough for me, plus discovered these handy function like
"lower()" and the object "api.env.realm". Tested this pretty nice
function and it works as expected:
"default_from=lambda givenname, sn: '%s.%s@%s' % (givenname.lower(),
sn.lower(), api.env.realm.lower()),"
The unique attribute is something which causes some headache. I saw it also in here:
https://directory.fedoraproject.org/docs/389ds/howto/howto-uid-uniqueness...
1. Still don't know how to implement it, would I create it inside my plugins schema?
But I can't just adapt the entries and throw them into the ldif file, can I?
(commented out a few lines, unsure about the "default:" prefix in each line)
dn: cn=mailalias uniqueness,cn=plugins,cn=config
default:objectClass: top
default:objectClass: nsSlapdPlugin
default:objectClass: extensibleObject
default:cn: mailalias uniqueness
default:nsslapd-pluginPath: libattr-unique-plugin
default:nsslapd-pluginInitfunc: NSUniqueAttr_Init
default:nsslapd-pluginType: preoperation
default:nsslapd-pluginEnabled: on
default:uniqueness-attribute-name: mailalias
default:uniqueness-subtrees: $SUFFIX
default:uniqueness-exclude-subtrees: cn=compat,$SUFFIX
default:uniqueness-exclude-subtrees: cn=staged users,cn=accounts,cn=provisioning,$SUFFIX
default:uniqueness-across-all-subtrees: on
default:nsslapd-plugin-depends-on-type: database
#default:uniqueness-subtree-entries-oc: posixAccount
#default:nsslapd-pluginId: NSUniqueAttr
#default:nsslapd-pluginVersion: 1.1.0
#default:nsslapd-pluginVendor: Fedora Project
#default:nsslapd-pluginDescription: Enforce unique attribute values
---------------------------------------------------------------------------------
This is in the IPA "update" format which is ldif-like. You can either
modify this to be a pure ldif, in a separate file from the schema, or as
an IPA update file (recommended). For the latter you want to name it
something like 10-postfix-uniqueness.update and install it in
/usr/share/ipa/updates. It will get picked up automatically by
ipa-server-upgrade.
You may want to consider adding an index for it as well if postfix will
search on mailalias.
But then a few questions came to my mind.
2. I'm using the lambda value to generate a mailAlias out of first name and last
name. If I now create such a unique constraint, it would throw an error when creating a
user with the same first name, last name, so it would't be possible to create a user
at all.
2.a: I would have to either remove the default_value lambda mailAlias, make it optional.
Which is not possible because then I get the error again: "missing attribute
"mailAlias" required by object class "postfixBookMailForward""
Or
2.b: I don't use the unique constraint and therefore pushing the responsibility to a
human person/ the admin to take care that the mail aliases stay unique.
which brings me to
2.c: IIRC general emails like "webmaster(a)yourdomain.com" are used and put on
multiple user accounts, if I'm not mistaken. Please correct me if I'm wrong. That
would mean, I definitely should not use such a unique constraint on mail alias.
Puhhh, pure logical issues for that one, I still would like to hear your opinion about
that. I tend to go with 2.b and let the admin create users (In case a user with the same
first- and last name already exists, add a suffix to the generated mail alias). As this is
a real edge case (especially if you plan to use that for 0 - 20 users), no need to create
complex mail alias generating functions. Means, the current implementation is done and can
be used.
I don't know much about using LDAP to store mail aliases but I think
you're right about 2b. Leave it up to the admin.
rob