Harry G Coin wrote:
> 
> 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
>>>>>> <[email protected]> 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-exclusivity
>>>>
>>>> . 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.

Yes. As I said, it's a matter of what we can test. We test NFS mounts
but not ceph.

When users report problems with untested software, we tend to point our
finger that way.

Again, in your case it's a repository issue, not a software issue.

rob
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to