OPNsense Forum

Archive => 19.1 Legacy Series => Topic started by: Taomyn on March 01, 2019, 08:20:11 am

Title: Upgrade to 19.1.2 HAProxy broken until forced config save
Post by: Taomyn on March 01, 2019, 08:20:11 am
Had a fairly smooth upgrade to 19.1.2 (LibreSSL) last night except for one thing - HAProxy would not start. Not much was showing in its log to say why so I tried a "test syntax", was ok, then an apply. After that the service would start.


I can't seem to find anything specific to the service start (maybe someone can suggest where to look), but in the system.log file the following was logged 3 times during the upgrade:



Code: [Select]
Feb 28 22:02:15 bart root: /usr/local/etc/rc.d/haproxy: WARNING: failed precmd routine for haproxy

I haven't tried rebooting the firewall since I got HAProxy working again, but will try that tonight when I am home.
Title: Re: Upgrade to 19.1.2 HAProxy broken until forced config save
Post by: no_Legend on March 02, 2019, 10:06:31 am
Meet the same problem.
But at my setup the haproxy is not starting anymore
Also the Trick with the apply Trick isn‘t working at my firewall.
A reboot is also not working for me.

Log isn’t showing anything which is responsible for that crash

Any suggestions from the developers?
Title: Re: Upgrade to 19.1.2 HAProxy broken until forced config save
Post by: Taomyn on March 02, 2019, 11:16:46 am
I just rebooted my firewall and it did the same, and shows an error on the console like before attached below.


The log just shows:



Mar 2 10:57:01   root: /usr/local/etc/rc.d/haproxy: WARNING: failed precmd routine for haproxy


In trying to find the cause a few minutes later the service seemed to eventually start up and is running again.
Title: Re: Upgrade to 19.1.2 HAProxy broken until forced config save
Post by: franco on March 05, 2019, 07:32:28 pm
Prodded maintainer again, it's better to push this to GitHub or or gets lost beween Twitter and forums... :/
Title: Re: Upgrade to 19.1.2 HAProxy broken until forced config save
Post by: fraenki on March 06, 2019, 10:26:01 am
I just rebooted my firewall and it did the same, and shows an error on the console like before attached below.
The log just shows:

Thanks for the screenshot. HAProxy complains that the hostname, which it is configured to bind to, does not resolve ("invalid address"). This would be expected, if either the internet connection is unavailable or DNS not working.

What type of internet connection are you using? Does OPNsense connect you with the internet or is there another router in your network?


Regards
- Frank
Title: Re: Upgrade to 19.1.2 HAProxy broken until forced config save
Post by: fraenki on March 06, 2019, 11:41:36 am
HAProxy complains that the hostname, which it is configured to bind to, does not resolve ("invalid address"). This would be expected, if either the internet connection is unavailable or DNS not working.

Just to add a different point of view:
It's usually not a good idea to bind services to addresses that are not *always* available. For example public addresses like myhost.example.com. This may not work in certain situations or break unexpectedly, because it depends on many (more or less) unrelated services like DNS, PPPoE, etc.

A better approach would be to bind the service to an *internal* address, that is configured on the firewall (like an IP alias or CARP address), i.e. 192.168.0.1. This would ensure that the service is always able to startup. But, of course, you would need to add a NAT rule (port forward) to make this service reachable from the internet.


Regards
- Frank
Title: Re: Upgrade to 19.1.2 HAProxy broken until forced config save
Post by: Taomyn on March 06, 2019, 03:07:01 pm

What type of internet connection are you using? Does OPNsense connect you with the internet or is there another router in your network?


Regards
- Frank


I have a PPPoE connection to my ISP that is managed by OPNsense.


Nothing has changed other than upgrading from 19.1.1 to 19.1.2 i.e. it was all working fine before.
Title: Re: Upgrade to 19.1.2 HAProxy broken until forced config save
Post by: fraenki on March 06, 2019, 03:17:19 pm
I have a PPPoE connection to my ISP that is managed by OPNsense.

Nothing has changed other than upgrading from 19.1.1 to 19.1.2 i.e. it was all working fine before.

Unfortunately there's nothing I could do about it. HAProxy clearly states what the problem is: "invalid address".
So for some reason this address is not available when HAProxy tries to start.

It could be that PPPoE takes too long to connect, or DNS is not yet available, etc. I don't know. Best advice I could give is to not depend on such things and use an internal address instead.

I do understand that this is probably not the answer you were expecting, because you stated that "it broke after the upgrade"...  8) However, as stated earlier, when using public addresses you add many dependencies to this service and thus it may break rather unexpectedly.


Regards
- Frank
Title: Re: Upgrade to 19.1.2 HAProxy broken until forced config save
Post by: Taomyn on March 06, 2019, 04:34:26 pm
Ok, so considering I simply followed the directions setting up HAProxy back in OPSense v16, how should it be set up so as to avoid this going forward? I can't even find where the name is being referenced to change any way.
Title: Re: Upgrade to 19.1.2 HAProxy broken until forced config save
Post by: fraenki on March 17, 2019, 11:40:40 pm
I can't even find where the name is being referenced to change any way.

Search in all HAProxy "Virtual Services" and check the "Listen Addresses" option. The name should be referenced there.


Regards
- Frank
Title: Re: Upgrade to 19.1.2 HAProxy broken until forced config save
Post by: Taomyn on March 19, 2019, 07:48:06 am

Search in all HAProxy "Virtual Services" and check the "Listen Addresses" option. The name should be referenced there.


Regards
- Frank


Thank-you - I've found it, changed the two "Public Server" entries to use 127.0.0.1 (was surprised there is no "localhost" alias), each with a new port, and then created two new NAT rules to forward to those.


Strangely one of my sites, a webmail service, appears to be actually working better this way - no idea why it would make a difference but nice nevertheless.