Apache mod_fcgid, virtualmin issue

So, mod_fcgid has all sorts of bugs, the "original" version that Virtualmin uses if we choose to use it. So, to get around this, we want to load the Apache taken over version, which currently is 2.3.5.1 which resolves many issues such a directives being ignored, etc. We have problems, for example, with processes (php cgi) never being terminated, so, we can get hundreds of them.

Virtualmin, however, adds a directive for each new virtual server, such as:

FCGIWrapper /home/somestore/fcgi-bin/php5.fcgi .php

That's ok, except, Apache renamed all the directives! That means when a new server is created, the apache httpd.conf file has syntax errors.

Is there any way to use mod_fcgid with virtualmin, but, have it NOT create those directives? We can add the new ones to the config to be added when a new VS is created. But it doesn't do any good if VM also adds the old ones.

The new directive for this is, for example:

FcgidWrapper /home/somestore/fcgi-bin/php5.fcgi .php

See:

http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html

See also:

http://svn.apache.org/repos/asf/httpd/mod_fcgid/trunk/README-FCGID

The bugs are just too numerous to use the Centos really old version. And, we need to use the worker mpm.

Status: 
Active

Comments

Those directives are needed for Virtualmin to run PHP scripts via mod_fcgid. However, if you want to run some other apps vai fcgid, you could instead configure Virtualmin to use CGI or mod_php to run PHP scripts .. this can be done on a per-domain basis at Server Configuration -> Website Options.

Does that help?

No.

The mod_fcgid virtualmin loads is many years old, it has bugs that we cannot live with as the server will crash.

We also must use the worker mpm.

So, we need to upgrade to the new mod_fcgid, which is now run by apache.

That version of mod_fcgid has new directives.

So, we can't use mod_php as that does not work with worker mpm.

I suppose we could use CGI, but, we want to use mod_fcgid for efficiency.

You should realize also that the day centos (or any other supported OS) releases an upgrade to mod_fcgid, and of course they will eventually, all virtualmin sites that upgrade will in fact break. So, you should keep that in mind as all of the directives will be wrong.

Perhaps you misunderstood my question, instead of al that extra text, it boils down to this...

Today, when using mod_fcgid, Virtualmin correctly includes the FCGIWrapper directive.

Unfortunately, that breaks when the new mod_fcgid is used (apache took over that module), as that uses FcgidWrapper instead of FCGIWrapper.

So, you have a danger in that when the OS releases that version, Virtualmin will break unbeknown to perhaps you and others.

So, I am trying to get you to make this ready before then so you don't have a lot of trouble when that happens.

The Apache version has been out for a while, and, will replace all existing mod_fcgid at some point. We just need to do it sooner due to the bugs in mod_fcgid, the Centos version, which is many years old.

I am guessing the answer is there is no way for us to do this, other than modify Virtualmin code.

Still, you should really give this careful consideration as you will save a whole lot of headaches later!

I mis-spoke. Just read in a change file:

"The old directive names will still work but are deprecated"

So, I suppose my dire warning is not correct. Sorry.

However, you SHOULD realize it would be good to get ahead of the game here. The good news is all the servers I have with the GPL version will work fine since that version does not add the directives. My apache server config area of virtualmin does.

You really should look at just how broke the current mod_fcgid is! It's really bad.

Ok, I am glad to hear that the old directives still work - it would be really bad if an Apache module upgrade was to break an existing config!

So when you upgraded, did your existing Apache config stop working? I wouldn't have expected that, assuming that the old directives are still accepted.

I don't know really as I removed all of the old ones, and, the old ones in /etc/httpd/conf.d/fcgid.conf were changed by the new rpm.

Testing the sites now.

The biggest fixes are how all the directives are ignored with virtual hosts. So, as you may know, you can't run PHP more than 500 times thru mod_fcgid as it aborts then. So, you have to set a directive. That directive is ignored due to some bugs. Also, processes not killed when they should be, so, the list keeps growing and mod_fcgid lost track of the existing processes.

Of course, deprecated means it will be removed eventually.

Here's another improvement for you when using mod_fcgid

In the php5.cgi file you create, the last line is:

/usr/bin/php-cgi

This causes several problems. #1 is it is a little wasteful since now there are TWO processes, the one for php5.fcgi and the one for php-cgi. Take a look at ps, try it yourself.

The second problem this causes is if you want to set the min and max # of processes via fcgid.conf file. Processes indeed may terminate, but, it only terminates the php5.fcgi process, leaving the php-cgi processes orphaned.

By using the following, both problems are avoided. Change that last line in php5.fcgi to:

exec /usr/bin/php-cgi

What I actually use on my GPL version servers is:

exec /usr/bin/php-cgi -d session.save_path=$PWD/../tmp -d upload_tmp_dir=$PWD/../tmp

This allows php to use the specific servers tmp directory for the tmp files for security reasons.

At least, you should use exec. I suppose the other settings can be tuned in the local users php.ini file

Virtualmin does use exec, unless you have ulimits defined in the php5.fcgi file - if exec was used, the ulimit on processes would never have a change to take effect.

You can configure the max process limit at Administration Options -> Edit Owner Limits.

I just noticed something. In the server settings, templates, there is a menu choice for "PGP wrapper scripts", where, I can say automatic generation, OR, I can specify a specific script. If I specify said script, I have control over the content today. So, I can avoid anything I do not like about the script for that piece.

The whole mod-fcgid settings should be reworked though. I'd be happy to assist with this. They are all over the place, and, some make no sense at all. In your previous message, you pointed out that ulimit meant you can't use exec, well, it also means mod_fcgid can't kill processes and creates orphans, which isn't good. Of course, that setting, which is in the template also and can only be used when part of fcgid for php of course, is really not needed for fcgid since that can be done via fcgid directives. So, perhaps you can still use your setting, but, specify it in another way and not use ulimit.

There are a number of useful options to be added for mod_fcgid that are missing, and, some can be made better so that it runs properly and efficiently. mod_fcgid is a VERY nice feature you should brag about more. I wish you could specify a fcgid ONLY mode, that would cause other things to kick in such as allowing mpm worker for apache, which then invalidates the php configuration variables since those cannot be used without mod_php.

I wish also the Apache directives and settings for new sites could really mean you add nothing more for fcgid. i.e., I would have to add it.

I guess it's just sort of hard to work with mod_fcgid as currently coded in Virtualmin. It could be a whole lot easier.

If you are open to it, I'd be happy to work with you and write up some sort of initial document of ideas that I have and go from there. I'd rather not take the time though if you are not interested at this time since I am very busy and would rather have the honesty!

Sure, I would be definitely interested to hear ideas on how fcgid support could be improved - I suspect you have more experience with it than me :-)

Regarding the mod_php directives, those are added so that if the user switches his domain back to mod_php mode, any custom settings like memory limits will still be used. If you don't want them to appear, you can disable mod_php globally in the Apache config.