Infrastructure/infra-docs-fpo
1
0
Fork 0
Code Issues 100 Pull requests 6 Projects Releases Packages Wiki Activity Actions

DC move: iad => rdu3, 10.3. => 10.16.

Browse source 
And remove some obsolete things.

Signed-off-by: Nils Philippsen <nils@redhat.com>
This commit is contained in:
Nils Philippsen 2025-07-04 11:55:02 +02:00
parent f3756ceb83
commit b4afb2f945
83 changed files with 386 additions and 429 deletions
Download patch file Download diff file Expand all files Collapse all files

26
modules/sysadmin_guide/pages/fedmsg-certs.adoc
View file

@ -31,11 +31,11 @@ Every instance of each service on each host has its own cert and private
key, signed by the CA. By convention, we name the certs
`<service>-<fqdn>.\{crt,key}` For instance, bodhi has the following certs:
* bodhi-app01.iad2.fedoraproject.org
* bodhi-app02.iad2.fedoraproject.org
* bodhi-app03.iad2.fedoraproject.org
* bodhi-app01.stg.iad2.fedoraproject.org
* bodhi-app02.stg.iad2.fedoraproject.org
* bodhi-app01.rdu3.fedoraproject.org
* bodhi-app02.rdu3.fedoraproject.org
* bodhi-app03.rdu3.fedoraproject.org
* bodhi-app01.stg.rdu3.fedoraproject.org
* bodhi-app02.stg.rdu3.fedoraproject.org
* more
Scripts to generate new keys, sign them, and revoke them live in the
@ -60,7 +60,7 @@ The attempt here is to minimize the number of potential attack vectors.
Each private key should be readable only by the service that needs it.
bodhi runs under mod_wsgi in apache and should run as its own unique
bodhi user (not as apache). The permissions for
its _iad2.fedoraproject.org_ private_key, when deployed by ansible, should
its _rdu3.fedoraproject.org_ private_key, when deployed by ansible, should
be read-only for that local bodhi user.
For more information on how fedmsg uses these certs see
@ -105,15 +105,15 @@ $ ./build-and-sign-key <service>-<fqdn>
....
For instance, if we bring up a new app host,
_app10.iad2.fedoraproject.org_, we'll need to generate a new cert/key pair
_app10.rdu3.fedoraproject.org_, we'll need to generate a new cert/key pair
for each fedmsg-enabled service that will be running on it, so you'd
run:
....
$ source ./vars
$ ./build-and-sign-key shell-app10.iad2.fedoraproject.org
$ ./build-and-sign-key bodhi-app10.iad2.fedoraproject.org
$ ./build-and-sign-key mediawiki-app10.iad2.fedoraproject.org
$ ./build-and-sign-key shell-app10.rdu3.fedoraproject.org
$ ./build-and-sign-key bodhi-app10.rdu3.fedoraproject.org
$ ./build-and-sign-key mediawiki-app10.rdu3.fedoraproject.org
....
Just creating the keys isn't quite enough, there are four more things
@ -131,9 +131,9 @@ to be blown away and recreated, the new service-hosts will be included.
For the examples above, you would need to add to the list:
....
shell-app10.iad2.fedoraproject.org
bodhi-app10.iad2.fedoraproject.org
mediawiki-app10.iad2.fedoraproject.org
shell-app10.rdu3.fedoraproject.org
bodhi-app10.rdu3.fedoraproject.org
mediawiki-app10.rdu3.fedoraproject.org
....
You need to ensure that the keys are distributed to the host with the