Auto-update Tech namespace pages 2024-09-16 08:56:37.023784

content/tech-docs/Tech:Deleting_and_moving_batches_of_pages_on_a_wiki.md

@@ -7,9 +7,9 @@ title: Tech:Deleting and moving batches of pages on a wiki
 To delete or move large batches of pages on a wiki, execute the following commands for the `deleteBatch.php` and `moveBatch.php` [MediaWiki](https://meta.miraheze.org/wiki/MediaWiki) maintenance scripts in the following sequence:
 
 * Login to `mwtask181` (active maintenance server).
-* Upload a text file, named as *subdomain.txt*, ideally, to your shell folder, which contains the list of pages for deletion or moving (include the namespace, where applicable!), replacing the *italicized* portions as applicable.
-* Run `sudo -u www-data php /srv/mediawiki/w/maintenance/deleteBatch.php --wiki=wikidbname -u "Miraheze maintenance script" -r "[[phab:T###|Requested]]" /home/yourshellusername/wikisubdomain.txt`, replacing the ***bolded and italicized*** portions as applicable. **Note:***`deleteBatch.php`* is interchangeable with *`moveBatch.php`* as applicable.
-* sudo `sudo -u www-data php /srv/mediawiki/w/maintenance/deleteBatch.php --wiki=wikidbname -u "Miraheze maintenance script" -r "[[phab:T###|Requested]]" /home/yourshellusername/wikisubdomain.txt`, replacing the ***bolded italicized*** portions as applicable. **Note:***`deleteBatch.php`* is interchangeable with *`moveBatch.php`* as applicable.
+* Upload a text file, named as *subdomain.txt* , ideally, to your shell folder, which contains the list of pages for deletion or moving (include the namespace, where applicable!), replacing the *italicized*  portions as applicable.
+* Run `sudo -u www-data php /srv/mediawiki/w/maintenance/deleteBatch.php --wiki=wikidbname -u "Miraheze maintenance script" -r "[[phab:T###|Requested]]" /home/yourshellusername/wikisubdomain.txt`, replacing the ***bolded and italicized***  portions as applicable. **Note:***`deleteBatch.php`*  is interchangeable with *`moveBatch.php`*  as applicable.
+* sudo `sudo -u www-data php /srv/mediawiki/w/maintenance/deleteBatch.php --wiki=wikidbname -u "Miraheze maintenance script" -r "[[phab:T###|Requested]]" /home/yourshellusername/wikisubdomain.txt`, replacing the ***bolded italicized***  portions as applicable. **Note:***`deleteBatch.php`*  is interchangeable with *`moveBatch.php`*  as applicable.
 * Logout (if you are done with your business on `mwtask181`).
 
 [Category:Technology guidelines and guides](https://meta.miraheze.org/wiki/Category:Technology_guidelines_and_guides)

content/tech-docs/Tech:Icinga-MediaWiki_Monitoring.md

@@ -6,63 +6,63 @@ This page is used to provide monitoring guidance for MediaWiki-related services
 
 ## JobChron Service 
 
-* *Why does this check exist? What does it monitor?***This check monitors whether the JobChron service is up and running.**
-* *Is an alert a bad thing?***Yes, JobChron should always be running on the redis servers.**
-* *If its warning/critical, how do we fix it?***It may be possible to resolve by either manually starting the JobChron service (`sudo service jobchron start`), or restarting it (`sudo service jobchron restart`). You can also try and see why it failed to start by viewing the service status (`sudo service jobchron status`). If you don't have access to the relevant server(s), a task on Phorge should be filed and those with access should be alerted to be able to assist.**
+* *Why does this check exist? What does it monitor?* **This check monitors whether the JobChron service is up and running.**
+* *Is an alert a bad thing?* **Yes, JobChron should always be running on the redis servers.**
+* *If its warning/critical, how do we fix it?* **It may be possible to resolve by either manually starting the JobChron service (`sudo service jobchron start`), or restarting it (`sudo service jobchron restart`). You can also try and see why it failed to start by viewing the service status (`sudo service jobchron status`). If you don't have access to the relevant server(s), a task on Phorge should be filed and those with access should be alerted to be able to assist.**
 
 ## Redis Service 
 
-* *Why does this check exist? What does it monitor?***This check simply monitors whether the Redis service is up and running.**
-* *Is an alert a bad thing?***Yes, Redis should always be running.**
-* *If it's warning/critical, how do we fix it?***A task on Phorge should be filed immediately and everyone (including Infrastructure) should be pinged to investigate why it is down and resolve.**
+* *Why does this check exist? What does it monitor?* **This check simply monitors whether the Redis service is up and running.**
+* *Is an alert a bad thing?* **Yes, Redis should always be running.**
+* *If it's warning/critical, how do we fix it?* **A task on Phorge should be filed immediately and everyone (including Infrastructure) should be pinged to investigate why it is down and resolve.**
 
 ## PHP-FPM 
 
-* *Why does this check exist? What does it monitor?***This check monitors whether PHP-FPM processes are up and running.**
-* *Is an alert a bad thing?***Yes, PHP-FPM should always be running.**
-* *If it's warning/critical, how do we fix it?***It may be possible to resolve by either manually starting the php-fpm service (`sudo service php-fpm start`), or restarting it (`sudo service php-fpm restart`). You can also try and see why it failed to start, by viewing the service status (`sudo service php-fpm status`). If you are unable to resolve the issue, then a Phorge task, triaged as "Unbreak Now" should be filed, and the relevant technical team members alerted to assist. If this alert is given, chances are users may receive errors on their end with PHP-FPM down. If that's the case, an incident report should also be filed for the issue.**
+* *Why does this check exist? What does it monitor?* **This check monitors whether PHP-FPM processes are up and running.**
+* *Is an alert a bad thing?* **Yes, PHP-FPM should always be running.**
+* *If it's warning/critical, how do we fix it?* **It may be possible to resolve by either manually starting the php-fpm service (`sudo service php-fpm start`), or restarting it (`sudo service php-fpm restart`). You can also try and see why it failed to start, by viewing the service status (`sudo service php-fpm status`). If you are unable to resolve the issue, then a Phorge task, triaged as "Unbreak Now" should be filed, and the relevant technical team members alerted to assist. If this alert is given, chances are users may receive errors on their end with PHP-FPM down. If that's the case, an incident report should also be filed for the issue.**
 
 ## Memcached 
 
-* *Why does this check exist? What does it monitor?***This check simply monitors whether the memcached service is up and running.**
-* *Is an alert a bad thing?***Yes, memcached should always be running.**
-* *If it's warning/critical, how do we fix it?***A Phorge task should be created, triaged as "Unbreak Now" until the issue is resolved. While in theory the MediaWiki Team manages, since only Reception123 has access, Infrastructure should also be alerted to be able to assist.**
+* *Why does this check exist? What does it monitor?* **This check simply monitors whether the memcached service is up and running.**
+* *Is an alert a bad thing?* **Yes, memcached should always be running.**
+* *If it's warning/critical, how do we fix it?* **A Phorge task should be created, triaged as "Unbreak Now" until the issue is resolved. While in theory the MediaWiki Team manages, since only Reception123 has access, Infrastructure should also be alerted to be able to assist.**
 
 ## Nutcracker 
 
-* *Why does this check exist? What does it monitor?***This check monitors whether the nutcracker service is running.**
-* *Is an alert a bad thing?***Yes, nutcracker should always be running.**
-* *If it's warning/critical, how do we fix it?***It may be possible to resolve by either manually starting the nutcracker service (`sudo service nutcracker start`), or restarting it (`sudo service nutcracker restart`). You can also try to see why it failed to start, by viewing the service status (`sudo service nutcracker status`). If you are unable to immediately resolve this, a Phorge task should be created, triaged as "Unbreak Now" until the issue is resolved.**
+* *Why does this check exist? What does it monitor?* **This check monitors whether the nutcracker service is running.**
+* *Is an alert a bad thing?* **Yes, nutcracker should always be running.**
+* *If it's warning/critical, how do we fix it?* **It may be possible to resolve by either manually starting the nutcracker service (`sudo service nutcracker start`), or restarting it (`sudo service nutcracker restart`). You can also try to see why it failed to start, by viewing the service status (`sudo service nutcracker status`). If you are unable to immediately resolve this, a Phorge task should be created, triaged as "Unbreak Now" until the issue is resolved.**
 
 ## JobRunner Service 
 
-* *Why does this check exist? What does it monitor?***This check monitors whether the jobrunner process is running correctly.**
-* *Is an alert a bad thing?***Yes, unless done intentionally by a member of SRE, jobrunner should be running on all designated servers at all times.**
-* *If it's warning/critical, how do we fix it?***If the jobrunner is not running on a server, it can be restarted by doing `sudo service jobrunner restart`. If there is an error when restarting, that must be investigated. You can try to see what error occured using `sudo service jobrunner status`.**
+* *Why does this check exist? What does it monitor?* **This check monitors whether the jobrunner process is running correctly.**
+* *Is an alert a bad thing?* **Yes, unless done intentionally by a member of SRE, jobrunner should be running on all designated servers at all times.**
+* *If it's warning/critical, how do we fix it?* **If the jobrunner is not running on a server, it can be restarted by doing `sudo service jobrunner restart`. If there is an error when restarting, that must be investigated. You can try to see what error occured using `sudo service jobrunner status`.**
 
 ## MediaWiki Rendering 
 
-* *Why does this check exist? What does it monitor?***This check monitors whether MediaWiki is accessible.**
-* *Is an alert a bad thing?***Yes, it means MediaWiki may be down, and users may be receiving errors on their end.**
-* *If it's warning/critical, how do we fix it?***If the issue persists and users are reporting errors such as 502 or 503, then a Phorge task should be created, triaged as "Unbreak Now" until the issue is resolved for users. To attempt to resolve it, restarting PHP-FPM (`sudo service php8.2-fpm restart`) could help under some circumstances. If you have root access, you could also try restarting the relevant server(s). If that still doesn't work, try looking at logs, to determine the cause of the outage. Chances are it will resolve itself after some time if you're unable to. If the outage was user-facing, an incident report should also be filed for it.**
+* *Why does this check exist? What does it monitor?* **This check monitors whether MediaWiki is accessible.**
+* *Is an alert a bad thing?* **Yes, it means MediaWiki may be down, and users may be receiving errors on their end.**
+* *If it's warning/critical, how do we fix it?* **If the issue persists and users are reporting errors such as 502 or 503, then a Phorge task should be created, triaged as "Unbreak Now" until the issue is resolved for users. To attempt to resolve it, restarting PHP-FPM (`sudo service php8.2-fpm restart`) could help under some circumstances. If you have root access, you could also try restarting the relevant server(s). If that still doesn't work, try looking at logs, to determine the cause of the outage. Chances are it will resolve itself after some time if you're unable to. If the outage was user-facing, an incident report should also be filed for it.**
 
 ## WikiTideRenewSSL 
 
-* *Why does this check exist? What does it monitor?***This check monitors whether the SSL renewal services is up and running.**
-* *Is an alert a bad thing?***Yes, this must be investigated.**
-* *If it's warning/critical, how do we fix it?***If the service is down it should be restarted. If it cannot be restarted/is not functional, that should be further investigated.**
+* *Why does this check exist? What does it monitor?* **This check monitors whether the SSL renewal services is up and running.**
+* *Is an alert a bad thing?* **Yes, this must be investigated.**
+* *If it's warning/critical, how do we fix it?* **If the service is down it should be restarted. If it cannot be restarted/is not functional, that should be further investigated.**
 
 ## SSL Validity Checks 
 
-* *Why does this check exist? What does it monitor?***This check monitors whether SSL certificates are set to expire in the next 15 days.**
-* *Is an alert a bad thing?***Usually no, WikiTideSSLBot will renew non-wildcard certs. If it is CRITICAL, however, there might be a problem with the bot, so that needs reporting.**
-* *If it's warning/critical, how do we fix it?***If it is critical (and non-wildcard) the reason for why the bot is not auto-generating should be investigated. If it cannot be figured out in time, the certs should be [manually renewed](/tech-docs/techssl_certificates). For wildcards certs, they need to be renewed manually in any case once there is a warning.**
+* *Why does this check exist? What does it monitor?* **This check monitors whether SSL certificates are set to expire in the next 15 days.**
+* *Is an alert a bad thing?* **Usually no, WikiTideSSLBot will renew non-wildcard certs. If it is CRITICAL, however, there might be a problem with the bot, so that needs reporting.**
+* *If it's warning/critical, how do we fix it?* **If it is critical (and non-wildcard) the reason for why the bot is not auto-generating should be investigated. If it cannot be figured out in time, the certs should be [manually renewed](/tech-docs/techssl_certificates). For wildcards certs, they need to be renewed manually in any case once there is a warning.**
 
 ## Reverse DNS Checks 
 
-* *Why does this check exist? What does it monitor?***This check performs a reverse DNS lookup to determine domains that have been pointed to us are still pointing to us**
-* *Is an alert a bad thing?***Yes, if not just a temporary issue that resolves itself, it is a problem.**
-* *If it's warning/critical, how do we fix it?***The person who requested the custom domain (or other wiki bureaucrats) should be notified and asked to point their domains to us again. If there is no response and/or they fail to do so in a reasonable time (not less than a week) the custom domain and SSL certificate should be removed until the issue is resolved.**
+* *Why does this check exist? What does it monitor?* **This check performs a reverse DNS lookup to determine domains that have been pointed to us are still pointing to us**
+* *Is an alert a bad thing?* **Yes, if not just a temporary issue that resolves itself, it is a problem.**
+* *If it's warning/critical, how do we fix it?* **The person who requested the custom domain (or other wiki bureaucrats) should be notified and asked to point their domains to us again. If there is no response and/or they fail to do so in a reasonable time (not less than a week) the custom domain and SSL certificate should be removed until the issue is resolved.**
 
 [Category:Technology guidelines and guides](https://meta.miraheze.org/wiki/Category:Technology_guidelines_and_guides)
 

content/tech-docs/Tech:MariaDB.md

@@ -33,7 +33,7 @@ An alternative (might be faster in some situations):
 ```
 (the directory at the destination **must** be created before, please specify the correct date as well)
 
-At the destination, the backup must be *prepared*, since the data is not consistent yet. You can do this using mariabackup:
+At the destination, the backup must be *prepared* , since the data is not consistent yet. You can do this using mariabackup:
 ```
 [again, raise the soft open files limit] ulimit -Sn 1000000
 mariabackup --prepare --open-files-limit=900000 --target-dir=/home/dbcopy/backup-db12-10january2020 --use-memory=2G

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

@@ -23,7 +23,7 @@ In case of any doubts regarding a command or configuration change, mw-admins sho
 * Always run them as www-data (prefix command with `sudo -u www-data`).
 * Always `!log` maintenance script runs in #miraheze-tech-ops (unless you were running puppet or were using sql.php, and did **not** execute any queries that changed the database (e.g. SELECT/DESCRIBE queries)
    * You can optionally use the [mwscript](https://meta.miraheze.org/wiki/Tech:MediaWiki_appserver#mwscript) wrapper to automatically log these.
-* If you need to run a script on all wikis, use the *foreachwikiindblist* wrapper:
+* If you need to run a script on all wikis, use the *foreachwikiindblist*  wrapper:
 * `sudo -u www-data /usr/local/bin/foreachwikiindblist /srv/mediawiki/cache/databases.json /srv/mediawiki/<version>/maintenance/yourscript.php --put-your-parameters --here`
 * update.php is evil. If you need to run it while you're not doing a MediaWiki upgrade, then something is really wrong.
    * maintenance/update.php just automatically creates all required database tables on the wiki(s) it is run on. SQL files should be added to the CreateWiki config setting so that tables are automatically added to all new wikis. See [Tech:Adding a new extension](/tech-docs/techadding_a_new_extension) for enabling extensions or adding tables to existing wikis.

content/tech-docs/Tech:Projects-en.md

@@ -15,7 +15,7 @@ A proposal template is available [here](https://meta.miraheze.org/wiki//Template
 Anyone may:
 * Propose a new project (see [here](https://meta.miraheze.org/wiki//Template)).
 * Comment on a proposal (use the talk page of the relevant proposal).
-* Work on a proposal (see [Contributing](https://meta.miraheze.org/wiki/Contributing) and *starting points* in a proposal for guidance).
+* Work on a proposal (see [Contributing](https://meta.miraheze.org/wiki/Contributing) and *starting points*  in a proposal for guidance).
 
 ## Current proposals 
 

content/tech-docs/Tech:Projects-es.md

@@ -15,7 +15,7 @@ Una plantilla de propuesta está disponible [aquí](https://meta.miraheze.org/wi
 Cualquiera puede:
 * Proponer un nuevo proyecto (véase [aquí](https://meta.miraheze.org/wiki//Template)).
 * Comentar en una propuesta (usa la página de discusión de la propuesat relevante).
-* Trabajar en una propuesta (véase [Contribuir](https://meta.miraheze.org/wiki/Special:MyLanguage/Contributing) y *puntos de partida* en una propuesta para guiarse).
+* Trabajar en una propuesta (véase [Contribuir](https://meta.miraheze.org/wiki/Special:MyLanguage/Contributing) y *puntos de partida*  en una propuesta para guiarse).
 
 ## Propuestas actuales 
 

content/tech-docs/Tech:Projects-tr.md

@@ -14,7 +14,7 @@ Teklif şablonu [burada](https://meta.miraheze.org/wiki//Template) ve bir alt sa
 Herkes şunları yapabilir:
 * Yeni bir proje önerebilir ([buraya](https://meta.miraheze.org/wiki//Template) bakın).
 * Bir teklif hakkında yorum yapın (ilgili teklifin tartışma sayfasını kullanın).
-* Bir teklif üzerinde çalışın (rehberlik için bir teklifteki [Katkıda Bulunma](https://meta.miraheze.org/wiki/Contributing) ve *başlangıç noktalarına* bakabilirsiniz).
+* Bir teklif üzerinde çalışın (rehberlik için bir teklifteki [Katkıda Bulunma](https://meta.miraheze.org/wiki/Contributing) ve *başlangıç noktalarına*  bakabilirsiniz).
 
 ## Current proposals