Auto-update Tech namespace pages 2024-09-16 07:11:43.740790

content/tech-docs/Tech:2018_Infrastructure_Assessment.md

@@ -0,0 +1,30 @@
+---
+title: Tech:2018 Infrastructure Assessment
+---
+
+This is a page designed to be a working ground for analysing the infrastructure Miraheze runs as of the 26th of July 2018.
+
+## Current Infrastructure 
+
+| Server | Primary Use | Services | CPU | Disk | Memory | Price (/mo) |
+| --- | --- | --- | --- | --- | --- | --- |
+| [bacula1](https://meta.miraheze.org/wiki/Tech:bacula1) | Backups | bacula, salt-minion | 1x2.40GHz | 500G | 512MB | $12 |
+| [cp2](https://meta.miraheze.org/wiki/Tech:cp2) | Caching | varnish, salt-minion | 1x3.40GHz | 25G | 256MB | $2.67 |
+| [cp4](https://meta.miraheze.org/wiki/Tech:cp4) | Caching | varnish, salt-minion | 1x2.40GHz | 40G | 1GB | $3.50 |
+| [cp5](https://meta.miraheze.org/wiki/Tech:cp5) | Caching | varnish, salt-minion | 1x2.30GHz | 25G | 1GB | $5 |
+| [db4](https://meta.miraheze.org/wiki/Tech:db4) | Database | MariaDB, postgres, salt-minion, bacula-client | 4x3.30GHz | 377G | 16GB | $80 |
+| [misc1](https://meta.miraheze.org/wiki/Tech:misc1) | Miscellaneous | dns, icinga, grafana, irc bots, mail, salt-minion | 1x2.40GHz | 40G | 1GB | $3.15 |
+| [misc2](https://meta.miraheze.org/wiki/Tech:misc2) | Miscellaneous | redis, piwik, salt-minion | 1x2.40GHz | 40G | 1GB | $3.15 |
+| [misc3](https://meta.miraheze.org/wiki/Tech:misc3) | Miscellaneous | parsoid, electron, restbase, salt, salt-minion | 2x2.40GHz | 60G | 2GB | $7 |
+| [misc4](https://meta.miraheze.org/wiki/Tech:misc4) | Miscellaneous | bacula-client, lizardfs-master, phabricator | 2x2.40GHz | 60G | 2GB | $7 |
+| [mw1](https://meta.miraheze.org/wiki/Tech:mw1) | MediaWiki | mediawiki, salt-minion | 4x3.30GHz | 75G | 1GB | $10 |
+| [mw2](https://meta.miraheze.org/wiki/Tech:mw2) | MediaWiki | mediawiki, salt-minion | 4x3.30GHz | 75G | 1GB | $10 |
+| [mw3](https://meta.miraheze.org/wiki/Tech:mw3) | MediaWiki | mediawiki, salt-minion, jobrunner | 4x3.30GHz | 75G | 1GB | $10 |
+| [ns1](https://meta.miraheze.org/wiki/Tech:ns1) | DNS | dns | 1x3.40GHz | 12G | 128MB | $1.13 |
+| [puppet1](https://meta.miraheze.org/wiki/Tech:puppet1) | Puppet | puppet, salt-minion, bacula-client | 2x2.40GHz | 60G | 2GB | $7 |
+| [lizardfs1](https://meta.miraheze.org/wiki/Tech:lizardfs1) | Static | lizardfs, salt-minion, bacula-client | 2x2.30GHz | 150G | 512MB | $4.85 |
+| [lizardfs2](https://meta.miraheze.org/wiki/Tech:lizardfs2) | Static | lizardfs, salt-minion, bacula-client | 2x2.30GHz | 150G | 512MB | $4.85 |
+| [test1](https://meta.miraheze.org/wiki/Tech:test1) | Testing | mediawiki, salt-minion | CPU: 1x2.40GHz | 40G | 1GB | $3.50 |
+
+----
+**Source**: https://meta.miraheze.org/wiki/Tech:2018_Infrastructure_Assessment

content/tech-docs/Tech:Adding_a_new_extension.md

@@ -0,0 +1,30 @@
+---
+title: Tech:Adding a new extension
+---
+
+Any user can create a pull request to install and enable an extension, but it has to be merged by a [sysadmin](https://meta.miraheze.org/wiki/Special:MyLanguage/System_administrators). If you want to add a new extension, request it [here](https://meta.miraheze.org/wiki/Special:MyLanguage/Request_features).
+
+All of this stuff needs to be done before the steps above:
+
+* Open a ticket for a Security Review
+* Wait. We will review the extension following [the MediaWiki extension developers' security checklist](https://meta.miraheze.org/wiki/mw:Security_for_developers), among other things. If we notice a bug or a security vulnerability, we'll try to fix it or wait for the extension developers to fix it.
+* On passing review, the extension needs to be added to the [mediawiki-repos](https://github.com/miraheze/mediawiki-repos) repository on GitHub. There are detailed instructions for how to do this in the README on the repository itself.
+The above steps are for the `mediawiki-repos` repository. The following are for the `mw-config` repository.
+* ManageWikiExtensions.php gets a setting added as well. (Make sure to check if it requires another extension or if it should be restricted)
+* If the extension has database tables, make sure to add them to the ManageWikiExtensions.php config!
+* It is not required, but preferable that you also load it on test151 in order to make sure that everything works as intended
+* Setup any other extension globals here.
+* Then run the following script on mwtask181 and/or test151: `mwdeploy --world --config --l10n --extension-list --servers=all`
+
+It should be noted that it is a good idea to add any configuration variable the extension adds to [ManageWiki](https://meta.miraheze.org/wiki/ManageWiki) to save the effort of doing that at a later date and be user-friendly.
+
+## See also 
+
+* [Updating an extension](https://meta.miraheze.org/wiki/Tech:Updating_an_extension)
+* [Removing an extension](https://meta.miraheze.org/wiki/Tech:Removing_an_extension)
+
+[Category:Guides](https://meta.miraheze.org/wiki/Category:Guides)
+[Category:Technology guidelines and guides](https://meta.miraheze.org/wiki/Category:Technology_guidelines_and_guides)
+
+----
+**Source**: https://meta.miraheze.org/wiki/Tech:Adding_a_new_extension

content/tech-docs/Tech:Appointment_and_revocation_policy.md

@@ -0,0 +1,65 @@
+---
+title: Tech:Appointment and revocation policy
+---
+
+`{{ {{Outdated}} }}`
+
+This policy concerns the procedure for granting shell access. Granting shell access (aka access to a server, or multiple servers) to someone needs to be done with extreme caution. With more people having shell access to (critical) servers, the chances of suffering from human mistakes and compromised shell accounts do increase.
+
+## Appointment 
+
+Once an access request is made, any volunteer should feel free to ask the prospective shell user relevant questions: whether they are about hypothetical situations they may encounter, what tasks they intend to focus on, what the access means for them, etc.
+
+While not necessary, it is encouraged that all SRE take part in the discussion and comment. Once an access request has elapsed an appropriate period of time (a few days to a week), the Engineering Managers will discuss the request together and make a joint decision considering all comments received, relevant experience, and community engagement. Depending on the request, either the Engineering Manager for MediaWiki (sysadmin global group, mw-admin access level) or the Engineering Manager for Infrastructure will close the Phorge task with the decision.
+
+## Re-appointment after inactivity 
+
+See: [Tech:Inactivity policy](https://meta.miraheze.org/wiki/Tech:Inactivity_policy)
+
+## Removal 
+
+In the unfortunate circumstance that a user with access falls under the standards of a system administrator, violates policies deliberately, acts inappropriately, etc. the removal procedure may be initiated. It is to be noted that removal is the last resort, and that before considering removal, attempts to rectify the situation by communicating with the user in question should be made.
+
+If a member of the SRE team believes that one of their colleagues falls under the aforementioned, they may contact their Engineering Manager and explain their situation and their thoughts on the matter. If the Engineering Manager in question declines to act or does not take appropriate measures, the SRE member may [complain to the Board](https://meta.miraheze.org/wiki/:File:Miraheze-Complaints-Procedure.pdf). Board complaints often can be resolved by mediation and informal discussions, so SRE members are encouraged to make use of this procedure if they are dissatisfied with the Engineering Manager's response, if they feel it would be more appropriate to contact the Board in the first place, or if the complaint concerns an Engineering Manager.
+
+The Engineering Manager for the relevant team may propose that a system administrator is removed to the SRE Management Team, either after having received a report from a team member or of their own accord. Both Engineering Managers will weigh the arguments and may consult the whole Site Reliability Engineering team on whether they believe the user in question should be removed.
+
+### For Inactivity 
+
+See: [Tech:Inactivity policy](https://meta.miraheze.org/wiki/Tech:Inactivity_policy)
+
+## Suspension 
+
+In exceptional circumstances, where waiting for the removal process to take place is impractical or not possible, a user may be temporarily suspended and have all their access removed by one of the Engineering Managers. This would be followed by the regular removal procedure, and access would be added back if it is ultimately decided against removal.
+
+In ultimate emergencies, such as compromised accounts, any member with the relevant permissions may temporarily remove another sysadmin from the compromised account in question.
+
+## How to Request Access 
+
+### 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).
+* 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
+   * GitHub Username
+   * Preferred shell username
+   * A freshly generated 4096 bit RSA or ed25519 keypair, protected with a secure password.
+      * Obviously you should only give us the public key, keep the private key private.
+      * This key should not be used for non-Miraheze servers!
+      * If using a FIDO2 key, see [Tech:FIDO2 SSH](https://meta.miraheze.org/wiki/Tech:FIDO2_SSH).
+   * Description of the access you need. If you require sudo rights, please do not forget to include that as well.
+   * The reason you need shell access.
+   * A verification that your Miraheze, GitHub and Phorge accounts are owned by you. This can be accomplished by a) pasting the public key of your keypair on your **Miraheze Meta** user page (or another page in your user namespace) and b) creating a GitHub repository with a file containing the public key (or committing your public key to an already existing repository).
+
+### Expanding Current Access 
+
+If you already have a shell account and want to get extra privileges (or are requesting access to more servers) after this process has been completed, then you need to:
+* Login to [Phorge](https://meta.miraheze.org/wiki/phorge:) and make a new request by using [this form](https://meta.miraheze.org/wiki/phorge:maniphest/task/edit/form/17/), including in the request:
+   * Why you need extra access, and what benefit this would provide to either Miraheze or yourself (regarding productivity);
+   * What access you specifically need (log viewing, service interaction, ability to deploy changes).
+
+[Category:Tech](https://meta.miraheze.org/wiki/Category:Tech)
+
+----
+**Source**: https://meta.miraheze.org/wiki/Tech:Appointment_and_revocation_policy

content/tech-docs/Tech:Bast161.md

@@ -0,0 +1,26 @@
+---
+title: Tech:Bast161
+---
+
+```
+{{ {{Server
+| name = bast161
+| location = FiberState Salt Lake City
+| host = bast161.wikitide.net
+| usage = Bastion
+| status = running
+| memory = 1GB
+| cpu = 1 core
+| ssd = 10GB U.2 NVMe
+| os = Debian 12
+| type = KVM
+| kernel =
+| cloud = cloud16
+| updated = {{REVISIONDAY}} {{REVISIONMONTHNAME}} {{REVISIONYEAR}}
+}} }}
+```
+
+**bast161** is a FiberState server in Salt Lake City, Utah running Debian Bookworm.
+
+----
+**Source**: https://meta.miraheze.org/wiki/Tech:Bast161

content/tech-docs/Tech:Bast181.md

@@ -0,0 +1,26 @@
+---
+title: Tech:Bast181
+---
+
+```
+{{ {{Server
+| name = bast181
+| location = FiberState Salt Lake City
+| host = bast181.wikitide.net
+| usage = Bastion
+| status = running
+| memory = 1GB
+| cpu = 1 core
+| ssd = 10GB U.2 NVMe
+| os = Debian 12
+| type = KVM
+| kernel =
+| cloud = cloud18
+| updated = {{REVISIONDAY}} {{REVISIONMONTHNAME}} {{REVISIONYEAR}}
+}} }}
+```
+
+**bast181** is a FiberState server in Salt Lake City, Utah running Debian Bookworm.
+
+----
+**Source**: https://meta.miraheze.org/wiki/Tech:Bast181

content/tech-docs/Tech:CSP_Policy.md

@@ -0,0 +1,36 @@
+---
+title: Tech:CSP Policy
+---
+
+`{{ {{Tech policy}} }}`
+
+This policy lays out the process by which the [Technology team](https://meta.miraheze.org/wiki/Tech:Volunteers) may approve new additions to the Content Security Policy (CSP). Sites added to the CSP may have content on that domain loaded by all Miraheze wikis. CSP approvals are generally the responsibility of MediaWiki Specialists, as a function of MediaWiki security. Though, any step in the approvals process may be handled by an Infrastructure Specialist.
+
+## Questions 
+
+* Is the site equipped with a privacy policy?
+   * Does the site attempt to comply with the GDPR? Can European Union inhabitants invoke their individual rights?
+   * Does the site provide a list of personal data being collected by using the service?
+   * Is the website owner known to have a bad reputation regarding privacy?
+   * Can wikis use the external service, even if the visitor wants to deny any cookies or other form of tracking?
+   * Will wikis stay usable, even if the visitor blocks the external resource by using an ad blocker?
+   * Is there a Data Protection Officer and/or Privacy Team that can be contacted by Miraheze?
+* Is the site equipped with a security policy?
+   * Does the site clarify their security measures to protect collected user data? Can the site assure measures are being taken to protect code injection into the loaded external resources?
+   * Is the website owner known to have a bad reputation regarding information security?
+   * Is there a Chief Information Security Officer and/or Security Team that can be contacted by Miraheze?
+
+## Principles 
+
+* All above questions must be answered with honesty. Answers must be backed up by references, be it public or private ones. If a question cannot be answered, the answer must be explicitly answered as 'unknown'.
+* The Content Security Policy rule must be scoped to allow minimal content inclusion: only mandatory (sub)domains and resource types (e.g. script-src, img-src, font-src) can be added to the Content Security Policy.
+* The Technology team explores the option of resolving the problem using existing, trustworthy and contracted services, servers and service providers. This could include proxying any resource loading and data transfers through Miraheze servers or by using vetted, contracted service providers. If this is not possible due to workload, financial or technical constraints,
+* The Director of Technology will be consulted for determining consensus. If consensus is reached to allow the external resource, the resource can be added to the Content Security Policy.
+* In the event of an imminent threat to service stability, privacy or security, the Technology team (as the ultimately responsible party) may remove any external resource from the Content Security Policy, without announcement beforehand, and may require a new review before the resource can be readded to the Content Security Policy.
+* This policy applies to all services governed by Miraheze's Privacy Policy. Two resource types are exempted from this policy and can be added by the Technology team: any resource fully controlled by the Technology team (hosted on-premise or outsourced, via contracted vendor) and any resource hosted via a domain name fully owned by Miraheze.
+In the event of a dispute or situation not covered by this policy, the Director of Technology decides.
+
+[Category:Tech policy](https://meta.miraheze.org/wiki/Category:Tech_policy)
+
+----
+**Source**: https://meta.miraheze.org/wiki/Tech:CSP_Policy

content/tech-docs/Tech:Cloud15.md

@@ -0,0 +1,25 @@
+---
+title: Tech:Cloud15
+---
+
+```
+{{ {{Server
+| name = cloud15
+| location = FiberState Salt Lake City
+| host = cloud15.wikitide.net
+| usage = Cloud
+| status = running
+| memory = 256GB
+| cpu = 40 cores @ 3.8 GHz
+| ssd = 4TB NVMe
+| os = Debian 12
+| type = bare metal
+| kernel = 
+| updated = {{REVISIONDAY}} {{REVISIONMONTHNAME}} {{REVISIONYEAR}}
+}} }}
+```
+
+**cloud15** is a FiberState bare metal dedicated server in Salt Lake City, Utah running Debian Bookworm. It is a [virtualization host server](https://meta.miraheze.org/wiki/Tech:Proxmox).
+
+----
+**Source**: https://meta.miraheze.org/wiki/Tech:Cloud15

content/tech-docs/Tech:Cloud16.md

@@ -0,0 +1,25 @@
+---
+title: Tech:Cloud16
+---
+
+```
+{{ {{Server
+| name = cloud16
+| location = FiberState Salt Lake City
+| host = cloud16.wikitide.net
+| usage = Cloud
+| status = running
+| memory = 256GB
+| cpu = 40 cores @ 3.8 GHz
+| ssd = 4TB NVMe
+| os = Debian 12
+| type = bare metal
+| kernel = 
+| updated = {{REVISIONDAY}} {{REVISIONMONTHNAME}} {{REVISIONYEAR}}
+}} }}
+```
+
+**cloud16** is a FiberState bare metal dedicated server in Salt Lake City, Utah running Debian Bookworm. It is a [virtualization host server](https://meta.miraheze.org/wiki/Tech:Proxmox).
+
+----
+**Source**: https://meta.miraheze.org/wiki/Tech:Cloud16