SUEXEC is the only obstacle in my way

19 posts / 0 new
Last post
#1 Fri, 02/10/2006 - 09:49
BarryJohnson

SUEXEC is the only obstacle in my way

I decided recently to stop using my ISP to host a number of web sites I have due to lack of support (and down time). So I set about setting up my own web server (with virtual domains etc). Then I came across Webmin and Virtual min. What an amazing package!!

4 days on I am now struggling. Mainly for one reason. Apache needs to be re-compiled so that the --with-suexec-docroot=/home

Because I am new to setting up Apache servers, I had no idea that RPM's that come with Fedora etc install Apache to different directories than when you install Apache from source. I also naively assumed that when Apache is installed from source, that it will also include all the modules etc that you get when installed using an RPM. To be honest, don't have much idea what the difference is. My install of Apache from source was configured using ./configure --with-suexec-docroot=/home (I had been reading the documentation on the Virtualmin web site) and that was basically it. Although I could get Apache started ok, it appeared that no modules had been installed. Oops!

Ok, what would be really useful are one of the following:-

A pre configured Apache RPM that makes it compliant with Virtualmin (Not the Pro version).

or

An appropriate Apache ./configure script all ready to go with Virtualmin.

Either of the above would be a great help to me.

One other concern I have is that once Virtualmin is up an running with Apache (if I ever get there), any YUM updates are going to cause a failure of my sites due to configuration changes etc. httpd is often a dependency for other packages.

Fri, 02/10/2006 - 14:59
Joe
Joe's picture

Hey Barry,

I think you're making too much of the "rebuild apache SRPM" step. It really isn't hard at all.

Here's what you do:

[ol]

[*]Make sure you have a the necessary build tools. gcc, make, binutils, libtool, autoconf maybe, openssl-devel packages, etc. Many of these are listed right in the source RPM and when you try to build it will demand them by name (I'll tell you where to get that and what to do with it in a moment), while others are just assumed for a build system. If you've built Apache from source on the machine, you probably already have everything you need. These can all be installed with yum.[/*]

[*]Install the rpm-build package with yum.[/*]

[*]Get the SRPM from http://mirrors.kernel.org/fedora/core/updates/4/SRPMS/httpd-2.0.54-10.2....

[*]Install it with "rpm -ivh httpd-2.0.54-10.2.src.rpm"[/*]

[*]Edit the httpd.spec file found in /usr/src/redhat/SPECS and change the suexec-docroot line.[/*]

[*]Rebuild it with "rpmbuild -ba httpd.spec"[/*]

[/ol]

If you are missing any of the dependencies it will either tell you, or give an error--sometimes those errors are sensible and you'll know immediately what you're missing. Sometimes they are not sensible. If you can't guess what you're missing, bring it back to me here, and I'll tell else you need to install.

I've been planning to setup a freely accessible version of the repository to provide the httpd packages and a few of the other "custom" packages that we provide, but I've been absolutely swamped with customer issues and bugs (alongside development of the next version of the installer with additional OS support, logging, and some other new features). I believe I'm beginning to get caught up, but it'll still be awhile before I can afford to divert the hour or three it'll take to do correctly from already underway projects.

--

Check out the forum guidelines!

Sat, 02/11/2006 - 11:15
BarryJohnson

Many thanks for your help here. After I posted my original message, I formatted my disk and re-installed everything and installed Apache using the automated menus etc. I then updagraded everything using YUM.

I then followed your instructions and got there eventually after installing a number of dependancies. I got a little bit stuck because the version of Apache that I currently had was httpd-2.0.54-10.3 which is the latest one currenty available via the link you gave me. I wasn't sure if I could get a later file from a different web site so I downloaded the existing version I already have installed. I had to issue a 'yum remove httpd' and re-install via the newly rebuilt RPM file since I could find no way of forcing an upgrade. After issuing the suexec -V command I finally discovered that the doc root had changed. Hey Presto!! At last. Smiling face finally.

A couple of questions:-

1) Now that Apache is installed correctly (I hope), what happens to my configuration files if a newer version comes out via YUM and I am offered to upgrade?

2) If I want to manually upgrade to a newer version of Apache (which I have seen on other SRPM files via other links) do I need to go through the same process you have already described? Or can I just download a newer RPM and upgrade using RPM.

3) Should I stick with SRPM files found only on the Fedora distibutions of SRPM? Or do SRPM files differ with Apache.

Apologies for my lack of knowledge on the subject. Hence why I am posting in the newbie section.

Sat, 02/11/2006 - 17:20 (Reply to #3)
Joe
Joe's picture

<i>1) Now that Apache is installed correctly (I hope), what happens to my configuration files if a newer version comes out via YUM and I am offered to upgrade?</i>

Configuration files are respected during upgrades via RPM. It's one of the nice things about a good package manager.

<i>2) If I want to manually upgrade to a newer version of Apache (which I have seen on other SRPM files via other links) do I need to go through the same process you have already described? Or can I just download a newer RPM and upgrade using RPM.</i>

I'd strongly suggest you stick with the latest version provided by your OS (Fedora Core 4). Any other SRPM is likely to put things somewhere else--and might break your existing configuration. Unless you know there is some feature in a new version that you need, there is simply no point in choosing a package other than the latest security update from your OS vendor.

<i>3) Should I stick with SRPM files found only on the Fedora distibutions of SRPM? Or do SRPM files differ with Apache.</i>

Stick with Fedora SRPMS. Others will probably break something somewhere (and you might not know it until it does something obscene to your system). It's entirely possible to do anything you want, use any version you like, etc. it's just a matter of deciding how much time/effort you're willing to spend on keeping odd-ball versions working.

Also, Virtualmin has per-OS configuration files. If you were to use a package built for another OS, you'll probably need to make some changes to the configuration of the Webmin and Virtualmin packages to match the different package.

--

Check out the forum guidelines!

Mon, 02/13/2006 - 15:12
BarryJohnson

I've managed to get Postfix working (sort off). However, I realised that I had forgotton to change the local mail delivery directory from /var/spool/mail to /home/mail as per the virtualmin documentation.

After making the changes, I found that my Outlook Express client (from another PC on the network) was reporting the following error when trying to send mail to my SMTP server (Postfix):-

&quot;The Postfix program

&lt;user@mydomain.com&gt; (expanded from[user@mydomain.com&gt;): cannot
access mailbox /home/mail/mymailboxname for user myusername cannot open file:
Permission denied&quot;

I've substited my real names so that I don't publicise my domain names etc (hope you don't mind). Basically, mail delivery to /var/spool/mail was working ok. And now Postfix doesn't have the permissions to access /home/mail

I had a look at the current permissions on /var/spool/mail which are set to Owner as ROOT and group as mail. Permissions are Owner can View/Modify, Group can View/Modify, Others can View. /home/mail is set as Owner root and group is root. While the Owner can View/Modify, Group can view and Others can view (this was the default).

I tried changing the permissions (using a GUI) as I haven't a clue using the command line) to the same as /var/spool/mail this didn't work. So now I'm stumped. I'm sure it's something obvious. Can you help?

Mon, 02/13/2006 - 16:09
Joe
Joe's picture

Hi Barry,

You're probably hitting SELinux controls now. The SELinux policy on FC4 is close to being useable for virtual hosting, but a few issues still pop up.

Try turning it off with &quot;setenforce 0&quot; from the command line as root, and see what happens.

Also, you may want to use Maildir instead of a traditional mbox mail spool. SELinux policy on FC4 permits Maildir delivery without any changes (you'll still probably have to turn it off if you plan to have any CGI scripts that write data to the domain home directories). Maildir is what the Virtualmin Professional installer sets up, and provides faster service for very large volumes of mail.

--

Check out the forum guidelines!

Wed, 02/15/2006 - 04:13
BarryJohnson

Hi Joe,

setenforce 0 solved the problem.

I then went on to enable Dovecot. After making sure I had mail in my inbox I did a telnet localhost 110 and checked for mail, nothing. I then setup a mail client to check for mail, nothing. I assumed that the mail location for Dovecot was wrong, so I went into mail file location for dovecot and changed it to /home/mail

Now when my email client asks for a password and I enter it, the client just sits there and never comes back saying anything. I assume that Dovecot doesn't like where it's looking.

I also checked that there was a sym link from /var/spool/mail to /home/mail as per the instructions. I also tried changing the mail file location in Dovecot to /var/spool/mail again this didn't work.

I assume that I have to do some sort of configuration changes to get it to look in the mailboxes?

Also, you mentioned that I may want to use Maildir instead of a traditional mbox mail spool. What is Maildir? How do I change this?

Wed, 02/15/2006 - 12:26
BarryJohnson

I figured it out.

Although I did have to disable SELinux. I hope there's not serious security implications that go with this

Wed, 02/15/2006 - 13:18 (Reply to #8)
Joe
Joe's picture

SELinux is an additional layer of access controls on top of standard UNIX permissions. Only a few Linux distributions offer it, and those that do are still doing a lot of polishing to make the system actually useful with the additional locks in place. As I mentioned, it is possible to use the targeted FC4 policy in some virtual hosting situations, it still requires some work to allow script execution and a few other things. It is simply not worth the effort at this point (the biggest part of the effort is due to the overall suckiness of the management tools, and the errors produced--adding new rules is like writing software in a language that is poorly documented and hasn't worked the way the documentation indicates for at least a year).

In another year or two, the tools will be in wider use, they should have gotten the polish they need...and policies for virtual hosting with SELinux enabled will be better understood (I know this last one to be true, as I have an SELinux+Virtualmin production server that I am using to learn the implications of this tighter security model--if no one else addresses it, I'll address the lack of documentation about virtual hosting with SELinux).

As long as you a run a tight, up-to-date, system, SELinux should never be needed. It's a nice extra layer of protection, but we've made it this far with only UNIX permissions in Linux, I think we can make it another year or so.

--

Check out the forum guidelines!

Thu, 02/16/2006 - 17:55
BarryJohnson

I've just uploaded my first live web site. All is working apart from PHP. If I put a phpinfo.php file in public_html and go to it, I just get a blank screen. No errors or anything.

Am I missing something obvious here? I appear to have php version 5 installed and I have a php.ini file in /etc

Is php execution just meant to work straight away or do I have to do some configuring?

Tue, 05/02/2006 - 19:13
rawoo

I am having a similar problem with configuring suexec docroot. Using CentOS 4.2 and the version 4 repositories for the latest httpd SRPMS, rebuilding apache as above does not change docroot to /home. It still points to /var/www as indicated by the suexec -V command. What am I missing? Any help is appreciated.

Thanks

Tue, 05/02/2006 - 20:05 (Reply to #11)
Joe
Joe's picture

Hey Rich,

CentOS splits suexec out into its own package. You need to install it from the bunch of packages that your SRPM rebuild generated.

--

Check out the forum guidelines!

Tue, 05/02/2006 - 23:23
rawoo

Okay, thanks. I'm afraid, as a newbie, I'll need someone to take me by the hand in this case. Can you give me more specific info? What's the file that I should search for and the steps necessary to get this problem corrected.

Thanks in advance...

Tue, 05/02/2006 - 23:51 (Reply to #13)
Joe
Joe's picture

Hey Rich,

Wherever you found the httpd RPM that you built and installed (according to the directions above) you will also find a new package named httpd-suexec.

Or did you perhaps not notice that the &quot;rpmbuild -ba httpd.spec&quot; step is not the end of the process? That just builds a bunch of RPMs, which must then be installed using &quot;rpm -i /path/to/rpms...&quot;.

In other words add to the end of the six steps above:

7. Install the packages that have been built using the command &quot;rpm -i /path/to/rpms...&quot; where &quot;/path/to/rpms...&quot; is probably &quot;/usr/src/redhat/RPMS/i386/httpd*&quot;. This information will be printed out at the end of the build process. Just look a few lines up in the shell to see where they ended up.

--

Check out the forum guidelines!

Tue, 05/02/2006 - 23:57 (Reply to #14)
Joe
Joe's picture

Note also that you <i>need</i> to get the appropriate SRPM for your OS and version (this is why I can't easily provide RPMs with this change made--there's gotta be a different one for every single OS and version, if all of the system default paths are to remain correct, which we want for the sake of simplicity when configuring Webmin). So, you don't want to grab the one linked above. You want the latest one for CentOS 4.

And, of course, pay attention to what happens when try to do all of these things. If you make a mistake, an error will be printed, and the information provided by the error can help you figure out what you did wrong (or, if not you, then me when you pass along the error here). Without any errors, I'm just shooting in the dark at what you might have done wrong...probably leading to more information than you need.

--

Check out the forum guidelines!

Tue, 05/02/2006 - 23:52
rawoo

Well, I actually looked at the directory /usr/src/redhat/RPMS/i386 and found a file named httpd-suexec-2.0.52-22.ent.centos4.i386.rpm and attempted to install this file but received a message that it was already installed. Any ideas?

Thanks

Wed, 05/03/2006 - 00:19 (Reply to #16)
Joe
Joe's picture

Hey Rich,

<i>Well, I actually looked at the directory /usr/src/redhat/RPMS/i386 and found a file named httpd-suexec-2.0.52-22.ent.centos4.i386.rpm and attempted to install this file but received a message that it was already installed. Any ideas?</i>

Yep, uninstall it, and install yours. You didn't change the version of the package, so RPM doesn't know it's actually a different package.

rpm -e httpd-suexec
rpm -Uvh httpd-suexec-2.0.52-22.ent.centos4.i386.rpm

The flip-side of this is that you'll want to setup yum to exclude httpd-suexec updates in the future, because you don't want your site to stop working everytime there is an upgrade to the package. (You should upgrade when new versions arrive, of course, but with a package you build yourself.)

--

Check out the forum guidelines!

Wed, 05/03/2006 - 08:48
rawoo

Thanks...it now works. Wow, what service! And so prompt!

For the record, I had to add --nodeps to the first rpm command due to dependencies.

Tue, 08/01/2006 - 21:32
rawoo

Can anyone provide me with a step-by-step instructions for configuring suexec to point to / home on ubuntu with apache. I'm at a lost at where to begin.

Thanks