diff --git a/content/tech-docs/Tech:Communication.md b/content/tech-docs/Tech:Communication.md index e009b69ec..4cc7db664 100644 --- a/content/tech-docs/Tech:Communication.md +++ b/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. diff --git a/content/tech-docs/Tech:Compromised_Handling.md b/content/tech-docs/Tech:Compromised_Handling.md index 9613aaab3..31a3c77d6 100644 --- a/content/tech-docs/Tech:Compromised_Handling.md +++ b/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,7 +30,7 @@ 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 @@ -39,7 +38,7 @@ We operate as an open project, therefore any security incident (no matter how sm 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)** \ No newline at end of file diff --git a/content/tech-docs/Tech:Experimental_Wikis.md b/content/tech-docs/Tech:Experimental_Wikis.md index b53807d52..d97e7a8b8 100644 --- a/content/tech-docs/Tech:Experimental_Wikis.md +++ b/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. diff --git a/content/tech-docs/Tech:FIDO2_SSH.md b/content/tech-docs/Tech:FIDO2_SSH.md index 10f0bf6ea..f1b81a844 100644 --- a/content/tech-docs/Tech:FIDO2_SSH.md +++ b/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 diff --git a/content/tech-docs/Tech:GHSA.md b/content/tech-docs/Tech:GHSA.md index 07dfda2cd..bd7b19e0c 100644 --- a/content/tech-docs/Tech:GHSA.md +++ b/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)** \ No newline at end of file diff --git a/content/tech-docs/Tech:SRE_Import_guideline.md b/content/tech-docs/Tech:Import_guideline.md similarity index 82% rename from content/tech-docs/Tech:SRE_Import_guideline.md rename to content/tech-docs/Tech:Import_guideline.md index 912a94917..3b879b975 100644 --- a/content/tech-docs/Tech:SRE_Import_guideline.md +++ b/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)** \ No newline at end of file +**[Go to Source →](https://meta.miraheze.org/wiki/Tech:Import_guideline)** \ No newline at end of file diff --git a/content/tech-docs/Tech:Moving_a_wiki_to_another_database_server.md b/content/tech-docs/Tech:Moving_a_wiki_to_another_database_server.md index 51e17a254..595193617 100644 --- a/content/tech-docs/Tech:Moving_a_wiki_to_another_database_server.md +++ b/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) ---- diff --git a/content/tech-docs/Tech:Organization-Infrastructure_Specialists.md b/content/tech-docs/Tech:Organization-Infrastructure_Specialists.md index 59f47ddff..d54ea061e 100644 --- a/content/tech-docs/Tech:Organization-Infrastructure_Specialists.md +++ b/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 diff --git a/content/tech-docs/Tech:Organization.md b/content/tech-docs/Tech:Organization.md index 28315d7c2..e981d02ed 100644 --- a/content/tech-docs/Tech:Organization.md +++ b/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. diff --git a/content/tech-docs/Tech:Projects.md b/content/tech-docs/Tech:Projects.md index 64e9a8ed2..ca2a6099c 100644 --- a/content/tech-docs/Tech:Projects.md +++ b/content/tech-docs/Tech:Projects.md @@ -2,10 +2,12 @@ title: Tech:Projects --- - `{{ {{SRE navigation|projects|header=SRE Projects|description= Miraheze's system administrators are always planning out things. Learn more about our current projects on Miraheze Meta.|keywords=sre projects, miraheze sre projects}} }}` + + `{{ {{Tech navigation|projects|header=Technology Team Projects|description= Miraheze's Technology team are always planning out things. Learn more about our current projects on Miraheze Meta.|keywords=tech projects, miraheze tech projects}} }}` + Miraheze continually strives to provide a strong, community centred service; along with that comes community scrutiny and community involvement over projects that are planned to take up considerable resources in terms of development, reviewing efforts, deployment, or long-standing maintenance. -Below is a list of large projects that SRE has in mind, the idea of this page is to: +Below is a list of large projects that the [Technology team](/tech-docs/techvolunteers) has in mind, the idea of this page is to: * Have a centralised place for active community discussion over merits, design specs, etc. * Store all information about a project in a central place, not in [Phorge](https://meta.miraheze.org/wiki/Phorge). * Be planned and thoroughly thought through before being formally proposed as a project eligible for a goal. @@ -19,7 +21,7 @@ Anyone may: ## Current proposals -* [Automation of SSL requests](https://meta.miraheze.org/wiki//Automation_of_SSL_requests) — Implement a system where on request, users are able to generate a Lets Encrypt certificate which is then deployed to GitHub and to MediaWiki via $wgServer (after being approved by an SRE member) (~175 hours). +* [Automation of SSL requests](https://meta.miraheze.org/wiki//Automation_of_SSL_requests) — Implement a system where on request, users are able to generate a Lets Encrypt certificate which is then deployed to GitHub and to MediaWiki via $wgServer (after being approved by a Technology team member) (~175 hours). * [CreateWiki AI improvement](https://meta.miraheze.org/wiki//CreateWiki_AI_improvement) — Improve the current AI system for CreateWiki to allow for different factors to be taken into account when assessing how 'good' a request is (~175 hours). * [Proper CI for Miraheze extensions](https://meta.miraheze.org/wiki//Proper_CI_for_Miraheze_extensions) — Implement proper continuous integration for extensions maintained by Miraheze (~175 hours). diff --git a/content/tech-docs/Tech:Removing_an_extension.md b/content/tech-docs/Tech:Removing_an_extension.md index ab800bb89..225259f32 100644 --- a/content/tech-docs/Tech:Removing_an_extension.md +++ b/content/tech-docs/Tech:Removing_an_extension.md @@ -2,7 +2,9 @@ title: Tech:Removing an extension --- -If a decision has been made to remove an extension from Miraheze for whatever reason (i.e., it's unmaintained, it isn't compatible with the current version of MediaWiki, etc.) the following procedure should be followed when removing an extension. Any user can create a pull request to remove an extension, but it has to be merged and deployed by a [system administrator](/tech-docs/techvolunteers). +`{{ {{Outdated}} }}` + +If a decision has been made to remove an extension from Miraheze for whatever reason (i.e., it's unmaintained, it isn't compatible with the current version of MediaWiki, etc.) the following procedure should be followed when removing an extension. Any user can create a pull request to remove an extension, but it has to be merged and deployed by a [Technology team member](/tech-docs/techvolunteers) with access. The steps below must be done in this order: diff --git a/content/tech-docs/Tech:SRE_2021_Restructure-Approvals_Policy.md b/content/tech-docs/Tech:SRE_2021_Restructure-Approvals_Policy.md deleted file mode 100644 index e29835ce1..000000000 --- a/content/tech-docs/Tech:SRE_2021_Restructure-Approvals_Policy.md +++ /dev/null @@ -1,106 +0,0 @@ ---- -title: Tech:SRE 2021 Restructure/Approvals Policy ---- - -# Proposed version - -Name: Expenditure Authorisation Policy - Site Reliability Engineering (available on-wiki and in PDF format for the Board) - -* Author: Ferran Tufan -* Date: 2021-01-24 -* Ratified by Board on: - -## Definitions - -* Board: Miraheze Limited's Board of Directors, legally responsible for the company and allocating donor funds to departments. -* Budget: the sum of money received from the Board in order to operate the Site Reliability Engineering team. -* Budget holder: a member of Site Reliability Engineering, responsible for tracking the budget and authorising expenditures. Unless otherwise specified, the Director of Site Reliability Engineering is the budget holder. In the case of absence from the Director of Site Reliability Engineering, one of the Engineering Managers will be appointed as (ad-interim) budget holder. -* Budget period: the timeframe (January 1 - June 30 or July 1 - December 31) for which a budget has been allocated. -* Commitment: an obligation to spend a certain amount of money over a given timespan. -* Director of Site Reliability Engineering: a member of Site Reliability Engineering in charge of leading Site Reliability Engineering, appointed by the Board. -* Emergency: a situation where looping through the regular approval chain would (or greaterly impact) very likely cause permanent data loss or a data breach, therefore immediate spending is necessary. -* Engineering Manager: a member of Site Reliability Engineering in charge of leading a team within Site Reliability Engineering, appointed by the Director of Site Reliability Engineering. -* Volunteer: a member of Site Reliability Engineering, regardless of the role. - -## Description - -Site Reliability Engineering (SRE) is responsible for the innovation, security, privacy and administration of IT services, infrastructure and data of Miraheze. Site Reliability Engineering maintains all Miraheze servers and services, develops new extensions for the community, resolves the requests of the community and advises the Board on information security and privacy matters. - -The Site Reliability Engineering department reports directly to the [Board](https://meta.miraheze.org/wiki/Board). In order to provide services to the Miraheze community, Site Reliability Engineering receives a budget from twice per year. This budget is located on a dedicated bank account. This document describes which rules apply to Site Reliability Engineering for spending the budget. - -## Expenditure - -The authorised person for expenditure depends on the commitment. For example, purchasing a £50/month (including VAT) server with a 24-month commitment (obligation) results in a commitment of £50 * 24 = £1200. With just a monthly commitment (obligation), the commitment is £50 * 1 = £50. Signing a contract with high monthly expenses with a long-time commitment to pay for the services implies higher financial risks - potentially even affecting Miraheze after a budget period has passed, hence the commitment is an important indicator. In general: the higher the commitment, the stricter the rules are. - -* Commitment up to £300.00: sign-off from the budget holder. -* Commitment exceeding £300.00, but up to £600.00: sign-off from the budget holder and at least one (1) Engineering Manager. -* Commitment exceeding £600.00: sign-off from the budget holder and at least two (2) Engineering Managers. - -## Emergencies - -The aforementioned approval chain must be adhered to at all times. However, in an emergency, waiting for the formally required sign-offs may pose a threat to Miraheze. If a situation is an emergency and involved team members have a good faith belief the required budget holder and/or Engineering Managers will not be able to respond in a reasonable amount of time (rule of thumb: 30 minutes), the Engineering Managers and the budget holder are authorised to spend without any formal approval or with only a fraction of the required sign-offs. They must inform the budget holder (Engineering Managers) or the Board (budget holder) regarding the expenses as soon as possible. The consequences of misuse of funds are up to the discretion of the budget holder (Engineering Managers) or the Board (budget holder). - -## Objections - -Any volunteer has the right to raise objections against a decision from the budget holder or Engineering Managers. They should try to resolve the dispute with the involved parties first. However, if the volunteer is not satisfied with the outcome, they are allowed to invoke the Board's [complaints procedure](https://meta.miraheze.org/wiki/File:Miraheze-Complaints-Procedure.pdf) for the objection. The Board has the final say in the complaints procedure. - -## Out of budget - -If the budget has been exceeded (due to regular requests or emergencies), the budget holder must testify to the Board. If an emergency is (partially) the cause of this incident, the involved parties must testify to the Board as well. The Board has the authority to take any action in order to resolve the incident. Examples of actions are, but are not limited to: -* Allocating extra funds for the remainider of the budget period. -* Firing the Director of Site Reliability Engineering (budget holder). -* Reverting a commitment (if possible). - -## Ad-hoc - -In the event of a situation not covered by this policy, the Board has to pass a resolution. A change to this policy (other than fixing a spelling mistake) must go through the resolution process of the Board. - -# Old version - -[File:Approvals_Policy_-_Technical_Team.pdf](https://meta.miraheze.org/wiki/File:Approvals_Policy_-_Technical_Team.pdf) - -*Reminder for all: you are working with donor money. Any purchase not for the sake of improving the Miraheze services does not fall under this policy. Misuse of funds is a gross offense.* - -The *Technical Team*, also known as *Site Reliability Engineering*, is responsible for hosting the sites and managing the IT services used by Miraheze, has a budget allocated bi-yearly by the Board. A budget period covers Jan 1 – Jun 30 or Jul 1 – Dec 31. This approvals policy should ensure consensus on spending and transparency about Miraheze’s expenses within the Technical Team. - -Assignment of roles: -* Budget holder: Ferran Tufan (as appointed by the Board) -* Senior Site Reliability Engineers: John Lewis -* Site Reliability Engineers: anyone in the ‘ops’ group, sans Senior Site Reliability Engineers and -(ad-interim) budget holder -* (Ad-interim) budget holder, in case of long-term absence (unless otherwise overridden): John -Lewis - -## Personal budget - -Site Reliability Engineers must adhere strict standards before they are appointed, and they might need to purchase test servers for experiments. Every Site Reliability Engineer gets a $25.00 fixed budget, for Senior Site Reliability Engineers this is $40.00. This may be retrieved out of the bank account directly (by buying the server in the control panel, if applicable) or will be reimbursed upon request. In the current situation, this amount is $0. - -## Regular requests - -Use significant figures for calculation. -If the purchase cannot be covered by personal budget, the policy below must be applied. -Up to 15.00% per budget period: sign-off from budget holder. -15.00% - 30.00%: sign-off from budget holder, one Senior Site Reliability Engineer (if applicable), and: -* at least one, or 25%3 of Site Reliability Engineers (rounded up to above), whichever is higher. -30.00% or greater: sign-off from budget holder, one Senior Site Reliability Engineer (if applicable), -and: -* at least two, or 50%3 of Site Reliability Engineers (rounded up to above), whichever is higher. - -## Emergencies - -When purchases must be made to reduce the impact of an emergency (e.g. keeping critical data intact), a Senior Site Reliability Engineer may decide to make purchases without prior approval by the budget holder, even if the purchase exceeds their (total/combined) personal budget. They must inform the budget holder as soon as possible. The consequences of misuse of funds are up to the discretion of the budget holder. - -## Objections - -Any (Senior) Site Reliability Engineer can raise objections against a decision of the budget holder. They should try to resolve the dispute with the budget holder, however; if that is not possible, they can notify the Board of the objection. In said case the Board may decide to pass a resolution to agree/revert the decision of the budget holder. The Board has the final say in any dispute. - -## Out of budget - -If the budget has been exceeded (due to regular requests or emergencies), the budget holder will have to testify to the Board. If the Board determines the budget holder has acted irresponsibly, they may appoint a new (temporarily) budget holder. Other consequences are also up to the Board. - -## Ad-hoc - -In the event a situation is not covered by this policy, a decision has to be approved by the Board. Any change made to this policy must go through the resolution process of the Board. - ----- -**[Go to Source →](https://meta.miraheze.org/wiki/Tech:SRE_2021_Restructure/Approvals_Policy)** \ No newline at end of file diff --git a/content/tech-docs/Tech:SRE_2021_Restructure.md b/content/tech-docs/Tech:SRE_2021_Restructure.md deleted file mode 100644 index db605ae56..000000000 --- a/content/tech-docs/Tech:SRE_2021_Restructure.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: Tech:SRE 2021 Restructure ---- - -This page describes the proposed restructuring of the Site Reliability Engineering team. This restructure was approved on 30 January 2021. - -The new top-down structure would be: - -## Department: Site Reliability Engineering - -This is the department that covers the pre-existing technical team members within. The department is responsible for the innovation, security, privacy, and administration of IT services, infrastructure and data of Miraheze. Site Reliability Engineering maintains all Miraheze servers and services, develops new extensions for the community, resolves the requests of the community and advises the Board on information security and privacy matters. - -### Position: Director of Site Reliability Engineering - -The Director of Site Reliability Engineering is a member of Site Reliability Engineering, appointed by Miraheze Limited's Board of Directors, to perform day-to-day management of Miraheze's Technical Operations. They maintain contact with the Service Providers, work as the budget holder in accordance with the approvals policy for the technical budget and advise on the larger projects undertaken by members of the department. They also line manage team leads (Engineering Managers) to ensure regular engagement with all members of the wide department and collect their views on organisation-level changes. - -## Team: Infrastructure, Site Reliability Engineering - -The Infrastructure team ensures Miraheze's services and servers are fast, reliable, and secure. MediaWiki being the key product of Miraheze, Infrastructure is responsible for providing all miscellaneous, yet critical services that make MediaWiki reliable, useful, secure and scalable. Infrastructure develops and maintains the virtual servers, relational databases, media storage, automation tooling, configuration management systems, network, continuous integration and continuous delivery, cache stores and observability platforms. - -Members of this team are called 'Site Reliability Engineers' but other more appropriate names to accurately describe one person's specialisms in future may be adopted as needed. - -### Position: Engineering Manager, Infrastructure - -The Infrastructure Engineering Manager leads the infrastructure team and ensures: -* appropriate task management for Infrastructure Team tasks, -* goals are met and kept on track for Infrastructure, -* the wellbeing and growth of the Infrastructure team. - -The Engineering Manager is appointed by the Director of Site Reliability Engineering and is responsible for ensuring cross-team collaboration and proactive engagement with other teams and departments. - -## Team: MediaWiki, Site Reliability Engineering - -The MediaWiki team is responsible for offering the MediaWiki core platform and MediaWiki extensions. They develop in-house extensions, maintain the latest stable version of MediaWiki core and extensions, handle the configuration and feature requests from the community and work with Wikimedia (upstream) and other third-parties. - -Members of this team are called 'MediaWiki Engineers' but other more appropriate names to accurately describe one person's specialisms in future may be adopted as needed. - -### Position: Engineering Manager, MediaWiki - -The MediaWiki Engineering Manager leads the MediaWiki team and ensures: -* Appropriate task management for MediaWiki Team tasks; -* Goals are met and kept on track for MediaWiki; and -* The wellbeing and growth of the MediaWiki team. - -The Engineering Manager is appointed by the Director of Site Reliability Engineering and is responsible for ensuring cross-team collaboration and proactive engagement with other teams and departments. - ----- -**[Go to Source →](https://meta.miraheze.org/wiki/Tech:SRE_2021_Restructure)** \ No newline at end of file diff --git a/content/tech-docs/Tech:Security.md b/content/tech-docs/Tech:Security.md index c1e2de7dc..0851f31b3 100644 --- a/content/tech-docs/Tech:Security.md +++ b/content/tech-docs/Tech:Security.md @@ -2,23 +2,21 @@ title: Tech:Security --- -`{{ {{Outdated}} }}` - -Unfortunately, most of our third-party repos don't have specific mail lists for security, and therefore the main checks will have to be done by the SRE member on duty. However, security-announcements is subscribed to the following: -* ` icinga-announce-request@lists.icinga.org ` -* ` announce-request@mariadb.org ` -* ` https://community.grafana.com/c/security-announcements/38 ` and ` https://community.grafana.com/c/releases/9 ` +Unfortunately, most of our third-party repos don't have specific mail lists for security, and therefore the main checks will have to be done by a [Technology team member](/tech-docs/techvolunteers). However, security-announcements is subscribed to the following: +* `icinga-announce-request@lists.icinga.org` +* `announce-request@mariadb.org` +* `https://community.grafana.com/c/security-announcements/38` and ` https://community.grafana.com/c/releases/9` ## Handling a Security incident guidelines (Relationship with Trust and Safety) -Since the creation of the Trust and Safety team in early 2021, the T&S team is primarily responsible for dealing with security threats, such as DoS/DDoS attacks or any other exploits that can be used that would cause harm to Miraheze. That being said, in this area, Site Reliability Engineering cooperation is essential for T&S to be able to effectively operate, and in some cases the SRE team will have to take urgent measures to stop or prevent an active threat from doing damage to the farm. There are two main types of threat that will generally arise: +Since the creation of the Trust and Safety team in early 2021, the T&S team is primarily responsible for dealing with security threats, such as DoS/DDoS attacks or any other exploits that can be used that would cause harm to Miraheze or the [WikiTide Foundation](https://meta.miraheze.org/wiki/WikiTide_Foundation). That being said, in this area, Technology team cooperation is essential for T&S to be able to effectively operate, and in some cases the Technology team will have to take urgent measures to stop or prevent an active threat from doing damage to the farm. There are two main types of threat that will generally arise: `{{ {{note}} }}` This guideline only applies to threats where actions for resolution aren’t around software deploys created externally (or internally for our software). ### Active threat (Emergency) There is an '**active' threat** when there is evidence that there have recently been attempts (whether successful or not) from a third party to exploit a vulnerability or to attack Miraheze otherwise (DDoS/DoS, etc.). -Due to their urgent nature, active threats may be dealt with by any SRE member without having to first consult T&S or the Engineering Manager of the relevant team (attempts to contact T&S should always be made first, but if there is no response action may be taken). Any action done by the SRE member should be *temporary* and after it is done the EM and the T&S team should be informed. +Due to their urgent nature, active threats may be dealt with by any Technology team member without having to first consult T&S or the Director of Technology (attempts to contact T&S should always be made first, but if there is no response action may be taken). Any action done by a Technology team member should be *temporary* and after it is done the Director of Technology and the T&S team should be informed. **Examples of active threats**: Someone posting code that can be used to exploit something, an active DDoS/DoS attack taking place. @@ -26,11 +24,11 @@ Due to their urgent nature, active threats may be dealt with by any SRE member w There is a '**passive' threat** when there is evidence of an existing vulnerability, but there is no evidence of any proof of concept or actual attempt (whether successful or not) to exploit that vulnerability recently. While these are still serious security issues, they are not as urgent as active threats, given the low probability that they will be exploited immediately. -Due to their less urgent nature than active threats, SRE members should only deal with them after an EM or a T&S member (or both) have been consulted (attempts to contact T&S should always be made first, if there is no response the EM should be contacted). Any action done by the SRE member should be *temporary* (unless T&S agrees to a permanent solution) and after it is done the T&S team should be informed (if done on EM approval only). +Due to their less urgent nature than active threats, Technology team members should only deal with them after the Director of Technology or a T&S member (or both) have been consulted (attempts to contact T&S should always be made first, if there is no response the Director of Technology should be contacted). Any action done by the Technology team member should be *temporary* (unless T&S agrees to a permanent solution) and after it is done the T&S team should be informed (if done on Director of Technology approval only). **Examples of passive threats**: Someone reporting a vulnerability but no evidence that it has been exploited (or attempts have been made) or is widely known. -If in doubt about whether a threat is active or passive and no EM or T&S member is around, use your judgment and consult members of the team who are around. Remember that T&S and SRE must collaborate on security issues. +If in doubt about whether a threat is active or passive and the Director of Technology or any T&S member is around, use your judgment and consult members of the team who are around. Remember that T&S and the Technology team must collaborate on security issues. ---- **[Go to Source →](https://meta.miraheze.org/wiki/Tech:Security)** \ No newline at end of file diff --git a/content/tech-docs/Tech:Server_usage.md b/content/tech-docs/Tech:Server_usage.md index 1c5bc7577..41e628fe3 100644 --- a/content/tech-docs/Tech:Server_usage.md +++ b/content/tech-docs/Tech:Server_usage.md @@ -2,7 +2,8 @@ title: Tech:Server usage --- -`{{ {{SRE navigation|servers|header=Servers|description=Miraheze has lots of servers in order to support its massive user base. Learn more about them here on Miraheze Meta.|keywords=miraheze servers}} }}` + `{{ {{Tech navigation|servers|header=Servers|description=Miraheze has lots of servers in order to support its massive user base. Learn more about them here on Miraheze Meta.|keywords=miraheze servers}} }}` + Miraheze requires lots of **servers** in order to provide service. With over 400,000 unique visits and millions of page views per day, we require quite a bit of processing power. Currently, servers at Miraheze are used for: diff --git a/content/tech-docs/Tech:Translating_Miraheze_extensions-zh-tw.md b/content/tech-docs/Tech:Translating_Miraheze_extensions-zh-tw.md deleted file mode 100644 index 01dcd1744..000000000 --- a/content/tech-docs/Tech:Translating_Miraheze_extensions-zh-tw.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Tech:Translating Miraheze extensions/zh-tw ---- - - -Miraheze develops and maintains a few extensions, for example [CreateWiki](https://meta.miraheze.org/wiki/github:miraheze/CreateWiki) and [ManageWiki](https://meta.miraheze.org/wiki/github:miraheze/ManageWiki). As Miraheze has users with no or limited knowledge of English, internationalization is important for such users. - -現在我們使用 [translatewiki.net](https://meta.miraheze.org/wiki/translatewiki:)來處理 [新增維基](https://meta.miraheze.org/wiki/$cw)和 [維基管理](https://meta.miraheze.org/wiki/$mw)的翻譯。 - -## TranslateWiki process - -* Add strings on en.json. -* Translatewiki.net bot will pull the code when they import the strings, and it will be shown to translators to translate. -* Translators in Translatewiki.net translate the texts. -* Translatewiki.net bot will push the $lang.json when the export bot is run. -* They are then deployed to the Miraheze cluster (the submodule must be updated). - -## Categories - -* [Category:Tech](https://meta.miraheze.org/wiki/Category:Tech) - ----- -**[Go to Source →](https://meta.miraheze.org/wiki/Tech:Translating_Miraheze_extensions/zh-tw)** \ No newline at end of file diff --git a/content/tech-docs/Tech:Wiki_recreations.md b/content/tech-docs/Tech:Wiki_recreations.md deleted file mode 100644 index 0748a296e..000000000 --- a/content/tech-docs/Tech:Wiki_recreations.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: Tech:Wiki recreations ---- - -`{{ {{SRE navigation|noticeboard|header=Wiki recreations following database outage|description=A recent database outage affected many wikis and now bureaucrat action is required to decide what course of action to take. Learn more on Miraheze Meta.|keywords=miraheze recreate wiki}} }}` - -In November and December, 2022, the cloud server hosting a database, db141, went offline due to disk/corruption issues. We have been able to restore almost all wikis affected in the November crash and have recreated all wikis affected by the December crash. We have restored all content on public wikis (beginning with the letter A to O) affected by the December crash. - -See [Tech:SRE noticeboard](https://meta.miraheze.org/wiki/Tech:SRE_noticeboard) for more information. - -## FAQ - -### What happened? - -See [Tech:SRE noticeboard#What happened?](https://meta.miraheze.org/wiki/Tech:SRE_noticeboard#What_happened?) for details. - -### My wiki (created after November 16) has been recreated but I don't see any edits, why? - -All public wikis created after November 16 which were on `db141` and between the letters A to O have had their content restored. If your wiki is in this category and your edits have not been reimported, please [contact us](https://meta.miraheze.org/wiki/Help_center). - -### My wiki still displays a "Wiki temporarily unavailable" screen, why? - -It may be due to one of two reasons: -* **Your wiki was affected by database corruption** - A few wikis (initially 19, now down to 2) were affected by database corruption. If that's the case, [you will find your wiki listed here](https://meta.miraheze.org/wiki/phab:P475) (all 19 of the original wikis affected are listed here). We are working to bring back affected wikis and have brought most wikis back online. -* **This is a bug** - If your wiki is not on the list linked above, it is likely due to a bug as all wikis have been recreated. Please [contact us](https://meta.miraheze.org/wiki/Help_center) if that is the case. - -### I am not bureaucrat on my wiki, why? - -This is likely due to a bug. Please file a request at [Stewards' noticeboard#Administrator/Bureaucrat access](https://meta.miraheze.org/wiki/Stewards'_noticeboard#Administrator/Bureaucrat_access) asking that you be repromoted. At this moment, we are only processing requests from the original wiki requester. - ----- -**[Go to Source →](https://meta.miraheze.org/wiki/Tech:Wiki_recreations)** \ No newline at end of file