This enables Pakfire to return a Status-Summary for the Current Core-Update-Level, time since last updates, the availability of a core-/packet-update and if a reboot is required to complete an update. This can be used by monitoring agents (e.g. zabbix_agentd) to monitor the update status of the IPFire device.
Signed-off-by: Alexander Koch <ipfire@starkstromkonsument.de>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Force the initscript to remove the PID file when calling "stop" section.
If suricata crashes during startup, the PID file still remains and the service
cannot be started anymore until the file has been deleted.
Now when calling "stop" or "restart" the PID file will be deleted and the service
can be used again.
Fixes#12067.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
The script usualy will be executed by cron which will start it with
root permissions, so the downloaded tarball is owned by this user.
This has to be changed to the user which runs the WUI (nobody:nobody) to
allow, changing the ruleset to an other one and to display the ruleset area.
Fixes#12066
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
The script now will use the previously introduced seperate firewall chains called
IPS_INPUT, IPS_FORWARD and IPS_OUTPUT.
The commit also creates an AND connection between the choosen network zones in the UI and
the final firwall rules.
Fixes#12062.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
Create and use seperate iptables chain called IPS_INPUT, IPS_FORWARD and IPS_OUTPUT
to be more flexible which kind of traffic should be passed to suricata.
Reference #12062
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
This is a regression from disabling charon.install_routes.
VPNs are routing fine as long as traffic is passing through
the firewall. Traps are not propertly used as long as these
routes are not present and therefore we won't trigger any
tunnels when traffic originates from the firewall.
Fixes: #12045
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This causes some i2c drivers to load and tons of error messages
being created in syslog. So we skip searching for any sensors
that do not exist.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Set permissions for /var/lib/tor and /var/ipfire/tor to
tor:tor, regardless whether Tor user has been created before
or not.
This ensures Tor starts properly on existing systems after
reinstallation of the add-on. Thanks to Michael for the hint.
Further, a comment for new Tor user in /etc/passwd has been added.
Fixes#11779.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
If Tor is operating in relay mode, it has to open a lot of outgoing
TCP connections. These should be separated from any other outgoing
connections, as allowing _all_ outgoing traffic will be unwanted and
risky in most cases.
Thereof, Tor will be running as a dedicated user (see second patch),
allowing usage of user-based IPtables rulesets.
Partially fixes#11779.
Singed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This allows more-fine granular firewall rules (see first patch for
further information). Further, it prevents other services running as
"nobody" (Apache, ...) from reading Tor relay keys.
Fixes#11779.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
For details see:
http://www.squid-cache.org/Versions/v4/changesets/
The 'configure'-option "--disable-ipv6" was removed, it is no longer necessary.
See:
https://lists.ipfire.org/pipermail/development/2016-April/002046.html
"The --disable-ipv6 build option is now deprecated.
...
Squid-3.5.7 and later will perform IPv6 availability tests on startup in
all builds.
- Where IPv6 is unavailable Squid will continue exactly as it would
have had the build option not been used.
These Squid can have the build option removed now."
The warning message concerning a "BCP 177 violation" while
starting 'squid' can be ignored.
Best,
Matthias
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
We are using the netfilter MARK in IPsec & QoS and this
is causing conflicts.
Therefore, we use the highest bit in the IPS chain now
and clear it afterwards because we do not really care about
this after the packets have been passed through suricata.
Then, no other application has to worry about suricata.
Fixes: #12010
Signed-off-by: Arne Fitzenreiter <arne.fitzenreiter@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
