CVE-2025-8671 was announced here: https://www.openwall.com/lists/oss-security/2025/08/13/6 https://www.openwall.com/lists/oss-security/2025/08/16/1
Whiteboard: (none) => MGA9TOOSource RPM: (none) => bind, lighttpd, varnishCVE: (none) => CVE-2025-8671
No registered maintainers for any of these packages, so assigning to all. CC'ing mrambo3501 and daviddavid
Assignee: bugsquad => pkg-bugsCC: (none) => geiger.david68210, marja11, mhrambo3501
I haven't looked at the others but ISC does not consider this a vulnerability for bind. "Conclusion: ISC deems BIND not vulnerable. See #5325 (comment 570095) for further details." https://gitlab.isc.org/isc-projects/bind9/-/issues/5325
Cauldron is already at varnish 7.7.3. Per https://varnish-cache.org/security/VSV00017.html 7.7.3 is not vulnerable. Incoming lighttpd-1.4.80-1.mga10 will resolve this issue for lighttpd.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
Oops, missed the mga9too.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Two packages updated for Mageia 9 (no update for bind as ISC does not consider this a vulnerability for bind). Advisory: ======================== Updated packages fix security vulnerability: It was discovered that A denial of service attack can be performed on Cache servers that have the HTTP/2 protocol turned on. An attacker can create a large number of streams and immediately reset them without ever reaching the maximum number of concurrent streams allowed for the session, causing the server to consume unnecessary resources processing requests for which the response will not be delivered (CVE-2025-8671). References: https://www.openwall.com/lists/oss-security/2025/08/13/6 https://www.openwall.com/lists/oss-security/2025/08/16/1 https://www.cve.org/CVERecord?id=CVE-2025-8671 ======================== Updated varnish packages in core/updates_testing: ======================== lib64varnish3-7.7.3-1.mga9 lib64varnish-devel-7.7.3-1.mga9 varnish-7.7.3-1.mga9 from varnish-7.7.3-1.mga9.src.rpm Updated lighttpd packages in core/updates_testing: ======================== lighttpd-1.4.80-1.mga9.x86_64.rpm lighttpd-mod_ajp13-1.4.80-1.mga9 lighttpd-mod_auth-1.4.80-1.mga9 lighttpd-mod_authn_file-1.4.80-1.mga9 lighttpd-mod_authn_ldap-1.4.80-1.mga9 lighttpd-mod_deflate-1.4.80-1.mga9 lighttpd-mod_magnet-1.4.80-1.mga9 lighttpd-mod_webdav-1.4.80-1.mga9 from lighttpd-1.4.80-1.mga9.src.rpm varnish test procedures https://bugs.mageia.org/show_bug.cgi?id=11678#c2 and https://bugs.mageia.org/show_bug.cgi?id=21449#c3 lighttpd test procedure https://bugs.mageia.org/show_bug.cgi?id=11662#c3
Keywords: (none) => has_procedureWhiteboard: MGA9TOO => (none)Assignee: pkg-bugs => qa-bugsVersion: Cauldron => 9
MGA9-64 server Plasma Wayland on Compaq H000SB No installation issues. Followed bug 21449 for varnish. # systemctl start varnish.service # systemctl status -l varnish.service ● varnish.service - Varnish a high-perfomance HTTP accelerator Loaded: loaded (/usr/lib/systemd/system/varnish.service; disabled; preset: disabled) Active: active (running) since Fri 2025-10-10 17:38:03 CEST; 18s ago Process: 107181 ExecStart=/usr/sbin/varnishd -P /run/varnish/varnish.pid -f /etc/varnish/default.vcl -a ${ADDRESS}:${PORT} -T 127.0.0.1:6082 -t > Main PID: 107182 (varnishd) Tasks: 29 (limit: 8805) Memory: 34.8M CPU: 2.494s CGroup: /system.slice/varnish.service ├─107182 /usr/sbin/varnishd -P /run/varnish/varnish.pid -f /etc/varnish/default.vcl -a :6081 -T 127.0.0.1:6082 -t 120 -W epoll -p threa> └─107195 /usr/sbin/varnishd -P /run/varnish/varnish.pid -f /etc/varnish/default.vcl -a :6081 -T 127.0.0.1:6082 -t 120 -W epoll -p threa> Oct 10 17:38:03 mach3.hviaene.thuis varnishd[107182]: Version: varnish-7.7.3 revision 6884b75af9c9bdb2c9b6e2aa464a435e42cb4931 Oct 10 17:38:03 mach3.hviaene.thuis varnishd[107182]: Platform: Linux,6.6.105-server-1.mga9,x86_64,-jnone,-sfile,-sdefault,-hcritbit Oct 10 17:38:03 mach3.hviaene.thuis varnishd[107182]: Warning: mlock() of VSM failed: Cannot allocate memory (12) Oct 10 17:38:03 mach3.hviaene.thuis varnishd[107182]: Info: max locked memory (soft): 82000 bytes Oct 10 17:38:03 mach3.hviaene.thuis varnishd[107182]: Info: max locked memory (hard): 82000 bytes Oct 10 17:38:03 mach3.hviaene.thuis varnishd[107182]: Child (107195) Started Oct 10 17:38:03 mach3.hviaene.thuis varnishd[107182]: Child launched OK Oct 10 17:38:03 mach3.hviaene.thuis varnishd[107182]: Child (107195) said Child starts Oct 10 17:38:03 mach3.hviaene.thuis varnishd[107182]: Child (107195) said SMF.s0 mmap'ed 1073741824 bytes of 1073741824 Oct 10 17:38:03 mach3.hviaene.thuis systemd[1]: Started varnish.service. # systemctl start varnishncsa.service # systemctl status -l varnishncsa.service ● varnishncsa.service - Varnish NCSA logging Loaded: loaded (/usr/lib/systemd/system/varnishncsa.service; disabled; preset: disabled) Active: active (running) since Fri 2025-10-10 17:39:17 CEST; 4s ago Main PID: 107324 (varnishncsa) Tasks: 1 (limit: 8805) Memory: 260.0K CPU: 77ms CGroup: /system.slice/varnishncsa.service └─107324 /usr/bin/varnishncsa -a -w /var/log/varnish/varnishncsa.log Oct 10 17:39:17 mach3.hviaene.thuis systemd[1]: Started varnishncsa.service. [root@mach3 ~]# varnishadm status Child in state running # varnishadm backend.list Backend name Admin Probe Health Last change boot.default healthy 0/0 healthy Fri, 10 Oct 2025 15:38:03 GMT # varnishadm banner ----------------------------- Varnish Cache CLI 1.0 ----------------------------- Linux,6.6.105-server-1.mga9,x86_64,-jnone,-sfile,-sdefault,-hcritbit varnish-7.7.3 revision 6884b75af9c9bdb2c9b6e2aa464a435e42cb4931 Type 'help' for command list. Type 'quit' to close CLI session. That is good to go for varnish. Coming back for lighttpd
CC: (none) => herman.viaene
Checked bug 11662 and 30912. [root@mach3 ~]# systemctl status -l httpd ○ httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; preset: disabled) Active: inactive (dead) [root@mach3 ~]# systemctl start lighttpd [root@mach3 ~]# systemctl status -l lighttpd ○ lighttpd.service - Lightning Fast Webserver With Light System Requirements Loaded: loaded (/usr/lib/systemd/system/lighttpd.service; disabled; preset: disabled) Active: inactive (dead) Oct 10 17:46:38 mach3.hviaene.thuis systemd[1]: Starting lighttpd.service... Oct 10 17:46:38 mach3.hviaene.thuis lighttpd[108992]: Syntax OK Oct 10 17:46:38 mach3.hviaene.thuis systemd[1]: Started lighttpd.service. Oct 10 17:46:38 mach3.hviaene.thuis lighttpd-angel[108994]: 2025-10-10 17:46:38: (server.c.1802) can't find groupname lighttpd Oct 10 17:46:38 mach3.hviaene.thuis lighttpd-angel[108993]: lighttpd-angel.c.107: child (pid=108994) exited normally with exitcode: 255 Oct 10 17:46:38 mach3.hviaene.thuis systemd[1]: lighttpd.service: Deactivated successfully. Something missing? There is indeed no group lighttpd in the system.
Indeed lighttpd now runs as a specific user instead of the apache user. This also affected logging which requires the same. Good thing QA is around to catch this. Added user group creation to package and modified owner user for logging permissions. Updated file list. Updated lighttpd packages in core/updates_testing: ======================== lighttpd-1.4.80-1.1.mga9 lighttpd-mod_ajp13-1.4.80-1.1.mga9 lighttpd-mod_auth-1.4.80-1.1.mga9 lighttpd-mod_authn_file-1.4.80-1.1.mga9 lighttpd-mod_authn_ldap-1.4.80-1.1.mga9 lighttpd-mod_deflate-1.4.80-1.1.mga9 lighttpd-mod_magnet-1.4.80-1.1.mga9 lighttpd-mod_webdav-1.4.80-1.1.mga9 from lighttpd-1.4.80-1.1.mga9.src.rpm
Hi Mike, I just tried new version, still not right. this is what I installed: The following 7 packages are going to be installed: - lighttpd-1.4.80-1.1.mga9.x86_64 - lighttpd-mod_auth-1.4.80-1.1.mga9.x86_64 - lighttpd-mod_authn_file-1.4.80-1.1.mga9.x86_64 - lighttpd-mod_deflate-1.4.80-1.1.mga9.x86_64 - lighttpd-mod_magnet-1.4.80-1.1.mga9.x86_64 - lighttpd-mod_webdav-1.4.80-1.1.mga9.x86_64 - webserver-base-2.0-16.mga9.noarch I started services and noticed that they are running as root except for a couple running with my ID: $ ps -ef | grep ligh root 871 1 0 20:09 ? 00:00:00 /usr/sbin/lighttpd-angel -D -f /etc/lighttpd/lighttpd.conf lighttpd 873 871 0 20:09 ? 00:00:00 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf root 885 1 0 20:09 ? 00:00:00 /usr/sbin/lightdm root 894 885 3 20:09 tty1 00:00:11 /usr/libexec/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt1 -novtswitch root 1286 885 0 20:09 ? 00:00:00 lightdm --session-child 13 20 brian 1675 1322 0 20:09 ? 00:00:00 light-locker Hope this helps. Also in systemctl status lighttpd I see: $ systemctl status lighttpd ● lighttpd.service - Lightning Fast Webserver With Light System Requirements Loaded: loaded (/usr/lib/systemd/system/lighttpd.service; enabled; preset:> Active: active (running) since Sat 2025-10-11 20:09:03 CDT; 4min 44s ago Process: 864 ExecStartPre=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.c> Main PID: 871 (lighttpd-angel) Tasks: 2 (limit: 4662) Memory: 1.5M CPU: 42ms CGroup: /system.slice/lighttpd.service ├─871 /usr/sbin/lighttpd-angel -D -f /etc/lighttpd/lighttpd.conf └─873 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf Warning: some journal files were not opened due to insufficient permissions.
CC: (none) => brtians1
Hmm... strange. I'm not seeing that. [mrambo@baggins x86_64]$ rpm -qa | grep lightt lighttpd-1.4.80-1.1.mga9 lighttpd-mod_magnet-1.4.80-1.1.mga9 lighttpd-mod_webdav-1.4.80-1.1.mga9 lighttpd-mod_authn_file-1.4.80-1.1.mga9 lighttpd-mod_auth-1.4.80-1.1.mga9 lighttpd-mod_deflate-1.4.80-1.1.mga9 [mrambo@baggins x86_64]$ sudo systemctl start lighttpd [mrambo@baggins x86_64]$ systemctl status lighttpd ● lighttpd.service - Lightning Fast Webserver With Light System Requirements Loaded: loaded (/usr/lib/systemd/system/lighttpd.service; disabled; preset: disabled) Active: active (running) since Sun 2025-10-12 12:21:50 EDT; 38s ago Process: 2956589 ExecStartPre=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS) Main PID: 2956590 (lighttpd-angel) Tasks: 2 (limit: 19102) Memory: 808.0K CPU: 8ms CGroup: /system.slice/lighttpd.service ├─2956590 /usr/sbin/lighttpd-angel -D -f /etc/lighttpd/lighttpd.conf └─2956591 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf Oct 12 12:21:50 baggins systemd[1]: Starting lighttpd.service... Oct 12 12:21:50 baggins lighttpd[2956589]: Syntax OK Oct 12 12:21:50 baggins systemd[1]: Started lighttpd.service. Please check these things on your installation. 1) did the user and group get created? [mrambo@baggins x86_64]$ grep lightt /etc/group lighttpd:x:950: [mrambo@baggins x86_64]$ grep lightt /etc/passwd lighttpd:x:951:950:system user for lighttpd:/var/lib/lighttpd:/sbin/nologin 2) did the log directory get created with correct ownership? [mrambo@baggins x86_64]$ ll /var/log | grep lightt drwxr-x--- 2 lighttpd lighttpd 4096 Oct 10 19:20 lighttpd/ 3) did the log files themselves get created with correct ownership? [mrambo@baggins x86_64]$ sudo ls -l /var/log/lighttpd/ total 4 -rw-r--r-- 1 lighttpd lighttpd 0 Oct 10 19:17 access.log -rw-r--r-- 1 lighttpd lighttpd 640 Oct 12 12:21 error.log
group and user created within /var/log/lighttpd I see: ls -l total 32 -rw------- 1 root root 5332 Oct 12 17:07 lightdm.log -rw------- 1 root root 6519 Oct 11 20:22 lightdm.log.old -rw------- 1 root root 3713 Oct 12 17:07 seat0-greeter.log -rw------- 1 root root 4061 Oct 11 20:09 seat0-greeter.log.old -rw------- 1 root root 1011 Oct 12 17:07 x-0.log -rw------- 1 root root 2213 Oct 11 20:22 x-0.log.old who knows, maybe doing systemctl enable lighttpd systemctl start lighttpd as root messed it up. Let me try another build. It's just a VM.
Oops wrong folder However, I did another build on a fresh instance. The server seems to be working. [root@vbox lighttpd]# pwd /var/log/lighttpd [root@vbox lighttpd]# ls -ltr total 8 -rw-r--r-- 1 lighttpd lighttpd 70 Oct 12 18:42 error.log -rw-r--r-- 1 lighttpd lighttpd 333 Oct 12 18:43 access.log [root@vbox lighttpd]# [root@vbox log]# systemctl status lighttpd ● lighttpd.service - Lightning Fast Webserver With Light System Requirements Loaded: loaded (/usr/lib/systemd/system/lighttpd.service; disabled; preset> Active: active (running) since Sun 2025-10-12 18:42:18 CDT; 5min ago Process: 2468 ExecStartPre=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.> Main PID: 2470 (lighttpd-angel) Tasks: 2 (limit: 6088) Memory: 1.3M CPU: 18ms CGroup: /system.slice/lighttpd.service ├─2470 /usr/sbin/lighttpd-angel -D -f /etc/lighttpd/lighttpd.conf └─2471 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf Oct 12 18:42:18 vbox systemd[1]: Starting lighttpd.service... Oct 12 18:42:18 vbox lighttpd[2468]: Syntax OK Oct 12 18:42:18 vbox systemd[1]: Started lighttpd.service. # ps -ef | grep light root 1194 1 0 18:41 ? 00:00:00 /usr/sbin/lightdm root 1215 1194 2 18:41 tty1 00:00:09 /usr/libexec/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt1 -novtswitch root 1494 1194 0 18:41 ? 00:00:00 lightdm --session-child 13 20 brian 1830 1577 0 18:41 ? 00:00:00 light-locker root 2470 1 0 18:42 ? 00:00:00 /usr/sbin/lighttpd-angel -D -f /etc/lighttpd/lighttpd.conf lighttpd 2471 2470 0 18:42 ? 00:00:00 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf It all seems to be working.
Yes, this last time you got the same results I was getting. The 'grep light' on the last cmd threw me off because it picked up output from both lightdm and lighttpd and I didn't notice it. Those are very different services. I think you might have been in the wrong directory in comment #11. Those logs look like they are all lightdm related. My system only has access.log and error.log in the /var/log/lighttpd directory.
I was in the wrong folder. <head slap> after I posted. Noticed it on second attempt. Sorry about that. I think lighttpd is ready.
Removed everything lighttpd, checked /etc and /var/log, all lighttpd gone.Installed newer version, no installation issues. # systemctl start lighttpd # systemctl status -l lighttpd ● lighttpd.service - Lightning Fast Webserver With Light System Requirements Loaded: loaded (/usr/lib/systemd/system/lighttpd.service; disabled; preset: disabled) Active: active (running) since Mon 2025-10-13 10:26:15 CEST; 7s ago Process: 14567 ExecStartPre=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS) Main PID: 14568 (lighttpd-angel) Tasks: 2 (limit: 8805) Memory: 844.0K CPU: 39ms CGroup: /system.slice/lighttpd.service ├─14568 /usr/sbin/lighttpd-angel -D -f /etc/lighttpd/lighttpd.conf └─14569 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf Oct 13 10:26:15 mach3.hviaene.thuis systemd[1]: Starting lighttpd.service... Oct 13 10:26:15 mach3.hviaene.thuis lighttpd[14567]: Syntax OK Oct 13 10:26:15 mach3.hviaene.thuis systemd[1]: Started lighttpd.service. But pointing to http://localhost returns error 404. Made sure firewall is not blocking.
# systemctl enable lighttpd Created symlink /etc/systemd/system/multi-user.target.wants/lighttpd.service → /usr/lib/systemd/system/lighttpd.service. [root@mach3 ~]# systemctl status -l lighttpd ● lighttpd.service - Lightning Fast Webserver With Light System Requirements Loaded: loaded (/usr/lib/systemd/system/lighttpd.service; enabled; preset: disabled) Active: active (running) since Mon 2025-10-13 10:48:10 CEST; 9min ago Main PID: 16689 (lighttpd-angel) Tasks: 2 (limit: 8805) Memory: 828.0K CPU: 83ms CGroup: /system.slice/lighttpd.service ├─16689 /usr/sbin/lighttpd-angel -D -f /etc/lighttpd/lighttpd.conf └─16690 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf Oct 13 10:48:10 mach3.hviaene.thuis systemd[1]: Starting lighttpd.service... Oct 13 10:48:10 mach3.hviaene.thuis lighttpd[16687]: Syntax OK Oct 13 10:48:10 mach3.hviaene.thuis systemd[1]: Started lighttpd.service. [root@mach3 ~]# systemctl restart lighttpd [root@mach3 ~]# systemctl status -l lighttpd ● lighttpd.service - Lightning Fast Webserver With Light System Requirements Loaded: loaded (/usr/lib/systemd/system/lighttpd.service; enabled; preset: disabled) Active: active (running) since Mon 2025-10-13 10:57:42 CEST; 4s ago Process: 17475 ExecStartPre=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS) Main PID: 17477 (lighttpd-angel) Tasks: 2 (limit: 8805) Memory: 884.0K CPU: 39ms CGroup: /system.slice/lighttpd.service ├─17477 /usr/sbin/lighttpd-angel -D -f /etc/lighttpd/lighttpd.conf └─17478 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf Oct 13 10:57:42 mach3.hviaene.thuis systemd[1]: Starting lighttpd.service... Oct 13 10:57:42 mach3.hviaene.thuis lighttpd[17475]: Syntax OK Oct 13 10:57:42 mach3.hviaene.thuis systemd[1]: Started lighttpd.service. Still 404.
Mageia 9, x64 I have been having trouble just lately trying to access QA packages via qarepo. Tried coffee this time and packages* not found. It is actually months since a repository was available. Waited until the new servers business was settled but still no joy.
CC: (none) => tarazed25
Should have checked the later entries here. The repository holds the 1.1 packages as tested by Mike, Herman etc. Sorry for the noise.
Sadly I followed another packagers actions on the cauldron package figuring I need not re-invent the wheel. Turns out I should have gotten involved in wheel making. Added back a patch that set the default document root and a couple of other parameters for the server service. Updated file list. Updated lighttpd packages in core/updates_testing: ======================== lighttpd-1.4.80-1.2.mga9 lighttpd-mod_ajp13-1.4.80-1.2.mga9 lighttpd-mod_auth-1.4.80-1.2.mga9 lighttpd-mod_authn_file-1.4.80-1.2.mga9 lighttpd-mod_authn_ldap-1.4.80-1.2.mga9 lighttpd-mod_deflate-1.4.80-1.2.mga9 lighttpd-mod_magnet-1.4.80-1.2.mga9 lighttpd-mod_webdav-1.4.80-1.2.mga9 from lighttpd-1.4.80-1.2.mga9.src.rpm (Basic web service does work for me now. If nothing more is found broken by QA I'll be sending an update for cauldron soon because it is broken in the same ways.)
Keywords: (none) => advisory
YESSSSS !!!! It works.
Whiteboard: (none) => MGA9-64-OK
Validating.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
The new lighttpd package has broken my existing lighttpd configuration: Oct 14 09:53:31 localhost systemd[1]: Starting lighttpd.service... Oct 14 09:53:31 localhost lighttpd[114097]: Syntax OK Oct 14 09:53:31 localhost systemd[1]: Started lighttpd.service. Oct 14 09:53:31 localhost lighttpd-angel[114099]: 2025-10-14 09:53:31: (mod_openssl.c.3766) ssl.cipher-list is deprecated. Please prefer lighttpd secure TLS defaults, or use ssl.openssl.ssl-conf-cmd "CipherString" to set custom cipher list. Oct 14 09:53:31 localhost lighttpd-angel[114099]: 2025-10-14 09:53:31: (configfile.c.1778) opening errorlog '/var/log/lighttpd/error.log' failed: Permission denied Oct 14 09:53:31 localhost lighttpd-angel[114099]: 2025-10-14 09:53:31: (server.c.1967) Opening errorlog failed. Going down. Oct 14 09:53:31 localhost lighttpd-angel[114098]: lighttpd-angel.c.107: child (pid=114099) exited normally with exitcode: 255 Oct 14 09:53:31 localhost systemd[1]: lighttpd.service: Deactivated successfully. This makes sense because the directory /var/log/lighttpd/ is now owned by the user lighttpd whereas it used to be owned by apache. Since the existing configuration files were not replaced and specify the apache user, it now refuses to start. This backwards-incompatible change should be reverted.
CC: (none) => dan
I guess your logs must be still owned by apache. Whoever wrote the spec has a clause in %post that is supposed to ensure log ownership remains correct across upgrades. It would appear it doesn't work as was expected. It is upstream that made the decision to use their own user, which I tried to accommodate. But I think I remember seeing where that could be changed so I'll try to revert it all to use the apache user.
I think the test in the %postinstall scriptlet is wrong: grep '^server.username = "lighttpd"' should really be: grep '^server.username = "apache"' but this is a) brittle (the user could have moved the user setting to a different config file in /etc/lighttpd/conf.d/), and b) disruptive, as an upgrade within a major release should not make any such fundamental change to a package. Policy is that the package version shouldn't even have been bumped at all but rather the old package should have been patched. I don't recall any discussion about an exception to this policy for this package. There are other major assumptions elsewhere in the system about the lighttpd user besides the logs ownership, starting with the ownership of files to serve (/var/www/ or elsewhere), access to databases, ownership of unix sockets to various daemons, ownership of scripts to analyze logs, access to authencation systems and cgi scripts, etc. Changing the default user may be acceptable in a major distro release, but only with an accompanying entry in the release notes telling the user about it and how to conform or revert. Reverting to apache is definitely the right solution for mga9.
On reflection, that specific part of apache/lighttpd part of the script isn't at fault; it's that the script only works for a narrow case. If grep '^server.username = "lighttpd"' is true, then either 1) the user has changed the old config script username from apache to lighttpd, or 2) the user didn't change the old config script and it was wholesale replaced with the new one. In the case of 1), the logfile ownership already would have been fixed by the user at the same time as the config file was modified, so chown isn't needed (but is probably harmless). For 2), is is needed since there could be log files owned by apache. But the script doesn't take into account my situation 3) where username=apache but the user edited the config file so that it isn't replaced in the upgrade. In that case, the script should "chown apache /var/log/lighttpd/" (and NOT any subdirectories), which is who owned it in the past. This chown should also be done to both /var/lib/lighttpd and /var/lib/lighttpd/sockets revert the ownership change there as well. There are many more than these 3 variants, though, so an automatic upgrade of user to lighttpd is effectively impossible in the remaining cases. For example, 4) would be the user didn't change lighttpd.conf (so the user used to be apache) so rpm upgrades it so the user is now lighttpd. However, other config files, cgi scripts, cron jobs, etc. (as explained in comment 24) still assume apache and the web server fails to run. This is all just needed for Cauldron since the mga9 update should remain using apache everywhere.
Part of the problem is that I overlooked that the file they check for the configured username in has changed. The filename that contains server.username is now /etc/lighttpd/lighttpd.annotated.conf instead of /etc/lighttpd/lighttpd.conf. Because I failed to notice that change the code in %post did not update the ownership on the log files as anticipated. But I'll still change it all back to using apache anyway and once I can test and try to make sure it does everything right I'll submit new packages. As I was thinking about it I don't see why to not do the same thing for Cauldron since we use the apache username almost universally for web related stuff afaik. Let me know if you think otherwise. Thanks for your patience and effort.
Keywords: validated_update => (none)
Besides lighttpd, I see only apache and nginx among popular webservers available in Mageia, and none of them have maintainers. I don't know what user nginx runs under right now, but configuring all the web servers to run as apache does make it much easier to supply packages that work with any web server. It seems unlikely that someone would want to run more than one webserver on a machine and if so, find it necessary to also separate them with separate users. My vote would be to stick with apache everywhere, including in Cauldron.
I have updated both cauldron and Mageia 9 to use the apache user and update all log directories and files. I loosened the check in %post to try to ensure that if the apache is user is in play those logs and files are always fixed. My tests were successful but they were only with the basic installation. Updated file list. Updated lighttpd packages in core/updates_testing: ======================== lighttpd-1.4.80-1.3.mga9 lighttpd-mod_ajp13-1.4.80-1.3.mga9 lighttpd-mod_auth-1.4.80-1.3.mga9 lighttpd-mod_authn_file-1.4.80-1.3.mga9 lighttpd-mod_authn_ldap-1.4.80-1.3.mga9 lighttpd-mod_deflate-1.4.80-1.3.mga9 lighttpd-mod_magnet-1.4.80-1.3.mga9 lighttpd-mod_webdav-1.4.80-1.3.mga9 from lighttpd-1.4.80-1.3.mga9.src.rpm
Whiteboard: MGA9-64-OK => (none)
Advisory updated
Just my 2c. I think putting all kinds of webservers under one user is a bad idea. Keep separate things separate, so if and when something goes wrong with the apache user (security concerns) not all the rest can be affected.
Version 1.3 works OK, keeping in mind I removed the previous version after the test yesterday.
MGA9-64, Xfce, VboxVM (New install) The following 8 packages are going to be installed: - lighttpd-1.4.80-1.3.mga9.x86_64 - lighttpd-mod_ajp13-1.4.80-1.3.mga9.x86_64 - lighttpd-mod_auth-1.4.80-1.3.mga9.x86_64 - lighttpd-mod_authn_file-1.4.80-1.3.mga9.x86_64 - lighttpd-mod_deflate-1.4.80-1.3.mga9.x86_64 - lighttpd-mod_magnet-1.4.80-1.3.mga9.x86_64 - lighttpd-mod_webdav-1.4.80-1.3.mga9.x86_64 - webserver-base-2.0-16.mga9.noarch 1.4MB of additional disk space will be used. -- rebooted - noticed lighttpd service didn't get set to autostart. This can be a mistake or a feature pending on your opinion. - started service - got the "it works" message $ ps -ef | grep lighttp root 2458 1 0 08:21 ? 00:00:00 /usr/sbin/lighttpd-angel -D -f /etc/lighttpd/lighttpd.conf apache 2459 2458 0 08:21 ? 00:00:00 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf works for me
Herman and Brian make a clean install, but can some of you test uodating current version of lighttpd packages? Thank you
lighttpd-1.4.80-1.3.mga9 was a transparent upgrade for me now. I think the chown part of the %postinstall script can be completely deleted. Now that the username is once again apache as before, there's no reason to change the ownership of people's files. > Keep separate things separate, so if and when something goes wrong with the > apache user (security concerns) not all the rest can be affected. I think it's very unlikely that someone will run two different webservers on the same host at the same time.
@Dan I can think of some scenarios where an administrator would like (or have to) run two different webservers at the same time. Depending on other factors those could end up on the same host. But if you want, let us keep this conversation private, not on this bug. I take katnateks demand. I'll be back.
Installed 1.4.69 and run it. It works. Installed 1.4.80-1.3 over it, it still works. Stpopped lighttp and started again. Works OK.
I think to avoid more churn on the mga9 pkg I'll just leave it as it is. Hopefully 10 will be out soonish anyway. I'll remove the chown in %post on the Cauldron pkg and resubmit. That code as been in the spec since the beginning of the package but I didn't see any comments as to why. We'll hope for the best and we can always add it back anyway. This package was a learning experience for me. I've re-added the validated_update tag I removed earlier since everyone seems to agree that it finally works right. Thanks to everyone who helped.
Keywords: (none) => validated_update
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2025-0239.html
Status: REOPENED => RESOLVEDResolution: (none) => FIXED