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/...
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.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland