Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#988236: roundcube-core: Install breaks lighttpd if fastcgi-php-fpm module is active
31 views
Skip to first unread message
Kurt Fitzner
May 8, 2021, 8:10:03 AM5/8/21
to
Package: roundcube
Version: 1.4.11+dfsg.1-3
Severity: important
Dear Maintainer,
If roundcube is installed on a system with lighttpd, then the installer
attempts to activate lighttpd's php module fastcgi-php. However, If the
module fastcgi-php-fpm is already active, then having them both active breaks
lighttpd and the subsequent force-reload that the installer attemmpts on
lighttpd causes it to fail.
On systems with lighttpd, the installer should detect if fastcgi-php-fpm is
already active and if so, should not subsequently activate fastcgi-php.
I'm not sure this shouldn't have a higher severity, but I'll let you judge.
Thanks,
Kurt Fitzner
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages roundcube-core depends on:
ii dbconfig-common 2.0.19
ii debconf [debconf-2.0] 1.5.75
ii dpkg 1.20.9
ii libjs-bootstrap4 4.5.2+dfsg1-6
ii libjs-codemirror 5.59.2+~cs0.23.109-1
ii libjs-jquery 3.5.1+dfsg+~3.5.5-7
ii libjs-jquery-minicolors 2.2.6+dfsg-4
ii libjs-jquery-ui 1.12.1+dfsg-8
ii libjs-jstimezonedetect 1.0.6-5
ii libmagic1 1:5.39-3
ii php 2:7.4+76
ii php-auth-sasl 1.1.0-1
ii php-cli 2:7.4+76
ii php-common 2:76
ii php-intl 2:7.4+76
ii php-mail-mime 1.10.10-1
ii php-masterminds-html5 2.7.4+dfsg-2
ii php-mbstring 2:7.4+76
ii php-net-sieve 1.4.4-2
ii php-net-smtp 1.9.0-1
ii php-net-socket 1.2.2-2
ii php-pear 1:1.10.12+submodules+notgz+20210212-1
ii php7.4 [php] 7.4.15-5+deb11u1
ii php7.4-cli [php-cli] 7.4.15-5+deb11u1
ii php7.4-intl [php-intl] 7.4.15-5+deb11u1
ii php7.4-json [php-json] 7.4.15-5+deb11u1
ii php7.4-mbstring [php-mbstring] 7.4.15-5+deb11u1
ii roundcube-mysql 1.4.11+dfsg.1-3
ii ucf 3.0043
Versions of packages roundcube-core recommends:
ii lighttpd [httpd-cgi] 1.4.59-1
ii php-fpm 2:7.4+76
ii php-gd 2:7.4+76
ii php-pspell 2:7.4+76
ii php7.4-fpm [php-fpm] 7.4.15-5+deb11u1
ii php7.4-gd [php-gd] 7.4.15-5+deb11u1
ii php7.4-pspell [php-pspell] 7.4.15-5+deb11u1
ii spawn-fcgi 1.6.4-2
Versions of packages roundcube-core suggests:
pn php-crypt-gpg <none>
pn php-mkopinsky-zxcvbn-php <none>
pn php-net-ldap3 <none>
ii roundcube-plugins 1.4.11+dfsg.1-3
Versions of packages roundcube depends on:
ii dpkg 1.20.9
-- debconf information:
roundcube/upgrade-error: abort
roundcube/install-error: abort
roundcube/dbconfig-remove: true
roundcube/remote/newhost:
roundcube/remove-error: abort
roundcube/mysql/method: Unix socket
roundcube/purge: false
roundcube/remote/host: localhost
roundcube/passwords-do-not-match:
roundcube/language: en_CA
roundcube/internal/skip-preseed: false
* roundcube/database-type: mysql
roundcube/dbconfig-reinstall: false
roundcube/restart-webserver: true
roundcube/remote/port:
roundcube/hosts:
* roundcube/mysql/admin-user: root
roundcube/reconfigure-webserver: apache2, lighttpd
roundcube/db/app-user: roundcube@localhost
roundcube/upgrade-backup: true
roundcube/internal/reconfiguring: false
roundcube/mysql/authplugin: default
roundcube/db/dbname: roundcube
roundcube/missing-db-package-error: abort
* roundcube/dbconfig-install: true
roundcube/dbconfig-upgrade: true
Version: 1.4.11+dfsg.1-3
Severity: important
Dear Maintainer,
If roundcube is installed on a system with lighttpd, then the installer
attempts to activate lighttpd's php module fastcgi-php. However, If the
module fastcgi-php-fpm is already active, then having them both active breaks
lighttpd and the subsequent force-reload that the installer attemmpts on
lighttpd causes it to fail.
On systems with lighttpd, the installer should detect if fastcgi-php-fpm is
already active and if so, should not subsequently activate fastcgi-php.
I'm not sure this shouldn't have a higher severity, but I'll let you judge.
Thanks,
Kurt Fitzner
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages roundcube-core depends on:
ii dbconfig-common 2.0.19
ii debconf [debconf-2.0] 1.5.75
ii dpkg 1.20.9
ii libjs-bootstrap4 4.5.2+dfsg1-6
ii libjs-codemirror 5.59.2+~cs0.23.109-1
ii libjs-jquery 3.5.1+dfsg+~3.5.5-7
ii libjs-jquery-minicolors 2.2.6+dfsg-4
ii libjs-jquery-ui 1.12.1+dfsg-8
ii libjs-jstimezonedetect 1.0.6-5
ii libmagic1 1:5.39-3
ii php 2:7.4+76
ii php-auth-sasl 1.1.0-1
ii php-cli 2:7.4+76
ii php-common 2:76
ii php-intl 2:7.4+76
ii php-mail-mime 1.10.10-1
ii php-masterminds-html5 2.7.4+dfsg-2
ii php-mbstring 2:7.4+76
ii php-net-sieve 1.4.4-2
ii php-net-smtp 1.9.0-1
ii php-net-socket 1.2.2-2
ii php-pear 1:1.10.12+submodules+notgz+20210212-1
ii php7.4 [php] 7.4.15-5+deb11u1
ii php7.4-cli [php-cli] 7.4.15-5+deb11u1
ii php7.4-intl [php-intl] 7.4.15-5+deb11u1
ii php7.4-json [php-json] 7.4.15-5+deb11u1
ii php7.4-mbstring [php-mbstring] 7.4.15-5+deb11u1
ii roundcube-mysql 1.4.11+dfsg.1-3
ii ucf 3.0043
Versions of packages roundcube-core recommends:
ii lighttpd [httpd-cgi] 1.4.59-1
ii php-fpm 2:7.4+76
ii php-gd 2:7.4+76
ii php-pspell 2:7.4+76
ii php7.4-fpm [php-fpm] 7.4.15-5+deb11u1
ii php7.4-gd [php-gd] 7.4.15-5+deb11u1
ii php7.4-pspell [php-pspell] 7.4.15-5+deb11u1
ii spawn-fcgi 1.6.4-2
Versions of packages roundcube-core suggests:
pn php-crypt-gpg <none>
pn php-mkopinsky-zxcvbn-php <none>
pn php-net-ldap3 <none>
ii roundcube-plugins 1.4.11+dfsg.1-3
Versions of packages roundcube depends on:
ii dpkg 1.20.9
-- debconf information:
roundcube/upgrade-error: abort
roundcube/install-error: abort
roundcube/dbconfig-remove: true
roundcube/remote/newhost:
roundcube/remove-error: abort
roundcube/mysql/method: Unix socket
roundcube/purge: false
roundcube/remote/host: localhost
roundcube/passwords-do-not-match:
roundcube/language: en_CA
roundcube/internal/skip-preseed: false
* roundcube/database-type: mysql
roundcube/dbconfig-reinstall: false
roundcube/restart-webserver: true
roundcube/remote/port:
roundcube/hosts:
* roundcube/mysql/admin-user: root
roundcube/reconfigure-webserver: apache2, lighttpd
roundcube/db/app-user: roundcube@localhost
roundcube/upgrade-backup: true
roundcube/internal/reconfiguring: false
roundcube/mysql/authplugin: default
roundcube/db/dbname: roundcube
roundcube/missing-db-package-error: abort
* roundcube/dbconfig-install: true
roundcube/dbconfig-upgrade: true
Guilhem Moulin
May 9, 2021, 12:00:03 PM5/9/21
to
Control: reassign -1 roundcube-core 1.4.11+dfsg.1-3
On Sat, 08 May 2021 at 09:07:26 -0300, Kurt Fitzner via Pkg-roundcube-maintainers wrote:
> On systems with lighttpd, the installer should detect if fastcgi-php-fpm is
> already active and if so, should not subsequently activate fastcgi-php.
Thanks, this is related to #898040.
> I'm not sure this shouldn't have a higher severity, but I'll let you judge.
Like #898040 I don't think this warrants RC severity. But should a fix
make it in time it's definitely suitable to request an unblock request.
That said I'm not sure to how to fix this. I'm not really familiar with
lighttpd but I don't see a way to list enabled modules other than
looking in /etc/lighttpd/conf-enabled which I'm not really keen to do.
In fact I'm not sure it's a roundcube-core issue in the first place:
`lighty-enable-mod fastcgi-php` arguably should do some sanity check,
otherwise what's the advantage compared to manually creating symlinks?
In a minimal sid chroot:
$ apt install -y lighttpd php-fpm
[…]
$ service lighttpd start
Starting web server: lighttpd.
$ lighty-enable-mod fastcgi-php-fpm
Met dependency: fastcgi
Enabling fastcgi-php-fpm: ok
Enabling fastcgi: ok
Run "service lighttpd force-reload" to enable changes
$ service lighttpd force-reload
Reloading web server configuration: lighttpd.
$ lighty-enable-mod fastcgi-php
Enabling fastcgi-php: ok
Run "service lighttpd force-reload" to enable changes
$ echo $?
0
$ service lighttpd force-reload
Duplicate array-key '.php'
2021-05-09 12:52:17: configfile.c.1970) source: /etc/lighttpd/conf-enabled/15-fastcgi-php.conf line: 21 pos: 1 parser failed somehow near here: (EOL)
2021-05-09 12:52:17: configfile.c.1970) source: /etc/lighttpd/lighttpd.conf line: 51 pos: 15 parser failed somehow near here: (EOL)
If these modules are incompatible lighty-enable-mod(1) should ideally
give a hint. I see module snippets have a way to express dependencies,
but unfortunately not conflicts.
lighttpd maintainers (CC'ed): What's the best way to express “enable
fastcgi-php (or fastcgi-php-fpm) unless fastcgi.server already has a
handler for .php”? Or if that's not possible “enable fastcgi-php unless
fastcgi-php-fpm is already enabled”? Simply expand
/etc/lighttpd/conf-enabled/*-fastcgi-php-fpm.conf and check for a match,
or is there a more robust way?
Thanks!
--
Guilhem.
On Sat, 08 May 2021 at 09:07:26 -0300, Kurt Fitzner via Pkg-roundcube-maintainers wrote:
> On systems with lighttpd, the installer should detect if fastcgi-php-fpm is
> already active and if so, should not subsequently activate fastcgi-php.
> I'm not sure this shouldn't have a higher severity, but I'll let you judge.
make it in time it's definitely suitable to request an unblock request.
That said I'm not sure to how to fix this. I'm not really familiar with
lighttpd but I don't see a way to list enabled modules other than
looking in /etc/lighttpd/conf-enabled which I'm not really keen to do.
In fact I'm not sure it's a roundcube-core issue in the first place:
`lighty-enable-mod fastcgi-php` arguably should do some sanity check,
otherwise what's the advantage compared to manually creating symlinks?
In a minimal sid chroot:
$ apt install -y lighttpd php-fpm
[…]
$ service lighttpd start
Starting web server: lighttpd.
$ lighty-enable-mod fastcgi-php-fpm
Met dependency: fastcgi
Enabling fastcgi-php-fpm: ok
Enabling fastcgi: ok
Run "service lighttpd force-reload" to enable changes
$ service lighttpd force-reload
Reloading web server configuration: lighttpd.
$ lighty-enable-mod fastcgi-php
Enabling fastcgi-php: ok
Run "service lighttpd force-reload" to enable changes
$ echo $?
0
$ service lighttpd force-reload
Duplicate array-key '.php'
2021-05-09 12:52:17: configfile.c.1970) source: /etc/lighttpd/conf-enabled/15-fastcgi-php.conf line: 21 pos: 1 parser failed somehow near here: (EOL)
2021-05-09 12:52:17: configfile.c.1970) source: /etc/lighttpd/lighttpd.conf line: 51 pos: 15 parser failed somehow near here: (EOL)
If these modules are incompatible lighty-enable-mod(1) should ideally
give a hint. I see module snippets have a way to express dependencies,
but unfortunately not conflicts.
lighttpd maintainers (CC'ed): What's the best way to express “enable
fastcgi-php (or fastcgi-php-fpm) unless fastcgi.server already has a
handler for .php”? Or if that's not possible “enable fastcgi-php unless
fastcgi-php-fpm is already enabled”? Simply expand
/etc/lighttpd/conf-enabled/*-fastcgi-php-fpm.conf and check for a match,
or is there a more robust way?
Thanks!
--
Guilhem.
Guilhem Moulin
May 10, 2021, 2:50:03 PM5/10/21
to
On Sun, 09 May 2021 at 17:48:28 +0200, Guilhem Moulin wrote:
> That said I'm not sure to how to fix this. I'm not really familiar with
> lighttpd but I don't see a way to list enabled modules other than
> looking in /etc/lighttpd/conf-enabled which I'm not really keen to do.
> […]
> That said I'm not sure to how to fix this. I'm not really familiar with
> lighttpd but I don't see a way to list enabled modules other than
> looking in /etc/lighttpd/conf-enabled which I'm not really keen to do.
> lighttpd maintainers (CC'ed): What's the best way to express “enable
> fastcgi-php (or fastcgi-php-fpm) unless fastcgi.server already has a
> handler for .php”? Or if that's not possible “enable fastcgi-php unless
> fastcgi-php-fpm is already enabled”? Simply expand
> /etc/lighttpd/conf-enabled/*-fastcgi-php-fpm.conf and check for a match,
> or is there a more robust way?
Here is a workaround that seems to work:
> fastcgi-php (or fastcgi-php-fpm) unless fastcgi.server already has a
> handler for .php”? Or if that's not possible “enable fastcgi-php unless
> fastcgi-php-fpm is already enabled”? Simply expand
> /etc/lighttpd/conf-enabled/*-fastcgi-php-fpm.conf and check for a match,
> or is there a more robust way?
https://salsa.debian.org/roundcube-team/roundcube/-/commit/4638e975366c980280bd3b63020eaee45df88f52
lighttpd maintainers: is it acceptable to look for matches in
/etc/lighttpd/conf-enabled/*-fastcgi-php.conf and …/*-fastcgi-php-*.conf?
The aim would be to ship a fix in Bullseye; we can always refine the
logic during the Bookworm release cycle.
Cheers,
--
Guilhem.
Kurt Fitzner
May 10, 2021, 10:40:04 PM5/10/21
to
For what it's worth, I concur with this solution. The lighty-enable-mod
and -disable-mod helpers are an abstraction layer that certainly
originated with Debian and may still be unique to Debian (et al). They
came into being sometime in 2005-ish. While, as an abstraction, its
purpose is to hide the underlying config file mechanics, I can't see the
underlying mechanism changing any time soon if it hasn't in the last 16
years.
Upstream lighty has never adopted this abstraction, so I can't see it
worth the trouble to expand on it now.
I think you've lighted (hah) upon the best solution here.
and -disable-mod helpers are an abstraction layer that certainly
originated with Debian and may still be unique to Debian (et al). They
came into being sometime in 2005-ish. While, as an abstraction, its
purpose is to hide the underlying config file mechanics, I can't see the
underlying mechanism changing any time soon if it hasn't in the last 16
years.
Upstream lighty has never adopted this abstraction, so I can't see it
worth the trouble to expand on it now.
I think you've lighted (hah) upon the best solution here.
Guilhem Moulin
May 11, 2021, 7:40:03 AM5/11/21
to
On Mon, 10 May 2021 at 23:19:51 -0300, Kurt Fitzner via Pkg-roundcube-maintainers wrote:
> I think you've lighted (hah) upon the best solution here.
I don't really like it as it makes assumptions about another namespace/
> I think you've lighted (hah) upon the best solution here.
interface. There is also no guaranty that fastcgi handlers for .php
match that glob (lighttpd <1.4.55-2 doesn't ship anything for PHP-FPM,
and a user could very well have hand-crafted 00-php-fpm.conf).
24fade6 might limit the risk of ending up with a broken configuration,
but in my eyes it's more a workaround than a fix.
--
Guilhem.
Guilhem Moulin
May 14, 2021, 8:00:04 AM5/14/21
to
for an unblock request.
Given #898040, #988236 and #988282 I believe the vast majority of
roundcube-core users don't use our lighttpd integration. Nonetheless I
added an autopkgtest (in experimental) to help detect such regressions
further down the road. :-)
Cheers
--
Guilhem.
0 new messages