From 513ee29ff46ec73c2c21c54ae56d176147a60578 Mon Sep 17 00:00:00 2001
From: Kevin Fenzi <kevin@scrye.com>
Date: Dec 06 2025 19:10:57 +0000
Subject: Add a WIP anubis SOP


Signed-off-by: Kevin Fenzi <kevin@scrye.com>

---

diff --git a/modules/sysadmin_guide/pages/anubis.adoc b/modules/sysadmin_guide/pages/anubis.adoc
new file mode 100644
index 0000000..1a8a278
--- /dev/null
+++ b/modules/sysadmin_guide/pages/anubis.adoc
@@ -0,0 +1,81 @@
+= anubis Infrastructure SOP
+
+anubis is a web application that 'weighs' connections.
+Some are sent a 'proof of work' challenge to complete, some
+are just blocked (known crawler bots), and some are are just accepted.
+
+Upstream project page: https://github.com/TecharoHQ/anubis
+
+== Contact Information
+
+Owner::
+  Fedora Infrastructure
+Contact::
+  #fedora-admin, infrastructure mailing list
+People::
+  sysadmin-main
+Machines::
+  Proxy servers, copr servers and pagure
+Purpose::
+  Block scraper bots from taking up resources while allowing 
+  legit connections through.
+
+== Architecture
+
+On our pagure.io servers ( pagure.io, stg.pagure.io ), 
+anubis is deployed with the upstream
+container. This container is managed via a systemd unit file that
+passes various env variables in for some configuration and also
+passes a config yaml into the container for more configuration.
+Requests come in to the normal apache server where ssl is terminated.
+Then, they go to the container for anubis to process. 
+If a challenge is needed, anubis sends one and on successfull completion
+sets a secure cookie that the challenge was passed. 
+Further connections from the same browser will be passed through.
+The actual application in apache then listens on another local
+port and anubis proxys to it.
+
+On other proxy servers and copr, anubis is installed from the
+fedora native package. This package has a systemd service file and
+configuration in /etc/anubis. Normally we just use the 'default'
+template, so 'anubis@default.service'. The setup is much like
+the container version, requests come in, ssl termination and then on
+to anubis service to proxy into the actual website listening on
+another port on localhost. websites are enabled for this via an
+'anubis' variable thats set to true on websites where anubis is
+desired. On sites where it is not, the config simply doesn't
+direct traffic through it.
+
+== Storage backend
+
+Currently we are simply using the 'memory' storage backend.
+This means that if you restart the anubis service, all users
+that were required to complete a challenge will have to complete
+a new one (as anubis has no memory of the old ones). If this
+becomes a problem we can look at one of the persistent
+storage backends.
+
+== switching a website to/from anubis
+
+To switch a site you simply need to adjust the 'anubis' variable and
+re-run the proxyies ansible playbook.
+
+== Configuration
+
+anubis allows you to import internal / compiled in policies,
+or configure your own. The default is:
+
+import: (data)/botPolicies.yaml
+
+This gives you a good overall generic policy. This policy
+blocks known abusive ai crawler networks and requires
+challenges for any connections using a user agent that
+contains "Mozilla" (as pretty much all browsers do).
+challenges are also good for 24 hours. After that the
+browser/user will get another challenge.
+
+== Updating container on rhel8 hosts
+
+sudo -u anubis podman pull ghcr.io/techarohq/anubis:latest
+will pull the latest container on the rhel8 hosts.
+You need to then restart the anubis service.