{"id":17330342,"url":"https://github.com/foxboron/infrastructure","last_synced_at":"2025-06-24T22:39:43.815Z","repository":{"id":148133349,"uuid":"119531400","full_name":"Foxboron/infrastructure","owner":"Foxboron","description":"Arch Linux infrastructure repo","archived":false,"fork":false,"pushed_at":"2020-09-27T18:52:39.000Z","size":10254,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":3,"default_branch":"master","last_synced_at":"2025-02-01T11:12:39.637Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Foxboron.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-01-30T12:15:05.000Z","updated_at":"2020-06-13T18:36:10.000Z","dependencies_parsed_at":"2023-05-19T06:30:21.358Z","dependency_job_id":null,"html_url":"https://github.com/Foxboron/infrastructure","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Foxboron%2Finfrastructure","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Foxboron%2Finfrastructure/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Foxboron%2Finfrastructure/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Foxboron%2Finfrastructure/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Foxboron","download_url":"https://codeload.github.com/Foxboron/infrastructure/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":245791932,"owners_count":20672669,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-15T14:50:59.504Z","updated_at":"2025-03-27T05:44:38.746Z","avatar_url":"https://github.com/Foxboron.png","language":"Shell","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Arch Infrastructure\n\nThis repository contains the complete collection of ansible playbooks and roles for the Arch Linux infrastructure.\n\nIt also contains git submodules so you have to run `git submodule update --init\n--recursive` after cloning or some tasks will fail to run.\n\n## Requirements\n\nInstall these packages:\n  - terraform\n  - terraform-provider-keycloak\n\n### Instructions\n\nAll systems are set up the same way. For the first time setup in the Hetzner rescue system,\nrun the provisioning script: `ansible-playbook playbooks/tasks/install-arch.yml -l $host`.\nThe provisioning script configures a sane basic systemd with sshd. By design, it is NOT idempotent.\nAfter the provisioning script has run, it is safe to reboot.\n\nOnce in the new system, run the regular playbook: `HCLOUD_TOKEN=$(misc/get_key.py misc/vault_hetzner.yml hetzner_cloud_api_key) ansible-playbook playbooks/$hostname.yml`.\nThis playbook is the one regularity used for administrating the server and is entirely idempotent.\n\nWhen adding a new machine you should also deploy our SSH known_hosts file and update the SSH hostkeys file in this git repo.\nFor this you can simply run the `playbooks/tasks/sync-ssh-hostkeys.yml` playbook and commit the changes it makes to this git repository.\nIt will also deploy any new SSH host keys to all our machines.\n\n#### Note about GPG keys\n\nThe root_access.yml file contains the root_gpgkeys variable that determine the users that have access to the vault, as well as the borg backup keys.\nAll the keys should be on the local user gpg keyring and at **minimum** be locally signed with --lsign-key. This is necessary for running either the reencrypt-vault-key\nor the fetch-borg-keys tasks.\n\n#### Note about Ansible dynamic inventories\n\nWe use a dynamic inventory script in order to automatically get information for\nall servers directly from hcloud. You don't really have to do anything to make\nthis work but you should keep in mind to NOT add hcloud servers to `hosts`!\nThey'll be available automatically.\n\n#### Note about first time certificates\n\nThe first time a certificate is issued, you'll have to do this manually by yourself. First, configure the DNS to\npoint to the new server and then run a playbook onto the server which includes the nginx role. Then on the server,\nit is necessary to run the following once:\n\n    certbot certonly --email webmaster@archlinux.org --agree-tos --rsa-key-size 4096 --renew-by-default --webroot -w /var/lib/letsencrypt/ -d \u003cdomain-name\u003e\n\nNote that some roles already run this automatically.\n\n#### Note about packer\n\nWe use packer to build snapshots on hcloud to use as server base images.\nIn order to use this, you need to install packer and then run\n\n    packer build -var $(misc/get_key.py misc/vault_hetzner.yml hetzner_cloud_api_key env) packer/archlinux.json\n\nThis will take some time after which a new snapshot will have been created on the primary hcloud archlinux project.\n\n#### Note about terraform\n\nWe use terraform in two ways:\n\n    1) To provision a part of the infrastructure on hcloud (and possibly other service providers in the future)\n    2) To declaratively configure applications\n\nFor both of these, we have set up a separate terraform script. The reason for that is that sadly terraform can't have\nproviders depend on other providers so we can't declaratively state that we want to configure software on a server which\nitself needs to be provisioned first. Therefore, we use a two-stage process. Generally speaking, scenario 1) is configured in\n`tf-stage1` and 2) is in `tf-stage2`. Maybe in the future, we can just have a single terraform script for everything\nbut for the time being, this is what we're stuck with.\n\nThe very first time you run terraform on your system, you'll have to init it:\n\n    cd tf-stage1  # and also tf-stage2\n    terraform init -backend-config=\"conn_str=postgres://terraform:$(../misc/get_key.py group_vars/all/vault_terraform.yml vault_terraform_db_password)@state.archlinux.org\"\n\nAfter making changes to the infrastructure in `tf-stage1/archlinux.fg`, run\n\n    terraform plan\n\nThis will show you planned changes between the current infrastructure and the desired infrastructure.\nYou can then run\n\n    terraform apply\n\nto actually apply your changes.\n\nThe same applies to changed application configuration in which case you'd run\nit inside of `tf-stage2` instead of `tf-stage1`.\n\nWe store terraform state on a special server that is the only hcloud server NOT\nmanaged by terraform so that we do not run into a chicken-egg problem. The\nstate server is assumed to just exist so in an unlikely case where we have to\nentirely redo this infrastructure, the state server would have to be manually\nset up.\n\n#### SMTP Configuration\n\nAll hosts should be relaying email through our primary mx host (currently 'orion'). See docs/email.txt for full details.\n\n#### Note about opendkim\n\nThe opendkim DNS data has to be added to DNS manually. The roles verifies that the DNS is correct before starting opendkim.\n\nThe file that has to be added to the zone is `/etc/opendkim/private/$selector.txt`.\n\n### Putting a service in maintenance mode\n\nMost web services with a nginx configuration, can be put into a maintenance mode, by running the playbook with a maintenance variable:\n\n    ansible-playbook -e maintenance=true playbooks/\u003cplaybook.yml\u003e\n\nThis also works with a tag:\n\n    ansible-playbook -t \u003ctag\u003e -e maintenance=true playbooks/\u003cplaybook.yml\u003e\n\nAs long as you pass the maintenance variable to the playbook run, the web service will stay in maintenance mode. As soon as you stop\npassing it on the command line and run the playbook again, the regular nginx configuration should resume and the service should accept\nrequests by the end of the run.\n\nPassing maintenance=false, will also prevent the regular nginx configuration from resuming, but will not put the service into maintence\nmode.\n\nKeep in mind that passing the maintenance variable to the whole playbook, without any tag, will make all the web services that have the\nmaintenance mode in them, to be put in maintenance mode. Use tags to affect only the services you want.\n\nDocumentation on how to add the maintenance mode to a web service is inside docs/maintenance.txt\n\n### Finding servers requiring security updates\n\nArch-audit can be used to find servers in need of updates for security issues.\n\n    ansible all -a \"arch-audit -u\"\n\n#### Updating servers\n\nThe following steps should be used to update our managed servers:\n\n  * pacman -Syu\n  * manually update the kernel, since it is in IgnorePkg by default\n  * sync\n  * checkservices\n  * reboot\n\n## Servers\n\n### vostok\n\n#### Services\n  - backups\n\n### orion\n\n#### Services\n  - repos/sync (repos.archlinux.org)\n  - sources (sources.archlinux.org)\n  - archive (archive.archlinux.org)\n  - torrent tracker hefurd (tracker.archlinux.org)\n\n### luna\n\n#### Services\n\n  - aur (aur.archlinux.org)\n  - mailman\n  - projects (projects.archlinux.org)\n\n### apollo\n\n#### Services\n  - wiki (wiki.archlinux.org)\n  - bugs (bugs.archlinux.org)\n  - archweb\n  - patchwork\n\n## bugs.archlinux.org\n\n#### Services\n  - flyspray\n\n## bbs.archlinux.org\n\n#### Services\n  - bbs\n\n### phrik.archlinux.org\n\n#### Services\n   - phrik (irc bot) users in the phrik group defined in\n     the hosts vars and re-used the archusers role. Users\n     in the phrik group are allowed to restar the irc bot.\n\n### dragon\n\n#### Services\n  - build server\n  - sogrep\n  - arch-boxes (packer)\n\n### state.archlinux.org\n\n#### Services\n  - postgres server for terraform state\n\n### quassel.archlinux.org\n\n#### Services\n  - quassel core\n\n### homedir.archlinux.org\n\n#### Services\n  - ~/user/ webhost\n\n### accounts.archlinux.org\n\nThis server is /special/. It runs keycloak and is central to our unified Arch Linux account management world.\nIt has an Ansible playbook for the keycloak service but that only installs the package and starts it but it's configured via a secondary Terraform file only for keycloak `keycloak.tf`.\nThe reason for doing it this way is that Terraform support for Keycloak is much superior and it's declarative too which is great for making sure that no old config remains in the case of config changes.\n\nSo to set up this server from scratch, run:\n\n  - `cd tf-stage1`\n  - `terraform apply`\n  - `cd ../tf-stage2`\n  - `terraform import keycloak_realm.master master`\n  - `terraform apply`\n\n#### Services\n  - keycloak\n\n### mirror.pkgbuild.com\n\n#### Services\n  - Load balancer for PIA mirrors across the world. Uses Maxmind's GeoIP City\n    database for routing users to their nearest mirror. Account information is\n    stored in the ansible vault.\n\n### reproducible.archlinux.org\n\n#### Services\n  - Runs a master rebuilderd instance with two PIA workers (repro1.pkgbuild.com,\n    repro2.pkgbuild.com and repro3.pkgbuild.com).\n    repro3.pkgbuild.com is packet.net machine which runs Ubuntu.\n\n### runner1.archlinux.org\n\nSlow-ish PIA box with spinning disks.\n\n#### Services\n  - GitLab runner\n\n### runner2.archlinux.org\n\nMedium-fast-ish packet.net box with Debian on it. Is currently maintained manually.\n\n#### Services\n  - GitLab runner\n\n## Ansible repo workflows\n\n### Replace vault password and change vaulted passwords\n\n  - Generate a new key and save it as ./new-vault-pw: `pwgen -s 64 1 \u003e new-vault-pw`\n  - `for i in $(ag ANSIBLE_VAULT -l); do ansible-vault rekey --new-vault-password-file new-vault-pw $i; done`\n  - Change the key in misc/vault-password.gpg\n  - `rm new-vault-pw`\n\n### Re-encrypting the vault after adding or removing a new GPG key\n\n  - Make sure you have all the GPG keys **at least** locally signed\n  - Run the playbooks/tasks/reencrypt-vault-key.yml playbook and make sure it does not have **any** failed task\n  - Test that the vault is working by running ansible-vault view on any encrypted vault file\n  - Commit and push your changes\n\n### Fetching the borg keys for local storage\n\n  - Make sure you have all the GPG keys **at least** locally signed\n  - Run the playbooks/tasks/fetch-borg-keys.yml playbook\n  - Make sure the playbook runs successfully and check the keys under the borg-keys directory\n\n## Backup documentation\n\nBackups should be checked now and then. Some common tasks:\n\n### Listing current backups per server\n\n    borg list borg@vostok.archlinux.org:/backup/\u003chostname\u003e\n\nExample\n\n    borg list borg@vostok.archlinux.org:/backup/homedir.archlinux.org\n\n### Listing files in a backup\n\n    borg list borg@vostok.archlinux.org:/backup/\u003chostname\u003e::\u003carchive name\u003e\n\nExample\n\n    borg list borg@vostok.archlinux.org:/backup/homedir.archlinux.org::20191127-084357\n\n## One-shots\n\nA bunch of once-only admin task scripts can be found in `one-shots/`.\nWe try to minimize the amount of manual one-shot admin work we have to do but sometimes for some migrations it might be necessary to have such scripts.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ffoxboron%2Finfrastructure","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ffoxboron%2Finfrastructure","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ffoxboron%2Finfrastructure/lists"}