Auto-update Tech namespace pages 2024-09-16 17:28:03.308154

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](https://meta.miraheze.org/wiki/Tech:Appointment_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:GitHub.md

@@ -11,31 +11,31 @@ Push access to the repositories is limited to [system administrators](https://me
 ### puppet 
 
 Puppet is the repository that manages all services/servers.
-* **Push Access**: [Site Reliability Engineers (Infrastructure)](https://meta.miraheze.org/wiki/Tech:Organisation#Team:_Infrastructure,_Site_Reliability_Engineering)
+* **Push Access**: [Site Reliability Engineers (Infrastructure)](/tech-docs/techorganization#team-infrastructure-site-reliability-engineering)
 * **Servers**: [puppet181](/tech-docs/techpuppet181)
 
 ### mw-config 
 
 mw-config (MediaWiki configuration) is the repository that manages settings for MediaWiki.
-* **Push Access**: [Site Reliability Engineers (Infrastructure)](https://meta.miraheze.org/wiki/Tech:Organisation#Team:_Infrastructure,_Site_Reliability_Engineering), [MediaWiki Engineers](https://meta.miraheze.org/wiki/Tech:Organisation#Team:_MediaWiki,_Site_Reliability_Engineering)
+* **Push Access**: [Site Reliability Engineers (Infrastructure)](/tech-docs/techorganization#team-infrastructure-site-reliability-engineering), [MediaWiki Engineers](/tech-docs/techorganization#team-mediawiki-site-reliability-engineering)
 * **Servers**: [mw151](/tech-docs/techmw151), [mw152](/tech-docs/techmw152), [mw161](/tech-docs/techmw161), [mw162](/tech-docs/techmw162), [mw171](/tech-docs/techmw171), [mw172](/tech-docs/techmw172), [mw181](/tech-docs/techmw181), [mw182](/tech-docs/techmw182), [mwtask181](/tech-docs/techmwtask181), [test151](/tech-docs/techtest151)
 
 ### mediawiki 
 
 mediawiki is the repository that manages the MediaWiki source code, skins, and extensions.
-* **Push Access**: [Site Reliability Engineers (Infrastructure)](https://meta.miraheze.org/wiki/Tech:Organisation#Team:_Infrastructure,_Site_Reliability_Engineering), [MediaWiki Engineers](https://meta.miraheze.org/wiki/Tech:Organisation#Team:_MediaWiki,_Site_Reliability_Engineering)
+* **Push Access**: [Site Reliability Engineers (Infrastructure)](/tech-docs/techorganization#team-infrastructure-site-reliability-engineering), [MediaWiki Engineers](/tech-docs/techorganization#team-mediawiki-site-reliability-engineering)
 * **Servers**: [mw151](/tech-docs/techmw151), [mw152](/tech-docs/techmw152), [mw161](/tech-docs/techmw161), [mw162](/tech-docs/techmw162), [mw171](/tech-docs/techmw171), [mw172](/tech-docs/techmw172), [mw181](/tech-docs/techmw181), [mw182](/tech-docs/techmw182), [mwtask181](/tech-docs/techmwtask181), [test151](/tech-docs/techtest151)
 
 ### dns 
 
 [DNS](/tech-docs/techdns) (Domain Name System) is the repository that manages all DNS for Miraheze.
-* **Push Access**: [Site Reliability Engineers (Infrastructure)](https://meta.miraheze.org/wiki/Tech:Organisation#Team:_Infrastructure,_Site_Reliability_Engineering)
+* **Push Access**: [Site Reliability Engineers (Infrastructure)](/tech-docs/techorganization#team-infrastructure-site-reliability-engineering)
 * **Servers**: [ns1](/tech-docs/techns1), [ns2](/tech-docs/techns2)
 
 ### ssl 
 
 [SSL](/tech-docs/techssl_certificates) (Secure Sockets Layer) is the repository that manages all SSL certificates for Miraheze.
-* **Push Access**: [Site Reliability Engineers (Infrastructure)](https://meta.miraheze.org/wiki/Tech:Organisation#Team:_Infrastructure,_Site_Reliability_Engineering), ssl-admins
+* **Push Access**: [Site Reliability Engineers (Infrastructure)](/tech-docs/techorganization#team-infrastructure-site-reliability-engineering), ssl-admins
 * **Servers**: [puppet181](/tech-docs/techpuppet181)
 
 ## MediaWiki extensions and skins 

content/tech-docs/Tech:Graylog.md

@@ -63,7 +63,7 @@ You can also see this quick [video](https://imgur.com/a/yca7doi) on what the con
 
 If using OpenSSH, you can use `ssh -D 8089 <server>.wikitide.net`.
 
-If using a bastion server and your configuration is based on [Tech:SSH#OpenSSH](https://meta.miraheze.org/wiki/Tech:SSH#OpenSSH), you should use `ssh -D 8089 wikitidebast`. This avoids making two SSH connections to the bastion.
+If using a bastion server and your configuration is based on [Tech:SSH#OpenSSH](/tech-docs/techssh#openssh), you should use `ssh -D 8089 wikitidebast`. This avoids making two SSH connections to the bastion.
 
 ### PuTTY 
 

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](https://meta.miraheze.org/wiki/Tech:Appointment_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:Organization-mw-admins.md

@@ -22,7 +22,7 @@ In case of any doubts regarding a command or configuration change, mw-admins sho
 * They should typically only be run on mwtask181 or mwtask171.
 * Always run them as www-data (prefix command with `sudo -u www-data`).
 * Always `!log` maintenance script runs in #miraheze-tech-ops (unless you were running puppet or were using sql.php, and did **not** execute any queries that changed the database (e.g. SELECT/DESCRIBE queries)
-   * You can optionally use the [mwscript](https://meta.miraheze.org/wiki/Tech:MediaWiki_appserver#mwscript) wrapper to automatically log these.
+   * You can optionally use the [mwscript](/tech-docs/techmediawiki_appserver#mwscript) wrapper to automatically log these.
 * If you need to run a script on all wikis, use the *foreachwikiindblist* wrapper:
 * `sudo -u www-data /usr/local/bin/foreachwikiindblist /srv/mediawiki/cache/databases.json /srv/mediawiki/<version>/maintenance/yourscript.php --put-your-parameters --here`
 * update.php is evil. If you need to run it while you're not doing a MediaWiki upgrade, then something is really wrong.

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](https://meta.miraheze.org/wiki/Tech:Puppet#Adding_a_new_puppet_agent_.28server.29_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:SLO.md

@@ -48,7 +48,7 @@ Miraheze's Site Reliability Engineering team have crafted a set of Service Level
 
 | Service | Type | Objective | Dec 22 | Jan 23 | Feb 23 | Mar 23 | Apr 23 | May 23 | Jun 23 | Jul 23 | Aug 23 | Sep 23 | Oct 23 | Nov 23 |
 | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| rowspan="2" | [JobQueue](https://meta.miraheze.org/wiki/Tech:MediaWiki_appserver#Jobrunner) | Availability | 99.5% | style="background-color:#f08080;" | [95.30%](https://meta.miraheze.org/wiki/phorge:T10218) | style="background-color:#90ee90;" | 99.90% | style="background-color:#90ee90;" | 100% |
+| rowspan="2" | [JobQueue](/tech-docs/techmediawiki_appserver#jobrunner) | Availability | 99.5% | style="background-color:#f08080;" | [95.30%](https://meta.miraheze.org/wiki/phorge:T10218) | style="background-color:#90ee90;" | 99.90% | style="background-color:#90ee90;" | 100% |
 | Errors | 1.5% | style="background-color:#f08080;" | [1.8%](https://meta.miraheze.org/wiki/phorge:T10218) | style="background-color:#f08080;" | [3.37%](https://meta.miraheze.org/wiki/phorge:T10218) | style="background-color:#90ee90;" | 0.02% |
 | rowspan="3" | [MediaWiki](/tech-docs/techmediawiki_appserver) | Availability | 99% | style="background-color:#f08080;" | [96.5%](https://meta.miraheze.org/wiki/phorge:T10219) | style="background-color:#90ee90;" | 99.30% | style="background-color:#90ee90;" | 99.50% |
 | Error | 3% | style="background-color:#90ee90;" | 2.03% | style="background-color:#90ee90;" | 1.54% | style="background-color:#90ee90;" | 0.35% |

content/tech-docs/Tech:Server_admin_log.md

@@ -4,6 +4,14 @@ title: Tech:Server admin log
 
 ## 2024-09-16 
 
+* 16:53 MirahezeLSBot: [@test151] finished deploy of {'folders': '1.43/extensions/MirahezeMagic'} to test151 - SUCCESS in 0s
+* 16:53 MirahezeLSBot: [@test151] starting deploy of {'folders': '1.43/extensions/MirahezeMagic'} to test151
+* 16:53 MirahezeLSBot: [@test151] finished deploy of {'folders': '1.42/extensions/MirahezeMagic'} to test151 - SUCCESS in 0s
+* 16:53 MirahezeLSBot: [@test151] starting deploy of {'folders': '1.42/extensions/MirahezeMagic'} to test151
+* 16:38 MirahezeLSBot: [@mwtask171] finished deploy of {'folders': '1.42/extensions/MirahezeMagic'} to all - SUCCESS in 21s
+* 16:37 MirahezeLSBot: [@mwtask171] starting deploy of {'folders': '1.42/extensions/MirahezeMagic'} to all
+* 16:37 MirahezeLSBot: [reception@mwtask181] finished deploy of {'versions': '1.42', 'upgrade_extensions': 'MirahezeMagic'} to all - SUCCESS in 29s
+* 16:37 MirahezeLSBot: [reception@mwtask181] starting deploy of {'versions': '1.42', 'upgrade_extensions': 'MirahezeMagic'} to all
 * 13:16 Reception123: salt-ssh -E 'mw.*' cmd.run 'sudo -u www-data /usr/local/bin/foreachwikiindblist /srv/mediawiki/cache/databases.json /srv/mediawiki/1.42/maintenance/run.php /srv/mediawiki/1.42/extensions/MirahezeMagic/maintenance/resetWikiCaches.php'  on all mw servers
 * 02:39 MirahezeLSBot: [agent@mwtask181] finished deploy of {'l10n': True, 'force': True, 'versions': '1.42'} to all - SUCCESS in 606s
 * 02:29 MirahezeLSBot: [agent@mwtask181] starting deploy of {'l10n': True, 'force': True, 'versions': '1.42'} to all

content/tech-docs/Tech:Server_lifecycle.md

@@ -10,22 +10,22 @@ Anyone from Site Reliability Engineering managing services offered by the Techni
 
 ## Installing 
 
-These steps must be performed in order. This list is not exhaustive, but applies to all servers. Certain servers, such as Proxmox hosts, may need an adjusted procedure from your side: [Tech:Proxmox#VPS](https://meta.miraheze.org/wiki/Tech:Proxmox#VPS)
+These steps must be performed in order. This list is not exhaustive, but applies to all servers. Certain servers, such as Proxmox hosts, may need an adjusted procedure from your side: [Tech:Proxmox#VPS](/tech-docs/techproxmox#vps)
 * Add an entry for the server to the wikitide.net DNS zone. If possible, also setup reverse DNS for the IPs.
 * Change the hostname of the server. This must be in the format <server name>.wikitide.net. If you cannot do this via the Service Provider, run the command `hostnamectl set-hostname <server name>.wikitide.net` via the console.
 * Log in via the console, KVM, or whatever it is called by the Service Provider. In most case, you have received the password via mail. Never share root passwords with other people.
 * 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](https://meta.miraheze.org/wiki/Tech:Puppet#Adding_a_new_puppet_agent_.28server.29_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](https://meta.miraheze.org/wiki/Tech:Puppet#Removing_puppet_agent_.28server.29_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](https://meta.miraheze.org/wiki/Tech:Puppet#Removing_puppet_agent_.28server.29_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.

content/tech-docs/Tech:Upgrading_MediaWiki-Branching_Commands.md

@@ -3,7 +3,9 @@ title: Tech:Upgrading MediaWiki/Branching Commands
 ---
 
 * Follow below to branch extensions/skins/core
-`import os
+```
+<nowiki>
+import os
 from json import loads
 
 file = open('users/me/mediawiki/.branches.json', 'r')
@@ -21,7 +23,9 @@ for branch in file.keys():
 for ext in extensions:
     branch = file['default']
     print(f'fixing {ext} for {branch}')
-    os.system(f'cd /users/me/mediawiki && git submodule set-branch --branch {branch} -- {ext} && cd {ext} && git checkout {branch} && git pull')`
+    os.system(f'cd /users/me/mediawiki && git submodule set-branch --branch {branch} -- {ext} && cd {ext} && git checkout {branch} && git pull')
+</nowiki>
+```
 
 ----
 **Source**: [https://meta.miraheze.org/wiki/Tech:Upgrading_MediaWiki/Branching_Commands](https://meta.miraheze.org/wiki/Tech:Upgrading_MediaWiki/Branching_Commands)