ipa-server installation is categorized as Directory Server

[gonoph]

in execution/process_rhel_addons.py:

if (package_name.startswith("389-ds")): directory_server_packages_installed = True

marks any ipa-server (IdM) installation as a directory server installation.

There should be a more accurate way of detecting a directory server installation.

[waldirio]

Hello,

Thank you @gonoph

I'll let @starnold-redhat answer that, once he is working much more on this project than me. However, let me share my 2 cents.

This is from a RHDS/Directory Server

[root@walldirectoryserver11 pki]# find product*
product
product/200.pem
product/479.pem
product-default
product-default/479.pem
[root@walldirectoryserver11 pki]# rct cat-cert product/200.pem 

+-------------------------------------------+
    Product Certificate
+-------------------------------------------+

Certificate:
    Path: product/200.pem
    Version: 1.0
    Serial: 12750047592154746489
    Start Date: 2019-06-12 18:45:22+00:00
    End Date: 2039-06-07 18:45:22+00:00

Subject:
    CN: Red Hat Product ID [03b3eb34-1e4b-4318-87fa-0b07ba776f78]

Issuer:
    C: US
    CN: Red Hat Entitlement Product Authority
    O: Red Hat, Inc.
    OU: Red Hat Network
    ST: North Carolina
    emailAddress: ca-support@redhat.com

Product:
    ID: 200
    Name: Red Hat Directory Server
    Version: 11
    Arch: x86_64
    Tags: dirsrv-11
    Brand Type: 
    Brand Name: 

[root@walldirectoryserver11 pki]#

I'm pretty sure that we can check if the .pem is around and in case of yes, you can combine them. The package + the pem file. In this way, we can guarantee this is a RHDS.

@starnold-redhat please, let us know what you think.

Thank you, folks! Waldirio

[waldirio]

Hi all

Complementing, I also have an IPA server.

[root@wallipa pki]# find product*
product
product-default
product-default/479.pem

[root@wallipa pki]# rpm -qa | grep 389-ds
389-ds-base-1.4.3.30-6.module+el8.7.0+16373+1a59bba2.x86_64
389-ds-base-libs-1.4.3.30-6.module+el8.7.0+16373+1a59bba2.x86_64

[root@wallipa pki]# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
pki-tomcatd Service: RUNNING
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful
[root@wallipa pki]# 

So, as we can see above, if you have only the package, yes, this is probably an IDM. However, if you have the package + the pem file, then this is an RHDS.

@starnold-redhat do you agree with that?

Thanks! Waldirio

[gonoph]

@waldirio I think that's a great way of detecting. I'm not sure if you'd want to check for situations where the packages are there, but someone deleted the .pem file? I may ask some folks in the Subscription Experience team if the .pem file is always placed there when it's installed from a Red Hat signed package.

[waldirio]

Hello,

The yum/dnf plugin is the guy responsible for download the .pem file and put in that place. That said, I believe this is the best way to check this out. Removing the file ... normally we don't see that, we see the oposite, for example, the customer adding another repo, just to install another package, not related to RHDS. If the package came from that repo, the .pem file will be local. However, the package mentioned above will not.

I believe, if your customer is looking for the RHDS info and this accurate, the combination of both facts will be the way, the package + pem file.

Side note, assuming that someone delete the file, next time you try to install something from that repo and/or when you update any package that are related to the rhds repo, only then, the package will be downloaded once again.

Thanks again!! Waldirio

[gonoph]

Ah! Perfect! That makes sense via the plugin putting the pem file there based on the repo.

[starnold-redhat]

I think we're going to strip all the logic - except for looking for pem files. So that should stop those kind of issues hopefully