- Existing situation is if four new client connections are created and then it is decided
to restore to an earlier stage the new certficates will be in the certs directory but
not usable from the WUI page as they are no longer shown in the client connection table
as that now shows the ones from the restored backup.
- This patch clears the /var/ipfire/ovpn/certs/ directory before restoring the contents
of the backup so that the certs directory only holds what was in the backup.
Fixes: Bug#13404
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- This was fixed by moving the code for checking if the common name is already used, to
the same location as the code for checking if the connection name is already used.
- Tested out on vm testbed and confirmed that the certificates are not created and the
index.txt not updated if the common name is flagged as already being used. If the
entry is changed to use a new CN and Save pressed then the certs are saved and the
index.txt updated. If Cancel is pressed then no certs are saved and index.txt is not
updated.
Fixes: Bug#13404
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- This v2 version is to correct the bug number. I entered a wronn bug number in the first
version
- This extends the allowed options from just array of ip-address to also include
integer 8 or integer 16 or integer 32.
- Tested out on vm testbed. The array of integer 8 (or 16 or 32) is acceptewd by the dhcp
options section. I am not able to test out that the function actually works as I don't
have any dhcp situation set up to use that capability.
- Records or array of records is still not included. It was only an expansion of the array
of section to include integers.
Fixes: bug#11774
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- If Freifunk München e.V. is entered as a remark it gets converted to
Freifunk München e.V.
- This is because cleanhtml is used on the remark text before saving it to the file and
the HTML::Entities::encode_entities command that is run on that remark text encodes all
higher bit characters as unsafe characters and replaces them with their HTML entity
representation.
- Have tested out the remark with a range of different characters with diacritical marks
and all of the ones tested were re-written.
- The use of the cleanhtml makes sense when used on URL's or on text that is going to be
printed as part of the HTML code for a page but it doesn't seem to make sense for text
used in a remark.
- The cleanhtml function is only used on the remark text in dns.cgi and not on any other
entries on the page.
- Removing the call to the cleanhtml function results in the German umlauts being printed
in the remark section.
- Many of the WUI pages have the cleanhtml function used on remark or comment text.
- fwhosts.cgi does not use cleanhtml anywhere. So all its remark sections work with
characters with diacritical marks.
- If this patch is accepted, I will then submit patches for the other WUI pages where
characters with diacritical marks are re-written in remark or comment sections.
Fixes: Bug#12395
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
We disable cores if the are affected by some cpu vulnerabilities
this cores report errors if you try to change the settings.
So only print the output for core0 and hide it for all cores.
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
the initskript loads a test-modul for amd-pstate (which traces on intel)
and off course reports errors if firmware settings are missing.
this also fix the error at start because also amd-pstate doesn't support
ondemand mode.
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
- The PT Attack ruleset has not been updated since 2021 and made read-only in 2022
The PT Attack website no longer has any reference to Suricata Rulesets. The PT Attack
ruleset is being removed.
- The Secureworks three rulesets are no longer available. The website path gives a 404
error. No mention of Suricata rulesets in the Secureworks website. The Secureworks three
rulesets are being removed.
- ThreatFox ruleset has been added to the list. Both a plain and archive version of the
rules are available but the plain version is being regularly updated while the archive
version was last updated 5 days ago. So this patch has implemented the plain version.
- All above was discussed in the January Developers Conference call.
- Tested out on my vm testbed. I had PT Attack selected as one of the providers. As
mentioned by Stefan removing PT Attack means it is not available in the list of
providers but the provider stays in the providers table but with the line shown in red.
I will update the wiki to mention the red highlight and what it means.
Suggested-by: Stefan Schantl <stefan.schantl@ipfire.org>
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- OpenSSL was updated to 3.1.4 in CU181 and to 3.2.1 in CU183 but in both cases freeradius
was not incremented to cause it to be shipped.
- This patch increments the freeradius PAK_VER to ensure it will be shipped.
Fixes: Bug#13590
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- If a fresh install is done then only the DROP_HOSTILE_IN & DROP_HOSTILE_OUT
rrd directories are created.
- With the DROP_HOSTILE directory missing then when the fwhits graph is updated an error
message is caused by the inability to open the required files.
- This patch adds an if/else loop into the fwhits graph code to deal with the two cases
of the DROP_HOSTILE being present or not depending on the history and if a backup with
logs has been restored from when DROP_HOSTILE was in use.
- Tested on vm testbed and created a historical line for the hostile data when it was not
split
- There might be a simpler or better approach than this but it was the only option I
could identify. I couldn't find anything about being able to use if loops within the
RRD::Graph loop
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
In IPFire 2, we don't make any use out of the debug information.
Therefore we can tell the compiler to generate as minimal debug
information as possible in order to have a faster compilation process.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
