Bug #9492
closed
Cannot reload remote haproxy via ACME package
Added by Florian Apolloner about 5 years ago.
Updated almost 5 years ago.
Affected Architecture:
All
Description
The acme instance cannot restart a remote haproxy service. I looked at the code and found this snippet: https://github.com/pfsense/FreeBSD-ports/blob/8f6f7405a4dbca174e31d3a4101b5b250fe4400a/security/pfSense-pkg-acme/files/usr/local/pkg/acme/acme.inc#L101-L104
In a debug shell I executed (to test):
require_once("xmlrpc_client.inc");
$extras = array();
$execstr = <<<EOD
require_once('service-utils.inc');
service_control_restart("haproxy", $extras);
EOD;
echo $execstr;
exec
which resulted in
require_once('service-utils.inc');
service_control_restart("haproxy", Array);
So it seems to me the interpolation of $extras is wrong. The master firewall says " Exception calling XMLRPC method exec_php # String could not be parsed as XML @ 2019-04-29 10:05:31 " in the error log and the remote firewall says: "PHP Parse error: syntax error, unexpected ')', expecting '(' in /usr/local/www/xmlrpc.php(140) : eval()'d code on line 2" -- which is in line with "Array)" being invalid.
Files
If I replace:
$extras = array();
with
$extras = var_export(array(), true);
it seems to work.
- Status changed from New to Feedback
- Assignee set to Jim Pingle
- % Done changed from 0 to 100
Jim Pingle wrote:
Fixed in ACME pkg v0.5.6
I just tried this and it still throws an error, to the best of my understanding the var_export has to occur before interpolating extras in the string. So something like:
extras_stringified = var_export($extras, true);
$execstr = <<<EOD
require_once('service-utils.inc');
service_control_restart("{$servicename}", $extras_stringified);
EOD;
- Status changed from Feedback to Assigned
Yeah, you're right. I didn't have a setup to test that handy, but it would have to come earlier. I'll come up with a better fix soon.
Would this affect more than just haproxy? This fits a failure to restart the webui on a remote system that occurred for me recently and couldn't nail down a cause for - mainly because I didn't notice it until I suddenly had an expired certificate until I restarted it manually, and the logs were already rotated out of existence for that period.
I does not affect the webgui because it uses another xmlrpc call. It affects every normal service though. I could also imagine if you restart two services (haproxy followed by the webgui), because it might abort after the first. Anyways, your certs should probably get added to monitoring ;)
OK, thanks, I was highly optimistic about having found a probable cause for a minute there, but I guess I get to go back to debugging and testing.
Yes, we'll remember to monitor the backup server now! Still need to find the root cause though, I don't want to have to make a point of SSHing in every 60 days. :)
- Status changed from Assigned to Feedback
Give 0.5.7 a try when it shows up shortly. It should work.
I just installed, 0.5.7 but it still throws an error (Interestingly only on the firewall running ACME). Can I get more information about this? (See attached file).
There is no error in that output related to the service restart. The error at the top is from config sync, which isn't related to the service reload command. For help tracking down that issue, post on the forum.
Can you tell if haproxy restarted on the secondary or not?
I still don't have a good setup handy to test this particular scenario out.
Hi Jim. Yes Haproxy did restart. While I agree that the sync error should be from something else it still seems to be an acme problem because it only happens when ACME gets a new cert. And it also didn't throw such an error on 0.5.5
I pushed another change just now that might help. Not sure it will, but it's worth a try.
- Status changed from Feedback to Resolved
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 