- The directory name for the hostile data was using HOSTILE while the chain was called
HOSTILE_DROP. This resulted in the files in the directory not being updated.
Fixes: bug#12838
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Bernhard Bitsch <bbitsch@ipfire.org>
- Chain that was specified was HOSTILE but actual used is HOSTILE_DROP
- Using HOSTILE caused no update fro the hostile data used in the Firewall Hits graph
Fixes: bug#12838
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Bernhard Bitsch <bbitsch@ipfire.org>
Acked-by: Bernhard Bitsch <bbitsch@ipfire.org>
This saves some resources when we re-read the same configuration file
too often.
Suggested-by: Anthony Heading <ajrh@ajrh.net>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This patch changes that the script will listen to changes to the
directory instead of the file which got complicated when files got
renamed.
It also processes all changes at the same time and tries finding out
what actions have to be performed in order to avoid unnecessary
iterations.
The script is also limited to process any changes only once every five
seconds to keep resource usage in check on busy systems.
Suggested-by: Anthony Heading <ajrh@ajrh.net>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This improves logging and enables logging to the console.
Suggested-by: Anthony Heading <ajrh@ajrh.net>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Since running virtual machines is one of our legitimate use cases, it
makes sense to provide Qemu with the ability of taking advantage of
IOMMU support for safer virtuall memory allocation, if available.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Acked-by: Michael Tremer <michael.tremer@ipfire.org>
This is recommended by KSPP, Lynis, and others. Indeed, there is no
legitimate reason why an unprivileged user on IPFire should do any
profiling. Unfortunately, this change never landed in the mainline
kernel, hence a distribution patch is necessary.
The second version of this patch rebases the kernel patch by Jeff
Vander Stoep against Linux 5.15.17 to avoid fuzzying.
Tested-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Since we dropped support for blocking P2P protocols, the corresponding translation strings
are no longer needed.
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Reviewed-by: Peter Müller <peter.mueller@ipfire.org>
Historically, the MD5 checksums in our LFS files serve as a protection
against broken downloads, or accidentally corrupted source files.
While the sources are nowadays downloaded via HTTPS, it make sense to
beef up integrity protection for them, since transparently intercepting
TLS is believed to be feasible for more powerful actors, and the state
of the public PKI ecosystem is clearly not helping.
Therefore, this patch switches from MD5 to BLAKE2, updating all LFS
files as well as make.sh to deal with this checksum algorithm. BLAKE2 is
notably faster (and more secure) than SHA2, so the performance penalty
introduced by this patch is negligible, if noticeable at all.
In preparation of this patch, the toolchain files currently used have
been supplied with BLAKE2 checksums as well on
https://source.ipfire.org/.
Cc: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Acked-by: Michael Tremer <michael.tremeripfire.org>
This script only appeared in conjunction with Core Update 75, released
January 2014. Although it is still being executed while restoring a
backup, it would only be effective if anyone tried to restore a backup
created before C75.
I don't think there is a realistic need to carry this script along any
further. In doubt, it might be better to start from scratch again rather
than trying to restore an 8 year old backup, expecting everything to be
peachy and vanilla with it.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
This reverts commit 77e3829dc1.
For the time being, shipping this was found to be too difficult, since
we cannot get linux-firmware down to an acceptable size limit.
Compressing the firmware on installations would work, but takes about 4
minutes on an Intel Xenon CPU alone, hence it is an unacceptable
workload to do for IPFire installation running on weaker hardware.
Therefore, we do not proceed with this at the moment.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
