I don't like virtualmin-base 1.0-29 :(

17 posts / 0 new
Last post
#1 Sat, 01/22/2011 - 13:24
Hal9000

I don't like virtualmin-base 1.0-29 :(

Hello! The virtualmin-base package version 1.0-29 introduced the dependency on libapache2-mod-php5. This is bad, because it wants to force me to install mod-php and therefor replace the apache2-mpm-worker package with the apache2-mpm-prefork package. I do not use nore want the mod-php5 module, I chose to use the worker mpm instead with php via fcgi. Is it possible you could rethink your decision to add that dependency? Thanks :)

Sat, 01/22/2011 - 13:45
andreychek

Howdy,

You're right, that's a problem!

There were actually a handful of other problems with virtualmin-base on Debian and Ubuntu systems... and in trying to get those resolved, another one was created.

I've mentioned this to Joe so that he can work out an alternative way of handling things.

Thanks for the heads up,

-Eric

Sat, 01/22/2011 - 16:55
Joe
Joe's picture

So, yeah, this is a known issue in the latest virtualmin-base. It only effects Ubuntu 10.04 systems (because only Ubuntu 10.04 has the weird, virtual hosting unfriendly, PHP configuration which Virtualmin has to fix during install). Debian and earlier Ubuntu versions are not effected, and are still using the old virtualmin-base package, which does not have this dependency.

It is a temporary kludge until I finish a new version of install.sh that no longer uses the virtualmin-base package at all, and is replaced by a virtualmin-configure package that has no dependencies and all dependencies are installed "manually" in the install.sh. I don't like this solution or any of the weird side-effects of the current virtualmin-base...they're all ugly, to me, compared to the yum/RPM version of the installation, but apt-get/dpkg just doesn't like to be scripted as much as yum/RPM do, and makes some scary (to me) decisions about what to uninstall when removing packages with dependencies.

Anyway, the point of all this rambling and complaining about apt-get is that in a few days there will be a new version of install.sh and a virtualmin-configure package and virtualmin-base will be deprecated. There will be a second script which converts a virtualmin-base install into a virtualmin-configure system without breaking anything (hopefully).

In the meantime, and I hesitate to even mention this because somebody is going to read it and think it's a recommendation, and then break their system because they didn't understand the advice or follow the steps precisely...it is not a recommendation. Just a workaround if you need to use worker and can't wait a few days for an automated way to convert your system.

So let's put some big warnings around it (sorry for being obnoxious about the warnings; I really don't want anyone to think this is a normal thing that all Ubuntu users should do):

WARNING: This is not advice or a recommendation. Only do this if you have read and understood every word in my comment and cannot wait a few days for a script to do it for you, and need to use the worker Apache module.

  1. Install all of the dependencies of virtualmin-base manually. You can get this list with the command, "apt-cache depends virtualmin-base". If you are already using worker and don't want it, leave off the mod_php dep that requires it.
  2. Uninstall virtualmin-base.

In a few days, when the new virtualmin-configure package is released, you can install it with the dpkg --unpack command, which won't run the configuration postinst script (this is important on a production system...you never want that configuration to happen on a system that differs from the default install in any significant way as it will break stuff). Or, you can opt to leave virtualmin-configure and virtualmin-base uninstalled altogether.

The reason you might want them is so that bugfixes to configuration of your system can happy automatically in the future...we use it to fix permissions problems, issues with package configuration, etc. that we discover after we have installations on a give OS running in the field. So, it can fix problems that you don't even know you have yet. We rarely use it, however, now that the installer default configuration is very stable and rarely needs changes post-install. So, it probably won't hurt anything to not have either one in place. But, if someday there is a problem discovered that we fix via a configuration change, you'll need to notice the problem and google out how we solved it. So far, there hasn't been such a configuration hotfix in over a year, I think. It's pretty rare.

--

Check out the forum guidelines!

Sat, 01/22/2011 - 17:06
Hal9000

Uhm... Ubuntu 10.04? I am running Debian 5.0 and still got that new virtualmin-base in apt. Personally, I can just wait until a newer version comes out. Virtualmin is installed and running already, so i'll just keep the update back until it won't break my apache setup :) Oh btw, will the new install.sh work on Debian 6.0? It's completely frozen in RC status and very close to release =)

Sat, 01/22/2011 - 17:48 (Reply to #4)
Joe
Joe's picture

Hmmm..That shouldn't be, but maybe the two are links rather than separate repos...

Oh btw, will the new install.sh work on Debian 6.0?

Not until there is a stable release. A few days or maybe a week or so after, it will be supported. Actually, install.sh would probably work today on Debian 6, but there wouldn't be a software repository for it to use for the actual installation. install.sh is stupid, and doesn't really "support" an OS...it just sets up the repository for the OS and downloads the packages that actually perform the installation (virtualmin-base, right now).

Anyway, we don't support alpha/beta/RC/snapshot/whatever releases of operating systems...it's hard enough to support systems that are reasonably unchanging.

--

Check out the forum guidelines!

Sun, 01/23/2011 - 00:54 (Reply to #5)
Hal9000

hmmm well it got upgraded both on my debian 5.0 + virtualmin gpl (where i use mod-php5 so no problem there) and as said is being offered as upgrade on my debian 5.0 + virtualmin pro system as well.

Thu, 02/24/2011 - 02:05
helpmin

There will be a second script which converts a virtualmin-base install into a virtualmin-configure system without breaking anything (hopefully).

Did you guys release this already?

Wed, 01/01/2014 - 17:09
bionitech

This thread is three years old and still unresolved as far as I can tell.

I installed Virtualmin using the install.sh script.

I am trying to install apache-mpm-worker, and it is forcing me to uninstall virtualmin-base.

"There will be a second script which converts a virtualmin-base install into a virtualmin-configure system without breaking anything (hopefully)."

Is this still the plan? Any progress?

I would consider this issue a major bug. Virtualmin DOES NOT depend on libapache2-mod-php5, so it should not be listed as a dependency.

Being unable to use mpm-worker makes Virtualmin USELESS for anything other than low-traffic sites.

https://www.virtualmin.com/node/25497

nibb Posted: Fri, 2013-02-22 15:00

Why does Virtuamin uses apache in pre-fork as default?

This is awful. Its not 2005 anymore. Most web servers use worker today. Not only it consumes less RAM but allows more traffic to be handled.

Pre-fork cannot scale in traffic.

Based on this, Virtualmin would only be suited for very low traffic websites and servers. Its not fully using the potential from Apache as a web server.

This behaviour should really change in the future. Or in either case, users should have the option when installing it or after it to decide which mode to use.

I searched the forums a bit and its seems you cannot use worker even if you want because it conflicts and creates problems with virtualmin itself.

Honestly, this could be a huge reason not to use Virtualmin. Virtualmin is supposed to be for hosting, to host multiple virtual hosts. But if you are limit into traffic you can handle with Apache it does not make to much sense.

---

I've tried the following work-around and it seems to have worked. This issue still needs to be dealt with though. Users shouldn't have to hunt through forums to find a work-around that is still experimental.


# aptitude -s remove virtualmin-base
The following packages will be REMOVED:
procmail-wrapper{u} usermin-virtual-server-theme{u} virtualmin-base
webmin-security-updates{u} webmin-virtual-server{u} webmin-virtual-server-theme{u}
webmin-virtualmin-awstats{u} webmin-virtualmin-dav{u} webmin-virtualmin-htpasswd{u}
webmin-virtualmin-mailman{u} webmin-virtualmin-svn{u}
0 packages upgraded, 0 newly installed, 11 to remove and 57 not upgraded.
Need to get 0 B of archives. After unpacking 11.2 GB will be freed.

aptitude unmarkauto procmail-wrapper usermin-virtual-server-theme virtualmin-base webmin-security-updates webmin-virtual-server webmin-virtual-server-theme webmin-virtualmin-awstats webmin-virtualmin-dav webmin-virtualmin-htpasswd webmin-virtualmin-mailman webmin-virtualmin-svn

# aptitude -s remove virtualmin-base The following packages will be REMOVED:
virtualmin-base
0 packages upgraded, 0 newly installed, 1 to remove and 58 not upgraded.
Need to get 0 B of archives. After unpacking 73.7 kB will be freed.

aptitude remove libapache2-mod-php5

aptitude install apache2-mpm-worker

(other references)
http://www.virtualmin.com/node/17298
http://www.virtualmin.com/node/16336
http://www.virtualmin.com/node/25497

Thu, 01/02/2014 - 00:32 (Reply to #8)
Joe
Joe's picture

Which distro and version are you using? I thought this had been resolved ages ago...it shouldn't be happening on modern Debian/Ubuntu versions. If it is, there's been a regression somewhere along the way, and I'll need to figure out how to deal with it again (I can't just roll a new virtualmin-base, as it'll remove necessary software).

--

Check out the forum guidelines!

Thu, 01/02/2014 - 01:03
bionitech

Debian 7.1
Linux 3.2.0-4-amd64 #1
SMP Debian 3.2.46-1 x86_64 GNU/Linux

Webmin version 1.650
Virtualmin version 4.02.gpl GPL

Package: virtualmin-base
State: not installed
Version: 1.0-29

virtualmin-install.sh downloaded 2013-07-27.

Thanks for your help Joe.

Thu, 01/02/2014 - 01:24 (Reply to #10)
Joe
Joe's picture

Hmmm..I must have pulled an old version of virtualmin-base when rolling Debian 7 support. Oops. I'm gonna have to make a virtualmin-configure package, as I'd intended to do in the past (I ended up not doing it because it introduces some other complexities that I don't like)...the workaround is still the same, though.

Also, I think it's worth discussing what worker vs prefork can do for you (and what it can't). In a virtual hosting environment, you're likely to have many users executing software. With suexec (which is the only sane way to execute code in a virtual hosting environment), you will end up with many forked Apache processes anyway. Using worker vs prefork is very unlikely to provide more than minor performance or memory usage benefit unless you are only hosting one or two domains (even then, you're still forking for your applications).

So, while I would like to narrow down where you're running into this problem and will definitely fix it, I also want to be clear that it is not nearly obvious that using worker is vastly superior to prefork in most Virtualmin deployments. Linux fork is very efficient, and the worker concurrency type is not vastly more efficient on Linux systems. Also, anyone using mod_php will probably need to choose prefork, as mod_php is historically not thread safe (I don't know if this has been fixed). Using suexec+fcgid removes this concern, as it is a process-based concurrency model, but it also removes any benefit to using worker, as you'll be spawning new processes to execute PHP, anyway.

Anyway, the worker concurrency model was introduced for operating systems that have slow fork (like Windows and Solaris). Linux doesn't benefit a huge amount from it. It isn't a disaster to use prefork; we just use whatever the OS sets up by default, when we don't have the borked virtualmin-base, which is prefork on every distro I now of (for a number of good reasons).

--

Check out the forum guidelines!

Thu, 01/02/2014 - 01:37 (Reply to #11)
Joe
Joe's picture

Actually, it looks like install.sh has the right dependency list (and always has for Debian 6&7 and new Ubuntu versions; and there's a special case for older Ubuntu versions), so I think I can just roll a new virtualmin-base without those dependencies, and have it work.

So, I think this is an easy fix. I'll have to do some testing though to make sure.

Thanks for the heads up.

--

Check out the forum guidelines!

Tue, 03/04/2014 - 11:39 (Reply to #12)
warphost

Using suexec+fcgid removes this concern, as it is a process-based concurrency model, but it also removes any benefit to using worker, as you'll be spawning new processes to execute PHP, anyway.

I might be missing something here... could you explain that one to me? :-)

Isn't there still a benefit to using worker mpm even if your site's Apache + PHP process/threads run under SuExecUserGroup?

In other words, regardless of which user/group the Apache listener thread in mpm is working under, it will still manage requests more economically (than prefork), allocating to its worker threads accordingly? I understand what you're saying about Linux processes being very efficient, thus negating the potential benefits of worker mpm, but worker would seem to offer memory efficiency which appears unachievable under prefork.

This suggests that while the speed of forking Linux processes is up to the job, memory allocation within apache-mpm-worker is more efficient, arguing in its favour.

Unless I've completely misunderstood (please don't say yes, please don't say yes...)

Cheers, Steve

Mon, 01/06/2014 - 13:20
bionitech

Using worker vs prefork is very unlikely to provide more than minor performance or memory usage benefit unless you are only hosting one or two domains

We are using only one domain on our server.

Mon, 01/06/2014 - 14:16
bionitech

Anyway, the worker concurrency model was introduced for operating systems that have slow fork (like Windows and Solaris). Linux doesn't benefit a huge amount from it. It isn't a disaster to use prefork; we just use whatever the OS sets up by default, when we don't have the borked virtualmin-base, which is prefork on every distro I now of (for a number of good reasons).

Thank you. This is useful information.

I had been reading about the advantages of worker in terms of increased processing power, lower overhead, and lower memory consumption.

I wanted to install worker and run some benchmarks and stress tests to compare against prefork. Each setup is unique unto itself, right, so the only way to know is to actually run the tests on our server.

Even if we go with prefork or if prefork is fine for linux (and not windows and solaris), the option should still be available to people who want to run worker.

Sun, 01/12/2014 - 17:22
Chris_C

Interesting thread. How about adding to the debate: pros and cons of mod_php vs. suexec+fcgid vs. php-fpm ?

From this page, php-fpm seems like a popularly used setup: http://blog.kmp.or.at/2013/06/apache-2-2-on-debian-wheezy-w-php-fpm-fast...

Sun, 01/12/2014 - 18:00
bionitech

Created a new thread for a discussion on the pros and cons of mod_php vs. suexec+fcgid vs. php-fpm and Apache MPM.

https://virtualmin.com/node/32051