aurweb: update rollout for >= v6.0.0

The long-awaited Python port of aurweb has been released (v6.0.0). There have been some patches since the initial release, bumping us up to v6.0.2 currently, and there will be more.

See https://gitlab.archlinux.org/archlinux/aurweb/-/tags for changelogs on each release version. These have been simplified to show what has changed from a user's perspective and not code-specific changes.

There are a few new ansible variables that must be defined:

• aurweb_secret
  • A secret key dedicated to the aurweb instance used for SSO sessions
• aurweb_asgi_bind
  • Address to bind gunicorn to ('127.0.0.1:8000')
• aurweb_workers
  • Number of workers to use for gunicorn (5)
• aurweb_postmaster
  • Email used for server error notifications. It is quite important to set this to an email who also has access to aur.archlinux.org's server logs, as server errors are notified given a hashed ID that can be used to locate the error in the logs.

New configuration options

• [options] max_search_results
• [options] salt_rounds
• [options] redis_address
• [options] traceback
• [ratelimit] cache
• [notifications] postmaster
• [fastapi] session_secret
• [devel] commit_url
• [devel] commit_hash

Configuration changes

• [options] cache
  • Added support for redis
  • Removed support for memcached
  • Removed support for apc

I highly suggest testing this on a deployment using the same playbook configuration on aur-dev.archlinux.org before deploying to aur.archlinux.org and checking to see that everything works as expected:

• aurweb website
• git repository
• cgit
• smartgit
• maintenance timers

The following branches are now equivalent: master, live, pu. We'll be using the pu branch as a bugfix staging tree and attempting to keep master and live as close as possible; live should still be used for aur.archlinux.org deployments.

We'll be releasing patches and bumping a few minor releases soon, stay tuned for new features and fixes.

Immediate Plans (new features)

• SSO support
• Reduction of number of requests a single user can file against a package
• Multi-section /{packages,pkgbase}/{name} side-panels
• Archive differentials
  • Maybe library/toolkit to make this easier for end-users
• Archive mimetypes
  • Support mime types based on the extension requested (.txt, .gz)
• Archive signatures
  • We should provide a .sig file for each archive we maintain, containing a hash of the current archive
  • Along with this, we should be producing archives elsewhere, then mving them into the archive location; currently, archives can be corrupted on download due to time taken to produce the archive
• Archives
  • Only update when needed
• dir="rtl" HTML markup based on the selected language (for languages which support rtl)
• Improve RPC's type=search performance

Suggestions

As I do not have access to the vault or other services in the Arch infrastructure, I would highly suggest testing this deployment on another machine, like aur-dev.archlinux.org. I made many modifications locally to test this out on a LAN ansible pair to test this personally.

It should be quite simple, as you can locally copy aur.archlinux.org.yml to aur-dev.archlinux.org.yml and try running aur-dev's playbook. If you do decide to do this (which would be quite nice), please let me know, as I can help QA the rollout.

Best, Kevin

docs/backups.md

@@ -85,10 +85,6 @@ For PostgreSQL backups are made using pg_dump to `postgres_backup_dir`.
 
 Restoring backups can be done with `pg_restore`. See also [official PostgreSQL docs](https://www.postgresql.org/docs/current/app-pgrestore.html).
 
-### Gitlab
-
-GitLab is backupped up using the `gitlab_backup` tool to `gitlab_backupdir`. See also [official GitLab docs](https://docs.gitlab.com/ee/raketasks/backup_restore.html).
-
 ## Adding a new server
 
 Adding a new server to be backed up goes as follows: