On 10/18/23 15:55, Rob Crittenden wrote:
Harry G Coin via FreeIPA-users wrote:
On 10/18/23 10:33, Christian Heimes wrote:
On 18/10/2023 16.57, Harry G Coin wrote:
On Tue, Oct 17, 2023 at 7:50 PM Christian Heimes via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On 17/10/2023 19.32, Harry G Coin via FreeIPA-users wrote:
'security' and 'other' seemingly 'unrelated' 'upgrades' to packages n levels deep but whose previously un-noticed freeipa killing race-condition or other bug manifests after the upgrade. I find myself obligated to prevent any security or other change from happening until the lowest possible usage times. For example today's 'random freeipa bother' is: Problem: cannot install both protobuf-3.5.0-15.el8.x86_64 and protobuf-3.19.0-2.el8s.x86_64 - package liborc1-1.7.9-1.el8.x86_64 requires libprotobuf.so.15()(64bit), but none of the providers can be installed - cannot install the best update candidate for package protobuf-3.19.0-2.el8s.x86_64 - cannot install the best update candidate for package liborc1-1.7.5-1.el8s.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
How did you end up with Hadoop-related libraries on your IPA server? Did you install additional services and EPEL on your IPA server?
To gain access to the file system published by the multi-rack high availability file system at https://ceph.io, named 'cephfs' (a native fs akin to nfs in some ways) one must install ceph-common. That package comes one per version of major ceph releases. That appears to play badly with freeipa packaging. I was hoping by waiting patiently the packagers would figure that out for us. Dependency hell strikes again.
You are living a dangerous life, you are running an untested and unsupported configuration of FreeIPA. All our docs *strongly* advise against additional services on an IPA server, e.g. https://www.freeipa.org/page/Deployment_Recommendations#freeipa-server-exclu... . Third party repositories with conflicting packages are even more problematic.
Thanks Christian. Might you publish a list of all the packages in the repos that can't be installed on a freeipa box? Can a freeipa system be an NFS client? Which file systems used by multiple tens of thousands around the world should avoid freeipa?
In this case it looks like a repo problem, not "rpm hell". It's completely unrelated to IPA. These are not IPA dependencies.
IPA connects a lot of disparate services together into a whole. There are only so many combinations we can test. This is why we recommend keeping things vanilla.
That is the point he was trying to make.
rob
Thanks Rob and Christian, Perhaps you'd agree it's necessary for freeipa to function as a client to the most used file systems (not server, which perhaps what Christian was pointing at). In the case of ceph, the client package is ceph-common. I can see how running a samba server and other file system servers would be problematic. But the need to be able to operate with network file system clients (particularly a kernel level file system) seems a necessary one.