On pe, 27 touko 2022, Rob Crittenden via FreeIPA-users wrote:
Leo O via FreeIPA-users wrote:
I wouldn't say "wrong approach in development" rather "wrong approach in FreeIPA development". There are a lot of products which you can extend pretty easy, e.g. by just mounting volumes with your files into the container. Especially a kind of a small extension like this, a ldap schema and a few ui elements makes you go through such a hassle, build a rpm package and an own docker image. That's horrible to be honest. Whoever is responsible here, I hope they read this, too, taking this into consideration on any FreeIPA upgrades making it more friendly for extensions and also give the docs a higher priority (P.S. I had to google how to install the FreeIPA packages on a fresh Rocky Linux VM, as I couldn't find it in the official FreeiPA docs, that's ridiculous).
What docs do you look at? It's pretty clearly documented at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
Rob is right. In addition, if you'd go to freeipa.org -> Documentation, https://www.freeipa.org/page/Documentation, it tells you where the user guides are (I did not copy the links below, to increase readability):
------------------------- User Guides Use Red Hat Enteprise Linux documentation:
- FreeIPA 3.0.x: - Identity Management Guide for RHEL 6 (report bug) - FreeIPA 3.3.x and 4.x: - Linux Domain Identity, Authentication and Policy Guide for RHEL 7 (report bug) - Windows Integration Guide for RHEL 7 (report bug) - System-Level Authentication Guide for RHEL 7 (report bug) - RHEL 8 / FreeIPA 4.7+: Documentation for planning Identity Management and setting up access control - RHEL 8 / FreeIPA 4.7+: Getting started using Identity Management - RHEL 8 / FreeIPA 4.7+: Configuring, managing and maintaining Identity Management in Red Hat Enterprise Linux 8
Upstream user guide is not maintained anymore as all effort is put into the Red Hat Enteprise Linux documentation. Bugs found in the documentation can be reported in Red Hat bugzilla -------------------------
You are welcome to contribute improvements to discover documentation.
I don't know give us something like a environment variable where we can add a plugin path, then we simply mount a volume with the extensions in whatever format/structure it needs and point to it using the env var. Idk, anything which is less cumbersome than the current approach.
IPA in a container is still a work in process and an engineering feat in itself to stuff multiple servers into a single container. Your expectations are simply too high for what it is.
Nevertheless, back to the technical part. By the way, thanks for your time Alexander, I appreciate it. I prepared a repo: https://github.com/leonidas-o/freeipa-postfixbook-plugin When I execute the command: "rpmbuild -ba freeipa-userstatus-plugin.spec" I get a "error: Failed build dependencies: python2-ipaserver >= 4.4.0 is needed by freeipa-postfixbook-plugin-0.9.0-1.el8.noarch"
So how do you setup your dev env? I've never build a rpm package, so this is pretty new to me. I mean currently is python3-ipaserver with all its dependencies installed, can't simply install python2-ipserver with all its dependencies as there are for sure dependency conflicts. Do you even build with one spec file several packages or having multiple spec files, e.g. one for python3, one for python2 and therefore also multiple dev env VMs where you can build that?
This requirement is specified in your specfile, not something IPA imposes. If you a building only for RHEL 8 (or clone) then you can drop all the RHEL-7 boilerplate, and probably much of the older Fedora stuff as well.
Also, instead of hacking right away, consider first how you'd be deploying and maintaining your changes. Supplying volumes with plugins is not something that I'd consider a good way to maintain software in containers. Typically, you'd build a new image that includes all your bits and supply data volumes. This is how FreeIPA container is built in itself. If you want to maintain a healthy image going forward, make sure you have that process automated too. Sure, you can simply copy bits here and there during image build phase but this is much easier if all your bits packaged with a proper packaging tool first.