Auto-update Tech namespace pages 2024-09-16 08:52:12.573167

content/tech-docs/Tech:Appointment_and_revocation_policy.md

@@ -38,7 +38,7 @@ In ultimate emergencies, such as compromised accounts, any member with the relev
 
 ### New Access 
 
-This applies to people, who do not have shell access yet. After you have articulated a valid reason for requesting shell access, and followed the instructions below, your request will be dealt with as [described above](#Appointment).
+This applies to people, who do not have shell access yet. After you have articulated a valid reason for requesting shell access, and followed the instructions below, your request will be dealt with as [described above](#appointment).
 * Ensure you have an account on [GitHub](https://meta.miraheze.org/wiki/github:) and [Phorge](https://meta.miraheze.org/wiki/phorge:) (which requires a Miraheze account).
 * Login into Phorge, and [fill in this form](https://meta.miraheze.org/wiki/phorge:maniphest/task/edit/form/17/) (do not forget to replace "[USERNAME]" with your username!). The form should contain the following information:
    * Miraheze Username

content/tech-docs/Tech:Compromised_Handling.md

@@ -66,7 +66,7 @@ MariaDB databases include wiki databases and other misc. services. If a database
 
 ### MariaDB - passwords 
 
-The level of severity depends on which password is assumed to have been compromised. An evaluation of all databases that may have been compromised should be done after immediately resetting the password that was compromised and all below (if root). The process [for databases above](#MariaDB - database(s)) applies mostly as a compromised password compromises databases.
+The level of severity depends on which password is assumed to have been compromised. An evaluation of all databases that may have been compromised should be done after immediately resetting the password that was compromised and all below (if root). The process [for databases above](#mariadb---databases) applies mostly as a compromised password compromises databases.
 
 The key should be updated both in puppet and manually on the server (Puppet does not automatically change SQL passwords).
 

content/tech-docs/Tech:GHSA.md

@@ -11,7 +11,7 @@ Advisories should only be created for software we build for external parties - t
 If you need to create an advisory, follow the steps below:
 * Go to the repository that is relevant for the code you wish to create an advisory for.
 * Select the 'Security' tab and then on the side menu, select 'Security Advisories' and then press the green button 'New Draft Security Advisory'.
-* Fill out the information to the best of your knowledge currently. If unsure, leave it blank or insert 'N/K'. See an explanation of the [CVSS](#Making an Assessment Using CVSS) matrix.
+* Fill out the information to the best of your knowledge currently. If unsure, leave it blank or insert 'N/K'. See an explanation of the [CVSS](#making-an-assessment-using-cvss) matrix.
 * Once created, on the right-hand side there is an option to invite 'Collaborators' to see the advisory. This can include anyone who may require access to the advisory prior to publishing, such as 'Security' project members who are not in Site Reliability Engineering, the reporter, or any trusted volunteer developer who has or is working on a patch.
 
 **If a fix is possible:**

content/tech-docs/Tech:Memcached.md

@@ -36,7 +36,7 @@ To use TCP, run the following:
 
 `telnet 127.0.0.1 11211`
 
-Then follow [#Commands](#Commands).
+Then follow [#Commands](#commands).
 
 You can do it via PHP by [following](https://meta.miraheze.org/wiki/github:miraheze/MirahezeMagic/blob/e4e20be/includes/MirahezeMagicHooks.php#L263) and the [docs](https://www.php.net/manual/en/class.memcached.php).
 

content/tech-docs/Tech:Organization-Site_Reliability_Engineering.md

@@ -19,7 +19,7 @@ This is a guide for all Miraheze Site Reliability Engineers. They have access to
 
 * When deploying a change (SSL certificate, database rename, etc.), you are **required** to closely watch the change going live.
 * After committing a change to any repo (and being sure it should work), run `sudo puppet agent -tv` on the server involved. It can take a while before the change is actually deployed.
-* Watch the error logs: [#Monitoring errors](#Monitoring errors).
+* Watch the error logs: [#Monitoring errors](#monitoring-errors).
 
 *Further specifics to be filled in by SRE*
 
@@ -29,7 +29,7 @@ This is a guide for all Miraheze Site Reliability Engineers. They have access to
 
 ## Debugging 
 
-* Look at the [error logs](#Monitoring errors).
+* Look at the [error logs](#monitoring-errors).
 * Try to send the failing HTTP request with the header `X-WikiTide-Debug: 1`, it could be an error that is cached in Varnish.
 
 ## See also 

content/tech-docs/Tech:Organization-mw-admins.md

@@ -42,21 +42,21 @@ See [Tech:Adding a new extension](/tech-docs/techadding_a_new_extension).
    * If a syntax error should occur, push a fixing-commit to the repo(s) and manually run puppet (`sudo puppet agent -t`) on mwtask181.
 * When a configuration variable is changed, you should be completely aware what it does, and how it could impact a wiki security-wise.
 * There is more stuff in LocalSettings.php than just configuration variables, like [this](https://github.com/miraheze/mw-config/blob/d9b720ba7a19fd77d7dc7c08a9e3f640cb6c9b0f/LocalSettings.php#L2905-L3028). You are allowed to edit such stuff, but if you are not familiar with its functionality, it's not recommended to touch it (or to merge pull requests that make changes to this area).
-See [#Deployment](#Deployment) for the rest.
+See [#Deployment](#deployment) for the rest.
 
 ## Deployment 
 
 * When deploying a configuration change or extension, you are **required** to closely watch the change going live.
 * After committing a change to the mediawiki or mw-config repo (and being sure it should work), run `sudo puppet agent -t` on mwtask181. It can take a while before the change is actually deployed.
-* Watch the error logs: [#Monitoring errors](#Monitoring errors).
+* Watch the error logs: [#Monitoring errors](#monitoring-errors).
 
 ## Monitoring errors 
 
 Follow the instructions at [Tech:Graylog](/tech-docs/techgraylog).
 
 ## Debugging 
 
-* Look at the [error logs](#Monitoring errors).
+* Look at the [error logs](#monitoring-errors).
 * Try to send the failing HTTP request to one of the mw servers with the header `X-Miraheze-Debug: (mw1[5678][12]|test151|mwtask181).wikitide.net` (replace with the desired server), it could be an error that is cached in Varnish.
 
 [Category:Technology guidelines and guides](https://meta.miraheze.org/wiki/Category:Technology_guidelines_and_guides)

content/tech-docs/Tech:Server_lifecycle.md

@@ -45,7 +45,7 @@ Reimaging a server means the server will be kept in use, but a new OS will be in
 
 ## Upgrade 
 
-An upgrade may be necessary in cases where horizontal scaling (having three smaller servers, instead of one big one) is not possible or needed. Upgrades must follow the [requesting](#Requesting) section above. An upgrade is considered to require a reboot, but without the need for a reimage. If a reimage is needed, please follow both these steps and the steps for [reimaging](#Reimage). The guide expects you have gotten an OK from the service experts, and that they are aware of the upgrades. If a server must be depooled before an upgrade is performed, the guide expects you know how to do that.
+An upgrade may be necessary in cases where horizontal scaling (having three smaller servers, instead of one big one) is not possible or needed. Upgrades must follow the [requesting](#requesting) section above. An upgrade is considered to require a reboot, but without the need for a reimage. If a reimage is needed, please follow both these steps and the steps for [reimaging](#reimage). The guide expects you have gotten an OK from the service experts, and that they are aware of the upgrades. If a server must be depooled before an upgrade is performed, the guide expects you know how to do that.
 
 * 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.