simon.schönbeck.dk

Tag: Apache

  • Which process at which port?

    I came back to the computer earlier today and found one of my servers to be unresponsive. The front-end of one of my bittorrent hosting boxes did not load so I tried some of the other websites hosted on the same box. None were loading.

    Luckily accessing via SSH worked fine and revealed that Apache had died for unknown reasons at some point from yesterday onwards. Trying to start Apache was not possible since it could not bind to the socket at port 80. I had already checked for any remaining PIDs from the previous httpd process, so I started worrying about a possible intrusion or some root-kit binding to port 80 instead of Apache.

    I started running netstat to reveal the listening ports but unfortunately the process information field was empty for this particular process in question. A quick search showed how lsof could also be used to display the name and pid of the listening process on any port number. In my case I typed:

    lsof -i :80

    This displayed a couple of known Python orphaned processes that belonged to the original and defunct httpd process. Once killed Apache was started with no issues.

    After all, nothing dramatic!

  • Virtualmin & suEXEC

    If by chance you have installed the Webmin module Virtualmin at some point you may have come across the following error message when setting up the module:

    Failed to save enabled features: The Suexec command on your system is configured to only run scripts under /var/www, but the Virtualmin base directory is /home. CGI and PHP scripts run as domain owners will not be executed.

    This error message is caused by using a version of suEXEC compiled by default to use /var/www as the document root of Apache. The suEXEC feature allows to execute scripts as the user owning the virtual host instead of the global apache user increasing security. The solution has either been to recompile suEXEC with the new desired path (/home in this case) or simply disable (Server Templates > Apache Website > Automatically add appropriate SuExec directive?) suEXEC completely inside the Virtualmin module configuration.

    A much simpler approach I used was to create a link between the two directories. I used mount to bind the two directories together and act as one. Voila, Virtualmin now continued the module setup without a remark!

    To achieve this I ran the following command as root:

    mount --bind /var/www /home

    That is it really. Now the directories act as one for the suEXEC wrapper too.

    Please note this will usually only last till next reboot. To mount permanently include the following line into your /etc/fstab:

    /var/www /home none bind

    The following is the extract from the mount man page:

    Since Linux 2.4.0 it is possible to remount part of the file hierarchy somewhere else. The call is
    mount --bind olddir newdir
    or fstab entry is:
    /olddir  /newdir  none  bind
    After this call the same contents is accessible in two places.  One can also remount a single file (on a single file).

    One note is that if you already had local users set up inside the /home directory you will mount on top of it, making the existing users data unavailable (not deleted). Simply unmount again and the users data will be back again. To get around this change the default path Virtualmin uses to create new virtual hosts home directories to something else e.g. /virtualmin. This can be done in the Users & Groups module.

  • Apache: DocumentRoot does not exist. Why SELinux?

    Once more SELinux has been playing up with the normal operations of a box. During the installation and set up of an Apache instance and a few virtual hosts I simply could not get around the dreaded error message:

    Starting httpd: Warning: DocumentRoot [/home/www/myhost] does not exist

    No matter which permissions and owners were given to the directories or files related the error still came up hindering the Apache httpd service to start. Obviously the path was correct, copied and pasted, to exclude any spelling issues.

    After experiencing similar conundrums in the past I had a slight suspicion regarding SELinux, which comes enabled by default on Fedora, may have been blocking access to the directory somehow.

    A bit of searching did confirm that SELinux indeed also intervened at this level blocking Apache’s normal operations. I fully understand and agree with the goal of SELinux, but it is simply too big a compromise between security and usability. As Theodore Tso pretty much summarises it:

    SELINUX is so horrible to use, that after wasting a large amount of time enabling it and then watching all of my applications die a horrible death since they didn’t have the appropriate hand-crafted security policy, caused me to swear off of it. For me, given my threat model and how much my time is worth, life is too short for SELinux.

    SELinux stays disabled again…