Oh, I think I have a handle on the first issue -- you can ignore my questions about that.

It turned out that the git-user (aka vcs-user) created files as phd:phd

This also reproduced locally for me (OS X Yosemite, openssh-6.7p1), and chmod on the parent directory alone was reliably sufficient to prevent SSH from working. The instructions already suggest a root-owned location, but D15794 notes this requirement explicitly.

I can confirm T9560 locally, at least, so that might be the problem or part of it -- maybe start there? If you can provide details we're happy to fix this properly.

Thanks @epriestley, i will try to investigate further. It seems that i have still something misconfigured. I'll get back as soon as i have to add something useful. :-)

Yes, you should NOT set AuthorizedKeysCommandUser root, this is needlessly dangerous and gives the script substantially more permission than it needs.

I ran into the same issue, it turned out, that the permissions for /phabricator, /libphutil and /phabricator as well as for the preceding parent-directory had to be 755.

I also caught this vaguely related downstream report of markup list styles not rendering properly in mock descriptions:

Your request doesn't describe a problem in using Phabricator. See Contributing Feature Requests and Describing Root Problems. Specifically we don't see "feature doesn't exist" as a root problem. We need to know how you're using Phabricator and what problem you ran into using it. We do this so we can group similar problems together and solve them in a single way, and that may be significantly different than your suggested solution.

Sorry I read it, but I don't understand what is missing

Please see Contributing Feature Requests for what information is required for filing a new feature request.

After we receive a push, try very very very very hard to release the lock if we're the thread holding it, even if we lost the global lock

Any test we execute must be distributed with phabricator/ and run on the first page load after an upgrade. That generally means it needs to be small, very fast, and completely conclusive. Compare to the test for Shellshock here, which runs in a few milliseconds, requires 10 lines of code, and is totally conclusive:

In T10832#171473, @epriestley wrote:

Broadly, I lean toward this policy going forward:

• When we can perform an accurate test for the vulnerability in a reasonable amount of time/effort and tell you that you are definitely vulnerable (as with Shellshock), we will continue to do so with an active setup warning.
• When we can not perform such a test (as here), we will publish guidance and note the issue in the changelog, but will not attempt to guess if the installed version may be vulnerable because this test will frequently be confusing/misleading/wrong.
• We can re-evaluate this after T5055, which may give us a wider range of tools for providing more accurate vulnerability notifications.

Well now I feel silly for not noticing that. I searched for the line number of the error ><

Even if it was just a redirect, that would be great.

We'll fix this eventually, but probably not until the next time we do major work on Phriction (T9379) since the impact is very minor.

Ah, it makes sense. Thanks!

I am seeing the same, and it makes sense, once you know it only contains waypoints that you click.

Thanks! The intended instruction was just "don't specify ssl.key, ssl.cert, etc.". D15787 should fix it.

I don't have to click "Cluster", it's just a subheader. Are you seeing something different?

There is no trickery involved in our repository edit field, it might as well be a datasource field.

FWIW I have updated to Ubuntu 16.04 locally and haven't had any issues with Arcanist.

But for even more elite productivity, all web pages should implement command interpreters so we can have CLIs in our web pages.

This is almost exactly how I use the internets. Did I win at interneting?

I'll fire up a VM this weekend and see if there are any issues.

@epriestley I misstated that. My intention was to say that Ubuntu is a platform which a decent chunk of people use. I definitely don't have data to back that up for Phabricator (And I don't think you guys have telemetry to be able to tell either).

Yeah in those cases, writing your own "Internal Tools Status" application would probably be better.

A few things that might motivate writing an API panel (which pulls from external sources) instead:

(I agree that this is a bad solution for notifying users of downtime/maintenance on the current instance, and that rooster/broadcast is better.)

Maybe T8145 / T5231, but I think the driving use case there was "notify users of Phabricator downtime" specifically. I'm imagining the driving use cases here not affecting all users and not directly impacting Phabricator, just having wide enough impact that there's interest in surfacing them more broadly. e.g., "We're having a production incident affecting video upload, ops is investigating" is important, but not "every Phabricator user must be notified" important.

We also talked about a "Rooster" system as well. Something outside of dashboards that is tied to a time or is user-closable.

Doing a Phriction panel, an iframe panel, or a custom API panel would also be reasonable approaches.

I think we also have a "notify my users about event x or y or downtime" task floating around somewhere else.

Here's an example I could imagine us doing: we have some button on admin.phacility.com that says "Start a deploy". When that's pressed it causes these actions to occur:

My concern is users will install their own dashboards and this doesn't particularly solve anything. I don't know what the core problem is to suggest an alternative solution.

This one seems OKish to me -- I think those use cases are pretty reasonable and root-problem-ish? I'm assuming "waht's currently broken" and "can we do deploys" are information known by some other system or tool.

Please see Contributing Feature Requests

Valid bug reports require steps to reproduce and version information. Please reopen the report once you've filled in this missing information. Thanks!

Thanks!
Yes, we will consider setting up alternate file domain

I think D15784 should fix the issue. It should land in master later today and be available in stable in about 24 hours. Let me know if you're still seeing issues once you update past that.

I think I know what's going on, although I'm unsure why the <2MB files would work, unless you happened to push those to a public ("Visible To: Public (No Login Required)") repository and pushed the large files to a private repository?