Haproxy reload op pfSense/FreeBSD

[Dennis]

Hoi,

Ik gebruik een pfSense router als proxy-toegang tot mijn website(s). In pfSense heb ik haproxy geconfigureerd als front-end-proxy. Dit werkt prima.

Omdat ik mijn site heb afgeschermd via https en client certificaten doet haproxy een check op de crl (certificate revocation list). Helaas heeft pfSense geen goede functionaliteit ingebouwd om de crl periodiek te updaten, vanaf bijvoorbeeld een url. Om die reden heb ik zelf een scriptje gebouwd die de crl download en vervolgens haproxy restart. Dit script draait elk uur met een cronjob.

Welnu, op zich werkt dit allemaal prima, maar ik gebruik een reload commando. Helaas is een gevolg hiervan dat de oude instance van haproxy blijft draaien en er een nieuwe bij komt. Na zo'n twee dagen is dan de cpu op en moet ik inloggen en een killall doen om het te fixen.

Op internet heb ik een mooie oplossing gevonden die de pid uit een file haalt en deze gebruikt voor een graceful reload (met -p). Zie hier: https://github.com/Mirantis/openstack-lbaas/issues/3. Probleem is denk ik dat dit prima werkt onder Linux, maar niet onder BSD (en dus pfSense).

Heeft iemand een oplossing om mijn probleem op te lossen, zodat ik geen tientallen instances meer krijg van haproxy? Ik hoop dat ik mijn probleem duidelijk uitgelegd heb. Dank alvast.

[Hero of Time]

Waarom haal je elk uur de CRL binnen? Wat is je bedoeling ermee? Je hebt alleen wat aan de CRL als je zelf naar een HTTPS enabled site gaat, niet als je die zelf draait.

[CyBeR]

Hero of Time schreef op dinsdag 20 februari 2018 @ 20:37:
Waarom haal je elk uur de CRL binnen? Wat is je bedoeling ermee? Je hebt alleen wat aan de CRL als je zelf naar een HTTPS enabled site gaat, niet als je die zelf draait.

Client certs kunnen ook in een CRL staan. Dus dan heb je er wel wat aan.

---

De reden dat je oude HAProxy processen hebt draaien is ws omdat er nog verbindingen open staan. Die worden dan afgehandeld en pas als ze allemaal weg zijn gaat 't oude proces weg. Dus, verbind af en toe opnieuw.

[Hero of Time]

CyBeR schreef op dinsdag 20 februari 2018 @ 20:39:
[...]

Client certs kunnen ook in een CRL staan. Dus dan heb je er wel wat aan.

Client certs zijn een vorm van authenticatie en vang je dus af in je applicatie, niet je proxy. Ze komen namelijk vaker van een PKI omgeving dan een volwaardige CA.

[CyBeR]

Dat is zeker niet per definitie zo.

[osmosis]

Laat je script eens zien?

Nu is het wat natte vinger werk om te raden wat er mis kan zijn

[Dennis]

Dank alvast voor jullie hulp. Dit is het script:

code:

# Update haproxy CRL file and reload haproxy config
/usr/local/bin/curl http://crl.vanleuverden.nl/crl/VanLeuverden+Users+CA+G4 > /var/etc/haproxy/clientcrl_owncloud-frontend-https.pem && /usr/local/bin/curl http://crl.vanleuverden.nl/crl/VanLeuverden+Root+CA+G4 >> /var/etc/haproxy/clientcrl_owncloud-frontend-https.pem
/usr/local/sbin/haproxy -f /var/etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D

Wat je ziet bij ps-aux:

code:

www  65113  0.0  0.7   48228 27088  -  Ss   Fri16       4:26.06 /usr/local/sbin/haproxy -f /var/etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D
www  65330  0.0  0.6   48228 26232  -  Ss   Sun20       1:52.59 /usr/local/sbin/haproxy -f /var/etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D
www  68383  0.0  0.6   48228 26232  -  Ss   Mon20       0:53.63 /usr/local/sbin/haproxy -f /var/etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D
www  68755  0.0  0.6   48228 26252  -  Ss   Sun06       2:30.74 /usr/local/sbin/haproxy -f /var/etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D
www  69982  0.0  0.6   48228 26264  -  Ss   Sat00       4:01.77 /usr/local/sbin/haproxy -f /var/etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D
www  74008  0.0  0.6   48228 26720  -  Ss   Wed08       7:41.65 /usr/local/sbin/haproxy -f /var/etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D
www  75602  0.0  0.7   48228 27160  -  Ss   Thu10       6:09.51 /usr/local/sbin/haproxy -f /var/etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D
www  75838  0.0  0.6   48228 26620  -  Ss   Thu14       5:54.93 /usr/local/sbin/haproxy -f /var/etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D
www  76836  0.0  0.6   48228 26300  -  Ss   Sat06       3:41.53 /usr/local/sbin/haproxy -f /var/etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D

(en nog veel meer)

Mijn PKI infrastructuur draai ik trouwens zelf, zoals je misschien al ziet . Mijn CA genereert elke X periode een CRL die ik vervolgens download in pfSense.

[CyBeR]

Je mist de optie -sf:

-sf <pid>* : send the "finish" signal (SIGUSR1) to older processes after boot
completion to ask them to finish what they are doing and to leave. <pid>
is a list of pids to signal (one per argument). The list ends on any
option starting with a "-". It is not a problem if the list of pids is
empty, so that it can be built on the fly based on the result of a command
like "pidof" or "pgrep".

[Dennis]

Yes thanks @CyBeR, maar denk dat ik het niet duidelijk heb uitgelegd (vind ik zelf na teruglezen ).

Het gaat erom dat $(cat /var/run/haproxy.pid) niet werkt in BSD. Ik krijg

Illegal variable name.

Dus de vraag is nu hoe ik die PID uit de file in het commando plak .

[CyBeR]

Oh, hah. Dat was idd niet duidelijk. Of zulke dingen als $(foo) werken ligt aan de shell waarin het uitgevoerd wordt. Je moet wellicht backticks (``) gebruiken in de jouwe.

[Dennis]

Aha, dat was de truc. Zo zie je maar hoeveel ik weet van unix . Ik doe mijn best, maar dit wist ik niet. Anyway, met backticks lijkt het commando te werken, heb ff een paar restarts gedaan en zie nog maar één haproxy in de process list.