This page was probably better. https://redmine.lighttpd.net/projects/1/wiki/docs_configuration#Troubleshooting

I'm still curious is this is a lighttp configuration issue. Ran across this comment from their documentation for example:

This didn't change the output. However, you can see I posted another solution.

Sorry, I missed the thread on this.

Okay, I think I'm into something. I logged the requests to see the differences between the one with curl command line that works, and the one from arcanist that fials.

Corrected the ip in the logs

Closing for now, feel free to follow up with steps we can follow to observe this locally. I have no idea how you're install got into this state.

Basically, if you want to see this implemented, please describe an attack scenario you're concerned about in detail.

Yes, I wasn't aware that enable_post_data_reading existed when I wrote this.

This is technically easy for us to implement, I'd just like a real security justification for it. From the first link, the justification seems to be:

See https://github.com/tinfoil/devise-two-factor/issues/30 and https://github.com/mdp/rotp/issues/44 for some discussion about this issue (also discussed a bit on oss-security mailing list as http://www.openwall.com/lists/oss-security/2015/06/20/4).

I suspect that your computer is possessed.

Yes, I got that output:

Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 11.22.33.44...
* Connected to my.phabserver.com (11.22.33.44) port 8080 (#0)
> POST /api/conduit.ping HTTP/1.1
> Host: my.phabserver.com:8080
> User-Agent: curl/7.50.1
> Accept: */*
> Content-Length: 35
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 35 out of 35 bytes
< HTTP/1.1 200 OK
< X-Powered-By: PHP/5.6.25
< Set-Cookie: phsid=A%2Fx3d7s2ghnuyafelgkpilokjdmu3lw2rxvnkwcpcm; expires=Thu, 26-Aug-2021 04:37:41 GMT; Max-Age=157680000; path=/; domain=my.phabserver.com; httponly
< X-Frame-Options: Deny
< Content-Type: application/json
< Cache-Control: no-store
< Expires: Sat, 01 Jan 2000 00:00:00 GMT
< X-Content-Type-Options: nosniff
< Content-Length: 61
< Date: Sat, 27 Aug 2016 04:37:41 GMT
< Server: lighttpd/1.4.41
< 
* Connection #0 to host my.phabserver.com left intact
{"result":"someserver","error_code":null,"error_info":null}

An even simpler script below, works now on my Fedora 24 server. Just make sure for your distribution, that the correct database (mysql/mariadb/etc.) service is edited, as well as the rest of the info.

no, HTTPSFuture also knows http; My dev instance is http://127.0.0.1:8080/api/, and it works fine.

I don't have https enabled on my phabricator instance. Could it be related to my problem?

for domain:

domain
string(15) "my.phabserver.com"

So far I have made the computer draw some circles:

The theme today is "Ancient Technology", so PHP fits right in!

Do you have any other repositories to try this on? Smaller ones, or some public repo from BitBucket?

This has happened about 2 months ago, so a lot of the damage has already happened. We had a listing somewhere about what to do, but I can't find it now, so I'll re-write it here for posterity:

This can cause a storm of commit mail when upgrading. If there are old tags which weren't imported at the time, when Phabricator is upgraded to a version containing D16129 it can fire off thousands of commit emails, flooding inboxes and making some folks grumpy at their Phabricator administrators.

Can you var_dump($core_future) at https://secure.phabricator.com/diffusion/PHU/browse/master/src/conduit/ConduitClient.php;5fd1af8b4f2b9631e2ceb06bd88d21f2416123c2$146 and $domain at https://secure.phabricator.com/diffusion/PHU/browse/master/src/future/http/HTTPSFuture.php;5fd1af8b4f2b9631e2ceb06bd88d21f2416123c2$175 ?

No, it's a DNS name from https://freedns.afraid.org/

This would be awesome.

do you happen to be using a dns name that you populated using your /etc/hosts file?

Thanks @chad, but it seems not good enough.

I still got the 404 error even with php 5.6. Here's my php -v output:

PHP 5.6.25 (cli) (built: Aug 26 2016 20:28:05) 
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies

I even removed php7 from my machine.
I got exactly the same error as before...

We don't expect to officially look into supporting PHP7 until 7.1. We've gotten a number of random issues from it we hope to be resolved in that release.

This is my php -v output... Does it have to do with the fact that I run PHP 7? But even so, like you said, it worked on secure.

PHP 7.0.10 (cli) (built: Aug 21 2016 07:35:18) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies

It's on arch linux, fully updated from today. My server is arch linux too, but I installed PHP 5.6 on it.

I'm pretty stumped here; Server seems OK, and client seems OK. Maybe test a completely different computer?

Maybe run php -v from command line, what system is this? But then again it works to secure...

I tried a couple of things, it seems it fails when trying to ping the server. This line $conduit->callMethodSynchronous('conduit.ping', array()); will throw the error, even though it clearly worked with curl.

Thanks!

I'll retarget this to add a setup warning about micro instances, this isn't the first time they've done surprising things (T2727, T8204, T8210).

I did, and it certainly seems to match up. I'm surprised it's so dramatic. I guess since it was working fine before, the sensible thing is probably to just wait for the credits to recover and go back to things on the t2 micro.

If you fiddle with the dropdown in the upper right you should be able to get historic data and maybe see if the graph went not-so-good around then. Doesn't seem implausible.

My graph certainly seems to imply that this is the issue.

Okay, so var_dump($uri) shows me that:
string(32) "http://my.phabserver.com:8080/api/"

If the task is frequently referenced, you can give it a Phurl and use ((super_cool_task)), as in ((php7)) and ((httpoxy)).

I tried the address http://my.phabricator.com:8080/api/conduit.connect and it returned me a json that look like this:
{"result":null,"error_code":"ERR-INVALID-USER","error_info":"The username you are attempting to authenticate with is not valid."}

I'd start maybe here:

Here's the actual credit graph in the AWS web console, under the Monitoring tab (lower right):

I don't think, with my current configuration, the port 80 is not accessible (limitation from my ISP), so I highly doubt I went through the wrong port.

One thing we could possibly do is try to hit the AWS meta-service during startup:

It's supposed to work; Does that 404 page looks like it's coming from the wrong port?

It's hard to say because workloads differ, but I'd steer away from the CPU credited "burstable" t2.* instances based on generally negative experiences with micros in the past.

Yes, arc install-certificate https://secure.phabricator.com/api/ is working. Does it has to do with my custom port 8080 or it should be supported?

No. No proxy and no vpn.

Does it work when you try to arc install-certificate https://secure.phabricator.com/api/ ?

Do you have any kind of proxy/vpn configured?

Hm, that's interesting. I know basically nothing about AWS, but I'll try adjusting phd.taskmasters, and if that doesn't work, I'll try using a bigger instance. Is the next size up sufficient, in your experience?

In AWS, my understanding is that micro instances have CPU credits and their CPU is stopped or heavily throttled if you exceed the credit hours. Has the instance exhausted its CPU credits? I think there's a graph on the console, maybe in the "CloudWatch" tab or something like that? I don't actually have any micro instances up right now to check.

It shows this:

HTTP/1.1 200 OK
X-Powered-By: PHP/5.6.25
Set-Cookie: phsid=A%2F72hqw6cmi3przavtmn3rayh57g5yo5utgibbrwza; expires=Wed, 25-Aug-2021 22:37:37 GMT; Max-Age=157680000; path=/; domain=my.phabricator.com; httponly
X-Frame-Options: Deny
Content-Type: application/json
Cache-Control: no-store
Expires: Sat, 01 Jan 2000 00:00:00 GMT
X-Content-Type-Options: nosniff
Content-Length: 61
Date: Fri, 26 Aug 2016 22:37:37 GMT
Server: lighttpd/1.4.41

Not really up on lighttpd, but this line looks like it should be ==, not =~ ?

(Is your server an underclocked Raspberry Pi emulated on an Amiga?)

EC2 t2.micro

How about from the terminal? curl -i http://my.phabricator.com:8080/api/conduit.ping ?

Yes, from my browser it shows {"result":"someservername","error_code":null,"error_info":null} when I typed http://my.phabricator.com:8080/api/conduit.ping.

(Is your server an underclocked Raspberry Pi emulated on an Amiga?)

/api/conduit.ping here returns a json; Does it work for your install from the browser?

Not that was printed to the console.

That looks pretty normal to me.

Here's my output for arc install-certificate --trace:

 ARGV  '/home/master/build/arcanist/bin/../scripts/arcanist.php' 'install-certificate' '--trace'
 LOAD  Loaded "phutil" from "/home/master/build/libphutil/src".
 LOAD  Loaded "arcanist" from "/home/master/build/arcanist/src".
Config: Did not find user configuration at "/home/master/.arcrc".
Config: Did not find system configuration at "/etc/arcconfig".
Working Copy: Reading .arcconfig from "/home/master/prog/myproject/.arcconfig".
Working Copy: Path "/home/master/prog/myproject" is part of `git` working copy "/home/master/prog/myproject".
Working Copy: Project root is at "/home/master/prog/myproject".
Config: Did not find local configuration at "/home/master/prog/myproject/.git/arc/config".
 CONNECT  Connecting to "http://my.phabricator.com:8080/api/"...
>>> [0] <conduit> conduit.ping() <bytes = 39>
>>> [1] <http> http://my.phabricator.com:8080/api/conduit.ping
<<< [1] <http> 71,707 us
<<< [0] <conduit> 72,471 us
Usage Exception: Failed to connect to server (http://my.phabricator.com:8080/api/): [HTTP/404] Not Found
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
  <title>404 - Not Found</title>
 </head>
 <body>
  <h1>404 - Not Found</h1>
 </body>
</html>

P2005. This was all written to stderr, not stdout. I let it run for a little while and then interrupted.

Yeah sorry a " " snuck in there while I was copy/pasting it.

@jonah214 I vote for see stuff that goes by. You can use the paste application https://secure.phabricator.com/paste/ so it's easier for us to look at.

>>> [536] <exec> $ hg log --template='{node}' --rev ''\''caac1231de800ccaa18c96
98ae72f6cb7dfca637'\'''

I don't know a lot about hg internals, but 1,000 branches and 10,000 commits doesn't sound like too much to process.