Auto-update Tech namespace pages 2024-09-17 22:29:12.679314

content/tech-docs/Tech:Communication.md

@@ -10,7 +10,7 @@ This page aims to document our communication channels, and outline a general str
 
 * **[Discord](https://meta.miraheze.org/wiki/Discord)**. Over on Discord there's special channels for communicating important announcements. such as `#announcements`, which is also mirrored on other Discord servers.
 * **[Hund](https://meta.miraheze.org/wiki/Tech:Hund)**. Your standard status page. Available at [status.miraheze.wiki](https://status.miraheze.wiki), and additionally has multiple types of subscriptions.
-* **[Tech:SRE noticeboard](https://meta.miraheze.org/wiki/Tech:SRE_noticeboard)**. A page hosting on-wiki announcements by SRE.
+* **[Tech:Noticeboard](/tech-docs/technoticeboard)**. A page hosting on-wiki announcements by the [Technology team](/tech-docs/techvolunteers).
 * **Twitter, Mastodon and Facebook**. Social media.
 * **On-wiki sitenotices**. Sitenotices that are shown on either wikis meeting a specific condition ("targeted"), such as having an extension enabled, or shown everywhere ("global"). Managed at [mw-config/Sitenotice.php](https://github.com/miraheze/mw-config/blob/master/Sitenotice.php) on [GitHub](/tech-docs/techgithub).
 * Less importantly, **[Phorge](https://meta.miraheze.org/wiki/Phorge)**. While it can be argued comments and tasks there are not for the community at-large, some may use these for the latest "announcements", especially in tasks related to farm-wide issues. Just something to keep in mind.
@@ -23,11 +23,11 @@ We should aim to:
 * Keep the messaging in all the channels in-sync, and;
 * Offer updates as the situation evolves.
 
-This is a deceptively-complex issue, therefore, this should ideally be the responsibility of a Community Engagement Specialist, who participates in the (sometimes private) conversations regarding issues (such as security issues which are not discussed in the open), and both understands the technical jargon used in SRE and is able to translate it for the community at wide to understand.
+This is a deceptively-complex issue, therefore, this should ideally be the responsibility of a [Community Liaison](/tech-docs/techorganization#community-liaison), who participates in the (sometimes private) conversations regarding issues (such as security issues which are not discussed in the open), and both understands the technical jargon used in the Technology team and is able to translate it for the community at wide to understand.
 
-Ideally, communication should happen once everyone relevant on SRE has discussed the issue, to ensure everyone has a consistent messaging.
+Ideally, communication should happen once everyone relevant on the Technology team has discussed the issue, to ensure everyone has a consistent messaging.
 
-### Appropriate channels
+### Appropriate channels 
 
 Not all channels are made the same. Some, like on-wiki sitenotices, are very intrusive. You should keep it appropriate.
 

content/tech-docs/Tech:Compromised_Handling.md

@@ -11,9 +11,7 @@ If you're on this page just to learn things, that's good. If you're on this page
 We store a fair amount of private things, not so much user-facing all the time but service-level things like passwords, certificate keys, actual servers, and so on. Here is a list of things we store which if compromised, should be dealt with as a serious incident:
 
 * Servers
-* Bacula (passwords)
 * Grafana (passwords)
-* GlusterFS (SSL Certificates)
 * Icinga2 (It contains passwords to connect to the db)
 * Icingaweb2 (Includes user passwords in the db and contains passwords to connect to the db)
 * IRC (mirahezebots password)
@@ -23,6 +21,7 @@ We store a fair amount of private things, not so much user-facing all the time b
 * PuppetDB (passwords for postgresql)
 * Redis (password)
 * Salt master (private keys)
+* Swift (passwords)
 * SSL (private keys)
 
 If you add something to private git which is not covered above, please ensure you update this page with the necessary information. If you don't and a security incident occurs relating to what you've added, you will be liable for the outcome even if you were not the cause of the incident in the first place.
@@ -31,15 +30,15 @@ If you add something to private git which is not covered above, please ensure yo
 
 In general, an email to tech `{{ {{@}} }}`miraheze.org should always be sent if any data (or suspicion of data) is compromised. Specific services will have specific additional people to contact or people who should be notified to assess the situation (the person who is most knowledgeable about the component - see list of [Technology team members](/tech-docs/techvolunteers)).
 
-We operate as an open project, therefore any security incident (no matter how small) will result in a community notification through an incident report. An incident report should always be submitted for security incidents as they're far more damaging in the long run than a 10-minute service outage, and is our way of showing progress and work towards providing a more secure platform. Reports should be drafted and approved by an Engineering Manager first as the consequences of a poor or unsatisfactorily complete report can be unpredictable.
+We operate as an open project, therefore any security incident (no matter how small) will result in a community notification through an incident report. An incident report should always be submitted for security incidents as they're far more damaging in the long run than a 10-minute service outage, and is our way of showing progress and work towards providing a more secure platform. Reports should be drafted and approved by the Director of Technology first as the consequences of a poor or unsatisfactorily complete report can be unpredictable.
 
 ## Handling Compromises 
 
 ### Servers 
 
 The servers should be the most secure parts of the Miraheze operation. Firewalls exist to keep port access limited, failed SSH attempts eventually result in port bans for specific IPs, secure ciphers are used, and the root user cannot be logged into. Security updates are also run regularly - this prospect should be very unlikely but things happen.
 
-Once someone is aware that a server has been compromised, their ability to handle the situation will be limited by their access. Site Reliability Engineering should be notified immediately. In extreme cases, if the user discovering the possible compromise has root access on the server but is not a Site Reliability Engineer, they may be able to handle parts of the plan below; however, if they're unsure, crowd control is the best method by means of either shutting the server down, disallowing port 22, or shutting down SSH - Site Reliability Engineering have back doors in, others do not.
+Once someone is aware that a server has been compromised, their ability to handle the situation will be limited by their access. The [Technology team](/tech-docs/techvolunteers) should be notified immediately.
 
 * Ensure no one can gain access to the system after the issue has been discovered. Be it stopping the ssh server, shutting it down (or a reboot to close connections), blocking all ports etc. just ensure no one can get into the system.
 * Begin to get a handle on how access may have been gained - through software? an SSH account? Compromised SSH key? If it can be tied to a certain and definitive SSH account - remove said account from all servers and check the rest for safety.
@@ -48,10 +47,6 @@ Once someone is aware that a server has been compromised, their ability to handl
 
 The above is a basic plan to follow. Certain situations require more in-depth investigations, they can take minutes to hours to days to even weeks.
 
-### Bacula 
-
-Bacula passwords are used for authenticating communication between Bacula clients and directors. If the password becomes compromised, it is a possibility that a user can run their own backups using Bacula and thusly compromise data. The password should be reset in private git and puppet can then be run to update the passwords globally on the cluster. You should try to conclude how the password was compromised as it may make the solution ineffective here.
-
 ### Grafana 
 
 Grafana passwords are used so that users can edit the dashboards. If a user forgets their password, they can have grafana reset their password by sending them an email. If their account became compromised, the hacker could make a malicious dashboard that could possibly gain additional metrics we don't want them to know about the system.
@@ -97,6 +92,7 @@ Under EU law, we're required to notify all European users in the event of a brea
 ## Categories
 
 * [Category:Tech](https://meta.miraheze.org/wiki/Category:Tech)
+* [Category:Technology guidelines and guides](https://meta.miraheze.org/wiki/Category:Technology_guidelines_and_guides)
 
 ----
 **[Go to Source →](https://meta.miraheze.org/wiki/Tech:Compromised_Handling)**

content/tech-docs/Tech:Experimental_Wikis.md

@@ -2,13 +2,15 @@
 title: Tech:Experimental Wikis
 ---
 
-Experimental wikis are active wikis with experienced contributors that have agreed to receive changes earlier than others and provide feedback to SRE. Please ping SRE, so they can consider running a cache purge if they desire when enabling the flag.
+`{{ {{Outdated}} }}`
+
+Experimental wikis are active wikis with experienced contributors that have agreed to receive changes earlier than others and provide feedback to the [Technology team](/tech-docs/techvolunteers). Please ping the Technology team, so they can consider running a cache purge if they desire when enabling the flag.
 
 To have the flag enabled in ManageWiki (by a Steward), the following criteria must be met:
 * The wiki must be active and used regularly.
 * The wiki must be public.
 * Users on the wiki should be technically competent and polite.
-* The wiki should have a variety of extensions installed (especially Cargo/Social Profile/FlaggedRev/DPL/Complex ones).
+* The wiki should have a variety of extensions installed (especially Cargo/Semantic MediaWiki/SocialProfile/FlaggedRev/DPL/Complex ones).
 * The wiki should use gadgets or user scripts.
  `{{ {{note}} }}` The feature should be enabled on no more than 50 wikis.
 

content/tech-docs/Tech:FIDO2_SSH.md

@@ -28,7 +28,7 @@ If you use signed commits or OpenPGP, now would be a good time to use them for e
 
 If your key is broken, you will be locked out from login in. To prevent this, you can create multiple SSH keys using various **different** FIDO2 keys. Just repeat the above process with different keys, and assign their public keys to your shell account. That way, if your main key stops working, you'll not be locked out completely.
 
-Ignore this warning at your own peril: If your key stops working, it could become impossible for SRE to verify that any requests to change your keys on Puppet comes from you. Better to have multiple keys from the get-go.
+Ignore this warning at your own peril: If your key stops working, it could become impossible for the [Technology team](/tech-docs/techvolunteers) to verify that any requests to change your keys on Puppet comes from you. Better to have multiple keys from the get-go.
 
 ## See also
 

content/tech-docs/Tech:GHSA.md

@@ -18,13 +18,13 @@ If you need to create an advisory, follow the steps below:
 * Click the create private fork button. This must be done by a member of that repository.
 * Start creating your patch privately.
 * Ask someone to review the patch.
-* Ask a member of the SRE Management Team to review the advisory prior to publication. This is to ensure all lines of enquiry, and steps taken to prevent and minimise technical risk, have been taken. It is recommended to also inform [Trust and Safety](https://meta.miraheze.org/wiki/Trust_and_Safety) of the advisory prior to publication as well.
+* Ask the Director of Technology to review the advisory prior to publication. This is to ensure all lines of enquiry, and steps taken to prevent and minimise technical risk, have been taken. It is recommended to also inform [Trust and Safety](https://meta.miraheze.org/wiki/Trust_and_Safety) of the advisory prior to publication as well.
 * Click 'Request CVE'.
 * Publish it, you may for some repositories want to inform Wikimedia Security to add to the next supplementary announcement.
 * Check the information on Mitre/NVD is correct and communicate with them.
 
 **If a fix is not possible:**
-* Ask a member of the SRE Management Team to review the advisory prior to publication. This is to ensure all lines of enquiry and steps taken to prevent and minimise technical risk have been taken. It is recommended to also inform [Trust and Safety](https://meta.miraheze.org/wiki/Trust_and_Safety) of the advisory prior to publication as well.
+* Ask the Director of Technology to review the advisory prior to publication. This is to ensure all lines of enquiry and steps taken to prevent and minimise technical risk have been taken. It is recommended to also inform [Trust and Safety](https://meta.miraheze.org/wiki/Trust_and_Safety) of the advisory prior to publication as well.
 * Click 'Request CVE'.
 * Publish it, you may for some repositories want to inform Wikimedia Security to add to the next supplementary announcement.
 * Check the information on Mitre/NVD is correct and communicate with them.
@@ -79,7 +79,7 @@ If you need to create an advisory, follow the steps below:
 
 ## Categories
 
-* [Category:Guides for sysadmins](https://meta.miraheze.org/wiki/Category:Guides_for_sysadmins)
+* [Category:Technology guidelines and guides](https://meta.miraheze.org/wiki/Category:Technology_guidelines_and_guides)
 
 ----
 **[Go to Source →](https://meta.miraheze.org/wiki/Tech:GHSA)**

content/tech-docs/Tech:SRE_Import_guideline.md → content/tech-docs/Tech:Import_guideline.md

@@ -1,12 +1,12 @@
 ---
-title: Tech:SRE Import guideline
+title: Tech:Import guideline
 ---
 
 Imports are a vital process as they allow users to migrate their wikis from other platforms to Miraheze, to easily use content from other wikis without having to copy/paste, and they provide easier copyright attribution.
 
 While imports are very important to Miraheze, the import process must not be abused. Excessive requests for imports (especially those simply copying articles from Wikipedia or a single user trying to 'fork' wikis, are to be scrutinized before being authorized).
 
-This policy is an SRE policy and due to its complexity, it is not necessary to have regular users read it before making a request. Instead, it is to be used by SRE members when determining whether an import will be approved.
+This policy is a [Technology team](/tech-docs/techvolunteers) policy and due to its complexity, it is not necessary to have regular users read it before making a request. Instead, it is to be used by Technology team members when determining whether an import will be approved either those via [Special:RequestImport](https://meta.miraheze.org/wiki/Special:RequestImport) or manually.
 
 ## Types of import 
 
@@ -37,7 +37,6 @@ This table indicates the approximate sizes of XMLs/images to be considered for f
 
 All suggestions below can be exceeded if approved by a MWE that is satisfied a reasonable use case exists, after asking questions. The numbers are not fixed and should not be taken literally (i.e., if there's a 1.1 XML, that won't necessarily require additional questions). If the limit is not exceeded, no additional questions need to be asked and the import can be approved.
 
-| + |
 | Active users | Max XML size (suggestion) | Max images size (suggestion) | Additional comments |
 | --- | --- | --- | --- |
 | 1 | 500 MB | 2.5 GB | If from Wikipedia and not Templates, Gadgets, etc max 100 MB |
@@ -46,5 +45,10 @@ All suggestions below can be exceeded if approved by a MWE that is satisfied a r
 | 15-25 | 10 GB | 20 GB | |
 | > 25 | 15 GB | 30 GB | |
 
+## Categories
+
+* [Category:Tech](https://meta.miraheze.org/wiki/Category:Tech)
+* [Category:Technology guidelines and guides](https://meta.miraheze.org/wiki/Category:Technology_guidelines_and_guides)
+
 ----
-**[Go to Source →](https://meta.miraheze.org/wiki/Tech:SRE_Import_guideline)**
+**[Go to Source →](https://meta.miraheze.org/wiki/Tech:Import_guideline)**

content/tech-docs/Tech:Moving_a_wiki_to_another_database_server.md

@@ -4,7 +4,7 @@ title: Tech:Moving a wiki to another database server
 
 This page provides guidance if you need to move a wiki to another database server (typically relates to disk space issues/imbalances).
 
-Moving a wiki to another database is not complicated provided you have the required rights (SRE, root on the db servers).
+Moving a wiki to another database is not complicated provided you have the required rights (Infrastructure Specialists or database-admins).
 
 * Put the wiki you are moving into read-only mode (add a read-only notice if you'd like, especially if it is a large wiki, and it will take time).
    * Example: [https://github.com/miraheze/mw-config/commit/497e5608d95ba148b81133d5c34ce72a046d9c43](https://github.com/miraheze/mw-config/commit/497e5608d95ba148b81133d5c34ce72a046d9c43)
@@ -23,6 +23,7 @@ Moving a wiki to another database is not complicated provided you have the requi
 
 ## Categories
 
+* [Category:Tech](https://meta.miraheze.org/wiki/Category:Tech)
 * [Category:Technology guidelines and guides](https://meta.miraheze.org/wiki/Category:Technology_guidelines_and_guides)
 
 ----

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

@@ -37,7 +37,7 @@ Follow the instructions at [Tech:Graylog](/tech-docs/techgraylog) for most error
 
 ## See also 
 
-* [MediaWiki Specialists guide](https://meta.miraheze.org/wiki/Tech:Organization/MediaWiki_Specialists)
+* [MediaWiki Specialists guide](/tech-docs/techorganization-mediawiki_specialists)
 
 ## Categories
 

content/tech-docs/Tech:Organization.md

@@ -48,13 +48,13 @@ Project Managers triage incoming support requests from the community, within the
 
 ### MediaWiki Specialist 
 
-   *See also: [Tech:Organization/MediaWiki Specialists](https://meta.miraheze.org/wiki/Tech:Organization/MediaWiki_Specialists)*
+   *See also: [Tech:Organization/MediaWiki Specialists](/tech-docs/techorganization-mediawiki_specialists)*
 
 MediaWiki Specialists are responsible for maintaining the MediaWiki core platform and extensions, including in-house extensions. They operate the latest stable version of MediaWiki, manage configuration and feature requests from the community, and work with upstream and third-party MediaWiki developers.
 
 ### Infrastructure Specialist 
 
-   *See also: [Tech:Organization/Infrastructure Specialists](https://meta.miraheze.org/wiki/Tech:Organization/Infrastructure_Specialists)*
+   *See also: [Tech:Organization/Infrastructure Specialists](/tech-docs/techorganization-infrastructure_specialists)*
 
 Infrastructure Specialists ensure Miraheze's services and servers are fast, reliable and secure. Infrastructure Specialists are responsible for providing the critical services that support our deployment of MediaWiki, including virtual and physical servers, relational databases, media storage, automation tooling, configuration management systems, networking, continuous integration and continuous delivery, cache stores, and observability platforms.