Compare commits
No commits in common. "main" and "mailman_management" have entirely different histories.
main
...
mailman_ma
25 changed files with 19 additions and 819 deletions
|
|
@ -1,6 +1,3 @@
|
|||
**This repository is now moved to
|
||||
[Fedora Infra documentation](https://docs.fedoraproject.org/infra/howtos/)**
|
||||
|
||||
# How to do things around the infrastructure.
|
||||
|
||||
This repo contains the steps on How to do a tasks in the infrastructure. It is meant to be a knowledge database that can be quickly accessed and updated.
|
||||
|
|
|
|||
|
|
@ -1,32 +0,0 @@
|
|||
# Add external servers to vpn
|
||||
|
||||
- In the Fedora Infra Ansible repo edit the file **roles/batcave/files/allows**.
|
||||
Under the correct section add **require ip** ***<server_ip>***
|
||||
|
||||
- When this change is pushed run the batcave ansible playbook on the batcave.
|
||||
You will need sysadmin-main access for this
|
||||
|
||||
- Create openvpn and 2fa certificates for the new server.
|
||||
This requires sysadmin main access
|
||||
|
||||
> * https://pagure.io/fedora-infra/howtos/blob/main/f/generate_2fa_keys.md
|
||||
> * https://pagure.io/fedora-infra/howtos/blob/main/f/generate_openvpn_keys.md
|
||||
|
||||
- In the dns repo on batcave edit the file master/168.192.in-addr.arpa
|
||||
Add the new host to one of the unused adresses.
|
||||
Ensure the hostname ends in .vpn.fedoraproject.org.
|
||||
Don't forget to update the serial before saving.
|
||||
|
||||
- Also edit the master/vpn.fedoraproject.org file to add the server with
|
||||
the new 192.168.*.* address created in the previous step to the required section
|
||||
Don't forget to update the serial before saving.
|
||||
|
||||
- When the above edits are done follow the instructions in the DNS sysadmin sop
|
||||
about signing and pushing new dns chnages.
|
||||
> https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/dns/
|
||||
|
||||
- Finally in the Fedora Infra Ansible repo add a new file
|
||||
**roles/openvpn/server/files/ccd/*<server_name>*** with the new 192.168.*.* address.
|
||||
View one of the existing files in the repo for a sample of formatting.
|
||||
This change will be run when the server is provisioned.
|
||||
|
||||
|
|
@ -1,152 +0,0 @@
|
|||
# How to archive a Fedora Release
|
||||
.. title: How to Archive Old Fedora Releases.
|
||||
.. slug: archive-old-fedora
|
||||
.. date: 2016-04-08 updated: 2020-09-25
|
||||
.. taxonomy: Releng/Infrastructure
|
||||
|
||||
|
||||
## Document Info
|
||||
|
||||
The Fedora download servers contain terabytes of data, and to allow
|
||||
for mirrors to not have to take all of that data, infrastructure
|
||||
regularly moves data of end of lifed releases (from /pub/fedora/linux)
|
||||
to the archives section (/pub/archive/fedora/linux)
|
||||
|
||||
## Steps Involved
|
||||
|
||||
1. log into ```batcave01.iad2.fedoraproject.org```
|
||||
2. sudo log into a server which has read-write access to the download
|
||||
NFS partition. Then change to the appropriate user.
|
||||
```
|
||||
$ sudo -i ssh root@bodhi-backend01.iad2.fedoraproject.org
|
||||
# su - ftpsync
|
||||
$
|
||||
```
|
||||
3. Then change into the releases directory.
|
||||
```
|
||||
$ cd /pub/fedora/linux/releases
|
||||
```
|
||||
|
||||
4. Check to see that the target directory doesn't already exist.
|
||||
```
|
||||
$ ls /pub/archive/fedora/linux/releases/
|
||||
$ ls /pub/archive/fedora-secondary/releases/
|
||||
```
|
||||
|
||||
5. If the target directory does not already exist, do a recursive link
|
||||
copy of the tree you want to the target. This works because
|
||||
currently archives is on the same partition.
|
||||
```
|
||||
$ cp -lvpnr 21 /pub/archive/fedora/linux/releases/21
|
||||
```
|
||||
Common errors which might occur at this time is finding that the
|
||||
NFS partition is not mounted read-write. Other errors can occur
|
||||
where the NFS is read-write, but ftpsync does not have rights to
|
||||
copy a file. These need to be dealt with individually.
|
||||
|
||||
Another error which happens when I script things is that you find
|
||||
out that everything got copied into
|
||||
/pub/archive/fedora/linux/releases/21/21 even though it shouldn't.
|
||||
|
||||
6. If the target directory already exists, then we need to do a
|
||||
recursive rsync to update any changes in the trees since the
|
||||
previous copy.
|
||||
|
||||
```
|
||||
$ rsync -avSAXHP --delete ./21/ /pub/archive/fedora/linux/releases/21/
|
||||
```
|
||||
|
||||
Again common errors which need to be dealt with are permission
|
||||
items. Usually it is contacting other people in release
|
||||
engineering to see what is needed.
|
||||
|
||||
7. We now do the updates and updates/testing in similar ways.
|
||||
|
||||
```
|
||||
$ cd ../updates/
|
||||
$ cp -lpnr 21 /pub/archive/fedora/linux/updates/21
|
||||
$ cd testing
|
||||
$ cp -lpnr 21 /pub/archive/fedora/linux/updates/testing/21
|
||||
|
||||
$ cd ../updates/
|
||||
$ rsync -avSAXHP --delete 21/ /pub/archive/fedora/linux/updates/21/
|
||||
$ cd testing
|
||||
$ rsync -avSAXHP --delete 21/ /pub/archive/fedora/linux/updates/testing/21/
|
||||
```
|
||||
|
||||
8. At this point we now do the same with the fedora-secondary trees
|
||||
with similar syntax.
|
||||
```
|
||||
$ cd /pub/fedora-secondary/releases/
|
||||
$ cp -lpnr 21 /pub/archive/fedora-secondary/releases/21
|
||||
$ cd ../updates/
|
||||
$ cp -lpnr 21 /pub/archive/fedora-secondary/updates/21
|
||||
$ cd testing
|
||||
$ cp -lpnr 21 /pub/archive/fedora-secondary/updates/testing/21
|
||||
|
||||
$ cd /pub/fedora-secondary/releases/
|
||||
$ rsync -avSAXHP --delete 21/ /pub/archive/fedora-secondary/releases/21/
|
||||
$ cd ../updates/
|
||||
$ rsync -avSAXHP --delete 21/ /pub/archive/fedora-secondary/updates/21/
|
||||
$ cd testing
|
||||
$ rsync -avSAXHP --delete 21/ /pub/archive/fedora-secondary/updates/testing/21/
|
||||
```
|
||||
|
||||
8. Announce to the mirror list this has been done and that in 2 weeks
|
||||
you will move the old trees to archives.
|
||||
|
||||
9. In two weeks, log into mm-backend01 and run the archive script
|
||||
|
||||
```
|
||||
$ sudo -i ssh root@mm-backend01.iad2.fedoraproject.org
|
||||
# sudo -u mirrormanager mm2_move-to-archive \
|
||||
--originalCategory="Fedora Linux" \
|
||||
--archiveCategory="Fedora Archive" \
|
||||
--directoryRe='/21/Everything'
|
||||
# sudo -u mirrormanager mm2_move-to-archive \
|
||||
--originalCategory="Fedora Secondary Linux" \
|
||||
--archiveCategory="Fedora Archive" \
|
||||
--directoryRe='/21/Everything'
|
||||
```
|
||||
|
||||
10. If there are problems, the postgres DB may have issues and so you need to
|
||||
get a DBA to update the backend to fix items.
|
||||
|
||||
11. Wait an hour or so then you can remove the files from the main tree.
|
||||
|
||||
```
|
||||
$ sudo -i ssh bodhi-backend01.iad2.fedoraproject.org
|
||||
# su - ftpsync
|
||||
$ cd /pub/fedora/linux/releases
|
||||
$ cd 21
|
||||
$ ls # make sure you have stuff here
|
||||
$ rm -rf *
|
||||
$ ln ../20/README .
|
||||
$ cd ../../updates/21
|
||||
$ ls # make sure you have stuff here
|
||||
$ rm -rf *
|
||||
$ ln ../20/README .
|
||||
$ cd ../testing/21
|
||||
$ ls # make sure you have stuff here
|
||||
$ rm -rf *
|
||||
$ ln ../20/README .
|
||||
|
||||
$ cd /pub/fedora-secondary/releases
|
||||
$ cd 21
|
||||
$ ls # make sure you have stuff here
|
||||
$ rm -rf *
|
||||
$ ln ../20/README .
|
||||
$ cd ../../updates/21
|
||||
$ ls # make sure you have stuff here
|
||||
$ rm -rf *
|
||||
$ ln ../20/README .
|
||||
$ cd ../testing/21
|
||||
$ ls # make sure you have stuff here
|
||||
$ rm -rf *
|
||||
$ ln ../20/README .
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,22 +1,27 @@
|
|||
# How to remove 2 factor authentication tokens in IPA using ui
|
||||
# How to remove 2 factors authentication tokens?
|
||||
|
||||
* log into `https://id.fedoraproject.org/ipa/ui/` using noggin credentials
|
||||
* become root on os-master01 and/or os-master01.stg
|
||||
|
||||
* Click on the `Authentication` tab
|
||||
* Run the following commands:
|
||||
|
||||
* Click on the `OTP Tokens` sub tab
|
||||
```
|
||||
oc project fas
|
||||
oc get pods
|
||||
```
|
||||
|
||||
* Enter the username into the search bar. This will display a list of tokens associated with the user.
|
||||
* Look for the totpcgi-N-hash pods
|
||||
|
||||
* Select the desired token and click delete. A popup will appear, click delete again to confirm.
|
||||
* Log into that pod:
|
||||
|
||||
# How to remove 2 factor authentication tokens in IPA using cli
|
||||
```
|
||||
oc rsh <one of the pods above>
|
||||
```
|
||||
|
||||
* kinit as user with admin privileges on ipa server
|
||||
* Clean the tokens:
|
||||
|
||||
* Run `ipa otptoken-find --owner=<username>`
|
||||
```
|
||||
totpprov delete-user <fas username>
|
||||
```
|
||||
|
||||
* A list of the users otp tokens will be displayed. Copy `Unique ID` vlaue of the desired token
|
||||
|
||||
* Run `ipa otptoken-del <Unique_ID>`. The token is now removed
|
||||
* say yes, exit, and repeat for stg/prod as each has their own db.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,24 +0,0 @@
|
|||
# How to clean up the side-tags created by the monitor-gating project?
|
||||
|
||||
Monitor-gating runs in openshift and monitors the packager workflow end to end.
|
||||
Doing this for single build and multi-builds updates by gettings few tests
|
||||
packages go through that workflow.
|
||||
|
||||
If something happens and side-tags accumulates in koji, they can be cleaned
|
||||
using the following steps:
|
||||
|
||||
* Go to openshift
|
||||
https://os.fedoraproject.org/console/project/monitor-gating/overview
|
||||
(this links points directly to the monitor-gating project)
|
||||
|
||||
* Access the running pod
|
||||
|
||||
* Click on the "Terminal" tab to have a shell in that pod
|
||||
|
||||
* Run the following command:
|
||||
|
||||
python3 /opt/code/clean_up_side_tags.py /opt/config/runner.cfg
|
||||
|
||||
It will go through all the side-tags created by this user/keytab and delete
|
||||
them using fedpkg remove-side-tag. It will do this for all but one (which may be
|
||||
in use by the script when the command is ran).
|
||||
|
|
@ -1,64 +0,0 @@
|
|||
# Creating fedscm-admin token for releng
|
||||
|
||||
Members of the releng team that are processing fedora-scm-requests are using
|
||||
the CLI tool: fedscm-admin.
|
||||
They will need a few access to be able to use this tool properly:
|
||||
|
||||
- they will need a token to add/adjust things in PDC
|
||||
- they will need a token to create/modify things on src.fp.o
|
||||
- they will need a token to act on the fedora-scm-requests repo on pagure.io (this one
|
||||
can be created by themselves once they are given the access)
|
||||
|
||||
This doc covers the second point.
|
||||
|
||||
|
||||
* Log into pkgs01.iad2.fedoraproject.org
|
||||
* Run the following command:
|
||||
|
||||
````
|
||||
pagure-admin admin-token create <username> <expiration_date>
|
||||
````
|
||||
|
||||
For example:
|
||||
|
||||
````
|
||||
pagure-admin admin-token create petersen 2020-06-30
|
||||
````
|
||||
|
||||
This will ask you which ACLs you want this token to have, select:
|
||||
- create_project
|
||||
- modify_project
|
||||
- create_branch
|
||||
- generate_acls_project
|
||||
|
||||
Then confirm the creation of the token.
|
||||
|
||||
Once the token is created, you can check that it was properly created by doing:
|
||||
|
||||
````
|
||||
pagure-admin admin-token list --user<username>
|
||||
````
|
||||
|
||||
This will return all the active admin-token of that user. You should find the
|
||||
newly created token there.
|
||||
|
||||
You can also check the ACLs of that token by doing:
|
||||
````
|
||||
pagure-admin admin-token info <token>
|
||||
````
|
||||
|
||||
Finally, you can edit the expiration date of the token by doing:
|
||||
````
|
||||
pagure-admin admin-token update <token> <expiration_date>
|
||||
````
|
||||
|
||||
For example:
|
||||
````
|
||||
pagure-admin admin-token update foobarbaz 2000-01-01
|
||||
````
|
||||
|
||||
|
||||
|
||||
/!\ Note: there is no need to send that token to the user, simply ask them to
|
||||
check their API tokens in their settings' page. It will be shown there :)
|
||||
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
# How to create a keytab for an user?
|
||||
|
||||
First obtain Kerberos ticket with kinit:
|
||||
|
||||
```
|
||||
$ kinit myusername@FEDORAPROJECT.ORG
|
||||
Password for myusername@FEDORAPROJECT.ORG:
|
||||
```
|
||||
|
||||
Then obtain kvno value:
|
||||
|
||||
```
|
||||
$ kvno myusername@FEDORAPROJECT.ORG
|
||||
myusername@FEDORAPROJECT.ORG: kvno = 42
|
||||
```
|
||||
|
||||
Ticket is no longer needed and can be destroyed:
|
||||
|
||||
```
|
||||
$ kdestroy -p myusername@FEDORAPROJECT.ORG
|
||||
```
|
||||
|
||||
Generate keytab and write it to disk:
|
||||
|
||||
```
|
||||
$ ktutil
|
||||
ktutil: addent -password -p myusername@FEDORAPROJECT.ORG -k 42 -f
|
||||
Password for myusername@FEDORAPROJECT.ORG:
|
||||
ktutil: wkt /tmp/kt/fedora
|
||||
ktutil: q
|
||||
```
|
||||
|
||||
Done. You can now use the keytab to obtain the ticket without typing password:
|
||||
|
||||
```
|
||||
$ kinit -kt /tmp/kt/fedora myusername@FEDORAPROJECT.ORG
|
||||
```
|
||||
|
||||
|
||||
(source: https://pagure.io/fedora-infrastructure/issue/9544#comment-706949)
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
# How to create a group in dist-git?
|
||||
|
||||
/!\ You may want to read first groups_in_fedora.md for information on the
|
||||
different types of groups in Fedora.
|
||||
|
||||
Dist-git does not allow anyone to create groups, only admins can do it via the
|
||||
``pagure-admin`` CLI tool.
|
||||
|
||||
To create a group, you can simply run the command on pkgs01.iad2.fedoraproject.org:
|
||||
|
||||
::
|
||||
|
||||
pagure-admin new-group <group_name> <username of requester> \
|
||||
--description="short description" \
|
||||
--display="Name used in the UI"
|
||||
|
||||
The group members are then sync upon their login in dist-git (ie: people will
|
||||
have to log out and back in for their group membership to be refreshed).
|
||||
|
||||
How to give groups from someone to someone else can be found in:
|
||||
``give_groups_dist_git.md``
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
# How to deal with spam posts on discourse
|
||||
|
||||
When an ticket is raised for a spam user on the Fedora infra tracker take the
|
||||
following actions.
|
||||
|
||||
## Disable user in IPA
|
||||
|
||||
### Frontend
|
||||
|
||||
* Login to the [ipa server](https://id.fedoraproject.org/ipa/ui) and search the users name.
|
||||
* Click on the user.
|
||||
* In the Actions dropdown menu click disable
|
||||
|
||||
|
||||
### Command line
|
||||
|
||||
* ssh to ipa01.iad2.fedoraproject.org
|
||||
* run `ipa user-disable <user>`
|
||||
|
|
@ -45,25 +45,6 @@ git push
|
|||
|
||||
Source: https://pagure.io/fedora-infrastructure/issue/8638
|
||||
|
||||
# Regenerating TLS certificates
|
||||
|
||||
* First revoke old certificate
|
||||
|
||||
In the staging subdir run
|
||||
```
|
||||
/usr/share/easy-rsa/3/easyrsa revoke <service-name>
|
||||
```
|
||||
|
||||
Same for production, but without `.stg` in name and the commands need to be run from production subdir
|
||||
|
||||
* Remove the cert from `index.txt` and `index.txt.old`
|
||||
|
||||
The easiest way around this is to simply to a ``git grep <name of your cert>``.
|
||||
It should tell you that the name can be found in ``index.txt`` (and potentially
|
||||
``index.txt.old`` if another certificate was generated since the first attempt
|
||||
and yours).
|
||||
|
||||
* Follow the `How to create TLS certificates for fedora-messaging` section in this How-To
|
||||
|
||||
## Debugging
|
||||
|
||||
|
|
|
|||
|
|
@ -1,20 +0,0 @@
|
|||
# How to fix SAML login in bugzilla/AWS
|
||||
|
||||
Basically, we've observed that every now and then one of the ipsilon pod looses
|
||||
its config (or so it seems) which leads to make that pod unable to properly
|
||||
serve SAML requests.
|
||||
|
||||
Here are the steps to debug and fix this situation:
|
||||
|
||||
- Open all the web pod of ipsilon in different tags - Open the logs tab for
|
||||
each
|
||||
- Open bugzilla.redhat.com in a tab using the private browser mode
|
||||
- Try logging into bugzilla using the Fedora contributor button in the drop-down
|
||||
- Check the recent logs of the pods and find the one saying something like:
|
||||
``DEBUG(providers/saml2/auth.py:176 Redirect.saml2login()): saml2: 'NoneType' object has no attribute 'get_login_handler'``
|
||||
- copy the name of that pod
|
||||
- Go to the openshift's main node
|
||||
- Delete the pod using: ``oc -n ipsilon delete pod <pod-name>`` (for example: ``oc -n ipsilon delete pod ipsilon-24-8ztdd``),
|
||||
Openshift will automatically spawn a new one
|
||||
- Try login on bugzilla again - it should work (or maybe another pod is mis-behaving?)
|
||||
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
# How to generate 2 Factor Authentication key and certificate
|
||||
|
||||
Doing this requires membership in sysadmin-main FAS group.
|
||||
|
||||
All the following commands should be ran on one of batcave hosts.
|
||||
|
||||
Clone `ansible-private` repo:
|
||||
|
||||
git clone /srv/git/ansible-private
|
||||
|
||||
Change into `files/vpn` subdirectory in cloned repo:
|
||||
|
||||
cd ansible-private/files/2fa-certs
|
||||
|
||||
The process is described in the README but is basically:
|
||||
|
||||
. ./vars; ./build-and-sign-key <hostname>
|
||||
|
||||
Add generated files to git index, commit, push:
|
||||
|
||||
git status
|
||||
git add .
|
||||
git commit -a -m "Add 2 FA key/cert for <hostname>"
|
||||
git show
|
||||
git push
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
# How to generate private key and certificate for OpenVPN client
|
||||
|
||||
Doing this requires membership in sysadmin-main FAS group.
|
||||
|
||||
All the following commands should be ran on one of batcave hosts.
|
||||
|
||||
Clone `ansible-private` repo:
|
||||
|
||||
git clone /srv/git/ansible-private
|
||||
|
||||
Change into `files/vpn` subdirectory in cloned repo:
|
||||
|
||||
cd ansible-private/files/vpn
|
||||
|
||||
Run `addhost.sh` script to generate keys and cert, eg.:
|
||||
|
||||
./addhost.sh proxy33.fedoraproject.org
|
||||
|
||||
Add generated files to git index, commit, push:
|
||||
|
||||
git status
|
||||
git add .
|
||||
git commit -a -m "Add VPN key/cert for proxy33.fedoraproject.org"
|
||||
git show
|
||||
git push
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
# How to get the full logs of a pod in openshift?
|
||||
|
||||
You'll need the pod's name, the project's name and access to the openshift
|
||||
master.
|
||||
|
||||
Then you can run the command:
|
||||
|
||||
oc logs -n <project_name> <pod name>
|
||||
|
||||
for example:
|
||||
|
||||
oc logs toddlers-47-2tjj2 -n toddlers
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
# How to give a group from someone to someone else in dist-git?
|
||||
|
||||
Groups are linked to the user who created it and it used to not be possible to
|
||||
give the group to another user(\*), so lots of the early groups were created to
|
||||
the ``releng`` user, thus allowing to easily remove the user who asked for the
|
||||
group if they left the project.
|
||||
|
||||
It is nowadays possible to give groups from an user to another. This can be done
|
||||
by the person who is the current main admin of the group or a pagure admin.
|
||||
|
||||
The URL to give a group is:
|
||||
|
||||
::
|
||||
|
||||
https://src.fedoraproject.org/group/<group name>/edit
|
||||
|
||||
|
|
@ -88,15 +88,3 @@ group. This list can then be made private and invite-only.
|
|||
|
||||
**When requesting a pkgdb group, please let us know if you need a new mailing list
|
||||
to be created or not.**
|
||||
|
||||
## How to create a group?
|
||||
|
||||
1. Log in to [IPA interface](https://id.fedoraproject.org/ipa/ui)
|
||||
2. Click on the Groups tab
|
||||
3. Click on `+Add` button
|
||||
4. Fill in the Group name, description (optional)
|
||||
5. Tick the FAS group checkbox
|
||||
6. Click Add
|
||||
7. Click on the newly created group
|
||||
8. Add group sponsors (`<group_name> member managers` -> Users on the right) using `+Add` button
|
||||
9. Add members (if requested) using `+Add` button in `<group_name> members` -> Users
|
||||
|
|
|
|||
|
|
@ -1,40 +0,0 @@
|
|||
# How to deal with spam posts on pagure
|
||||
|
||||
When an ticket is raised for a spam user on the Fedora infra tracker take the
|
||||
following actions.
|
||||
|
||||
## Clear the spam
|
||||
Click on the user in pagure and check their activity for all comments they have
|
||||
made. Remove all these comments unless otherwise advised.
|
||||
|
||||
## Ban the user in pagure
|
||||
|
||||
ssh to pagure02.fedoraproject.org. As root user run the following command:
|
||||
|
||||
```
|
||||
pagure-admin block-user <username> <date to block until>
|
||||
```
|
||||
|
||||
For example:
|
||||
|
||||
```
|
||||
pagure-admin block-user spamuser 2060-01-01
|
||||
```
|
||||
|
||||
## Disable user in IPA
|
||||
|
||||
### Frontend
|
||||
|
||||
* Login to the [ipa server](https://id.fedoraproject.org/ipa/ui) and search the users name.
|
||||
* Click on the user.
|
||||
* In the Actions dropdown menu click disable
|
||||
|
||||
|
||||
### Command line
|
||||
|
||||
* ssh to ipa01.iad2.fedoraproject.org
|
||||
* run `ipa user-disable <user>`
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
# How to refresh the odcs oidc token used by OSBS
|
||||
|
||||
OSBS needs to trigger composes to ODCS for flatpak build, this is done using an OIDC token to authenticate the requests.
|
||||
This token expires every 365 days so it needs to be regenerated every year.
|
||||
|
||||
## Generate a new token
|
||||
In the ansible repo run the following command:
|
||||
|
||||
scripts/generate-oidc-token osbs -e 365 -s https://id.fedoraproject.org/scope/groups -s https://pagure.io/odcs/new-compose -s https://pagure.io/odcs/renew-compose -s https://pagure.io/odcs/delete-compose
|
||||
|
||||
|
||||
Follow the instructions given by the script and run the SQL command on the ipsilon database server:
|
||||
|
||||
ssh db-fas01.iad2.fedoraproject.org
|
||||
sudo -u postgres -i ipsilon
|
||||
ipsilon=# BEGIN;
|
||||
....
|
||||
ipsilon=# COMMIT;
|
||||
|
||||
Save the value of the token generated by the script in the ansible-private repo under `ansible-private/files/osbs/production/odcs-oidc-token` (same needs to be done for the staging cluster)
|
||||
|
||||
## Deploy the change
|
||||
|
||||
Run the following playbook to deploy the new token `ansible-playbook /srv/web/infra/ansible/playbooks/groups/osbs/configure-osbs.yml`
|
||||
|
|
@ -1,56 +0,0 @@
|
|||
# How to remove meeting minutes from meetbot?
|
||||
|
||||
Every now and then, we're asked to remove meeting minutes that meetbot recorded.
|
||||
|
||||
Meetbot records meeting on disk on value01.
|
||||
The minutes can be found in:
|
||||
|
||||
::
|
||||
|
||||
/srv/web/meetbot
|
||||
|
||||
Most often people asking to have some minutes removed, will give you an URL to
|
||||
that meeting.
|
||||
You can use it to find the corresponding file, based on this (see above) root
|
||||
directory.
|
||||
|
||||
For example the url:
|
||||
|
||||
::
|
||||
|
||||
https://meetbot.fedoraproject.org/teams/workstation/workstation.2020-08-19-18.13.log.html
|
||||
|
||||
points to the file:
|
||||
|
||||
::
|
||||
/srv/web/meetbot/teams/workstation/workstation.2020-08-19-18.13.log.html
|
||||
|
||||
|
||||
If you check this file, you will see that it is in fact a symlink to:
|
||||
|
||||
::
|
||||
|
||||
/srv/web/meetbot/fedora-meeting-2/2020-08-19/workstation.2020-08-19-18.13.log.html
|
||||
|
||||
(this will change for each meeting room and date of course).
|
||||
|
||||
|
||||
So to remove this meeting we need to:
|
||||
|
||||
* Create a backup in case we've messed things up::
|
||||
|
||||
mkdir meeting_workstation_20200819
|
||||
|
||||
* Move all the minutes from this meeting to this directory::
|
||||
|
||||
mv /srv/web/meetbot/fedora-meeting-2/2020-08-19/workstation.2020-08-19-18.13.* meeting_workstation_20200819
|
||||
|
||||
* Remove the symlink::
|
||||
|
||||
rm /srv/web/meetbot/teams/workstation/workstation.2020-08-19-18.13.*
|
||||
|
||||
|
||||
What about the UI?
|
||||
|
||||
Well, Mote seats on the top of the files meetbot generates, so cleaning up the
|
||||
files on disk will eventually end up cleaning things in the UI.
|
||||
|
|
@ -1,89 +0,0 @@
|
|||
# How to remove a git branch in a dist-git repository?
|
||||
|
||||
Historically we did not allow to remove git branches in dist-git repository, but
|
||||
FESCo recently approved their removal **if and only if** all the commits in the
|
||||
branch to be deleted can be reached from another branch.
|
||||
This is a requirement to ensure that if any of the commits were used in a build,
|
||||
we still have the commit accessible and thus we are able to reproduce the build
|
||||
if needed.
|
||||
|
||||
There is a script in the releng repository to use to check if a branch can
|
||||
safely be deleted.
|
||||
|
||||
So here are the steps to follow to remove the branch `<branch>` from the package
|
||||
`<foo>`.
|
||||
|
||||
- Clone the releng repo if you do not already have it:
|
||||
|
||||
```
|
||||
git clone https://pagure.io/releng.git
|
||||
```
|
||||
|
||||
|
||||
- If you already have it, pull the latest changes:
|
||||
|
||||
```
|
||||
pushd releng && git pull --rebase && popd
|
||||
```
|
||||
|
||||
- Clone the `<foo>` package locally:
|
||||
|
||||
```
|
||||
fedpkg clone <foo>
|
||||
```
|
||||
|
||||
- Checkout the <branch> branch:
|
||||
|
||||
```
|
||||
cd clone && git checkout <branch>
|
||||
```
|
||||
|
||||
- Run the script:
|
||||
|
||||
```
|
||||
python ../releng/scripts/distgit-branch-unused.py <branch>
|
||||
```
|
||||
|
||||
(If needed, see the ``--help`` of the script for more information)
|
||||
|
||||
|
||||
If the script returns that the branch is safe to delete:
|
||||
|
||||
- Go to pkgs01 as root
|
||||
|
||||
```
|
||||
ssh pkgs01.iad2.fedoraproject.org
|
||||
```
|
||||
|
||||
- Go to the git repository:
|
||||
|
||||
```
|
||||
cd /srv/git/repositories/<namespace>/<foo>.git
|
||||
```
|
||||
|
||||
- Move the head of the branch (this allows to recover it later if needed):
|
||||
|
||||
```
|
||||
mv refs/heads/<branch> heads_<branch>
|
||||
```
|
||||
|
||||
- Sometimes the ref is in the `packed-refs` file, in that case:
|
||||
|
||||
```
|
||||
grep <branch> packed-refs > heads_<branch>
|
||||
Then remove the line from `packed-refs` file
|
||||
```
|
||||
|
||||
- On your local clone of <foo>, check that the branch was deleted upstream:
|
||||
|
||||
```
|
||||
git fetch -p
|
||||
```
|
||||
|
||||
This should show something like:
|
||||
|
||||
$ git fetch -p
|
||||
From ssh://pkgs.fedoraproject.org/<namespace>/<foo>
|
||||
- [deleted] (none) -> origin/<branch>
|
||||
|
||||
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
# How to add allow root ssh login and remove fedora user
|
||||
|
||||
This will allow you to run ansible playbooks as the root user.
|
||||
It also removes the fedora user so that fas_client can install sucessfully in `/home/fedora`
|
||||
|
||||
Simply add the below text in to the `User Data` field when launching an EC2 instance.
|
||||
This appears as a text box at the bottom of the `Configure Instance` step when launching an instance.(Step 3)
|
||||
|
||||
|
||||
```
|
||||
#!/bin/bash
|
||||
cat /home/fedora/.ssh/authorized_keys > /root/.ssh/authorized_keys
|
||||
userdel -r fedora
|
||||
```
|
||||
|
||||
The script copies the public key from the fedora user and replaces the root users key with it.
|
||||
This is the public key which is associated with the keypair selected when launching the instance.
|
||||
It then deletes the Fedora user leaving root as the only ssh user on the instance.
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
# How to remove the monitoring of a rabbitmq queue
|
||||
|
||||
The monitoring of queue sizes of rabbitmq queue is done by nagios using two
|
||||
small configuration file.
|
||||
|
||||
To remove that monitoring, you simply need to remove these two files.
|
||||
|
||||
On the rabbitmq server (rabbitmq01):
|
||||
------------------------------------
|
||||
|
||||
* Remove the local nagios configuration file
|
||||
|
||||
rm /etc/nrpe.d/check_rabbitmq_queue_<queue_name>.cfg
|
||||
|
||||
* Then restart the local nagios plugin
|
||||
|
||||
systemctl restart nrpe
|
||||
|
||||
On the nagios server (noc01):
|
||||
-----------------------------
|
||||
|
||||
* Remove the nagios configuration file
|
||||
|
||||
rm /etc/nagios/services/rabbitmq-queue-<queue_name>.cfg
|
||||
|
||||
* Ensure the configuration is still valid:
|
||||
|
||||
nagios -v /etc/nagios/nagios.cfg
|
||||
|
||||
|
||||
* If and only **if** the check above passed, restart nagios on the nagios server
|
||||
|
||||
systemctl restart nagios
|
||||
|
|
@ -19,14 +19,13 @@ So we have created the folder:
|
|||
You can then create a tmux session using:
|
||||
|
||||
```
|
||||
tmux -S /var/tmux/<socket name> new -s <session name>
|
||||
tmux -S /var/tmux/<name> new -s <name>
|
||||
```
|
||||
(The socket and session names can be different, but they don't have to)
|
||||
|
||||
And the other person(s) can join it using:
|
||||
|
||||
```
|
||||
tmux -S /var/tmux/<socket name> att -t <session name>
|
||||
tmux -S /var/tmux/<name> att -t <name>
|
||||
```
|
||||
|
||||
Once the person who created the shared session stops it, the people who have
|
||||
|
|
|
|||
|
|
@ -1,16 +0,0 @@
|
|||
# How to unblock Bodhi rawhide updates
|
||||
|
||||
In the case where the rawhide updates in Bodhi are stuck in testing, it often means that one of the following
|
||||
process is not working properly.
|
||||
|
||||
Either the `bodhi-celery-beat` pod in openshift (used to schedule tasks at regular interval) is not triggering the
|
||||
`approve_testing_task` or the `bodhi-celery` pod is failing to process that task.
|
||||
|
||||
To unblock these update once can restart these pods. To do so ssh to the os-master01 hosts and run the following commands
|
||||
|
||||
```
|
||||
$ oc -n bodhi rollout latest dc/bodhi-celery-beat
|
||||
$ oc -n bodhi rollout latest dc/bodhi-celery
|
||||
```
|
||||
|
||||
Note using the `rollout` command allow us not to have any downtime.
|
||||
|
|
@ -1,45 +0,0 @@
|
|||
# How to udpate the watch status of someone in dist-git?
|
||||
|
||||
Let's start with: how to see someone's watch status?
|
||||
|
||||
There are two ways you can check this:
|
||||
|
||||
* Check the API
|
||||
|
||||
Visit https://src.fedoraproject.org/api/0/<namespace>/<name>/watchers
|
||||
ie: https://src.fedoraproject.org/api/0/rpms/borgbackup/watchers
|
||||
|
||||
it will give you information about all the watchers and what they watch.
|
||||
|
||||
* Using pagure-admin
|
||||
|
||||
On the pagure host, run:
|
||||
``pagure-admin get-watch <namespace>/<name> <usernme>``, for example:
|
||||
``pagure-admin get-watch rpms/borgbackup bpereto`` and it will return you the
|
||||
current watch status of that user on that project (or None if it is the
|
||||
default status).
|
||||
|
||||
|
||||
Now how do you update this?
|
||||
|
||||
* Using pagure-admin
|
||||
|
||||
On the pagure host, run:
|
||||
``pagure-admin update-watch <namespace>/<name> <usernme>``
|
||||
|
||||
You will be prompted with options about which status to set, use ``-1`` to
|
||||
revert to the default status.
|
||||
|
||||
Example:
|
||||
|
||||
# pagure-admin update-watch rpms/borgbackup bpereto
|
||||
Using configuration file `/etc/pagure/pagure.cfg`
|
||||
The watch status can be one of the following:
|
||||
-1: reset the watch status to default
|
||||
0: unwatch, don't notify the user of anything
|
||||
1: watch issues and PRs
|
||||
2: watch commits
|
||||
3: watch issues, PRs and commits
|
||||
Status:-1
|
||||
Updating watch status of bpereto to -1 (reset the watch status to default) on rpms/borgbackup
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue