diff --git a/README.md b/README.md
index d867915..35959d2 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,6 @@
+**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.
diff --git a/add_external_hardware_to_vpn.md b/add_external_hardware_to_vpn.md
new file mode 100644
index 0000000..5147446
--- /dev/null
+++ b/add_external_hardware_to_vpn.md
@@ -0,0 +1,32 @@
+# 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.
+
diff --git a/archiving_a_fedora_release.md b/archiving_a_fedora_release.md
new file mode 100644
index 0000000..1202b16
--- /dev/null
+++ b/archiving_a_fedora_release.md
@@ -0,0 +1,152 @@
+# 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 .
+
+```
+
+
+   
+
diff --git a/clean_2f_tokens.md b/clean_2f_tokens.md
index 13c00d9..f26ad56 100644
--- a/clean_2f_tokens.md
+++ b/clean_2f_tokens.md
@@ -1,27 +1,22 @@
-# How to remove 2 factors authentication tokens?
+# How to remove 2 factor authentication tokens in IPA using ui
 
-* become root on os-master01 and/or os-master01.stg
+* log into `https://id.fedoraproject.org/ipa/ui/` using noggin credentials 
 
-* Run the following commands:
+* Click on the `Authentication` tab
 
-```
-oc project fas
-oc get pods
-```
+* Click on the `OTP Tokens` sub tab
 
-* Look for the totpcgi-N-hash pods
+* Enter the username into the search bar. This will display a list of tokens associated with the user.
 
-* Log into that pod:
+* Select the desired token and click delete. A popup will appear, click delete again to confirm.
 
-```
-oc rsh <one of the pods above>
-```
+# How to remove 2 factor authentication tokens in IPA using cli
 
-* Clean the tokens:
+* kinit as user with admin privileges on ipa server
 
-```
-totpprov delete-user <fas username>
-```
+* Run `ipa otptoken-find --owner=<username>`
 
-* say yes, exit, and repeat for stg/prod as each has their own db.
+* 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
 
diff --git a/clean_monitoring_sidetags.md b/clean_monitoring_sidetags.md
new file mode 100644
index 0000000..e8f9d91
--- /dev/null
+++ b/clean_monitoring_sidetags.md
@@ -0,0 +1,24 @@
+# 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).
diff --git a/create_fedscm_admin_token.md b/create_fedscm_admin_token.md
new file mode 100644
index 0000000..9550769
--- /dev/null
+++ b/create_fedscm_admin_token.md
@@ -0,0 +1,64 @@
+# 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 :)
+
diff --git a/create_keytab.md b/create_keytab.md
new file mode 100644
index 0000000..2b40c6c
--- /dev/null
+++ b/create_keytab.md
@@ -0,0 +1,40 @@
+# 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)
diff --git a/creating_groups_distgit.md b/creating_groups_distgit.md
new file mode 100644
index 0000000..3badcc5
--- /dev/null
+++ b/creating_groups_distgit.md
@@ -0,0 +1,21 @@
+# 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``
diff --git a/discourse_spam.md b/discourse_spam.md
new file mode 100644
index 0000000..f1e2455
--- /dev/null
+++ b/discourse_spam.md
@@ -0,0 +1,18 @@
+# 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>`
diff --git a/fedora_messaging_certificates.md b/fedora_messaging_certificates.md
index 4e09be5..7f1aa10 100644
--- a/fedora_messaging_certificates.md
+++ b/fedora_messaging_certificates.md
@@ -45,6 +45,25 @@ 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
 
diff --git a/fix_bugzilla_aws_saml_login.md b/fix_bugzilla_aws_saml_login.md
new file mode 100644
index 0000000..e31d5c9
--- /dev/null
+++ b/fix_bugzilla_aws_saml_login.md
@@ -0,0 +1,20 @@
+# 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?)
+
diff --git a/generate_2fa_keys.md b/generate_2fa_keys.md
new file mode 100644
index 0000000..b1dd672
--- /dev/null
+++ b/generate_2fa_keys.md
@@ -0,0 +1,25 @@
+# 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
diff --git a/generate_openvpn_keys.md b/generate_openvpn_keys.md
new file mode 100644
index 0000000..563d985
--- /dev/null
+++ b/generate_openvpn_keys.md
@@ -0,0 +1,25 @@
+# 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
diff --git a/get_logs_pod_openshift.md b/get_logs_pod_openshift.md
new file mode 100644
index 0000000..06e8035
--- /dev/null
+++ b/get_logs_pod_openshift.md
@@ -0,0 +1,12 @@
+# 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
diff --git a/give_groups_dist_git.md b/give_groups_dist_git.md
new file mode 100644
index 0000000..03af364
--- /dev/null
+++ b/give_groups_dist_git.md
@@ -0,0 +1,16 @@
+# 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
+
diff --git a/groups_in_fedora.md b/groups_in_fedora.md
index c8b40f1..31a6367 100644
--- a/groups_in_fedora.md
+++ b/groups_in_fedora.md
@@ -88,3 +88,15 @@ 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
diff --git a/pagure_spam.md b/pagure_spam.md
new file mode 100644
index 0000000..d2624d2
--- /dev/null
+++ b/pagure_spam.md
@@ -0,0 +1,40 @@
+# 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>`
+
+
+
+
diff --git a/refresh_osbs_odcs_oicd_token.md b/refresh_osbs_odcs_oicd_token.md
new file mode 100644
index 0000000..1241017
--- /dev/null
+++ b/refresh_osbs_odcs_oicd_token.md
@@ -0,0 +1,24 @@
+# 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`
diff --git a/remote_meeting_minutes_meetbot.md b/remote_meeting_minutes_meetbot.md
new file mode 100644
index 0000000..8276aa1
--- /dev/null
+++ b/remote_meeting_minutes_meetbot.md
@@ -0,0 +1,56 @@
+# 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.
diff --git a/remove_branch_distgit.md b/remove_branch_distgit.md
new file mode 100644
index 0000000..82ee61a
--- /dev/null
+++ b/remove_branch_distgit.md
@@ -0,0 +1,89 @@
+# 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>
+
+
diff --git a/remove_fedora_user_at_launch_aws.md b/remove_fedora_user_at_launch_aws.md
new file mode 100644
index 0000000..65fde6d
--- /dev/null
+++ b/remove_fedora_user_at_launch_aws.md
@@ -0,0 +1,18 @@
+# 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.
diff --git a/remove_monitoring_rabbitmq_queue.md b/remove_monitoring_rabbitmq_queue.md
new file mode 100644
index 0000000..694c932
--- /dev/null
+++ b/remove_monitoring_rabbitmq_queue.md
@@ -0,0 +1,33 @@
+# 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
diff --git a/share_tmux_session.md b/share_tmux_session.md
index 785052b..addf2e0 100644
--- a/share_tmux_session.md
+++ b/share_tmux_session.md
@@ -19,13 +19,14 @@ So we have created the folder:
 You can then create a tmux session using:
 
 ```
-  tmux -S /var/tmux/<name> new -s <name>
+  tmux -S /var/tmux/<socket name> new -s <session 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/<name> att -t <name>
+  tmux -S /var/tmux/<socket name> att -t <session name>
 ```
 
 Once the person who created the shared session stops it, the people who have
diff --git a/unblock_bodhi_rawhide_updates.md b/unblock_bodhi_rawhide_updates.md
new file mode 100644
index 0000000..c130c99
--- /dev/null
+++ b/unblock_bodhi_rawhide_updates.md
@@ -0,0 +1,16 @@
+# 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.
diff --git a/update_watch_dist_git.md b/update_watch_dist_git.md
new file mode 100644
index 0000000..6697066
--- /dev/null
+++ b/update_watch_dist_git.md
@@ -0,0 +1,45 @@
+# 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
+