I spent 3 seconds on this and couldn't immediately identify the root cause.

This looks like an error in custom third-party code you've written (CommandTestEngine), not the upstream.

Oh, this isn't really the same as T4788. I don't think this, specifically, is a use case we're likely to address. Consider using projects (or subprojects, after T3670) to organize larger groups of tasks.

See T3963 for templating. You could also put the whole template in a code block or literal block so that people could just copy it directly.

Why is this important or useful?

We have a similar use case as Wikimedia's. We want the security team to CC people on tasks in Space:Security so that the CC'd people have viewing, editing, and commenting permissions, but don't have access to anything else in Space:Security. Is that possible?

Thanks!

Is there a stack trace for that error in your error log (often /var/log/apache2/error.log or similar)?

I'm not sure how you got into this state, since the relevant patch is reporting as "Applied":

I've moved the blog and stopped traffic to the old secure host. I'll decommission both hosts in a few days if nothing crops up.

See Phacility Cluster Network and Phacility Cluster Devices.

Oh, actually, our setup isn't quite like yours. There's one notification LB which sends traffic to one box. Instances just have nlb.phacility.com configured. So no web-tier proxying.

Yeah, this is what we do in the Phacility cluster. We have every instance sharing one notification server with software instancing right now and the box is <1% utilized.

Actually, I think you are correct.

Yes, but are you sure you need it? What are you seeing which indicates a notification server scaling issue?

Would this task be available for paid prioritization?

Document everything.

See T8227.

Perfect, thanks!

Do you have a stack trace in the Apache/nginx error.log (/var/log/apache2/error.log or /var/log/nginx/error.log or something similar, often, depending on configuration)?

Authorize trusted external keys.

Do users manually update the JIRA fields, or does something synchronize them?

To reproduce:

Get phabot running again.

• I (probably?) corrected the HTTPS issue by splitting the certificate and certificate chain files.
• I allowed the host to serve blog.phacility.com, javelinjs.com, and phabricator.org.
• Javelin and org are working fine so I updated DNS. I'll decommission the existing .org host.
• blog has some HTTP vs HTTPS stuff that I think I'm going to clean up in Phame itself.

(But it's also expected that when you "y" through the giant red ASCII art skull prompt, you're accepting consequences like this.)

This still sounds like a potential issue, I just wanted to make sure the messaging around it isn't unclear.

See also T7767.

Did you get this warning when you ran bin/remove destroy?

I think that should fix it, thanks for the report.

Thanks for the report!

When you say "need of a restarting", what do you mean, specifically?

Yeah I have a hacky workaround that I can do in nginx, but it feels like it would be nicer to just allow /status/ to ignore the host header altogether.

Or maybe even in Apache/nginx.

I worked around this in our SiteConfig subclass. You could conceivably also do it in preamble.php.

I'm actually facing a similar issue at the moment... what are the "reasonable workarounds"?

Redesign-specific.

Actually, looking at https://sslcheck.globalsign.com/en_GB/sslcheck?host=secure.phabricator.com#52.8.228.58-srv-reg provides some better insight: