please don't remove enrolled centos machines from IPA in staging #12514
Labels
No labels
announcement
authentication
automate
aws
backlog
blocked
bodhi
ci
Closed As
Duplicate
Closed As
Fixed
Closed As
Fixed with Explanation
Closed As
Initiative Worthy
Closed As
Insufficient data
Closed As
Invalid
Closed As
Spam
Closed As
Upstream
Closed As
Will Not or Can Not fix
cloud
communishift
copr
database
deprecated
dev
discourse
dns
downloads
easyfix
epel
factory2
firmitas
gitlab
greenwave
hardware
help wanted
high-gain
high-trouble
iad2
koji
koschei
lists
low-gain
low-trouble
mbs
medium-gain
medium-trouble
mini-initiative
mirrorlists
monitoring
Needs investigation
notifier
odcs
OpenShift
ops
OSBS
outage
packager_workflow_blocker
pagure
permissions
Priority
Needs Review
Priority
Next Meeting
Priority
🔥 URGENT 🔥
Priority
Waiting on Assignee
Priority
Waiting on External
Priority
Waiting on Reporter
rabbitmq
rdu-cc
release-monitoring
releng
repoSpanner
request-for-resources
s390x
security
SMTP
src.fp.o
staging
taiga
unfreeze
waiverdb
websites-general
wiki
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Infrastructure/fedora-infrastructure#12514
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As CentOS and Fedora are using shared IPA backend for authentication, I'd request that nothing touching enrolled centos machines in IPA would be done (manually or through scripts)
I had to just waste my time this morning investigating why ipsilon (https://id.stg.centos.org) wasn't allowing anyone to auth (and so no openidc for services using our ipsilon instance)
Someone (who ? or a script ?) removed
ipsilon.stg.iad2.centos.org
from the ipsilon HBAC rule, denying so all auth requests .Can you identify the root cause and ensure it wouldn't happen again please ?
Thanks a lot
Metadata Update from @zlopez:
seems related to https://pagure.io/fedora-infra/ansible/blob/main/f/playbooks/groups/ipsilon.yml#_92 ...
Metadata Update from @arrfab:
Metadata Update from @zlopez:
The change you are referring to happened 4 years ago. So I assume that didn't caused the machine to be removed.
Metadata Update from @kevin:
It's actually https://pagure.io/fedora-infra/ansible/blob/main/f/playbooks/groups/ipsilon.yml#_101
It was using the wrong hostname... but that was set in 2021?
b8e6754f97c (Aurélien Bompard 2021-03-22 17:07:45 +0100 101) host: "{{ (env == 'production')|ternary('ipsilon.iad2.centos.org', 'centos-ipa-client02.stg.iad2.fedoraproject.org') }}"
anyhow, I changed it to ipsilon.stg.iad2.centos.org
If you can confirm it's fixed / working?
forgot to give feedback (PTO) but yes, now working again ...
Is there a way to ensure that ansible would not remove hosts not managed by itself ?
Otherwise, just ensure that it's documented somewhere as that means that on my centos ansible infra side I'll never be autonomous to deploy/enroll a machine as then Fedora ansible would remove it :/
Well, I mean we could remove that task from our playbooks and you could depend on yourself to create that ?
Otherwise ansible is going to setup the thing thats defined.
Do you want us to remove that setup from our side?
@kevin : even if you remove that block, I guess that the other one about Fedora host would then remove the existing centos machines again .. so isn't there a parameter for that
ipahbacrule
to not purge things not declared ? if not then we'll have to still hard-code centos machines there but with dc move and so multiple machines that will need to be enrolled, I'd like that to be documented at least :)well, my reading / understanding of it is that:
https://pagure.io/fedora-infra/ansible/blob/main/f/playbooks/groups/ipsilon.yml#_85 creates the 'ipsilon' hbac rule and
https://pagure.io/fedora-infra/ansible/blob/main/f/playbooks/groups/ipsilon.yml#_101
has action: member, so it adds those members/hosts.
So, I guess we could change the first one to just confirm/add the fedora ipsilon servers and then it wouldn't recreate the rule...
but then the rule would have to be... manually created or something?
Would this be high trouble, medium trouble, low trouble or a timeboxed investigation?
What if we do this:
ie, we remove the host call from the one that makes the hbrbac rule, so it should just create it if it doesn't exist.
Then we populate the fedora hosts in a seperate host level task.