Oh and before I forget to ask… does it matter wich Apache version I use for this to work? Currently using 1.3.33
Tony
Yes, Apache 1.3 is missing some stuff. mod_fcgid doesn’t work with it (mod_fastcgi does, but the syntax is utterly different…I think the mod_fastcgi code is still in Virtualmin, but I don’t think it ever worked right, because of bugs in mod_fastcgi on Apache 2.0, so I wouldn’t bet on it actually working). So, yes, if you want php4 and php5, mod_fcgid, and suexec, you definitely want Apache 2.
Could you be a bit more specific with this? Do I need to compile both PHP Packages as CGI? Or only one and the other as module? Both are available from Fink as well as Darwinports.
I do have another OSX development Server here running Apache and 2 virtual server. One is running PHP4 as CGI (with FastCGI) and the other runs PHP5 as module. Work perfectly fine it seems.
We like to run both under mod_fcgid. That brings them under control of suexec, and makes it possible for both to run identically. Permissions are the same (and match the user), and loads of other bits are simplified or made more secure or both. I don’t like the “run mod_php for one and CGI for another” solution to this problem much. It’s just so inconsistent for your users and you. mod_fcgid is nearly identical in performance to mod_php (faster in some cases, slower in others, but never by much) and has all of the benefits of CGI (mainly suexec without wacky hacks like suphp).
Ok Joe thanks for clarifying this for me.
Since Apache 1.3.x will not work with mod_fcgid I tried to get Apache 2.x up and running. OSX Server actually comes equipped with 2 versions of Apache [1.3.33 & 2.0.54] but I decided to install 2.2.4 using MacPorts [former DarwinPorts]. Now, the install went smooth and I reconfigured the Apache server settings in Webmin. So far so good…
If I start Apache in Webmin I get this error:
Failed to start apache : Apache does not appear to be running :
httpd: Could not reliably determine the server’s fully qualified domain name, using machostlinkeu.local for ServerName
So I thought well I change the server hostname for the default server from automatic to localhost. Well and then I get this:
Failed to start apache : Apache does not appear to be running :
No other error message. So I tried "apachectl start" directly in the shell. No error messages and apache starts normally.
Funny enough though, clicking “start Apache” in Webmin throws the error, however it DOES start Apache. Virtualmin and System and Server Status on the other hand don’t show that Apache is started!?
I changed then the Webmin Apache config to use the 2.0.54 Version that comes with OSX Server, but the same this happens!? :[
Could you tell me how I can solve this?
Thanks,
Tony
Looks like Dovecot has the same issue in Webmin/Virtualmin. Almost like Apache, service starts but Webmin and Virtualmin still won’t show its running?!
Did some more testing with apache but still can not convince VMPro to show it as running. Here is a part of my error log file if that helps anybody?
[Sun Jul 22 15:07:54 2007] [notice] suEXEC mechanism enabled (wrapper: /usr/local/apache2/bin/suexec)
[Sun Jul 22 15:07:54 2007] [info] APR LDAP: Built with OpenLDAP LDAP SDK
[Sun Jul 22 15:07:54 2007] [info] LDAP: SSL support available
[Sun Jul 22 15:07:54 2007] [info] mod_fcgid: Process manager 2093 started
[Sun Jul 22 15:07:54 2007] [notice] Digest: generating secret for digest authentication ...
[Sun Jul 22 15:07:54 2007] [notice] Digest: done
[Sun Jul 22 15:07:54 2007] [notice] Apache/2.2.4 (Unix) configured -- resuming normal operations
[Sun Jul 22 15:07:54 2007] [info] Server built: Jul 21 2007 17:04:56
[Sun Jul 22 15:07:54 2007] [debug] prefork.c(991): AcceptMutex: sysvsem (default: sysvsem)
[Sun Jul 22 15:07:54 2007] [debug] proxy_util.c(1625): proxy: grabbed scoreboard slot 0 in child 2096 for worker proxy:reverse
[Sun Jul 22 15:07:54 2007] [debug] proxy_util.c(1724): proxy: initialized single connection worker 0 in child 2096 for (*)
[Sun Jul 22 15:07:54 2007] [debug] proxy_util.c(1625): proxy: grabbed scoreboard slot 0 in child 2095 for worker proxy:reverse
[Sun Jul 22 15:07:54 2007] [debug] proxy_util.c(1644): proxy: worker proxy:reverse already initialized
[Sun Jul 22 15:07:54 2007] [debug] proxy_util.c(1724): proxy: initialized single connection worker 0 in child 2095 for (*)
[Sun Jul 22 15:07:54 2007] [debug] proxy_util.c(1625): proxy: grabbed scoreboard slot 0 in child 2098 for worker proxy:reverse
[Sun Jul 22 15:07:54 2007] [debug] proxy_util.c(1644): proxy: worker proxy:reverse already initialized
[Sun Jul 22 15:07:54 2007] [debug] proxy_util.c(1724): proxy: initialized single connection worker 0 in child 2098 for (*)
[Sun Jul 22 15:07:54 2007] [debug] proxy_util.c(1625): proxy: grabbed scoreboard slot 0 in child 2097 for worker proxy:reverse
[Sun Jul 22 15:07:54 2007] [debug] proxy_util.c(1644): proxy: worker proxy:reverse already initialized
[Sun Jul 22 15:07:54 2007] [debug] proxy_util.c(1724): proxy: initialized single connection worker 0 in child 2097 for (*)
[Sun Jul 22 15:07:54 2007] [debug] proxy_util.c(1625): proxy: grabbed scoreboard slot 0 in child 2099 for worker proxy:reverse
[Sun Jul 22 15:07:54 2007] [debug] proxy_util.c(1644): proxy: worker proxy:reverse already initialized
[Sun Jul 22 15:07:54 2007] [debug] proxy_util.c(1724): proxy: initialized single connection worker 0 in child 2099 for (*)
Pretty weird is also that VMPro shows ProFTPd FTP Server as "running" but Webmins System and Server Status still shows a red X!? That is the same btw. for SSH,Squid (at least for me)!?
Appreciate any help with this,
Tony
Geeeeee… I got it… damn!
It was the whole time just because of those process ID files (.pid).
In Apache module config it was on "Work out automatically" and should be "/usr/local/apache2/logs/httpd.pid" (IF you compiled Apache2 from source that is). That btw. solved the trouble in Webmin "System and Server Status" as well.
So OSX users better make sure you get the RIGHT location of the PID files. Sometimes it helps if you start the service/process first and THEN use mdfind to locate it in the shell.
Tony
Thanks for the update Tony. I was just about to tell you to find the PIDs and get them right in the module (that’s always the cause of this trouble).
Webmin has a set of default configuration files, and depending on how you install software those files may be wrong. If you install from OS-provided packages, you’ll never run into a problem like this, but on Mac OS X, there may not be suitable packages. (Though looking back over this thread, I probably would have just gone with the 2.0.54 package you mentioned…nothing really great appeared in 2.2 that wasn’t in 2.0.54.)
Hi Joe,
I thought about switching to 2.0.54 cause I read about some security flaw on 2.2.4 already. Not sure if that would affect me but…
While I am here, maybe you could help me with this…
Drives in OSX are all having mount points in a subdir on the boot volume (i.e. /dev/disk3 = /Volumes/home). To switch to another disk in the shell I would do: cd /Volumes/home
Do you think this path (/Volumes/home) would work as "docroot" for suExec? Or should I just define the Apache data directory like this: --datadir=/Volumes/home - and let suExec handle the rest by itself?
Define as the DocumentRoot set for Apache. This will be the only hierarchy (aside from UserDirs) that can be used for suEXEC behavior. The default directory is the --datadir value with the suffix "/htdocs", e.g. if you configure with "--datadir=/home/apache" the directory "/home/apache/htdocs" is used as document root for the suEXEC wrapper.
ps: I think it would help me if I could see how the Apache is compiled that comes with VMPro. That would give me an idea what to include and what not before I compile mine again.
Thanks,
Tony
I thought about switching to 2.0.54 cause I read about some security flaw on 2.2.4 already. Not sure if that would affect me but...
Maybe a problem, maybe not. Each of the trees (1.3, 2.0, 2.2) is maintained separately, and security fixes go into each. 2.2.x is not inherently more secure than 1.3.x or 2.0.x. Also, OS vendors and packagers may or may not add their own patches to the package they distribute. Most Linux distributions pick a version and stick with it throughout the life cycle of that distribution version (so CentOS 4 is on Apache version 2.0.52 and will never have anything else…but it has had 32 builds of that version of 2.0.52, though only about a dozen of those have been rolled out to the official repository, while the rest lived in testing). That 2.0.52 is just as secure and reliable as the latest 2.2.x version, and has all of the latest security fixes.
But I have no idea what the policies on Mac OS X look like, or who is responsible for keeping them secure and bug free.
You are right, with all those variables in there. 
Oh well then let me try to do it on my own.
Ok, now I compile it with datadir and suexec docroot both set to “/Volumes/home/www”.
No problem so far and suexec -V shows the path I set. But now I have trouble compiling mod_fcgid even after fixing build path inside the Makefile script. “make” does work after patching the path but “make install” doesn’t seem to like my build directory outside of the main Apache2 dir. Why is BUILD inside the hosting dir now anyway?
GRR… HELP!!! 
Do I actually have to set the datadir to the same path as docroot when compiling Apache2? Virtualmin shouldn’t care where the DEFAULT/LOCAL web directory is located right? hmm…
Tony
Ok, now I compile it with datadir and suexec docroot both set to "/Volumes/home/www".
Not quite right. Leave off the www for suexec docroot (probably).
Presumably Virtualmin is going to be creating users in /Volumes/home, and not /Volumes/home/www? If so, the docroot must be the higher level directory. Datadir doesn’t matter, though it probably does need to be set (and it doesn’t need to be the same as suexec docroot…they aren’t really tied together in any meaninful way). It’s a historic relic from the pre-VirtualHost days. We flip Apache into VirtualHost mode, and explicitly set the DocumentRoot for every virtual server.
Do I actually have to set the datadir to the same path as docroot when compiling Apache2? Virtualmin shouldn't care where the DEFAULT/LOCAL web directory is located right? hmm..
So the answer to this is a definitive “No”. They aren’t related. docroot needs to be where you put your homes. Datadir is whatever you want it to be. But neither is related to mod_fcgid, as far as I know. But, then I build all of this stuff via rpmbuild or debuild, so I haven’t built Apache manually in years.
Not quite right. Leave off the www for suexec docroot (probably).
Presumably Virtualmin is going to be creating users in /Volumes/home, and not /Volumes/home/www? If so, the docroot must be the higher level directory.
Yes that was at least the default setting (well it was “/home” wich would have not worked for me as well since /home is in my case a different volume). I changed the home directory in the VM Module to “/Volumes/home/www” because the volumes name is “home” and I would like to have a directory inside it called “www” where VM should then create it’s subdir tree(s). Anything wrong with this? 
Tony
Anything wrong with this?
Nope. Sounds like all of your services will agree, so you’re fine. I just didn’t catch that you had a special volume for Virtualmin.
Cool! Yes that’s why I was afraid something [suexec/VM/etc.] might not like it.
Ok well I have some more questions now regarding the handling of the PHP wrapper and the initial handling of the php.ini files thru VMPro.
Because I am using MacPorts packages for PHP I had to change the wrapper script for PHP5 to look like this:
#!/bin/sh
PHPRC=$PWD/…/etc/php5
export PHPRC
PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN
exec /opt/local/bin/php-cgi
The problem is now that VMPro seems to simply ignore that I have PHP5 installed. "System Information" shows always PHP Version 4 and after creating a new virtual server it uses the PHP4 wrapper script instead of the PHP5 one!? Weird!
Is there any way I can let VM know WHAT PHP version i have installed? The only thing I found that I could change was the PHP-Configuration in Webmin!?
Thanks,
Tony
Ok here is a quick update…
This morning I updated Webmin to 1.351 and VMPro to 3.44. Now it seems to be able to setup the right wrapper for the installed version of PHP to the virtual servers home directory. Great! Now let me check what happens if I install PHP4 as well. Anything in particular I would have to look out for?
Will let you know how it goes…
Tony
Oh here is something that is bugging me and I could not find out how to solve this. When I try to install ANY of the VMPro third party scripts it downloads the script and then I get this error message:
Now installing PHP-Calendar version 0.10.7 …
HTTP/1.0 500 Perl execution failed Server: MiniServ/0.01 Date: Thu, 26 Jul 2007 15:35:34 GMT Content-type: text/html Connection: close
Error - Perl execution failed
setrgid() not implemented at /usr/local/webmin-1.351/proc/proc-lib.pl line 161.
Ah, this is a limitation of Webmin on Mac OS X, I think…and it might mean Install Scripts won’t work just yet.
I’ll ask Jamie to chime in with a definitive answer on whether this is fixable short-term.
I’ve seen this before on MacOS with Webmin - it means that the Perl function to change a process’s Unix group is not implemented, which is bad because switching from root to the user and group for a domain is a critical for certain Virtualmin functions.
However, I believe that it is fixed in later versions of Perl … if possible, you might want to try upgrading Perl on your OS X box. It may be necessary to re-compile it from the source.
Thanks Joe, Jamie…
it does look like I need to upgrade the Perl version I am using (right now using 5.008006). Well I could update to 5.8.8 do you think that should work then!? Could you point me to the section in Webmin where I can specify what Perl version it should use?
Thanks,
Tony