Infrastructure/howtos
3
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

Compare commits

base: Infrastructure:main
Branches Tags
Infrastructure:main
Infrastructure:mailman_management
..
compare: Infrastructure:mailman_management
Branches Tags
Infrastructure:main
Infrastructure:mailman_management

No commits in common. "main" and "mailman_management" have entirely different histories.
main ... mailman_ma

25 changed files with 19 additions and 819 deletions
Download patch file Download diff file Expand all files Collapse all files

3
README.md
View file

@ -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. # 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. 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.

32
add_external_hardware_to_vpn.md
View file

@ -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.

152
archiving_a_fedora_release.md
View file

@ -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 .
```

29
clean_2f_tokens.md
View file

@ -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 * say yes, exit, and repeat for stg/prod as each has their own db.
* Run `ipa otptoken-del <Unique_ID>`. The token is now removed

24
clean_monitoring_sidetags.md
View file

@ -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).

64
create_fedscm_admin_token.md
View file

@ -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 :)

40
create_keytab.md
View file

@ -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)

21
creating_groups_distgit.md
View file

@ -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``

18
discourse_spam.md
View file

@ -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>`

19
fedora_messaging_certificates.md
View file

@ -45,25 +45,6 @@ git push
Source: https://pagure.io/fedora-infrastructure/issue/8638 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 ## Debugging

20
fix_bugzilla_aws_saml_login.md
View file

@ -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?)

25
generate_2fa_keys.md
View file

@ -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

25
generate_openvpn_keys.md
View file

@ -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

12
get_logs_pod_openshift.md
View file

@ -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

16
give_groups_dist_git.md
View file

@ -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

12
groups_in_fedora.md
View file

@ -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 **When requesting a pkgdb group, please let us know if you need a new mailing list
to be created or not.** 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

40
pagure_spam.md
View file

@ -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>`

24
refresh_osbs_odcs_oicd_token.md
View file

@ -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`

56
remote_meeting_minutes_meetbot.md
View file

@ -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.

89
remove_branch_distgit.md
View file

@ -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>

18
remove_fedora_user_at_launch_aws.md
View file

@ -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.

33
remove_monitoring_rabbitmq_queue.md
View file

@ -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

5
share_tmux_session.md
View file

@ -19,14 +19,13 @@ So we have created the folder:
You can then create a tmux session using: 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: 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 Once the person who created the shared session stops it, the people who have

16
unblock_bodhi_rawhide_updates.md
View file

@ -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.

45
update_watch_dist_git.md
View file

@ -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