simon.schönbeck.dk

Tag: httpd

  • 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!

  • 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…