Development September 2022

development@lists.ipfire.org

14 participants
62 discussions

Can't push: "Error unpack remote failed..."
by Matthias Fischer 23 Sep '22

23 Sep '22

Hi, I'd like to have a problem* during pushing through GIT...: If I try something like git push mfischer unbound I get: **SNIP*** root@Devel64-1: /git/ipfire-2.x # git push mfischer unbound mfischer(a)git.ipfire.org's password: Enumerating objects: 153, done. Counting objects: 100% (149/149), done. Delta compression using up to 8 threads Compressing objects: 100% (89/89), done. Writing objects: 100% (98/98), 12.06 KiB | 823.00 KiB/s, done. Total 98 (delta 71), reused 4 (delta 0), pack-reused 0 error: remote unpack failed: unable to create temporary object directory To ssh://git.ipfire.org/pub/git/people/mfischer/ipfire-2.x.git ! [remote rejected] unbound -> unbound (unpacker error) error: failed to push some refs to 'ssh://git.ipfire.org/pub/git/people/mfischer/ipfire-2.x.git' ***SNAP*** Something up there in GIT doesn't like me anymore... Can someone confirm? Best, Matthias

3 4

[PATCH] expat: Update to version 2.4.9
by Adolf Belka 23 Sep '22

23 Sep '22

- Update from version 2.4.8 to 2.4.9 - Update of rootfile - Changelog Release 2.4.9 Tue September 20 2022 Security fixes: #629 #640 CVE-2022-40674 -- Heap use-after-free vulnerability in function doContent. Expected impact is denial of service or potentially arbitrary code execution. Bug fixes: #634 MinGW: Fix mis-compilation for -D__USE_MINGW_ANSI_STDIO=0 #614 docs: Fix documentation on effect of switch XML_DTD on symbol visibility in doc/reference.html Other changes: #638 MinGW: Make fix-xmltest-log.sh drop more Wine bug output #596 #625 Autotools: Sync CMake templates with CMake 3.22 #608 CMake: Migrate from use of CMAKE_*_POSTFIX to dedicated variables EXPAT_*_POSTFIX to stop affecting other projects #597 #599 Windows|CMake: Add missing -DXML_STATIC to test runners and fuzzers #512 #621 Windows|CMake: Render .def file from a template to fix linking with -DEXPAT_DTD=OFF and/or -DEXPAT_ATTR_INFO=ON #611 #621 MinGW|CMake: Apply MSVC .def file when linking #622 #624 MinGW|CMake: Sync library name with GNU Autotools, i.e. produce libexpat-1.dll rather than libexpat.dll by default. Filename libexpat.dll.a is unaffected. #632 MinGW|CMake: Set missing variable CMAKE_RC_COMPILER in toolchain file "cmake/mingw-toolchain.cmake" to avoid error "windres: Command not found" on e.g. Ubuntu 20.04 #597 #627 CMake: Unify inconsistent use of set() and option() in context of public build time options to take need for set(.. FORCE) in projects using Expat by means of add_subdirectory(..) off Expat's users' shoulders #626 #641 Stop exporting API symbols when building a static library #644 Resolve use of deprecated "fgrep" by "grep -F" #620 CMake: Make documentation on variables a bit more consistent #636 CMake: Drop leading whitespace from a #cmakedefine line in file expat_config.h.cmake #594 xmlwf: Fix harmless variable mix-up in function nsattcmp #592 #593 #610 Address Cppcheck warnings #643 Address Clang 15 compiler warnings #642 #644 Version info bumped from 9:8:8 to 9:9:8; see https://verbump.de/ for what these numbers do Infrastructure: #597 #598 CI: Windows: Start covering MSVC 2022 #619 CI: macOS: Migrate off deprecated macOS 10.15 #632 CI: Linux: Make migration off deprecated Ubuntu 18.04 work #643 CI: Upgrade Clang from 14 to 15 #637 apply-clang-format.sh: Add support for BSD find #633 coverage.sh: Exclude MinGW headers #635 coverage.sh: Fix name collision for -funsigned-char Signed-off-by: Adolf Belka <adolf.belka(a)ipfire.org> --- config/rootfiles/common/expat | 20 ++++++++++---------- lfs/expat | 4 ++-- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/config/rootfiles/common/expat b/config/rootfiles/common/expat index 69b3fbfe6..8feb895b3 100644 --- a/config/rootfiles/common/expat +++ b/config/rootfiles/common/expat @@ -2,20 +2,20 @@ #usr/include/expat.h #usr/include/expat_config.h #usr/include/expat_external.h -#usr/lib/cmake/expat-2.4.8 -#usr/lib/cmake/expat-2.4.8/expat-config-version.cmake -#usr/lib/cmake/expat-2.4.8/expat-config.cmake -#usr/lib/cmake/expat-2.4.8/expat-noconfig.cmake -#usr/lib/cmake/expat-2.4.8/expat.cmake +#usr/lib/cmake/expat-2.4.9 +#usr/lib/cmake/expat-2.4.9/expat-config-version.cmake +#usr/lib/cmake/expat-2.4.9/expat-config.cmake +#usr/lib/cmake/expat-2.4.9/expat-noconfig.cmake +#usr/lib/cmake/expat-2.4.9/expat.cmake #usr/lib/libexpat.la #usr/lib/libexpat.so usr/lib/libexpat.so.1 -usr/lib/libexpat.so.1.8.8 +usr/lib/libexpat.so.1.8.9 #usr/lib/pkgconfig/expat.pc #usr/share/doc/expat -#usr/share/doc/expat-2.4.8 -#usr/share/doc/expat-2.4.8/ok.min.css -#usr/share/doc/expat-2.4.8/reference.html -#usr/share/doc/expat-2.4.8/style.css +#usr/share/doc/expat-2.4.9 +#usr/share/doc/expat-2.4.9/ok.min.css +#usr/share/doc/expat-2.4.9/reference.html +#usr/share/doc/expat-2.4.9/style.css #usr/share/doc/expat/AUTHORS #usr/share/doc/expat/changelog diff --git a/lfs/expat b/lfs/expat index 76f5a8e94..a1a1326d0 100644 --- a/lfs/expat +++ b/lfs/expat @@ -24,7 +24,7 @@ include Config -VER = 2.4.8 +VER = 2.4.9 THISAPP = expat-$(VER) DL_FILE = $(THISAPP).tar.bz2 @@ -40,7 +40,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_BLAKE2 = a829bd94d2cc9b305874ae2539dd4388ea99eaed21d2da17bbd99a1e7735b0f7cb910d096f72c71b128dcb8ffdff9021109e7ff5e562d8cefad228fd8d66f897 +$(DL_FILE)_BLAKE2 = d60183f96f3359acc069af638cc8d16ba19f51fbd8a61eddd80c2babddde357dcf0561e87af901f53617bfd9452e146c9dd9f317729cd3648b65832a38388640 install : $(TARGET) -- 2.37.3

2 1

[PATCH] unbound: Update to 1.16.3
by Matthias Fischer 23 Sep '22

23 Sep '22

For details see: https://lists.nlnetlabs.nl/pipermail/unbound-users/2022-September/007885.ht… "This release fixes CVE-2022-3204 Non-Responsive Delegation Attack. It was reported by Yehuda Afek from Tel-Aviv University and Anat Bremler-Barr and Shani Stajnrod from Reichman University. This fixes for better performance when under load, by cutting promiscuous queries for nameserver discovery and limiting the number of times a delegation point can look in the cache for missing records. Bug Fixes - Patch for CVE-2022-3204 Non-Responsive Delegation Attack." Signed-off-by: Matthias Fischer <matthias.fischer(a)ipfire.org> --- config/rootfiles/common/unbound | 2 +- lfs/unbound | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/config/rootfiles/common/unbound b/config/rootfiles/common/unbound index 7fc4f191a..7af787f29 100644 --- a/config/rootfiles/common/unbound +++ b/config/rootfiles/common/unbound @@ -11,7 +11,7 @@ etc/unbound/unbound.conf #usr/lib/libunbound.la #usr/lib/libunbound.so usr/lib/libunbound.so.8 -usr/lib/libunbound.so.8.1.18 +usr/lib/libunbound.so.8.1.19 #usr/lib/pkgconfig/libunbound.pc usr/sbin/unbound usr/sbin/unbound-anchor diff --git a/lfs/unbound b/lfs/unbound index 5a3c70caf..636fe8bf9 100644 --- a/lfs/unbound +++ b/lfs/unbound @@ -24,7 +24,7 @@ include Config -VER = 1.16.2 +VER = 1.16.3 THISAPP = unbound-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -40,7 +40,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_BLAKE2 = 2f7f119d12807ff5c000fd500be72a0825614da3e1f079f9b8d15a651bda2fa0b41599a55c6f76b17ff56120aa61e48042469063f08dd199333520172ca16750 +$(DL_FILE)_BLAKE2 = b97deade78ab903363e06ff9d71b9895c754378ec276bb17556de62c48a88af5fbabd26f97fb47313d1e631fe75dee245aa38fbf42a865ac3e764882a1124a51 install : $(TARGET) -- 2.34.1

2 1

[PATCH] bind: Update to 9.16.33
by Matthias Fischer 23 Sep '22

23 Sep '22

For details see: https://downloads.isc.org/isc/bind9/9.16.33/doc/arm/html/notes.html#notes-f… "Security Fixes Previously, there was no limit to the number of database lookups performed while processing large delegations, which could be abused to severely impact the performance of named running as a recursive resolver. This has been fixed. (CVE-2022-2795) ISC would like to thank Yehuda Afek from Tel-Aviv University and Anat Bremler-Barr & Shani Stajnrod from Reichman University for bringing this vulnerability to our attention. [GL #3394] named running as a resolver with the stale-answer-client-timeout option set to 0 could crash with an assertion failure, when there was a stale CNAME in the cache for the incoming query. This has been fixed. (CVE-2022-3080) [GL #3517] A memory leak was fixed that could be externally triggered in the DNSSEC verification code for the ECDSA algorithm. (CVE-2022-38177) [GL #3487] Memory leaks were fixed that could be externally triggered in the DNSSEC verification code for the EdDSA algorithm. (CVE-2022-38178) [GL #3487] Feature Changes Response Rate Limiting (RRL) code now treats all QNAMEs that are subject to wildcard processing within a given zone as the same name, to prevent circumventing the limits enforced by RRL. [GL #3459] Zones using dnssec-policy now require dynamic DNS or inline-signing to be configured explicitly. [GL #3381] A backward-compatible approach was implemented for encoding internationalized domain names (IDN) in dig and converting the domain to IDNA2008 form; if that fails, BIND tries an IDNA2003 conversion. [GL #3485] Bug Fixes A serve-stale bug was fixed, where BIND would try to return stale data from cache for lookups that received duplicate queries or queries that would be dropped. This bug resulted in premature SERVFAIL responses, and has now been resolved. [GL #2982]" Signed-off-by: Matthias Fischer <matthias.fischer(a)ipfire.org> --- config/rootfiles/common/bind | 17 +++++++---------- lfs/bind | 4 ++-- 2 files changed, 9 insertions(+), 12 deletions(-) diff --git a/config/rootfiles/common/bind b/config/rootfiles/common/bind index 5aea1853b..879f8c832 100644 --- a/config/rootfiles/common/bind +++ b/config/rootfiles/common/bind @@ -157,7 +157,6 @@ usr/bin/nsupdate #usr/include/isc/heap.h #usr/include/isc/hex.h #usr/include/isc/hmac.h -#usr/include/isc/hp.h #usr/include/isc/ht.h #usr/include/isc/httpd.h #usr/include/isc/interfaceiter.h @@ -175,7 +174,6 @@ usr/bin/nsupdate #usr/include/isc/mem.h #usr/include/isc/meminfo.h #usr/include/isc/mutex.h -#usr/include/isc/mutexatomic.h #usr/include/isc/mutexblock.h #usr/include/isc/net.h #usr/include/isc/netaddr.h @@ -191,7 +189,6 @@ usr/bin/nsupdate #usr/include/isc/pool.h #usr/include/isc/portset.h #usr/include/isc/print.h -#usr/include/isc/queue.h #usr/include/isc/quota.h #usr/include/isc/radix.h #usr/include/isc/random.h @@ -274,24 +271,24 @@ usr/bin/nsupdate #usr/include/pk11/site.h #usr/include/pkcs11 #usr/include/pkcs11/pkcs11.h -usr/lib/libbind9-9.16.32.so +usr/lib/libbind9-9.16.33.so #usr/lib/libbind9.la #usr/lib/libbind9.so -usr/lib/libdns-9.16.32.so +usr/lib/libdns-9.16.33.so #usr/lib/libdns.la #usr/lib/libdns.so -usr/lib/libirs-9.16.32.so +usr/lib/libirs-9.16.33.so #usr/lib/libirs.la #usr/lib/libirs.so -usr/lib/libisc-9.16.32.so +usr/lib/libisc-9.16.33.so #usr/lib/libisc.la #usr/lib/libisc.so -usr/lib/libisccc-9.16.32.so +usr/lib/libisccc-9.16.33.so #usr/lib/libisccc.la #usr/lib/libisccc.so -usr/lib/libisccfg-9.16.32.so +usr/lib/libisccfg-9.16.33.so #usr/lib/libisccfg.la #usr/lib/libisccfg.so -usr/lib/libns-9.16.32.so +usr/lib/libns-9.16.33.so #usr/lib/libns.la #usr/lib/libns.so diff --git a/lfs/bind b/lfs/bind index bb5c26e1e..aeff480a2 100644 --- a/lfs/bind +++ b/lfs/bind @@ -25,7 +25,7 @@ include Config -VER = 9.16.32 +VER = 9.16.33 THISAPP = bind-$(VER) DL_FILE = $(THISAPP).tar.xz @@ -43,7 +43,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_BLAKE2 = df6f2c878138015da580dfaf0e16b5a97b11ead9f99c1425a09da8484954196ea3dafb828ac3ab386200ce2b180646c7eb1e0e62a84c153162270a4a1e19a5fc +$(DL_FILE)_BLAKE2 = 4246b61ce91af3d494ace4b8065b4c0043b2cfaf28c6de326691a969837e7d1cfbc0dac6b1e1a5182fc32af68048abcfa1202d00022951f3caa13afb03ebeb69 install : $(TARGET) -- 2.34.1

2 1

Fwd: Stale pakfire lock-file causing pakfire to no longer work
by Bernhard Bitsch 22 Sep '22

22 Sep '22

Hi all, just FYI the conversation between Robin and myself. I am optimistic to present a tested patch in the next days. Main idea behind the modification: Move the locking mechanism from test of file existence to file locking ( which is an atomic, uninteruptible OS function ). Regards, Bernhard -------- Weitergeleitete Nachricht -------- Betreff: Re: Stale pakfire lock-file causing pakfire to no longer work Datum: Thu, 22 Sep 2022 14:54:24 +0200 Von: Robin Roevens <robin.roevens(a)disroot.org> An: Bernhard Bitsch <bbitsch(a)ipfire.org> Hi Bernhard Bernhard Bitsch schreef op do 22-09-2022 om 14:47 [+0200]: > Hi Robin, > > the .cgi file uses pakfire routines, /opt/pakfire/lib/functions.pl to > be > exact. So it is guaranteed that the state is read consistantly. This > should have been true until now. > The problem is the timing of processing. The flock() function > delegates > the locking/unlocking to the OS. That is the unique instance you are > speaking of. > > The calling of pakfire ( via system()? ) and analysing the output is > more error-prone and time-consuming. > My approach just adds the lock() / unlock functions to the pakfire > library. All other functions remain untouched in the interface. Even better indeed. I did more or less the same with all the metadata parsing recently added to pakfire by me, where the webui no longer tries to do the same on it's own, but uses the pakfire functions. > > Two processes working on the pakfire database only need this one > semaphore to synchronise. The lock information ( PID, locking time ) > are > an extension, usable by the web interface for example. > > My test tasks, which have implemented the mechanism, are running now > without problems. I'm going to implement it into the pakfire packet > today. So I think, I'm able to send you a test version soon. Thanks. Looking forward to it. Robin > > Bernhard > > > Am 22.09.2022 um 14:24 schrieb Robin Roevens: > > Hi Bernhard > > > > Bernhard Bitsch schreef op do 22-09-2022 om 08:48 [+0200]: > > > Hi Robin, > > > > > > > > > Am 22.09.2022 um 00:16 schrieb Robin Roevens: > > > > Hi Bernhard > > > > > > > > Yes, I noticed that too in the meantime. > > > > Can we let the webgui just call pakfire without checking for a > > > > lockfile. But when pakfire exits with the error that it is > > > > locked, > > > > just > > > > retry (after delay?), showing the current waiting for lock > > > > screen > > > > in > > > > the webgui. > > > > > > > > > > The WebGUI repeats the lock check, yet. > > > But in the moment there is just the problem that the mechanism of > > > locking changed from creation/deletion to file lock/unlock. The > > > file > > > isn't deleted. > > > My idea: the locking writes pid and time to the file. So the > > > WebGUI > > > can > > > get the information (locked, locking time) for display in the > > > message. > > > Moreover the locking process can be given. > > > This arises some more complexity. Therefore the solution lasts a > > > bit. > > > > If I understand your intention the webgui would still try to > > independently figure out if pakfire is locked or not? > > But I don't think the webgui should try to figure that out by > > itself > > (as it did before by independently checking the existence of the > > file) > > but leave that part to pakfire itself. > > When pakfire is started, it checks for the lock and exits if > > locked, > > eventually indeed with a message containing the process that has > > the > > lock. And the webgui should pick that up to display to the user, > > and > > retry launching pakfire, until it actually does some work instead > > of > > exiting because of a lock. > > This way there is a single source of truth about the locking state > > of > > pakfire and that is pakfire itself; If the locking mechanism would > > change again some time in the future for reasons we don't know yet > > :-) > > then the webgui should not be needing modifications anymore to > > comply > > with the new mechanism. > > > > > Further I want to check for more possible problems in the pakfire > > > part > > > of IPFire. > > > Maybe we can find some more possible race conditions explaining > > > mysterious errors. > > > > > > Did you find any indications for the missing file deletion in the > > > 'normal' pakfire SW, yet? > > Not yet. To be honest, I didn't look for it anymore due to work on > > another bug. But I hope to investigate this further in the days to > > come. > > > > Robin > > > > > > > > Bernhard > > > > > > > Thanks for the good work! > > > > > > > > Robin > > > > > > > > Bernhard Bitsch schreef op ma 19-09-2022 om 15:32 [+0200]: > > > > > Hi Robin, > > > > > > > > > > we missed something. The WebGUI doesn't know about our file > > > > > locking. > > > > > :( > > > > > So it waits for deletion of the lock file. > > > > > I'll work on that asap. > > > > > > > > > > Bernhard > > > > > > > > > > Am 19.09.2022 um 00:58 schrieb Robin Roevens: > > > > > > Hi Bernhard > > > > > > > > > > > > I have good news. For now my pakfire status check in Zabbix > > > > > > is > > > > > > still > > > > > > correctly running and pakfire is still functioning. > > > > > > > > > > > > I do see a few missing results now and then. > > > > > > Every 10 minutes I should get the output of pakfire status > > > > > > in > > > > > > Zabbix. > > > > > > But once in a while I'm missing a result. So I assume those > > > > > > are > > > > > > the > > > > > > points where previous pakfire version would leave the > > > > > > lockfile > > > > > > and > > > > > > stop > > > > > > functioning. > > > > > > Now a subsequent call will succeed again and both the check > > > > > > and > > > > > > pakfire > > > > > > keeps on working. > > > > > > One time I'm missing 2 subsequent data points (02:50 and > > > > > > 03:00) > > > > > > but > > > > > > at > > > > > > 03:10 Zabbix again got new data from pakfire. > > > > > > > > > > > > So I think the flock method is a success! > > > > > > > > > > > > The pakfire process sometimes terminating unexpectedly > > > > > > still > > > > > > happens, > > > > > > but this now no longer breaks pakfire. > > > > > > As I'm still suspecting sudo, I think them most elegant > > > > > > solution to > > > > > > that would be to allow 'pakfire status' to be run as non > > > > > > privileged > > > > > > user without using sudo. But I will try to implement that > > > > > > myself > > > > > > soon > > > > > > and publish it to the devel list (if that indeed solves > > > > > > this > > > > > > problem). > > > > > > > > > > > > The most important thing is that pakfire no longer breaks, > > > > > > which > > > > > > seems > > > > > > to be fixed with the flock method. > > > > > > > > > > > > Anyway, I will leave this running now for about a week and > > > > > > see > > > > > > if > > > > > > pakfire still won't break. But I'm already quite sure that > > > > > > is > > > > > > solved > > > > > > now. > > > > > > > > > > > > Thanks for this implementation > > > > > > > > > > > > Robin > > > > > > > > > > > > Bernhard Bitsch schreef op zo 18-09-2022 om 02:00 [+0200]: > > > > > > > Hi Robin, > > > > > > > > > > > > > > Am 18.09.2022 um 00:23 schrieb Robin Roevens: > > > > > > > > Hi Bernhard > > > > > > > > > > > > > > > > Thanks. I installed it on my IPFire mini appliance. If > > > > > > > > tomorrow > > > > > > > > I > > > > > > > > still > > > > > > > > have a working check in Zabbix, it will already be a > > > > > > > > success as > > > > > > > > the > > > > > > > > original version always leaves a stale lockfile within > > > > > > > > 24h. > > > > > > > > But for safety I think is it best to have it run for at > > > > > > > > least a > > > > > > > > week or > > > > > > > > so without problem. > > > > > > > > > > > > > > > > The quick tests I perform manually indeed proved > > > > > > > > pakfire > > > > > > > > refusing > > > > > > > > to > > > > > > > > start when another instance is running. > > > > > > > > > > > > > > > > One thing, I noticed is that I now get > > > > > > > > --- > > > > > > > > Use of uninitialized value $ARGV[1] in string at > > > > > > > > /opt/pakfire/pakfire > > > > > > > > line 344. > > > > > > > > Use of uninitialized value $ARGV[1] in string at > > > > > > > > /opt/pakfire/pakfire > > > > > > > > line 346. > > > > > > > > --- > > > > > > > > when performing 'pakfire list', but for as far as I can > > > > > > > > see > > > > > > > > this > > > > > > > > was > > > > > > > > already there, but only now visible due to 'use > > > > > > > > warnings'. > > > > > > > > So > > > > > > > > that > > > > > > > > is > > > > > > > > not in scope here. > > > > > > > > > > > > > > > > > > > > > > Sorry, didn't scroll up the output while testing. > > > > > > > Yes, this issues were there already. I use the warnings > > > > > > > generally, > > > > > > > because of the complexity of Perl; you never are aware of > > > > > > > all > > > > > > > possible > > > > > > > interpretations of your written code. > > > > > > > I'm just doing a little change. As far as I see, all > > > > > > > options > > > > > > > are > > > > > > > handled > > > > > > > at the start of the program. If these options are deleted > > > > > > > from > > > > > > > the > > > > > > > arguments ( @ARGV ), the rest of the program works on an > > > > > > > array > > > > > > > containing only command ($ARGV[0]) and parameters. So the > > > > > > > checks > > > > > > > for > > > > > > > options can be eliminated. > > > > > > > > > > > > > > > And in a final version of course a message telling the > > > > > > > > user > > > > > > > > why > > > > > > > > it > > > > > > > > exited prematurely, should also be displayed. But that > > > > > > > > is a > > > > > > > > detail > > > > > > > > for > > > > > > > > later. > > > > > > > > > > > > > > > > > > > > > > Agreed. > > > > > > > > > > > > > > Regards > > > > > > > Bernhard > > > > > > > > > > > > > > > Regards > > > > > > > > Robin > > > > > > > > > > > > > > > > Bernhard Bitsch schreef op za 17-09-2022 om 23:11 > > > > > > > > [+0200]: > > > > > > > > > > > > > > > > > > Hi Robin, > > > > > > > > > > > > > > > > > > as announced I've made a version with the flock() > > > > > > > > > function. > > > > > > > > > Just unpack the arcive attached and copy it to > > > > > > > > > /opt/pakfire > > > > > > > > > directory. > > > > > > > > > My tests with the locking simulation look good. I > > > > > > > > > will > > > > > > > > > look > > > > > > > > > into > > > > > > > > > other > > > > > > > > > IPC functions for handling the race condition. > > > > > > > > > > > > > > > > > > BTW, do you know the reason for the waits in pakfire- > > > > > > > > > update > > > > > > > > > and > > > > > > > > > pakfire-upgrade functionality? > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Bernhard > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.

1 0

[PATCH] manualpages: Correct link to wiki for Network (other)
by Adolf Belka 22 Sep '22

22 Sep '22

- Network (other) help link was set to go to Network (internal) wiki page Link modified - Running the check_manualpages.pl script requires it to be executable so the build changed the permissions mode from 644 to 755 Tested-by: Adolf Belka <adolf.belka(a)ipfire.org> Signed-off-by: Adolf Belka <adolf.belka(a)ipfire.org> --- config/cfgroot/manualpages | 2 +- tools/check_manualpages.pl | 0 2 files changed, 1 insertion(+), 1 deletion(-) mode change 100644 => 100755 tools/check_manualpages.pl diff --git a/config/cfgroot/manualpages b/config/cfgroot/manualpages index c0cefed5e..0b904de42 100644 --- a/config/cfgroot/manualpages +++ b/config/cfgroot/manualpages @@ -22,7 +22,7 @@ services.cgi=configuration/status/services media.cgi=configuration/status/drives netexternal.cgi=configuration/status/network_ext netinternal.cgi=configuration/status/network_int -netother.cgi=configuration/status/network_int +netother.cgi=configuration/status/network_other netovpnrw.cgi=configuration/status/network_ovpnrw #netovpnsrv.cgi= wio.cgi=addons/wio diff --git a/tools/check_manualpages.pl b/tools/check_manualpages.pl old mode 100644 new mode 100755 -- 2.37.3

2 1

[PATCH v2] cpufrequtils: Remove SERVICES entry for this package - fixes Bug#12933
by Adolf Belka 21 Sep '22

21 Sep '22

- cpufrequtils is a set of "tools" to manage and set cpu freq settings. - There is an initscript but this is only loading the cpu dependent kernel modules that are required by cpufrequtils. - Therefore cpufrequtils is not a service but a set of tools that are used when required. - SERVICES line made blank so that this addon does not show up in the services addon table. - Modified install initscript line to not use SERVICES variable Fixes: Bug#12933 Signed-off-by: Adolf Belka <adolf.belka(a)ipfire.org> --- lfs/cpufrequtils | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lfs/cpufrequtils b/lfs/cpufrequtils index 752964198..dab254014 100644 --- a/lfs/cpufrequtils +++ b/lfs/cpufrequtils @@ -34,11 +34,11 @@ DL_FROM = $(URL_IPFIRE) DIR_APP = $(DIR_SRC)/$(THISAPP) TARGET = $(DIR_INFO)/$(THISAPP) PROG = cpufrequtils -PAK_VER = 11 +PAK_VER = 12 DEPS = -SERVICES = cpufreq +SERVICES = ############################################################################### # Top-level Rules @@ -91,7 +91,7 @@ $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) cd $(DIR_APP) && make install #install initscripts - $(call INSTALL_INITSCRIPTS,$(SERVICES)) + $(call INSTALL_INITSCRIPTS,cpufreq) @rm -rf $(DIR_APP) @$(POSTBUILD) -- 2.37.3

2 1

[PATCH] cpufrequtils: Remove SERVICES entry for this package - fixes Bug#12933
by Adolf Belka 21 Sep '22

21 Sep '22

- cpufrequtils is a set of "tools" to manage and set cpu freq settings. - There is an initscript but this is only loading the cpu dependent kernel modules that are required by cpufrequtils. - Therefore cpufrequtils is not a service but a set of tools that are used when required. - SERVICES line made blank so that this addon does not show up in the services addon table. Fixes: Bug#12933 Signed-off-by: Adolf Belka <adolf.belka(a)ipfire.org> --- lfs/cpufrequtils | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lfs/cpufrequtils b/lfs/cpufrequtils index 752964198..9076a70d7 100644 --- a/lfs/cpufrequtils +++ b/lfs/cpufrequtils @@ -34,11 +34,11 @@ DL_FROM = $(URL_IPFIRE) DIR_APP = $(DIR_SRC)/$(THISAPP) TARGET = $(DIR_INFO)/$(THISAPP) PROG = cpufrequtils -PAK_VER = 11 +PAK_VER = 12 DEPS = -SERVICES = cpufreq +SERVICES = ############################################################################### # Top-level Rules -- 2.37.3

3 3

[PATCH] crontab: add periodic cleanup the collectd RRD (graphs)
by Jon Murphy 20 Sep '22

20 Sep '22

- Created (mostly) for old openvpn graphs - RRD removed when no graph modification for +365 days - chosen since graph max out is 365 days - fcron job runs once per week - chosen since this is just a cleanup and it doesnt need to run everyday Note: logging can be added if needed. Signed-off-by: Jon Murphy <jon.murphy(a)ipfire.org> --- config/cron/crontab | 3 +++ 1 file changed, 3 insertions(+) diff --git a/config/cron/crontab b/config/cron/crontab index b727531fc..7088e0b75 100644 --- a/config/cron/crontab +++ b/config/cron/crontab @@ -80,5 +80,8 @@ HOME=/ # Cleanup the mail spool directory %weekly * * /usr/sbin/dma-cleanup-spool +# Cleanup the collectd RRD (graphs) +%weekly * * /bin/find /var/log/rrd -mtime +365 -type f -name '*.rrd' -delete -o -type d -empty -delete + # Update DNS trust anchor %daily,random * * @runas(nobody) /usr/sbin/unbound-anchor -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem -- 2.30.2

4 10

[PATCH] log.dat: Add NUT entry for System Logs - Fixes bug#12921
by Adolf Belka 19 Sep '22

19 Sep '22

- Also aligned all the code entries in %sections and %trsections Suggested-by: Michael <ip.fire(a)die-fritzens.de> Tested-by: Michael <ip.fire(a)die-fritzens.de> Signed-off-by: Adolf Belka <adolf.belka(a)ipfire.org> --- html/cgi-bin/logs.cgi/log.dat | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/html/cgi-bin/logs.cgi/log.dat b/html/cgi-bin/logs.cgi/log.dat index 20f61d4ea..5fb1fcd5d 100644 --- a/html/cgi-bin/logs.cgi/log.dat +++ b/html/cgi-bin/logs.cgi/log.dat @@ -50,7 +50,7 @@ $cgiparams{'SECTION'} = 'ipfire'; my %sections = ( 'auth' => '(\w+$pam_unix$\[.*\]: )', - 'wio' => '(wio:|wio\[.*\])', + 'wio' => '(wio:|wio\[.*\])', 'captive' => '(Captive:)', 'clamav' => '(clamd\[.*\]: |freshclam\[.*\]: )', 'collectd' => '(collectd\[.*\]: )', @@ -65,11 +65,12 @@ my %sections = ( 'kernel' => '(kernel: (?!DROP_))', 'monit' => '(monit\[.*?\]: )', 'ntp' => '(ntpd(?:ate)?\[.*\]: )', - 'oinkmaster' => '(oinkmaster\[.*\]: )', + 'nut' => '(upsmon\[.*?\]: )', + 'oinkmaster' => '(oinkmaster\[.*\]: )', 'openvpn' => '(openvpnserver\[.*\]: |.*n2n\[.*\]: )', 'pakfire' => '(pakfire:)', 'red' => '(red:|pppd\[.*\]: |chat\[.*\]|pppoe\[.*\]|pptp\[.*\]|pppoa\[.*\]|pppoa3\[.*\]|pppoeci\[.*\]|ipppd|ipppd\[.*\]|kernel: ippp\d|kernel: isdn.*|ibod\[.*\]|dhcpcd\[.*\]|modem_run\[.*\])', - 'samba' => '(nmbd|smbd|winbind)\[\d+\]:', + 'samba' => '(nmbd|smbd|winbind)\[\d+\]:', 'suricata' => '(suricata: )', 'squid' => '(squid\[.*\]: |squid: )', 'ssh' => '(sshd(?:$.*$)?\[.*\]: )', @@ -81,7 +82,7 @@ my %sections = ( # Translations for the %sections array. my %trsections = ( 'auth' => "$Lang::tr{'loginlogout'}", - 'wio' => 'Who Is Online?', + 'wio' => 'Who Is Online?', 'captive' => $Lang::tr{'Captive'}, 'clamav' => 'ClamAV', 'collectd' => 'Collectd', @@ -96,11 +97,12 @@ my %trsections = ( 'kernel' => "$Lang::tr{'kernel'}", 'monit' => 'Monit', 'ntp' => 'NTP', - 'oinkmaster' => 'Oinkmaster', + 'nut' => 'NUT', + 'oinkmaster' => 'Oinkmaster', 'openvpn' => 'OpenVPN', 'pakfire' => 'Pakfire', 'red' => 'RED', - 'samba' => $Lang::tr{'samba'}, + 'samba' => $Lang::tr{'samba'}, 'suricata' => "$Lang::tr{'intrusion detection'}", 'squid' => "$Lang::tr{'web proxy'}", 'ssh' => 'SSH', -- 2.37.3

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Development September 2022