> Joe Cooper wrote ..
>>> I and many have had this problem with upgrading. I had to do a
>>> complete install as a result of it and not getting advice on how to
>> We've answered the question dozens of times (on the mailing list and on
>> the Virtualmin.com forums), and the Virtualmin documentation covers the
>> subject of suexec in some detail. If you'd asked for help, I'm certain
>> you would have gotten it.
> Asked but, got told to use the install script. The script failed. Asked many question about it got no answers. Had to download the scripts. Root around in them to find out what files it was looking into to get it to work on my Debian system.
>>> Just turning it it off is not fixing it. And more importantly fixing
>>> the install so it works.
>> The install.sh automated install of Virtualmin has /always/ worked in
>> this regard. There has never been a time when following the
>> installation instructions found in the Virtualmin.com documentation
>> failed to correctly install an Apache with a correctly configured suexec
>> binary. The install /does/ work, and always has. If you choose to
>> manually install Virtualmin and its dependencies, instead of the
>> automated installation script that we provide, there's not much we can
>> do...installing a Webmin module can't rebuild your Apache for you.
> There has been problems with the script. I have had problems on two recommended system Ubuntu and Debian 4. Asked about the problems on the system. Never got an answer.
> I fallowed the instructions to install by script. Several times based on the script install.
> Several on the apt-get install (which should be the default way to install all software). Which dose not work by the way. Not even close for virtualmin. Webmin will install and work. Your deb or each should have a list of all dependencies if you need special ones like Apache then the deb should upgrade to it. Then there is no need to run scripts. Just the apt-get system.
> My own experience and some of those that had the problem has said it was in a upgrade of working webmin/virtualmin when the problem started. System was working before the upgrade, in my case apt-get set to your deposit, when webmin restarted it detected the error and the site no longer was able to run under /home
>> I don't know what more we can do. The warning was added because people
>> frequently were confused when scripts didn't work, because of a
>> misconfigured suexec binary. We now warn about that problem--it's a
>> feature, not a bug.
> So your saying that the change during the upgrade is not a bug. That suexec was always configured wrong and cgi was working by error before the upgrade.
> I had to move my cgi to another server after the upgrade.
> Most of the comments I read from users with the problem had used yum, apt-get to install the upgrade from your deb or rpm.s. Both should be able to install all the software from your repository as needed. Thus correcting problems using the os built in system. Which runs quite well from Webmin.
> I have reinstalled my entire server from the OS up to fix the problem with suexec. So this problem, for now, I don't have. I have botched backups and ramped memory problems instead to deal with. The reinstall was done more for getting mail working properly. I did get spamassain working but have lost a lot of user functionality in mail from the old version. (usermin filter, directories) Webmin directories for example. I have threads on these in the forums awaiting responses.
> Sorry if I ruffled some feathers.
You're shooting the messenger!
I had the same issue on one of our servers.... CentOS instead of
Debian.... but the same deal. I had made the decision to 'conform' to
the where Redhat wanted websites stored... just this one system which I
have not changed. For years, I had used /home. But as each year passed,
it seemed that overriding /var/www had just another thing or two that
needed to be changed for /home to work.
I had totally missed that suexec was compiled into Apache and that
within that the 'where' was hard coded. With CentOS, the default server
and the default cgi-bin is placed in /var/www during an installation and
I don't know a way to override that during a system install without
perhaps doing some work within the installation files/scripts
themselves. Suddenly, the beauty of the fairly easy installation and
maintenance using yum or apt-get has the potential of degrading.
So, there I was, looking at more and more configuration changes to use
/home instead of /var/www. It was just a whole lot easier to put most of
the disk space for /home into the /var partition. I've never looked
back. Made my life easier and when 'the messenger' told me suexec wasn't
working on that one older configuration, I was sort of upset like you.
But then I did a bit of research, found that it had never been working
and that I was operating under false pretenses, up until Virtualmin was
kind enough to give me an error message. So, yet again, I've been taught
something by the Webmin system. But do understand, they are just
'informing you' that your system is not working like you think it is.
They didn't do it, you did by choosing to use /home instead of /var/www.
Yes, this is a common practice, but it is getting more difficult to do,
particularly with regards to security devices like suexec.
So, if someone tells you that there is a big dent in the fender of your
car, don't go off on them for denting your car. They only told you there
is a dent in your car... they didn't put the dent there. As the old
adage goes, "Don't shoot the messenger."
Now, we could argue the merits of /var/www vs. /home for web storage. I
really didn't like making the change from /home into a more shared base
of /var. A place where log files, email and now websites are stored.
With my decision to use /var/www, I also made the decision to enable and
start using user quotas. Seemed like a good protection against a filled
drive space... like what if someone decides to upload 100 gigs of images
into their web space and you don't have 100 gigs free? Email breaks for
everyone! There are for sure pros and cons to /home and /var/www.
And there's this one other rule I try to live by... The more upset or
panicked I am by a computer, the more likely I will do something
'really' stupid. So, when that sets in, I just walk away until I can
calm down, get over it and then come back and the sane approach is
normally clear. Ultimately I have found that following this rule leads
to faster solutions and ultimately less downtime and less wasted time.
This can be really hard to do on an important and active server.