nyuuzyou/wikis huggingface dataset:
Microsites

The microsites are static sites hosted on the Ganeti infrastructure. 
== Operation ==
* Puppet: profile::microsites
* Backends: miscweb1002.eqiad.wmnet, miscweb2002.codfw.wmnet (Ganeti).
== Microsites ==
=== Annual Report ===
* URL: https://annual.wikimedia.org and https://15.wikipedia.org
* Maintainer: Communications department (#WMF-Communications)
* Issue tracker: #annual-report
* Source code: https://gerrit.wikimedia.org/g/wikimedia/annualreport (GitHub mirror)
=== Bugzilla Archive ===
* URL: https://static-bugzilla.wikimedia.org
* Maintainer: Dzahn
* Launch task: T85140
* Moved from Ganeti VMs to miscweb on k8s on 2022-01-20 ().
=== Design ===
* URL: https://design.wikimedia.org
* Maintainer: Audiences Design team
* Source code: https://github.com/wikimedia/WikimediaUI-Style-Guide
* Launch task: T185282
=== Research ===
* URL: https://research.wikimedia.org
* Maintainer: Research team
* Issue tracker: #Research-landing-page
* Source code: https://gerrit.wikimedia.org/g/research/landing-page/
* Creation task: T183916, T107389
=== Security ===
* URL: https://security.wikimedia.org
* Maintainer: Security team
* Source code: https://gerrit.wikimedia.org/g/wikimedia/security/landing-page
* Creation task: T257830
=== Transparency Report ===
* URL: https://transparency.wikimedia.org
* Maintainer: Legal department (#WMF-Legal)
* Source code: https://gerrit.wikimedia.org/g/wikimedia/TransparencyReport
* Creation task: phab:T84286
=== Wikidata Query Service (UIs) ===
* URL: https://query.wikidata.org (Query builder: https://query.wikidata.org/querybuilder)
* Maintainer: WMDE
* Source code: https://gerrit.wikimedia.org/g/wikidata/query/gui-deploy + https://gerrit.wikimedia.org/g/wikidata/query-builder/deploy
* Creation task: phab:T266702 phab:T266703
== Other static sites ==
The following static sites are hosted outside the microsites cluster: 
* analytics.wikimedia.org
* developer.wikimedia.org (served statically, but repo requires a build step to deploy)
* doc.wikimedia.org (mainly static but has PHP for Doxygen search)
* integration.wikimedia.org (mainly static, but also has paths that proxy to Zuul and Jenkins).
* performance.wikimedia.org (mainly static, but also has a path that proxies to XHGui).
See :Category:Services for many more partially static subdomains.
== External sites ==
* https://policy.wikimedia.org - Hosted at WordPress VIP (T110203)
* https://wikimediaendowment.org - Hosted at WordPress VIP (T136735)
Category:Services
Mirrors

:See also: Dumps/Mirror status
== mirrors.wikimedia.org ==
The Wikimedia Foundation hosts the following public mirrors via http:
* Debian (Official)
* Ubuntu (Official)
* Tails (Official)
* Debian OpenStack Backports (Unofficial)
This service carries the dual purpose of giving back to the FOSS projects we use and as our own internal mirror.
== Technical Info ==
# Debian
#* Publication Method:
#** DNS A/AAAA Record for ftp.us.debian.org, Debian Code
#** Official US mirror: https://www.debian.org/mirror/sponsors
#* Sync Method: SSH Trigger, syncs are triggered by an SSH forced key command for the mirror user. Debian has StrictHostKeyChecking no set on their side, so changing our SSH host key does not affect Debian's trigger.
# Ubuntu
#* Publication Method:
#** Official US mirror: https://launchpad.net/ubuntu/+mirror/wikimedia-archive
#* Sync Method: Systemd Timer
# Tails
#* Publication Method:
#** DNS A Record for dl.amnesia.boum.org.
#** Mirrorbits redirector
#* Sync Method: Systemd Timer
# Debian OpenStack Backports
#* Publication Method:
#** None, not published officially, but open to the public
#* Sync Method: Systemd Timer
== Implementation Info ==
As of December 2021 they are hosted on mirror1001.wikimedia.org.
The server is located at the Equinix data center in Ashburn, Virginia, United States (eqiad).
The relevant Puppet class is modules/role/manifests/mirrors.pp.
The repo for the puppet code can be git cloned with "git clone https://gerrit.wikimedia.org/r/operations/puppet" from Wikimedia's Gerrit installation.
== Monitoring and debugging ==
There are 2 Icinga checks called "Ubuntu mirror in sync with upstream" and "Debian mirror in sync with upstream" respectively.
If one of these alerts you should check on mirror1001 what happens if you manually run the check commands, 
$ /usr/local/lib/nagios/plugins/check_apt_mirror /srv/mirrors/ubuntu
$ /usr/local/lib/nagios/plugins/check_apt_mirror /srv/mirrors/debian
Also you can run the actual sync command manually but make sure to run it was the user "mirror", so "$ sudo -u mirror ftpsync".
Furthermore, you can check /etc/ftpsync/ftpsync.conf to see which upstream hosts we are rsyncing from and look at /var/log/ftpsync/ to check logfiles for errors.
For Debian you can also see if you are receiving SSH triggers: tail -F /var/log/auth.log | grep forced-command
== Contacting Wikimedia Maintainers ==
The mirror server is maintained by the Wikimedia SRE team. To report issues with mirrors.wikimedia.org, please create a ticket in Wikimedia's Phabricator and tag it with 'SRE'. You can also join the Libera.Chat IRC channels and .
== Contacting Upstream Maintainers ==
# Debian
#* Email: mirrors@debian.org, use this list to ask for changes to DNS records, may take a few days to obtain a reply
#* IRC: irc://irc.oftc.net/debian-mirrors
# Ubuntu
#* Email: mirrors@ubuntu.com
#* IRC: ircs://libera.chat/ubuntu-mirrors
# Tails
#* Email: tails-mirrors@boum.org, use this list to ask for changes to DNS records, may take a few days to obtain a reply
# Debian OpenStack Backports
#* IRC: irc://irc.oftc.net#debian-openstack
Category:Runbooks
Miscweb1002

miscweb1002 is a virtual machine on Ganeti which is hosting several misc. web sites, including:
*https://transparency.wikimedia.org
*https://transparency-archive.wikimedia.org
*https://transparency-private.wikimedia.org
*https://static-bugzilla.wikimedia.org
*https://15.wikipedia.org
*https://annual.wikimedia.org
*https://bienvenida.wikimedia.org
*https://design.wikimedia.org
*https://iegreview.wikimedia.org
*https://scholarships.wikimedia.org
*https://sitemaps.wikimedia.org
*https://wikiworkshop.org
It replaced bromine. Its counterpart in codfw is miscweb2002 which replaced vega.
== See also ==
* miscweb2002
* https://phabricator.wikimedia.org/T281538
Miscweb1003

miscweb1003 is a virtual machine on Ganeti which is hosting several misc. web sites, including:
*https://design.wikimedia.org
*https://iegreview.wikimedia.org
*https://wikiworkshop.org
It replaced miscweb1002. Its counterpart in codfw is miscweb2003 which replaced miscweb2002.
== See also ==
* miscweb2003
Miscweb2002

miscweb1002 is a virtual machine on Ganeti which is hosting several misc. web sites, including:
*https://transparency.wikimedia.org
*https://transparency-archive.wikimedia.org
*https://transparency-private.wikimedia.org
*https://static-bugzilla.wikimedia.org
*https://15.wikipedia.org
*https://annual.wikimedia.org
*https://bienvenida.wikimedia.org
*https://design.wikimedia.org
*https://iegreview.wikimedia.org
*https://scholarships.wikimedia.org
*https://sitemaps.wikimedia.org
*https://wikiworkshop.org
It replaced vega. Its counterpart in eqiad is miscweb1002 which replaced bromine.
== See also ==
* miscweb2002
Miscweb2003

miscweb2003 is a virtual machine on Ganeti which is hosting several misc. web sites, including:
*https://design.wikimedia.org
*https://iegreview.wikimedia.org
*https://wikiworkshop.org
It replaced miscweb2002. Its counterpart in eqiad is miscweb1003 which replaced miscweb1002.
== See also ==
* miscweb1003
Mobile

== This page has been deprecated, please see MobileFrontend ==
If you are looking for the original WAP-based mobile gateway, look here: Mobile.wikipedia.org.
Wikimedia-Mobile is the main gateway for all advanced mobile devices.
== Software ==
The main repository for the application is on GitHub at Wikimedia-Mobile
Please check the README on the above mentioned link to get more information on the application.
=== Libraries Used ===
* Merb Main site web framework
* Sinatra Stats framework
* Nokogiri libxml2 interface
* Curb libCurl interface
== Service Ops ==
If you need help managing the server, go here: MobileServiceOps
== Servers ==
There is only one server currently which handles DB, stats, cache, parsing, and web requests. See Mobile1 for that. 
* Mobile1
** Nginx
** Thin Cluster
** Memcached
** Ruby 1.9.1
To learn more about the roles these different bits and server use see MobileRoles
== Supported Platforms/Languages ==
We are working hard to strike a good balance with natural growth
of the platform and growth of support to new devices and platforms.
If we attempted to support every platform, we would be
distracted from adding new features and scaling the platform in a
natural way. However, if anyone wants to volunteer to work on adding
support for any platform or language, we are more than willing to
help with that.
=== Devices currently supported ===
* Palm Pre
* iPhone
* Kindle 2
* Android (G1)
=== Language Support ===
You can see all of the languages supported at
our Mobile Wikipedia translation project page
== Contact ==
The primary developer is Hampton Catlin, but for any server issues, you may also contact Tomaszf or Brion.
=== Bug Reports ===
Bugs may be reported in our Bugzilla Project
Category:Mobile services
MobileFrontend/Deployment

MobileFrontend rides the regular WMF deployment train. For out-of-band deployments, MobileFrontend has some deployment procedures/considerations beyond the normal WMF deployment procedures. This page serves to document these and is meant to be an addendum to How to deploy code.
== Deployment rubric ==
In general, MobileFrontend rides the regular WMF deployment train. Below is a rubric for making out-of band deployments for bug fixes, etc:
* Deploy ASAP: Patches to fix critical functionality, security issues, or legal issues. Eg mobile edits are not being saved or article content is no longer accessible.
* Deploy in next Lightning Deployment: Patches for semi-critical functionality that is broken but doesn't impede basic usage of critical site components (reading, editing). EG: the watchlist star on an article doesn't accurately indicate if an article is being watched.
* Deploy along with the next regular train: Patches for annoyances (styling not quite right, obscure javascript errors), non-security/legal issues in beta/alpha versions; all other patchsets.
== ResourceLoader ==
There is a bug in resource loader (#37812) that prevents module timestamps from properly updating in certain situations (eg when a resource path gets updated or a resource gets removed and nothing else in the module changes). This can result in outdated JS/CSS getting served. To fix this, first touch one of the resources of the affected module on Fenari:
$ cd /home/wikipedia/common
$ touch php-1.21wmf1/extensions/MobileFrontend/javascripts/modules/mf-search.js
Then, sync the file to the cluster:
$ sync-file php-1.21wmf1/extensions/MobileFrontend/javascripts/modules/mf-search.js 'touch file'
You may need to wait up to 5 minutes for the cached resources to expire.
== Mobile varnish cache ==
If HTML in the mobile version of the site is getting updated during a MobileFrontend deployment, you will likely need to get someone to manually purge the mobile varnish cache. Ping someone in ops (binasher, mutante, and LeslieCarr have typically helped me with this) to perform the flush. Instructions can be found on MobileFrontend#Flushing_the_cache.
== Performance ==
On the WMF cluster, it is vital to maintain a reasonable cache hit ratio of the mobile varnish servers. Mobile varnish stats can be monitored using Ganglia. Keep an eye on this for a while after a deployment.
== Apache logs ==
During and after a deployment, you should keep an eye on the apache logs on Fenari. We have had a number of instances of a deployment resulting in spamming the apache logs with errors and warnings that were not caught until some time after deployment. From fenari:
$ fatalmonitor
Or if you prefer to tail the log apache logs:
$ tail -f /home/wikipedia/logs/syslog/apache.log
You can also view a graph of recent exceptions and fatal errors on the cluster on Grafana.
Category:Mobile services
Category:How-To
MobileRoles

There are several roles needed for a functioning Mobile system.
== Terms ==
* RackApp = The main (currently) Merb Ruby application that makes up "WikimediaMobile"'s core code
* MobileArticle = A custom transformed version of a Wikipedia article in a reusable state
== List of Roles ==
* MobileHTTP = A server ready to handle public-facing mobile requests
* MemcachedServer
* Mysql = A log database server... only used by the LogParse script
== Basic Outline of Request Cycle ==
* An HTTP request comes in to MobileHTTP
* The Proxy Server on port 80 passes the request into the/an RackApp process
** The RackApp checks with MemcacheServer to see if the MobileArticle is cached
** If it is not found, then the RackApp uses libcurl to scrape a copy from #{lang}.wikipedia.org and transforms it with libxml2 into a cachable MobileArticle. This is then stored in the cache.
** The MobileArticle is put in a proper layout by the RackApp and is returned to the user
** The RackApp writes a log entry in JSON format in a file on MobileHTTP
* The Proxy Server sends back the document
== Basic Outline of Log Parsing ==
* A LogParse script is run every 5 minutes
* The script moves the log file to a tmp location (RackApps are still writing to it)
* The script sends a USR1 signal to the RackApp cluster which causes them to write to a new file
* The script parses the JSON-formatted log file and merges the information into a single stat entry
* The stat entry (makes up a row in the db) is written to the Mysql database
* The temporary log file is deleted
MobileServer/ServerSetup

== Server Install ==
* Ubuntu 8.04LTS
* RAID 1
* Wikimedia base system
== Application Install ==
* gcc
=== Ruby Base ===
* root@eiximenis:~# apt-get install ruby irb ruby1.8-dev rubygems
=== Libraries ===
* libsqlite3-dev
* libxslt1-dev
* libcurl3-dev
=== VC ===
* root@eiximenis:~# apt-get install git-core
=== Gems ===
* root@eiximenis:~# gem update
* root@eiximenis:~# gem install thor nokogiri net-ssh RubyInline ruby-json ruby-debug merb haml libxml-ruby curb merb-assets merb-haml merb-more
=== Apache ===
* apache2-mpm-worker
Category:Mobile services
Mobile iPhone

== Support ==
Thanks for your interest in finding out more about the Wikipedia iPhone app.
The current version of the app is very elementary and we are working on improving it.
If you have any feedback or need any help, please send an email
to The Mobile Wikipedia Feedback Team. We'll
get back to you ASAP.
== Development ==
Development is currently done in a mix of Objective-C, Ruby, and HTML5/JS. If you have
experience in any of these, you should be just fine. The application needs a pretty
thorough re-write at this time, more than it needs a new feature. Either going with a more
pure HTML5/JS kind of setup, or doing Objective-C and becoming more of a native application.
You need to get the two repos from here: Wikimedia on Github
Please send any development questions to the Mobile Wikipedia List
or visit us on Libera.chat in .
Category:Mobile services
Mobileapps (service)

Mobile Content Service is slated for service decommissioning in July 2023.
The mobileapps service (a.k.a. "mobile content service") provides a facade through which Wikimedia page content is requested, modified to remove unnecessary bits, and put into a form tailored for use by mobile clients. The underlying content is primarily Parsoid HTML fetched via the REST API, modified, and then stored in RESTBase for retrieval via the /page/summary, /page/mobile-sections and /page/mobile-html and other Page Content Service (PCS) endpoints.
Mobileapps runs on the Kubernetes cluster. Use of content provided by mobileapps was rolled out incrementally to Wikipedia Android app users in early 2016. The service currently provides article content for all users of the Android and iOS apps. It also provides the summary endpoint for Page Previews on web, and the native apps.
== Contact info ==
The mobileapps service is maintained primarily by the Wikimedia Product Infrastructure team, with support from the Platform Engineering Team team. Mentioning mobileapps in IRC on the ops channel should get their attention. If not you can mention individual team members on the #wikimedia-infrastructure IRC channel.
== Consequences of shutdown/failure ==
Page content and page previews on the Android and iOS apps would not be affected, maybe not immediately since this is behind RESTBase but eventually when pages get edited. (There is no fallback in the Android app anymore.)
Same for page previews on web.
== External links == 
* Wikimedia REST API mobile endpoints (link is to enwiki, but the endpoints are the same for all Wikipedias)
* Page Content Service (PCS): summary, mobile-html and related endpoints
* Mobile Content Service (MCS): mobile-sections* endpoints
* RESTBase services for apps
* Refresh RESTBase cache for mobileapps for troubleshooting and fighting vandalism tips
Category:Services
Monitoring/DatasourceError

DatasourceError alerts are generated by Grafana in response to the Grafana alerting engine experiencing some error fetching data to evaluate the alert state.
To see what error is occurring, find the event in the Alerts overview Logstash Dashboard. A description of the alert is provided under the labels.Error field and a link to the alert is provided under the labels.generatorURL field.
These notifications are usually not actionable for alerts recipients, but indicate a period of time where the monitoring engine was unable to determine the state of the service.
If you do not wish to be notified of this gap in monitoring, you can disable this type of notification for your alert(s) like so:
* Navigate to your alert rule configuration page
* Under "3 Alert evaluation behavior" - "Configure no data and error handling" change "Alert state if execution error or timeout" to "OK"
* Click "save" at the top of the page.
== See also ==
* DatasourceError alerts emitted by jinxer are unhelpful
* DatasourceError grafana alerting error message database is locked
Category:Runbooks
Monitoring/EdgeTrafficDrop

EdgeTrafficDrop is a Prometheus Alertmanager alert defined in traffic.yaml on the operations/alerts repo. The alert fires if there is a significant percentage difference in request rate compared to the recent past, and may be indicative of traffic anomalies.
=== Things to do ===
Check the dashboard varnish-caching-last-week-comparison for the affected cluster/site. For example, if the alert says "44% GET drop in text@codfw during the past 30 minutes", you want to select the text cluster and codfw as the site. If the shape of the curve is a clear drop without previous increase as shown in the image Traffic Drop on the right, this could mean that we served less traffic than normal due to either an attack or some anomalies in our infrastructure. If the pattern does not seem to recover on its own, page the Traffic team.
If instead the curve looks like a spike as show in the image Traffic Spike on the right, that is likely due to some anomalous incoming traffic and in general there's not much to worry about.
Regardless of the shape of the curve, you should do the following:
* Look at the load-balancers-lvs dashboard for the given site. If you see clear spikes there, it's probably a DoS attack. See the (D)DoS Playbook.
* Take a look at varnish-aggregate-client-status-codes for the relevant site/cluster to learn more about the type of traffic, in particular whether any specific method/status code stands out.
* Dig into webrequest_sampled_128 on Turnilo for the specific details of the type of requests causing the spike.
* Let #wikimedia-traffic know about your findings.
 
Category:Runbooks
Category:SRE Traffic
Monitoring/Latency

Icinga has alerts for increased latency at the Mediawiki appserver level.
In June 2021 we had a case where several appservers entered a weird state that caused latency alerts. The solution was to restart PHP on the affected appservers. The following Prometheus query was used to find the appservers that were in the weird state: 
(phpfpm_statustext_processes{cluster="appserver",state="idle"}) < 10
Then a 
sudo restart-php7.2-fpm
This reoccurred 3 times in 2 days, we ended up restarting all appservers. Phabricator task: https://phabricator.wikimedia.org/T285634
Monitoring/Long running screens

An Icinga check for "long running screen or tmux" processes was added in T165348.
reasoning was: "We should flag/alert long-running screen sessions, these are usually a sign of work which was forgotten or should rather be puppetised or launched by cron"
There are different options to solve an alert like this. Either determine it has been indeed been forgotten work and can be closed or that this is a kind of host where
long running screens are expected and the host should be white-listed to exclude it from the monitoring check.
The user name and PID running the process in question is part of the script output. So if that matches their IRC nick they should already get highlighted.
What you can do:
* if a WARNING: Ignore, unless it is your own process- warnings are there so the owner has a window to realize about it and close it 
if already a CRITICAL:
* ping the user and ask them if they still need the screen/tmux and ask them to close it or to ack it on icinga (Notice: There would be very few reasons to just ack it- so a good reason has to be given (e.g. ongoing outage). Prefer the permanent whitelist below.
or 
* go to the host in question yourself and check what is in the screen
** trick to get into the screen of another user: sudo -s; su $username; script /dev/null ; screen -x (why? )
** if things look inactive / forgotten.. close the screen, otherwise go back to asking the user
or
* mark the host in question as excluded from this monitoring because long-running screens are expected
** make a puppet change and set "monitor_screens: false" in Hiera for a role or host
Category:Monitoring
Category:Runbooks
Monitoring/Memory

=== Memory correctable errors -EDAC- ===
There seem to be a few different "classes" or "states" of EDAC errors:
# high count of CEs and recent kernel messages
# low count of CEs and no recent kernel messages
For class #1 The course of action is to file tasks to service owners to diagnose memory 
For class #2 reset edac counters to probe for re-occurrences i.e. 
sudo rmmod sb_edac edac_core ; sudo modprobe sb_edac edac_core
This post was taken from a comment on T183177
Category:Monitoring
Category:Runbooks