save IP/LB/FW configuration from loxilb UI so
when loxilb restart or bpfire reboot, the configuration
can be restored.
Signed-off-by: Vincent Li <vincent.mc.li@gmail.com>
add dummy ip 192.0.2.1 in virutal_ipaddress from (TEST-NET-1)
according to https://www.rfc-editor.org/rfc/rfc5737#section-3
for keepalived HA state tracking, the Master will always
have the dummy ip assigned to green0.
add refresh button for HA state refresh
Signed-off-by: Vincent Li <vincent.mc.li@gmail.com>
in HA scenario, the shared/floating VIP
is not configured on the red0 interface
when setup LoxiLB lb from the UI in standby
BPFire, some VIPs are missing since these
VIPs are only configured in the active BPFire.
get VIPs from /var/ipfire/loxilb/ipconfigfile
Signed-off-by: Vincent Li <vincent.mc.li@gmail.com>
when run loxicmd save -a -c /var/ipfire/loxilb/
ipconfig directory will be created, which conflicts
with loxilb UI that also save virtual ip to
/var/ipfire/loxilb/ipconfig, so rename ipconfig to
ipconfigfile.
Signed-off-by: Vincent Li <vincent.mc.li@gmail.com>
remove @nosaved from /var/ipfire/loxilb/settings
as it could interfere with running state of
loxilb
Signed-off-by: Vincent Li <vincent.mc.li@gmail.com>
remove @nosaved item from form submission
before writehash to each setting file because
it could interfere with each other.
for example, when change keepalived configuration
for green or red interface from the UI,
without removing @nosaved which has 'ENABLE_HA'
before writehash, 'ENABLE_HA=off' would be saved
in '/var/ipfire/keepalived/settings', this would
trigger the UI to show keepalived being "STOPPED"
or it could actually stopoped keepalived.
Signed-off-by: Vincent Li <vincent.mc.li@gmail.com>
In BPFire HA deployment, a floating/shared router IP
is required for backend/endpoint server. by default
BPFire uses the primary IP on green0 when running
setup script. Now the floating/shared router IP can
be added to green0 interface as secondary IP through
loxilb UI, keepalived UI can configure the secondary
IP as virtual ipaddress, when HA failover happens,
keepalived will move the virtual ipaddress to new active
BPFire.
Signed-off-by: Vincent Li <vincent.mc.li@gmail.com>
BPFire red0 does not support multicast, need to
have unicast peer configured, then the virtual
ipaddress can be added to red0 interface.
the UI requires /var/ipfire/keepalived/runsettings
/var/ipfire/keepalived/settings to be created, so
add them lfs/configroot
Signed-off-by: Vincent Li <vincent.mc.li@gmail.com>
since we added loxilb ip management to add ip on
red0 interface, we can select the virtual ip from
red0 interface.
Signed-off-by: Vincent Li <vincent.mc.li@gmail.com>
learned from ChatGPT to print dynamic options.
add semi column ';' right after heredoc like:
print <<END;
...
...
END
following result in error
print <<END
...
...
END; #<<<< ERROR
following is correct
print <<END
...
...
END
;
so better use the first format
Signed-off-by: Vincent Li <vincent.mc.li@gmail.com>
run command below when update language menu
perl -e "require '/var/ipfire/lang.pl'; &Lang::BuildCacheLang"
Signed-off-by: Vincent Li <vincent.mc.li@gmail.com>
write to /var/ipfire/ddos/settings file before
enable ddos to allow /etc/rc.d/init.d/ddos script
start up ddos according to the setting from
/var/ipfire/ddos/settings
Signed-off-by: Vincent Li <vincent.mc.li@gmail.com>
This is necessary since we now have a much shorter lifetime for the host
certificate. However, it is complicated to do this is which is why we
are copying the previous certificate and generate a new CSR. This is
then signed.
A caveat of this patch is that we do not rollover the key.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The function did not evaluate the return code which is why it used a
hack to figure out if some output is an error or not.
This is being fixed in this commit and the entire output is being
returned if the return code is non-zero.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- This v3 version has split the logging choice for drop hostile to separate the logging of
incoming drop hostile and outgoing drop hostile.
- The bug originator had no port forwards so all hostile would be dropped normally anyway.
However the logs were being swamped by the logging of drop hostile making analysis
difficult. So incoming drop hostile was desired to not be logged. However logging of
outgoing drop hostile was desired to identify if clients on the internal lan were
infected with malware trying to reach home.
- Added option with drop hostile section to decide if the dropped traffic should be
logged or not.
Fixes: bug12981
Tested-by: Adolf Belka <adolf.belka@ipfire.org
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Bernhard Bitsch <bbitsch@ipfire.org>
Tested-by: Bernhard Bitsch <bbitsch@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
