CentOS 5 Virtualmin Pro
Hi there,
Tried to activate .cgi extensions as per the instructions but kept getting an error 500.
From the virtual server in question the log showed: Options ExecCGI is off in this directory
From error log of suexec: command not in docroot
After a search for 'command not in docroot' I noticed reference to Apache2
Packages matching apache
apr 1.2.7-11 System Environment/Libraries Apache Portable Runtime library
apr-util 1.2.7-6 System Environment/Libraries Apache Portable Runtime Utility library
httpd 2.2.3-11.el5.centos System Environment/Daemons Apache HTTP Server
httpd-devel 2.2.3-11.el5.centos Development/Libraries Development tools for the Apache HTTP server.
mod_dav_svn 1.4.4-0.1.el5.rf System Environment/Daemons Apache server module for Subversion server.
mod_perl 2.0.2-6.3.el5 System Environment/Daemons An embedded Perl interpreter for the Apache Web server
mod_ssl 2.2.3-11.el5.centos System Environment/Daemons SSL/TLS module for the Apache HTTP server
Also, in Apache webserver >> Default server >> Document options:
Document root directory shows as: /var/www/html
Another thread mentions that the document root should be /home and that this should have been processed on the upgrade to Virtualmin Pro
Appreciate advice as to what to do.
Regards,
Cyrus
Based on trying to understand what's wrong, from other threads I gather that the install for some reason didn't replace my apache after upgrading to Virtualmin Pro:
[code:1]# suexec -V
-D AP_DOC_ROOT="/var/www"
-D AP_GID_MIN=100
-D AP_HTTPD_USER="apache"
-D AP_LOG_EXEC="/var/log/httpd/suexec.log"
-D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
-D AP_UID_MIN=500
-D AP_USERDIR_SUFFIX="public_html"
# suexec2 -V
-bash: suexec2: command not found[/code:1]
Joe, is it safe to:
[code:1]yum install apache2[/code:1]
If so, anything needs to be done after that? and just wondering why the upgrade didn't do this?
Regards,
Cyrus
<b>cyrus wrote:</b>
<div class='quote'>Joe, is it safe to:
[code:1]yum install apache2[/code:1]
If so, anything needs to be done after that? and just wondering why the upgrade didn't do this?</div>
From what I can tell this should be fine... it's the equivalent of what I did (except apt/debian in my case) to address the issue when I had it. After doing so everything was fine, no additional steps were necessary.
Cheers,
Gabe
<b>Joe wrote:</b>
<div class='quote'>If it fails, let me know the error. It sounds like the upgrade from GPL isn't working correctly, as it should have fixed both of these things automatically.</div>
Didn't have time to pursue this thread, but now have some time to get this right.
Request guidance to resolve this.
Regards,
Cyrus
<b>Joe wrote:</b>
<div class='quote'>If it fails, let me know the error. It sounds like the upgrade from GPL isn't working correctly, as it should have fixed both of these things automatically.
</div>
Is there another method to request for support? Mail sent to support [at] virtualmin.com does not respond.
The compare page states:-
<div class='quote'>Unlimited premium support via email and issue tracker for all Virtualmin Professional customers, with usual response time under 24 hours.</div>
Anyone knows which email address is being refered to above?
Regards,
Cyrus
<div class='quote'>Is there another method to request for support? Mail sent to support [at] virtualmin.com does not respond.</div>
I meant here in this thread. But, I managed to miss the message where you actually posted the results. ;-)
The ticket tracker is always the better method. Email is just for folks are aren't comfortable with the ticket tracker for some reason...but I've removed it as a suggestion, as it's become impossible for me to keep up with all of the support email I get now. With the ticket tracker, it'll be seen by both me and Jamie, and we'll be hiring an extra support person in the next month or two to help out. Tickets will always be the most likely to get some sort of response quickly. Email gets further and further backed up, as our customer base grows and Joe fails to scale (support@ is just me, in case I hadn't made that clear--without dumping those messages into a ticket tracker, there'd be no way to keep up with which ones had been answered and by whom, so it's a one man operation).
--
Check out the forum guidelines!
Still wondering how to set the docroot to <b>/home</b> in an existing Virtualmin Pro setup....shouldn't this have already happened during installation?
Could this also be the reason for cgiemail not being able to automatically install with 'Install Scripts'?
[code:1]Install Script
In domain virtualdomain.com
Downloading http://web.mit.edu/wwwdev/cgiemail/cgiemail-1.6.tar (153600 bytes) ..
Received 1024 bytes (0 %)
Received 15360 bytes (10 %)
Received 30720 bytes (20 %)
Received 46080 bytes (30 %)
Received 61440 bytes (40 %)
Received 76800 bytes (50 %)
Received 92160 bytes (60 %)
Received 107520 bytes (70 %)
Received 122880 bytes (80 %)
Received 138240 bytes (90 %)
Received 153600 bytes (100 %)
.. download complete.
Now installing cgiemail version 1.6 ..
Failed to compile cgiemail source :
More information on using this script can be found at
http://web.mit.edu/wwwdev/cgiemail/webmaster.html.
.. failed! See the error message above for the reason why.
<- Return to list of scripts [/code:1]
Regards,
Cyrus
Thanks <b>spazzwig</b>
however...apache is already there I guess, so got the response 'nothing to do'.
what I did was change the document root in the httpd.conf file in two places from /var/www/html to /home and restarted apache
Got the following response:
[code:1]Failed to apply changes :
[Sun Dec 23 02:45:39 2007] [error] [client 127.0.0.1] Directory index forbidden by Options directive: /var/www/html/
[Sun Dec 23 05:09:21 2007] [notice] caught SIGTERM, shutting down
[Sun Dec 23 05:09:23 2007] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sun Dec 23 05:09:23 2007] [notice] Digest: generating secret for digest authentication ...
[Sun Dec 23 05:09:23 2007] [notice] Digest: done[/code:1]
suexec -V still shows -D AP_DOC_ROOT="/var/www" and asking a .cgi to execute in a virtual domain still reflects from error log of suexec: command not in docroot
The document root in 'Apache webserver' is showing as /home under the default server and when I restarted apache again, there were no errors.
Now...how do I change the document root to reflect as /home in suexec
Seemed to have goofed up a bit in my endeavour.
1. Changed docroot by opening /usr/sbin/suexec with pico and changed /var/www to /home and saved.
2. [code:1]# suexec -V
Segmentation fault[/code:1]
(after I changed the doc root in /etc/sbin/suexec to /home)
3. Went back to /usr/sbin/suexec and changed the docroot back to /var/www (thought I'd backtrack)
4. OK
[code:1]# suexec -V
-D AP_DOC_ROOT="/var/www"
-D AP_GID_MIN=100
-D AP_HTTPD_USER="apache"
-D AP_LOG_EXEC="/var/log/httpd/suexec.log"
-D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
-D AP_UID_MIN=500
-D AP_USERDIR_SUFFIX="public_html"[/code:1]
5. I get no visible errors anywhere BUT:
Software Packages >> Search for httpd >> httpd 2.2.3-11.el5.centos >> Package details >> List files - Everything is listed as OK EXCEPT
[code:1]/usr/sbin/suexec (View) root apache Regular File 11.24 kB Failed file size check Failed MD5 check Failed modification time check[/code:1]
Failed file size check Failed MD5 check Failed modification time check
is in [color=#FF0000]RED[/color]
Regards,
Cyrus
OK...reverted back to square one from a backup, so everything is back to where it was, that is: -D AP_DOC_ROOT="/var/www"
In the meantime, had also tried to load mod_fcgid without any success. Got to the stage of correcting the MAKEFILE to the correct top_dir path but when I asked to make I got:
Makefile:13: /etc/httpd/build/special.mk: No such file or directory
make: *** No rule to make target `/etc/httpd/build/special.mk'. Stop.
So...obviously my upgrade to Pro didn't pick up certain aspects that it had to. Once again if I may...
<b>1.</b> How do I change the suexec docroot to /home in a centos-release-5-1.0.el5.centos.1 httpd-2.2.3-11.el5.centos environment that I understand is required, and should have been so by default with an upgrade.
<b>2.</b> How do I load mod_fcgid module that I understand is required, and should have been so by default with an upgrade.
Regards,
Cyrus
Whoah! That's some serious effort!
It's actually much easier than that.
yum update httpd
Should replace your Apache with a righteous build. We hope. If it doesn't, let me know why it refuses and I try to help you resolgve it.
SuExec is the one binary you cannot screw around with--it is a security package with extreme prejudice about anything out of the ordinary. Modifying it is effectively saying, "someone has done something nasty and intends to use suexec for evil rather than good".
mod_fcgid is also easy to get:
yum install mod_fcgid
If it fails, let me know the error. It sounds like the upgrade from GPL isn't working correctly, as it should have fixed both of these things automatically.
--
Check out the forum guidelines!
Hi there Joe,
Yeah...having fun..good learning process!! Appreciate your guidance.
[code:1][root@host ~]# yum update httpd
Loading "installonlyn" plugin
Setting up Update Process
Setting up repositories
rpmforge 100% |=========================| 1.1 kB 00:00
base 100% |=========================| 1.1 kB 00:00
updates 100% |=========================| 951 B 00:00
addons 100% |=========================| 951 B 00:00
extras 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
Could not find update match for httpd
No Packages marked for Update/Obsoletion
[root@host ~]# yum install mod_fcgid
Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
Reading repository metadata in from local files
Parsing package install arguments
Nothing to do[/code:1]
Had actually tried that sometime before with the same results.
Regards,
Cyrus
Is there a 'force' option in yum? In apt/emerge, you can force a recompile...
Even though the installer has noted that you have the right version, you probably need it to ./configure with the correct options.
Hey Cyrus,
You don't have Virtualmin repositories there at all. Howd'd that happen? (You've also got a non-OS repository "rpmforge" that is almost certainly going to cause problems.)
So, you upgraded to Pro via the "Upgrade" option within Virtualmin, right? Were there any errors during the upgrade? This doesn't look like anything actually happened with the upgrade, as everything ought to be coming in from our yum repository. How about sending me server details via email, and I'll drop in on this box and see if I can figure out what went wrong.
--
Check out the forum guidelines!
Thanks for the response Joe, ...have sent an email to joe [at] virtualmin.com with details required by you.
I noticed that the ticket tracker states:
<div class='quote'>If your issue description includes sensitive information, such as passwords and user names, please mark the issue private.</div>
however, couldn't find the area to actually mark the ticket as private...as such, the email to you as requested.
No major rush,....at your convenience.
Regards,
Cyrus