Phab-02 was deleted.

@Paladox Phab-02 doesn't have the same puppet class assigned as all the other instances. It is using role::phabricator::labs::diffusion instead of role::phabricator::labs to test potential Diffusion changes that would include hosting a git server on port 22. So, yes, SSH is supposed to be hosted on port 222. Whether it is still topical is another issue.

I can't log into phab-01, -02 nor -04, like I could in T125666, anymore.

Possibly a duplicate of T104910?

@mmodell What was the issue? Where you able to get into phab-02 as well?

We should definitely be telling users if they get unsubscribed to prevent users from silently being left out of updates and conversations.

I think that seems mostly reasonable. At least if a task author suddenly wants to subscribe a user he/she can see that they are already subscribed. I don't think there should be a problem.

I believe @chasemp was going to do something with the code in the change set.

I'm trying to make sense of the Grafana disk space available graphs. I don't know specifically how the root's partition is fluctuating but it would be helpful to have all the other partitions available too. (maybe we could get a Grafana admin to add the * to view all drives)

Over two days I've gotten four email. Two about phab-03 and two about harbormaster1.

I logged into phab-02 yesterday (actually I still am in tmux). /tmp is a 1 MiB partition that was full when I logged in with temp files from a mkinitramfs generation (probably from a kernel upgrade) which I cleared out. Now, /tmp is again full with mkinitramfs files.

In D113#2719, @mmodell wrote:

Ok so, here's the latest version of the text / markup. I think it might be too long winded, should I just leave off the 2nd and 3rd paragraph, and leave it to the wiki page to describe in detail?

Could this possibly use another Phabricator form? (Is there a way to remove the visibility of the form from the global drop down to just be used when specified in the URL?)

This requires an admin that has shell access to Phabricator. Not sure who that is exactly and who is available but the process has been done before (on me as well).

Would it be possible to only replace the base url path (from /r/project to /diffusion) and the project path (project repo to callsign) and keep all other URL paths?
e.g. If want to get to the REL1_25 branch of mediawiki/core with the redirect I would be able to use https://phabricator.wikimedia.org/r/project/mediawiki/core/browse/REL1_25/ and it would be redirected to https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_25/.

@mmodell Thanks for your details (and icons to go with it :)).

@Addshore, You can reopen T104910 if we have people that will triage the bug reports. I'm not as familiar with the OpenStack projects in Labs.

@mmodell This sounds like something probably caused by the Wednesday Phabricator upgrade (T114994).

@demon So instead of it being a "default" policy its a master policy that will override a more relaxed (specific) policy?

I've seen similar behavior in Google Chrome's omnibar (not at all related to this).

You may need to run bin/storage upgrade and the like.

I'm still not sure if we want the security extension on Phab-01 but if a Phabricator admin wants to do it its just:

1. Making sure the security extension is checked out in /srv/phab/libext/security (it should be with a puppet run)
2. Setting security extension to load: sudo bin/config set load-libraries '["/srv/phab/libext/Sprint/src","/srv/phab/libext/security/src"]'
3. And configuring the event listeners: sudo bin/config set events.listeners '["SecurityPolicyEventListener"]'

Ah, ok. (I'm a little bit curious of how the deployments are deployed; are they just pulled via git or something else?)

@mmodell Not at a computer but isn't that just the tracking tag var?

@Paladox Diffusion already mirrors all of the repositories. Are you wanting it to mirror unmerged patches as well?

Well the security extension isn't even present nor configured on Phab-01 (which creates the Herald rules). Known issue.

Some of the work going on with Phacility/Phabricator is to do just the opposite: merge in our custom patches into upstream's code as much as possible. Many projects are trying to move away from custom patches (Chromium Projects and Ubuntu just to name a couple) because they are hard to maintain because they can break with upstream updates. Try Googling "upstream first" for the whole picture.

Prod uses some variables from the private puppet repo for setting passwords and such. But the prod class also sets up mail servers and relays that would be complex to manage in labs.

I believe this feature would be very difficult to implement (given that there isn't even a trace of remote image engine support in Phabricator) with very little gain. It isn't that hard to re-upload or just post a link like Aklapper said.

Its not documented. But its not hard. Essentially its just:

1. Apply role::phabricator::labs and run puppet
2. cd /srv/phab/phabricator and run sudo bin/storage upgrade
3. Rerun puppet

And make sure your proxy points to <hostname>.wmflabs.org.

I don't think this is needed at the moment.

Those two commits ensure the directory is created but doesn't install the security extension for labs. Either security_tag needs to be set in role::phabricator::labs so that this happens or the security extension be removed from [[ https://github.com/wikimedia/operations-puppet/blob/production/manifests/role/phabricator.pp#L203 | libraries ]] so that it isn't referenced in the Phabricator configs.

role::phabricator::main isn't the right Puppet class to use in Labs. I'm pretty sure the error had to do with the site variables. I walked @Luke081515 through the rest of the process on IRC.

Hmm, it works for me on phab-t116442.performance.eqiad.wmflabs. @Luke081515, how did you configure the puppet group on the rcm project?

I believe the VCS user couldn't execute the script that is responsible for checking SSH keys against the Phabricator database which blocked users from authenticating.

Going to leave this for @chasemp. I'm not going to try anything until Gerrit-Migration calls for it.

In T115848#1745182, @Aklapper wrote:

In T115848#1744569, @Negative24 wrote:

I think some documentation should be written on this. I'm afraid code comments aren't commonly read by regular users. :)

@Negative24: Would you fancy editing https://www.mediawiki.org/wiki/Phabricator/Help#Uploading_file_attachments ? :)

I think some documentation should be written on this. I'm afraid code comments aren't commonly read by regular users. :)

Oh I see. When a file is uploaded via drag-and-drop it inherits the policy from the task and the Files policy is set to private because its assumed the file wouldn't need to be accessed by Files but if its just generically uploaded without drag-and-drop it uses the public policy.

@mmodell: Glaisher, Aklapper, and me all saw that unlinked files were private, owner-only protected (could this be a bug?)

@mmodell What does the default view policy on https://phabricator.wikimedia.org/applications/view/PhabricatorFilesApplication/ actually do then?

Could this possibly be a problem with the unfamiliar policy, "Files attached to objects are visible to users who can view those objects?"

1. mediawiki-docker
2. PHP (and Dockerfile)
3. webservice
4. no
5. no
6. no

Not ready for prime time but still interested.

All my scenarios are fixed now. Thank you.

@yuvipanda Exciting! I'll be interested in how this plays out with my mediawiki-docker project.

Should the Wikivoyage tool perhaps be moved to a production or production-like machine to prevent such occurrences? From what I've heard, anything that breaks the actual page of a Wikimedia wiki (not bot/maintenance tasks) should be put on a higher priority machine. (topic for another task; cc me if one is made)

Now, how will we remember to do this in the future?

You can get to your created tasks by going to Maniphest (on the left side bar of the start page) and clicking "Authored" in the left side bar again. The start pages can be customized by changing your Dashboard. See this page for more information.

So using repo names in the URL for Diffusion instead of callsigns?

@Krenair, You know where I could reach them?

@Aklapper, Is there a general IRC project that this could be filed into?
I'm looking for feedback on whether this would be a good idea and at what limit users should be blocked at. I can implement this into my bot, bot24-irc, once consensus is reached.

@Aklapper: No it hasn't. Closing since it probably was just a fluke.

@Dzahn, Isn't this the correct way to merge dups?

@Krenair I always thought that Passphrase would be useful but as it turns out I have never used it. Perhaps its because I don't usually share machines and if I want to share a MW instance I just use the email password function. Passphrase might be useful to Labs machines but other than that I don't know how useful it is.

In T106969#1513691, @yuvipanda wrote:

^ sounds great :) if you are interested in this I can create the project as mediawiki-docker

@yuvipanda Do you have someone specific in mind that can be CCed on this task?