Phabricator is an open-source software development platform. In Wikimedia, Phabricator is used for project management, software bug reporting and feature requests, and in the future also for code review in an integrated fashion. See mw:Phabricator for more details on end user usage.
The Phabricator install relies on db1072 (m3 eqiad master). Other DB hosts (backup slaves) are db1117 (eqiad), db2042 (codfw) and db2078 (codfw). Databases access is routed through dbproxy1003, a.k.a. m3-master.
A disaster recovery plan for phabricator.wikimedia.org is being drafted at Phabricator/Disaster_Recovery.
- 1 Operations Projects Workflows
- 2 Administrative Commands
- 3 Network Architecture
- 4 References
- 5 External links
Operations Projects Workflows
The operations specific projects on Phabricator include:
|Operations||General Operations Team Project|
|Labs||Labs Team Project|
|DC-Ops||Datacenter Team Project|
|hardware requests||Server Allocation Requests|
|procurement||Vendor & Procurement Tasks. Direct ordering of SSL certificates.|
|Ops Access Requests||Access requests to any Operations systems|
|ops-codfw||Onsite queue for codfw|
|ops-eqdfw||Onsite queue for eqdfw|
|ops-eqiad||Onsite queue for eqiad|
|ops-eqord||Onsite queue for eqord|
|ops-esams||Onsite queue for esams|
|ops-ulsfo||Onsite queue for ulsfo|
|DBA||Database administration requests|
|Operations Software Development||Software development projects|
Hardware Request Stage
- User requests hardware via Operations_requests#Hardware_Requests
- Rob reviews the hardware-requests project for all tasks that are assigned to him, or unassigned.
- Tasks assigned to others are not reviewed as often, as they are awaiting input from the assignee. If they are left neglected by the assignee long term, they will likely be rejected, or have the hardware-requests project removed from the task.
- If the system specification meets an on-site spare, system allocation may proceed.
- This allocation step is typically processed by Rob and approved by Mark. (It involves a general overview of the roadmap and system procurement planning.)
- If the system specifications require an order of hardware, the following occurs:
- A RT procurement queue ticket is created for each set of vendor quotes.
- Example: A caching system at this time could be Dell or HP, we create two RT tickets. One for each vendor to provide quotes for the system specification in question.
- Quotes are generated and reviewed by Rob, Mark, and the requestors for the hardware.
- Quotes are approved for purchase by Mark/Damon/Lila (escalation dependent on overall cost) and are typically placed by Rob (for US ordering) or Mark (for EU ordering).
- The hardware-requests task will have the system details noted (hostname/asset tag) and the task will be linked to the system setup task.
- These are kept separate for easy future search history on hardware allocations; thus its nice to leave a task with the hardware-request in said project.
Hardware/Server Setup / Deployment Stage Workflow
- A new phabricator task is created in the operations project.
- This task is the primary tracking task for the setup and deployment of the server.
- Task should include the following (base template):
- System Deployment Steps:
 - mgmt dns entries created/updated (both asset tag & hostname) [link sub-task for on-site work here, sub-task should include the ops-datacenter project]  - system bios and mgmt setup and tested [link sub-task for on-site work here, sub-task should include the ops-datacenter project]  - network switch setup (port description & vlan) [link sub-task for network configuration here, sub-task should include the network project]  - production dns entries created/updated (just hostname, no asset tag entry) [link sub-task for on-site work here, sub-task should include the ops-datacenter project]  - install-server module updated (dhcp and netboot/partitioning) [done via this task when on-site subtasks complete]  - install OS (note jessie or trusty) [done via this task when network sub-task(s) complete]  - service implementation [done via this task post puppet acceptance]
- The main task is basically for all the software setup, and the sub-tasks are for the specific on-site or networking tasks.
- Many times, the network task isn't created, as the person doing the software work can also do the network configuration.
Misc. Production Virtual Machine Requests Workflow
- User requests hardware via Operations_requests#Virtual_Machine_Requests_.28Production.29
- Alex reviews the vm-requests project for all tasks that are assigned to him, or unassigned.
- Tasks assigned to others are not reviewed as often, as they are awaiting input from the assignee. If they are left neglected by the assignee long term, they will likely be rejected, or have the vm-requests project removed from the task.
- If the system specifications meet all requirements for approval/allocation of a production virtual machine, Alex will process and grant the request.
- All Phabricator documentation refers to scripts in the phabricator bin directory. On our setup, that is:
Remove a repo
First you need the repo's callsign. This is an all-uppercase identifier with 'r' prefixed that is used in urls and such in Phabricator for the repo. For example, Puppet's is OPUP. First SSH to phab1001N. Then:
cd /srv/phab/phabricator sudo ./bin/remove destroy rFOO
Remove a file
First you need the file's ID prefixed with 'F'. First SSH to phab1001N. Then:
cd /srv/phab/phabricator sudo ./bin/remove destroy Fxxxxxxxx
Removing Two Factor Authentication
- Please note that removal of 2FA is a serious request, and all too easily socially engineered. All requests of this nature should be treated with the same degree of security and confirmation as ssh key changes. The user guidelines require one month between the paste of the user committed identity hash on the wiki user page and the reset request.
- When copying the text phrase from a Phabricator Paste, make sure to use
View Raw Fileand save the file, to avoid issues with line breaks via copy&paste. Afterwards, run
cat file | sha512sum.
- Once confirmed, the actual command is quite simple, run on the phabricator host:
sudo /srv/phab/phabricator/bin/auth strip --all-types --user <username>
- You will be prompted with a yes or no to remove the multi-authentication types on the user.
Revoking a Conduit token
Users can do this themselves with the big red "Terminate Tokens" button in Settings > Conduit API Tokens. If it needs to be forced for some reason, you can do it in the DB:
ssh db1043 sudo mysql --skip-ssl phabricator_conduit update conduit_token set expires=unix_timestamp()-60 where token='...';
Rebuild phabricator search index
Warning: This takes a really long time, probably more than 8 hours. Service will be online during the reindex, however, search quality will be degraded.
ssh phab1001 sudo /srv/phab/phabricator/bin/search init sudo /srv/phab/phabricator/bin/search index --all --force --background
Phabricator is currently hosted on phab1001.eqiad.wmnet / phab2001.codfw.wmnet.
The full path of traffic from the public internet through to the database is as follows:
cache_text esams -> cache_text codfw -> cache_text eqiad -> phab1001 -> dbproxy1003 -> db1043
- The Operations specific Phabricator projects were discussed in T119944 in early 2016.