Operating system: ubuntu
OS version: 18.04
we just realised, that after upgrading a testserver to virtualmin 6.15 that apache doesn’t come up. it basically is this non-bug: Remove "php_admin_value engine Off" if Apache mod_php is turned off [#59271] | Virtualmin
we had php_admin_value engine Off in all our apache domain configs which breaks if mod_php is not installed. so, is this update removing mod_php (maybe when not in use?)
I think so. Last night we updated a lot of systems (el6 and el7) to a newer version of virtualmin. After the update process lines containing “SetHandler application/x-httpd-php” were removed from /etc/httpd/conf.d/php.conf, leaving an empty config block:
<FilesMatch \.php$>
</FilesMatch>
These systems were running mod_php so things broke in interesting ways. Took a little while finding out. Adding this line back in fixed the issue for me.
<IfModule mod_php5.c>
#
# Cause the PHP interpreter to handle files with a .php extension.
#
<FilesMatch \.php$>
SetHandler application/x-httpd-php
</FilesMatch>
To me it seems some kind of regex replace during of after the update process.
jesus… has the virtualmin pro 6.15 been released with this bug?
I have got the same problem. I do not have a php.conf file in my Ubuntu though?
But in all my websites .conf files i have to rem this out:
#php_admin_value engine Off
Any ideas where to change? Or is just the way it has to be now?
Or… is it because my old server has another php version? I am not sure how I upgraded - but cant get my new server on php 7.4.12 LOL only 7.4.3
Have a nice virtualmin weekend 
Virtualmin (the virtual-server package) updates won’t remove packages.
We did remove the dependency on mod_php from a couple of the lamp stack packages and one of the yum groups, but that would also not remove mod_php unless you also followed it with apt-get autoremove and chose to remove the packages it suggested (if there were no other packages depending on e.g. php).
So: If mod_php was removed, you removed it. But if Virtualmin is not handling mod_php being missing correctly, that’s a bug (maybe a new bug introduced by fixing an old bug). I’m not clear on whether that’s the case.
You should not be running anything with mod_php at this point. It was a bug that php was installed at all by default on some systems. But, if you are running it, you definitely don’t want to uninstall it (using autoremove or whatever mechanism), until after you switch your apps to something else. Virtualmin updates won’t uninstall it automatically, but the change to lamp-stack to remove it as a dependency might have caused some folks to uninstall it accidentally if they follow it up with an autoremove.
…ok. I think I understand, but there is the fact that you removed the dependcies from mod_php when virtualmin depends on it (or didn’t I understand it? 
)
anyways, the bug report in my first message in this thread seems to be the key, as virtualmin should check that the apache configs it maintains are sane before restarting apache, shouldn’t it?
is there a way to find out which virtual domains are using mod_php?
No. Virtualmin does not depend on mod_php and has not for many years, and we really don’t want you to use mod_php. It was mistakenly included in some of the dependency lists for some distros and versions (which would have led to it being enabled in Apache and Virtualmin adding the php_admin_value bits to new domains). But, that was the bug. The mere existence of mod_php is a bug on a modern system.
Yes, but Virtualmin didn’t restart Apache in this case. Updating Virtualmin doesn’t restart Apache. But, if Apache was also updated at the same time, it would have been restarted. There are situations where Virtualmin restarts Apache, but an update is not one of them (domain creation, enabling SSL, deleting domains, or user explicitly asking to restart it, maybe a couple of other situations).
But, it does seem like maybe we’re still not handling mod_php coming or going entirely correctly. Jamie just checked in a fix for one of those cases, though, so it may be resolved in the next version of Virtualmin.
The core problem is that mod_php was ever installed at all. And, that was a bug in the lamp-stack packages in some distros/versions (and some CentOS 7 installs). That bug has been fixed, but now if that change led to the user uninstalling mod_php (whether wittingly or not…but they had to have done something other than just update the Virtualmin packages…it needed an autoremove or something else to make it happen) while having mod_php configuration in your Apache configs, that leads us to here.
But, the right answer here (as always) is to purge every bit of mod_php crap from your system and your configuration. The SetHandler rules can break things, the php_admin_value directives can break things. So, get rid of it.
ok, but we have at least on one server that I know of clients with some very old apps, which always ran on mod_php and which may really depend on it. (don’t ask, I am just the hoster )
so, a) how can I get a list of all the domains that use mod_php right now and b) if a domain doesn’t use mod_php, can I safely remove the offending line from the config? (php_admin_value engine Off)
If you have any domains using mod_php on the server, you need mod_php installed, so just reinstall it. It won’t be removed again, even if you autoremove, as long as it has been explicitly installed.
You can use virtualmin list-domains --multiline to see the execution mode of all domains.
we did a manual update and I still don’t get it. why is this not a mistake on your packaging?
The following packages were automatically installed and are no longer required:
php php8.0
Use 'apt autoremove' to remove them.
The following packages will be upgraded:
usermin virtualmin-lamp-stack webmin webmin-virtual-server
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 45.1 MB of archives.
After this operation, 8,708 kB disk space will be freed.
Do you want to continue? [Y/n]
these packages were installed by us on purpose. (we have a php installer script which uses the ppa:ondrej/php repo). and yes we usually clean up after updates. so, this is what breaks our websites. so, is virtualmin flagging these packages as obsolete? and if yes, this can’t be right, can it?
No. We do not mark anything obsolete and we have no Conflicts. You did not install those packages explicitly (it says they were “automatically installed” which means to satisfy dependencies which are going away or have gone away).
You can see exactly what we do WRT package dependencies: https://github.com/virtualmin/virtualmin-lamp-stack-ubu/blob/master/virtualmin-lamp-stack-2004.ctl (each distro version has a stack package, all in that directory for ubuntu and there is another repo of these metapackages for debian).
If you install those packages manually using apt-get install php php8.0 an autoremove will no longer offer to remove them. Currently you have not done that. Whatever script you ran did not install those packages explicitly. Packages installed by name, rather than to satisfy dependencies, are never removed by autoremove and do not get labelled “automatically installed”.
As an aside, from my perspective (as someone that manages a couple hundred Ubuntu systems in a high risk environment): autoremove should never be done automatically. A human should always look at what it’s doing so it doesn’t surprise you. An extra package sitting around doing nothing has very low cost. But, if it turns out if was doing something instead of nothing, the cost of fixing it being uninstalled can be high.
ok, thanks for the explanation, if you’re sure about this I put a checkmark behind it. we really, really run as the first step on every server after installing virtualmin a script, that starts with
#php default (currently 8.0)
apt -y install \
php \
...
but so be it.
re auto-remove, you may have a point, we just had never any trouble with it and started to automate this step as well some years ago.
I’m absolutely sure that autoremove only offers to remove packages that were installed to satisfy dependencies, never packages installed explicitly by name.
If you run apt-get install php on a system that has it already installed because of dependencies it will say it is setting it to manually installed, which means autoremove won’t offer to remove it again.
It’s my fault the mod_php packages snuck into some default installs, so I’m sorry it bit you. They were not supposed to be there, and if they hadn’t been, you would have had to manually install it from the beginning and it wouldn’t have gotten you now. So…I share the blame here. (But, do be careful with autoremove. It can lead to nasty surprises and you should keep an eye on it.)
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.