Support IPA IPA Trust with additional IPA server #106

justin-stephenson · 2024-08-01T13:32:35Z

Add new server master2.ipa2.test which deploys an IPA domain ipa2.test to be used in IPA IPA trust.

with this PR checked out
sudo make down
sudo make build
`sudo REGISTRY="localhost/sssd" make up

Linked PRs:
SSSD/sssd-test-framework#119
SSSD/sssd#7517

src/ansible/roles/dns/templates/etc.dnsmasq.conf.j2

src/ansible/roles/cleanup/tasks/main.yml

jakub-vavra-cz · 2024-08-01T14:09:27Z

src/ansible/roles/packages/tasks/Fedora.yml

@@ -221,7 +221,7 @@
    dnf:
      state: present
      name: sssd-kcm
-  when: "'base_ipa' in group_names or 'ipa' in group_names"
+  when: "'base_ipa' in group_names or 'base_ipa2' in group_names or 'ipa' in group_names"


Is there a reason to use base_ipa2? Wouldn't it be tha same as base_ipa?

Fixed to use base_ipa only, this was an oversight on my part.

Does not look fixed yet.

jakub-vavra-cz · 2024-08-01T14:13:55Z

src/ansible/inventory.yml

@@ -14,6 +14,9 @@ all:
        base_ipa:
          hosts:
            base-ipa
+        base_ipa2:


why create base_ipa2?

Fixed to use base_ipa only, this was an oversight on my part.

justin-stephenson · 2024-08-13T16:11:21Z

Hi @pbrezina Can you help me understand why docker.io/ubuntu:rolling build fails (https://github.com/SSSD/sssd-ci-containers/actions/runs/10370744252/job/28711693110?pr=106) when sshd does not restart properly on master2.ipa2.test. I see that the host keys are not found.

Aug 13 13:19:21 master2.ipa2.test sshd[6905]: Unable to load host key: /data/ssh-keys/hosts/master2.ipa2.test.ecdsa_key                                                    
Aug 13 13:19:21 master2.ipa2.test sshd[6905]: Unable to load host key: /data/ssh-keys/hosts/master2.ipa2.test.ed25519_key                                          
Aug 13 13:19:21 master2.ipa2.test sshd[6905]: Unable to load host key: /data/ssh-keys/hosts/master2.ipa2.test.rsa_key

I ran src/tools/gen-ssh-keys.sh and added the ssh keys for master2.ipa2.test into this PR. I also added master2.ipa2.test into the for loop in src/tools/gen-ssh-keys.sh

However, these are not being copied into the master2.ipa2.test system.

[root@master2 /]# ll data/ssh-keys/hosts/
total 192       
-rw-------. 1 root root  525 Aug 13 02:05 client.test.ecdsa_key                                                        
-rw-------. 1 root root  189 Aug 13 02:05 client.test.ecdsa_key.pub                                                    
-rw-------. 1 root root  419 Aug 13 02:05 client.test.ed25519_key                                                      
-rw-------. 1 root root  109 Aug 13 02:05 client.test.ed25519_key.pub                                                  
-rw-------. 1 root root 2610 Aug 13 02:05 client.test.rsa_key                                                          
-rw-------. 1 root root  581 Aug 13 02:05 client.test.rsa_key.pub                                                      
-rw-------. 1 root root  525 Aug 13 02:05 dc.samba.test.ecdsa_key                                                      
-rw-------. 1 root root  189 Aug 13 02:05 dc.samba.test.ecdsa_key.pub                                                  
-rw-------. 1 root root  419 Aug 13 02:05 dc.samba.test.ed25519_key                                                    
-rw-------. 1 root root  109 Aug 13 02:05 dc.samba.test.ed25519_key.pub                                                
-rw-------. 1 root root 2622 Aug 13 02:05 dc.samba.test.rsa_key                                                        
-rw-------. 1 root root  581 Aug 13 02:05 dc.samba.test.rsa_key.pub                                                    
-rw-------. 1 root root  525 Aug 13 02:05 dns.test.ecdsa_key                                                           
-rw-------. 1 root root  189 Aug 13 02:05 dns.test.ecdsa_key.pub                                                       
-rw-------. 1 root root  419 Aug 13 02:05 dns.test.ed25519_key                                                         
-rw-------. 1 root root  109 Aug 13 02:05 dns.test.ed25519_key.pub                                                     
-rw-------. 1 root root 2610 Aug 13 02:05 dns.test.rsa_key
-rw-------. 1 root root  581 Aug 13 02:05 dns.test.rsa_key.pub                                                         
-rw-------. 1 root root  525 Aug 13 02:05 kdc.test.ecdsa_key                                                           
-rw-------. 1 root root  189 Aug 13 02:05 kdc.test.ecdsa_key.pub                                                       
-rw-------. 1 root root  419 Aug 13 02:05 kdc.test.ed25519_key                                                         
-rw-------. 1 root root  109 Aug 13 02:05 kdc.test.ed25519_key.pub                                                     
-rw-------. 1 root root 2622 Aug 13 02:05 kdc.test.rsa_key
-rw-------. 1 root root  581 Aug 13 02:05 kdc.test.rsa_key.pub                                                         
-rw-------. 1 root root  525 Aug 13 02:05 master.ipa.test.ecdsa_key                                                    
-rw-------. 1 root root  189 Aug 13 02:05 master.ipa.test.ecdsa_key.pub                                                
-rw-------. 1 root root  419 Aug 13 02:05 master.ipa.test.ed25519_key                                                  
-rw-------. 1 root root  109 Aug 13 02:05 master.ipa.test.ed25519_key.pub                                              
-rw-------. 1 root root 2622 Aug 13 02:05 master.ipa.test.rsa_key                                                      
-rw-------. 1 root root  581 Aug 13 02:05 master.ipa.test.rsa_key.pub                                                  
-rw-------. 1 root root  525 Aug 13 02:05 master.keycloak.test.ecdsa_key                                               
-rw-------. 1 root root  189 Aug 13 02:05 master.keycloak.test.ecdsa_key.pub                                           
-rw-------. 1 root root  419 Aug 13 02:05 master.keycloak.test.ed25519_key                                             
-rw-------. 1 root root  109 Aug 13 02:05 master.keycloak.test.ed25519_key.pub                                         
-rw-------. 1 root root 2622 Aug 13 02:05 master.keycloak.test.rsa_key                                                 
-rw-------. 1 root root  581 Aug 13 02:05 master.keycloak.test.rsa_key.pub                                             
-rw-------. 1 root root  525 Aug 13 02:05 master.ldap.test.ecdsa_key                                                   
-rw-------. 1 root root  189 Aug 13 02:05 master.ldap.test.ecdsa_key.pub                                               
-rw-------. 1 root root  419 Aug 13 02:05 master.ldap.test.ed25519_key                                                 
-rw-------. 1 root root  109 Aug 13 02:05 master.ldap.test.ed25519_key.pub                                             
-rw-------. 1 root root 2622 Aug 13 02:05 master.ldap.test.rsa_key                                                     
-rw-------. 1 root root  581 Aug 13 02:05 master.ldap.test.rsa_key.pub                                                 
-rw-------. 1 root root  525 Aug 13 02:05 nfs.test.ecdsa_key                                                           
-rw-------. 1 root root  189 Aug 13 02:05 nfs.test.ecdsa_key.pub                                                       
-rw-------. 1 root root  419 Aug 13 02:05 nfs.test.ed25519_key                                                         
-rw-------. 1 root root  109 Aug 13 02:05 nfs.test.ed25519_key.pub                                                     
-rw-------. 1 root root 2610 Aug 13 02:05 nfs.test.rsa_key
-rw-------. 1 root root  581 Aug 13 02:05 nfs.test.rsa_key.pub

pbrezina · 2024-08-14T10:16:31Z

Makefile

@@ -18,13 +18,18 @@ up-keycloak:
 	docker-compose -f docker-compose.yml -f docker-compose.keycloak.yml up \
 	--no-recreate --detach ${LIMIT}

+up-ipaipatrust:


This is something we can test in PR CI, so I think we can start second IPA with just make up. What do you think?

Sure, PR updated.

pbrezina · 2024-08-14T10:17:47Z

data/configs/dnsmasq.conf

@@ -12,6 +12,7 @@ cache-size=0

 # These zones have their own DNS server
 server=/ipa.test/172.16.100.10
+server=/ipa2.test/172.16.100.80


It does not matter much but you can use .11 instead of .80 to keep IPA servers grouped together.

Fixed, switched to 172.16.100.11

pbrezina · 2024-08-14T10:26:24Z

Hi @pbrezina Can you help me understand why docker.io/ubuntu:rolling build fails (https://github.com/SSSD/sssd-ci-containers/actions/runs/10370744252/job/28711693110?pr=106) when sshd does not restart properly on master2.ipa2.test. I see that the host keys are not found.
Aug 13 13:19:21 master2.ipa2.test sshd[6905]: Unable to load host key: /data/ssh-keys/hosts/master2.ipa2.test.ecdsa_key                                                    
Aug 13 13:19:21 master2.ipa2.test sshd[6905]: Unable to load host key: /data/ssh-keys/hosts/master2.ipa2.test.ed25519_key                                          
Aug 13 13:19:21 master2.ipa2.test sshd[6905]: Unable to load host key: /data/ssh-keys/hosts/master2.ipa2.test.rsa_key  
I ran src/tools/gen-ssh-keys.sh and added the ssh keys for master2.ipa2.test into this PR. I also added master2.ipa2.test into the for loop in src/tools/gen-ssh-keys.sh

However, these are not being copied into the master2.ipa2.test system.

Ubuntu does not provide ipa package so base-ipa container is actually pulled from quay.io/sssd/ci-base-$svc:lates which does not contain your changes. Maybe, it would be possible to use the base image we just created? But build.sh would have to change. Maybe introduce UNAVAILABLE_BASE_IMAGE variable or something like that.

pbrezina · 2024-08-14T11:42:24Z

Hi @pbrezina Can you help me understand why docker.io/ubuntu:rolling build fails (https://github.com/SSSD/sssd-ci-containers/actions/runs/10370744252/job/28711693110?pr=106) when sshd does not restart properly on master2.ipa2.test. I see that the host keys are not found.
Aug 13 13:19:21 master2.ipa2.test sshd[6905]: Unable to load host key: /data/ssh-keys/hosts/master2.ipa2.test.ecdsa_key                                                    
Aug 13 13:19:21 master2.ipa2.test sshd[6905]: Unable to load host key: /data/ssh-keys/hosts/master2.ipa2.test.ed25519_key                                          
Aug 13 13:19:21 master2.ipa2.test sshd[6905]: Unable to load host key: /data/ssh-keys/hosts/master2.ipa2.test.rsa_key  
I ran src/tools/gen-ssh-keys.sh and added the ssh keys for master2.ipa2.test into this PR. I also added master2.ipa2.test into the for loop in src/tools/gen-ssh-keys.sh
However, these are not being copied into the master2.ipa2.test system.
Ubuntu does not provide ipa package so base-ipa container is actually pulled from quay.io/sssd/ci-base-$svc:lates which does not contain your changes. Maybe, it would be possible to use the base image we just created? But build.sh would have to change. Maybe introduce UNAVAILABLE_BASE_IMAGE variable or something like that.

Actually it wouldn't work because we run each distro on different host. We would need to store it as artifact and then download it and install it.

justin-stephenson · 2024-08-14T19:25:34Z

Ubuntu does not provide ipa package so base-ipa container is actually pulled from quay.io/sssd/ci-base-$svc:lates which does not contain your changes. Maybe, it would be possible to use the base image we just created? But build.sh would have to change. Maybe introduce UNAVAILABLE_BASE_IMAGE variable or something like that.

Actually it wouldn't work because we run each distro on different host. We would need to store it as artifact and then download it and install it.

Can ssh keys from both IPA servers master.ipa.test and master2.ipa2.test be added to quay.io/sssd/ci-base-ipa:latest ?

jakub-vavra-cz · 2024-08-15T05:47:38Z

src/ansible/roles/packages/tasks/Fedora.yml

@@ -264,7 +264,7 @@
      - ci-sssd-random
      - umockdev
    when: passkey_support
-  when: "'base_client' in group_names or 'client' in group_names or 'base_ipa' in group_names or 'ipa' in group_names"
+  when: "'base_client' in group_names or 'client' in group_names or 'base_ipa' in group_names or 'base_ipa2' in group_names or 'ipa' in group_names"


Here is still base_ipa2.

jakub-vavra-cz

The base_ipa2 is still present.

justin-stephenson · 2024-08-15T15:39:50Z

The base_ipa2 is still present.

Removed fully.

jakub-vavra-cz · 2024-08-16T07:59:15Z

src/ansible/playbook_image_service.yml

@@ -16,7 +16,9 @@
  roles:
  - samba

- hosts: master.ipa.test
+- hosts:


This should target group ipa.

Updated as part of rebase.

pbrezina · 2024-08-16T10:17:26Z

Ubuntu does not provide ipa package so base-ipa container is actually pulled from quay.io/sssd/ci-base-$svc:lates which does not contain your changes. Maybe, it would be possible to use the base image we just created? But build.sh would have to change. Maybe introduce UNAVAILABLE_BASE_IMAGE variable or something like that.

Actually it wouldn't work because we run each distro on different host. We would need to store it as artifact and then download it and install it.

Can ssh keys from both IPA servers master.ipa.test and master2.ipa2.test be added to quay.io/sssd/ci-base-ipa:latest ?

No until this PR is merged. But you could do it manually, however it's probably not worth the effort.

pbrezina · 2024-08-16T10:20:47Z

Justin, you can try removing the ssh host keys completely when you will rebase on top of Jakub's changes. I'm pretty sure I added them as a workaround for something, but I don't remember anymore. Maybe, it is not needed anymore.

justin-stephenson · 2024-08-16T17:26:53Z

Justin, you can try removing the ssh host keys completely when you will rebase on top of Jakub's changes. I'm pretty sure I added them as a workaround for something, but I don't remember anymore. Maybe, it is not needed anymore.

I rebased and removed the host keys.

jakub-vavra-cz

LGTM

danlavu · 2024-12-09T14:52:33Z

@justin-stephenson , before I go deeper into the PR. I think we should create a new network for ipa2 and make it more realistic.

server=/ipa2.test/172.16.101.10

WDYT?

justin-stephenson · 2024-12-09T15:57:17Z

@justin-stephenson , before I go deeper into the PR. I think we should create a new network for ipa2 and make it more realistic.
server=/ipa2.test/172.16.101.10
WDYT?

Forgive my ignorance but what is the benefit?

danlavu · 2024-12-09T17:01:43Z

Forgive my ignorance but what is the benefit?

Realism mostly, two domains sharing the same class C network, while it works, it's not suggested per our installation docs. I don't think it helps us to to test against an unsupported installation.

I do recall there has seem some automation limitations in the past, definitely one, maybe two bugs we would've caught if it wasn't sharing the same subnet.

justin-stephenson · 2024-12-09T19:03:20Z

Forgive my ignorance but what is the benefit?

Realism mostly, two domains sharing the same class C network, while it works, it's not suggested per our installation docs. I don't think it helps us to to test against an unsupported installation.

I do recall there has seem some automation limitations in the past, definitely one, maybe two bugs we would've caught if it wasn't sharing the same subnet.

I don't have a strong opinion either way, @pbrezina can you provide your thoughts?

danlavu · 2024-12-10T01:31:22Z

I don't have a strong opinion either way, @pbrezina can you provide your thoughts?

FWIW, I feel strongly about this. Testing against a supported/gss certified setup than a test. While it doesn't apply here, the downstream multi-domain AD stuff needs to be segmented this way otherwise dcpromo will fail.

pbrezina · 2024-12-10T15:28:01Z

Forgive my ignorance but what is the benefit?

Realism mostly, two domains sharing the same class C network, while it works, it's not suggested per our installation docs. I don't think it helps us to to test against an unsupported installation.
I do recall there has seem some automation limitations in the past, definitely one, maybe two bugs we would've caught if it wasn't sharing the same subnet.

I don't have a strong opinion either way, @pbrezina can you provide your thoughts?

I think it just unnecessarily complicates the setup. I have no idea if adding a network in a docker-compose is sufficient or additional tinkering to make the networks accessible from each other will be required.

But I don't have opinion whether it should or should not be done, I'm fine either way.

danlavu · 2024-12-10T15:46:00Z

A new docker net will be sufficient, I know it's extra complexity, but it's worth it.

justin-stephenson · 2024-12-11T14:11:11Z

A new docker net will be sufficient, I know it's extra complexity, but it's worth it.

Is it more than a simple one-line change? If yes would you mind adding a commit to this PR with these changes and pushing to this PR?

jakub-vavra-cz · 2024-12-12T14:23:14Z

Just be aware that we can't copy this that easily in idmci (without hadcoding specific openstack networks). We also need to make sure that the same network will still work.

danlavu · 2024-12-12T21:36:47Z

Just be aware that we can't copy this that easily in idmci (without hadcoding specific openstack networks). We also need to make sure that the same network will still work.

Ack, I did run it in IDMCI and the provision passes, I'll go ahead and test it.

2024-12-10T05:40:24 PLAY RECAP *********************************************************************
2024-12-10T05:40:24 client.test                : ok=82   changed=46   unreachable=0    failed=0    skipped=45   rescued=0    ignored=0   
2024-12-10T05:40:24 dc-nhhq.ad-nhhq.test       : ok=17   changed=8    unreachable=0    failed=0    skipped=8    rescued=0    ignored=0   
2024-12-10T05:40:24 dc.samba.test              : ok=67   changed=44   unreachable=0    failed=0    skipped=44   rescued=0    ignored=0   
2024-12-10T05:40:24 dns.test                   : ok=57   changed=26   unreachable=0    failed=0    skipped=42   rescued=0    ignored=0   
2024-12-10T05:40:24 kdc.test                   : ok=57   changed=27   unreachable=0    failed=0    skipped=46   rescued=0    ignored=0   
2024-12-10T05:40:24 master.ipa.test            : ok=61   changed=35   unreachable=0    failed=0    skipped=47   rescued=0    ignored=0   
2024-12-10T05:40:24 master.ldap.test           : ok=61   changed=31   unreachable=0    failed=0    skipped=44   rescued=0    ignored=0   
2024-12-10T05:40:24 master2.ipa2.test          : ok=60   changed=34   unreachable=0    failed=0    skipped=48   rescued=0    ignored=0   
2024-12-10T05:40:24 nfs.test                   : ok=54   changed=24   unreachable=0    failed=0    skipped=46   rescued=0    ignored=0

justin-stephenson · 2024-12-18T17:22:26Z

I rebased this PR, and also added capabilities to the 'ipa2' section in docker-compose.yml similar to

211908d

danlavu · 2024-12-19T03:49:33Z

@justin-stephenson, I have the configuration provisioning but the networks are not routable to one another so I'm trying to figure that out.

sumit-bose · 2025-02-12T14:35:29Z

Hi,

jfyi, I was still able to setup a test environment with this PR.

bye,
Sumit

This was referenced Aug 1, 2024

Add IPA IPA Trust Topology Controller SSSD/sssd-test-framework#119

Open

Tests: Add support for IPA IPA Trust SSSD/sssd#7517

Open

justin-stephenson marked this pull request as ready for review August 1, 2024 13:43

jakub-vavra-cz reviewed Aug 1, 2024

View reviewed changes

src/ansible/roles/dns/templates/etc.dnsmasq.conf.j2 Outdated Show resolved Hide resolved

jakub-vavra-cz reviewed Aug 1, 2024

View reviewed changes

src/ansible/roles/cleanup/tasks/main.yml Outdated Show resolved Hide resolved

jakub-vavra-cz reviewed Aug 1, 2024

View reviewed changes

src/ansible/roles/cleanup/tasks/main.yml Outdated Show resolved Hide resolved

jakub-vavra-cz reviewed Aug 1, 2024

View reviewed changes

andreboscatto assigned jakub-vavra-cz, danlavu and pbrezina Aug 6, 2024

andreboscatto requested review from danlavu and pbrezina August 6, 2024 12:36

justin-stephenson force-pushed the ipa_ipa_trust branch 2 times, most recently from 6301e05 to 46ac0c5 Compare August 13, 2024 13:31

pbrezina reviewed Aug 14, 2024

View reviewed changes

justin-stephenson force-pushed the ipa_ipa_trust branch from 46ac0c5 to fe0bad4 Compare August 14, 2024 19:23

jakub-vavra-cz reviewed Aug 15, 2024

View reviewed changes

jakub-vavra-cz requested changes Aug 15, 2024

View reviewed changes

justin-stephenson force-pushed the ipa_ipa_trust branch from fe0bad4 to 192a817 Compare August 15, 2024 15:39

jakub-vavra-cz reviewed Aug 16, 2024

View reviewed changes

justin-stephenson force-pushed the ipa_ipa_trust branch from 192a817 to 48104c2 Compare August 16, 2024 15:26

jakub-vavra-cz approved these changes Aug 19, 2024

View reviewed changes

alexey-tikhonov added the blocked label Sep 3, 2024

justin-stephenson force-pushed the ipa_ipa_trust branch from 48104c2 to f6d482a Compare December 18, 2024 17:14

sumit-bose mentioned this pull request Feb 12, 2025

Initial support for IDM IDM Trust SSSD/sssd#7679

Closed

Support IPA IPA Trust with additional IPA server

c8f6bdd

justin-stephenson force-pushed the ipa_ipa_trust branch from f6d482a to c8f6bdd Compare February 25, 2025 15:08

Support IPA IPA Trust with additional IPA server #106

Are you sure you want to change the base?

Support IPA IPA Trust with additional IPA server #106

Conversation

justin-stephenson commented Aug 1, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

justin-stephenson commented Aug 13, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pbrezina commented Aug 14, 2024

pbrezina commented Aug 14, 2024

justin-stephenson commented Aug 14, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jakub-vavra-cz left a comment

Choose a reason for hiding this comment

justin-stephenson commented Aug 15, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pbrezina commented Aug 16, 2024 • edited Loading

pbrezina commented Aug 16, 2024

justin-stephenson commented Aug 16, 2024

jakub-vavra-cz left a comment

Choose a reason for hiding this comment

danlavu commented Dec 9, 2024

justin-stephenson commented Dec 9, 2024

danlavu commented Dec 9, 2024

justin-stephenson commented Dec 9, 2024

danlavu commented Dec 10, 2024

pbrezina commented Dec 10, 2024

danlavu commented Dec 10, 2024

justin-stephenson commented Dec 11, 2024

jakub-vavra-cz commented Dec 12, 2024

danlavu commented Dec 12, 2024

justin-stephenson commented Dec 18, 2024

danlavu commented Dec 19, 2024

sumit-bose commented Feb 12, 2025

justin-stephenson commented Aug 1, 2024 •

edited

Loading

pbrezina commented Aug 16, 2024 •

edited

Loading