[Freeipa-users] Correct way to install plugins?

[Rob Crittenden]

Jeffery Harrell wrote:
> Thanks very much, Rob. Would it be best to install the schema file in
> …/updates so it lives there permanently, or is it enough to just run it
> through ipa-ldap-updater the one time? I’m sorry if that’s a dumb
> question; I’ve only been working with IPA for a couple weeks so I’m
> still working on building my intuition for it.

What I would recommend is packaging the whole thing as an rpm. Then you 
can be sure that the same bits are installed on every master and as 
changes are needed you can roll them out in a controlled way. And rpm -V 
will tell you if there are any local customizations.

This would involve putting the update files into .../updates. I don't 
believe there is any downside in putting files there.

rob

>
> I’d be happy to share my DHCP plugin, but it’s pretty sketchy. ISC
> DHCPd’s LDAP support is kind of idiosyncratic, so my plugin is pretty
> purpose-built for our environment and needs. It might be a starting
> point for somebody else, though. I’ll put the polish on the code and
> share a Github link later today or maybe tomorrow.
>
> Thanks again for the advice.
>
> On May 9, 2016 at 11:45:25 AM, Rob Crittenden (rcritten at redhat.com
> <mailto:rcritten at redhat.com>) wrote:
>
>> Jeffery Harrell wrote:
>> > Good morning. (It’s morning where I am.)
>> >
>> > I’ve written several plugins for my deployment, including a DHCP plugin,
>> > and I’m trying to figure out the best way to deploy them onto production
>> > servers.
>> >
>> > Let’s start with the schema. I could copy a schema file (e.g.,
>> > 89dhcp.ldif and others) into /etc/dirsrv/slapd-REALM/schema and do a
>> > schema reload, or I could use ldapmodify to write the schema directly
>> > into the running system so it gets written into
>> > /etc/dirsrv/slapd-REALM/schema/99user.ldif.
>> >
>> > Is there any reason to prefer one over the other? Doing it the first way
>> > seems more tidy to me, but it has to be done on each server separately,
>> > which makes me wonder if it might cause things to get weird with respect
>> > to replication during that short span of time when one server has the
>> > schema and the other doesn’t. The Red Hat Directory Server documentation
>> > stops short of saying that local schemata should always be installed
>> > with ldapmodify into 99user.ldif, but it seems to kind of head-fake in
>> > that direction, so I’m not sure what the right method is.
>>
>> The answer is neither: you want to use ipa-ldap-updater
>> --schema-file=<your_schema.ldif>
>>
>> You definitely want to do it online so the schema gets replicated (and
>> into 99user.ldif) so entries on non-updated masters don't blow up.
>>
>> > Then there are the update files. For the DHCP plugin, for instance, I
>> > have a short update file that initializes a few objects (see below). Is
>> > it better to just RUN this update against a live server with
>> > ipa-ldap-updater, or is it better to INSTALL this file
>> > in /usr/share/ipa/updates so it stays on the server permanently? Will
>> > the second approach be better in case of upgrades or whatever?
>>
>> I'd install it into /usr/share/ipa/updates. The updater is more or less
>> idempotent so it shouldn't hurt anything to run it multiple times.
>>
>> Once you have things working you might consider submitting your work
>> upstream. There is a long-standing ticket for DHCP integration,
>> https://fedorahosted.org/freeipa/ticket/939
>>
>> rob
>>
>> > Thanks very much for taking the time. I hope my questions made sense.
>> >
>> > Jeffery
>> >
>> > DHCP update file for reference, if necessary:
>> >
>> > dn: cn=dhcp,$SUFFIX
>> > add: objectClass: top
>> > add: objectClass: dhcpService
>> > add: dhcpStatements: authoritative
>> > add: dhcpStatements: default-lease-time 43200
>> > add: dhcpStatements: max-lease-time 86400
>> > add: dhcpStatements: one-lease-per-client on
>> >
>> > dn: cn=dhcpHosts,cn=Schema Compatibility,cn=plugins,cn=config
>> > add: objectClass: top
>> > add: objectClass: extensibleObject
>> > add: schema-compat-container-group: cn=hosts,cn=dhcp,$SUFFIX
>> > add: schema-compat-search-base: cn=computers,cn=accounts,$SUFFIX
>> > add: schema-compat-search-filter:
>> > (&(macAddress=*)(fqdn=*)(objectClass=ipaHost))
>> > add: schema-compat-entry-rdn: cn=%{fqdn}
>> > add: schema-compat-entry-attribute: objectClass=dhcpHost
>> > add: schema-compat-entry-attribute: dhcpHWAddress=ethernet %{macAddress}
>> > add: schema-compat-entry-attribute: dhcpStatements=fixed-address %{fqdn}
>> > add: schema-compat-entry-attribute: dhcpOption=host-name "%{fqdn}"
>> >
>> > dn: cn=DHCP Administrators,cn=privileges,cn=pbac,$SUFFIX
>> > add: objectClass: top
>> > add: objectClass: groupofnames
>> > add: objectClass: nestedgroup
>> > only: description: DHCP Administrators
>> >
>> > plugin: update_managed_permissions
>> >
>> >
>> >
>>