On 28 Mar 2023, at 15:35, Rob Crittenden rcritten@redhat.com wrote:

Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:

...

Hi,

I have almost finished a plugin for FreeIPA, so that admins can have similar functionality found on Postfix Admin.

freeipa-postfixadmin.png freeipa-postfixadmin/README.md at main · oculos/freeipa-postfixadmin https://github.com/oculos/freeipa-postfixadmin/blob/main/README.md github.com https://github.com/oculos/freeipa-postfixadmin/blob/main/README.md

There is already a good plugin that does a bit of that, but the goal is a bit different. My main goal is not to mix up postfix configuration with groups and hosts, but have separate entities for domain, aliases and virtual domains, in addition to mailboxes.

It was written mostly to allow me to migrate my mailboxes from MySQL to FreeIPA, and I don’t have a huge postfix configuration - I only have multiple domains, mailboxes, aliases and virtual domains, so that’s the functionality I wanted with this plugin.

There are a few things missing before this can go in production («production» here means to actually migrate my mailboxes to FreeIPA), adding a mailbox to ipa users on the gui being the most important one.

I would appreciate any comments and feedbacks regarding this plugin. It wasn’t easy to understand the logic on how to write one, but I got the hang of it (for simple stuff).

Thank you so much for your feedback, Rob. This is a very lonely job, as a lot of it is based on guess work. It took me a long time, for example, to understand that I could use something like “entity_select” to be able to allow the selection of records in another entity. I’d prefer to use the same type of dropbox as the “$type: select”, but it works fine. I also would like to use some dynamic control for some user interface items. For example, I want to add a checkbox where the user can choose to create a mailbox for the new user. But it would be nice to hide the “Active mailbox” selection if the user doesn’t check the “Create mailbox”.

My answers to your questions/comments:

Looks like a good start!

I have a few questions:

1. Where did the 1.3.6.1.4.1.60062 prefix for objectclasses and

attributes come from? Is this a private one?

Yes, I applied for those. I didn’t feel like reusing anything existent (except, I think, `status` and `mailQuota`). I didn’t want to use arbitrary oid’s either.

2. The domain_mod has a pre_callback that validates the domain. Isn't it

too late at this point? In any case, you may be able to move the validator to the Param instead.

Yes, I am not at home now, I think we don’t need that validation, as domains are - or should be - read only on the mod facet. So I agree.

3. If you specify all the objectclasses at in object_class you don't

need to manually add them.

Oh, that I didn’t know. Thanks!

4. There is a helper you can use to determine if an objectclass is

already in an entry, self.obj.has_objectclass()

Great, thanks!

5. If you convert create_default_objects.ldif to an update file you can

use $SUFFIX instead of hardcoding the domain part.

Yes, my plan is to do exactly that. I will focus more on how to make a simple installation script, without making a package. All the plugins I saw have a very complex installation because they are packed in some standard (rpm, for example), and I won’t go that route for now.

6. I'd rename create_attributes.ldif to something that looks more like a

schema file. By naming it is very clear but it's convention.

Thank you. Will do that as well.

I hope that if someone is interested that I could get some contribution when it comes to add permission settings to this plugin. One can only dream… :)

Best,

Francis