Auto-update Tech namespace pages 2024-09-16 17:41:17.764209

content/tech-docs/Tech:Proxmox.md

@@ -141,7 +141,7 @@ deb-src http://security.debian.org/debian-security bookworm/updates main
 deb http://ftp.uk.debian.org/debian/ bookworm-updates main
 deb-src http://ftp.uk.debian.org/debian/ bookworm-updates main
 ```
-* [Run puppet](/tech-docs/techpuppet#adding-a-new-puppet-agent-28server29-to-the-puppetserver). Do not log out before your user account is set up by puppet; otherwise you'll have a hard time getting back in.
+* [Run puppet](/tech-docs/techpuppet#adding-a-new-puppet-agent-server-to-the-puppetserver). Do not log out before your user account is set up by puppet; otherwise you'll have a hard time getting back in.
 ```
 # This file describes the network interfaces available on your system
 # and how to activate them. For more information, see interfaces(5).

content/tech-docs/Tech:Server_lifecycle.md

@@ -17,15 +17,15 @@ These steps must be performed in order. This list is not exhaustive, but applies
 * Most servers are accessible via SSH by default. In that case, you may find it easier to work via PuTTY or similar. To do that, dump the fingerprint of the SSH host key. For PuTTY, `ssh-keygen -E md5 -l -f /etc/ssh/ssh_host_ed25519_key.pub` seems to be appropriate.
 * When connecting, verify the fingerprint matches. If so, you can proceed with the rest of the steps.
 * Add the fingerprint to [Tech:SSH fingerprints](/tech-docs/techssh_fingerprints). Do this early, so you don't forget this.
-* Configure the server via Puppet: [Adding a new puppet agent (server) to the Puppetserver](/tech-docs/techpuppet#adding-a-new-puppet-agent-28server29-to-the-puppetserver).
+* Configure the server via Puppet: [Adding a new puppet agent (server) to the Puppetserver](/tech-docs/techpuppet#adding-a-new-puppet-agent-server-to-the-puppetserver).
 
 ## Decommissioning 
 
 Decommissioning a server means the server will be fully removed from the Miraheze infrastructure. The server must be cancelled (via OVH/RamNode control panel) or deleted from Proxmox (in the case of a VM). Its hostname may not be reused.
 
 * Depool the server from the services it's in use for. If the server is a master, failover to a replica or secondary server.
 * Set downtime in Icinga for the server and all of its services, to avoid unnecessary Icinga alerts for the server.
-* Ensure [the server is removed from the Puppet CA and database](/tech-docs/techpuppet#removing-puppet-agent-28server29-on-the-puppetserver).
+* Ensure [the server is removed from the Puppet CA and database](/tech-docs/techpuppet#removing-puppet-agent-server-on-the-puppetserver).
 * Remove all references to the server from manifests/site.pp. If the hostname and/or IP address is defined in other code (Hiera variables, mw-config/Database.php, etc.), remove those references as well.
 * Manually remove any traces of PII or other confidential information. On most systems, `rm -rf /root /etc/ssl/private /var/log` does most of the job. If the server was used for database hosting (e.g., MariaDB) or file hosting, please remove such information as well.
 * Cancel the service via the OVH or RamNode control panel. If the server is a Proxmox VM, fully remove the server from the Proxmox inventory.
@@ -36,7 +36,7 @@ Reimaging a server means the server will be kept in use, but a new OS will be in
 
 * Depool the server from the services it's in use for. If the server is a master, failover to a replica or secondary server.
 * Set downtime in Icinga for the server and all of its services, to avoid unnecessary Icinga alerts for the server.
-* Ensure [the server is removed from the Puppet CA and database](/tech-docs/techpuppet#removing-puppet-agent-28server29-on-the-puppetserver).
+* Ensure [the server is removed from the Puppet CA and database](/tech-docs/techpuppet#removing-puppet-agent-server-on-the-puppetserver).
 * **If the server will not serve the same role**: remove all references to the server from manifests/site.pp. If the hostname and/or IP address is defined in other code (Hiera variables, mw-config/Database.php, etc.), remove those references as well.
 * Manually remove any traces of PII or other confidential information. On most systems, `rm -rf /root /etc/ssl/private /var/log` does most of the job. If the server was used for database hosting (e.g., MariaDB) or file hosting, please remove such information as well.
 * Reimage the server with a fresh copy of Debian.