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.html > > 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 "[email protected]" 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 _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
