Auto-update Tech namespace pages 2024-09-16 17:36:48.877578

content/tech-docs/Tech:FIDO2_SSH.md

@@ -8,7 +8,7 @@ If you have access to a FIDO2 key, you can use it to add 2FA to your SSH login.
 
 ## Generating the key
 
-There are two options when creating FIDO2-backed keys: sk-ssh-ed25519 and sk-ssh-ecdsa. Due to [policy](/tech-docs/techappointment_and_revocation_policy#new_access), only Ed25519 keys are allowed.
+There are two options when creating FIDO2-backed keys: sk-ssh-ed25519 and sk-ssh-ecdsa. Due to [policy](/tech-docs/techappointment_and_revocation_policy#new-access), only Ed25519 keys are allowed.
 
 Generate your key via `ssh-keygen -t ed25519-sk -C "comment"`. This will create a non-discoverable key. Some additional considerations.
 

content/tech-docs/Tech:Inactivity_policy.md

@@ -43,7 +43,7 @@ If a person has been found to be inactive based on the criteria above more than
 
 If a user resigns due to the fact that they know they will be inactive, they may be re-added more easily than if they were applying for the first time. This however, does not apply to sysadmins who are *removed* for inactivity; they must follow the same procedure as a "new" sysadmin.
 
-If a former sysadmin wishes to come back after having resigned for being inactive, they should follow the [requesting access steps](/tech-docs/techappointment_and_revocation_policy#how_to_request_access) again,. However, instead of the procedure detailed in the [Tech:Appointment and revocation policy](/tech-docs/techappointment_and_revocation_policy), they may be quickly re-added with the common accord of the SRE Management Team.
+If a former sysadmin wishes to come back after having resigned for being inactive, they should follow the [requesting access steps](/tech-docs/techappointment_and_revocation_policy#how-to-request-access) again,. However, instead of the procedure detailed in the [Tech:Appointment and revocation policy](/tech-docs/techappointment_and_revocation_policy), they may be quickly re-added with the common accord of the SRE Management Team.
 
 [Category:Tech](https://meta.miraheze.org/wiki/Category:Tech)
 

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-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.
 ```
 # 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-28server29-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-28server29-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-28server29-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.