Ted Stresen-Reuter's picture

(This article refers to the turnkey-fileserver-13.0-wheezy-amd64.iso installation)

I teach High School IT. We have a lab with 25 computers. Students need to be able to save their work as we image the workstations every few months deleting everything on them along the way. The Turnkey Fileserver has been a godsend as it allowed us to quickly and easily set up a file server for the students' use.

One feature we required was a public web folder inside each student's home folder. This was solved easily enough by enabling the userdir configuration file in /etc/lighttpd/conf-available/10-userdir.conf. At first this seemed like a good enough solution but we quickly ran into problems. Specifically, some of the web applications students were installing required mod_rewrite and the rules were too complex to try and translate into lighttpd's syntax. Also, many of these web apps needed some sort of write access on the filesystem inside the user's folder and as far as I could tell, lighttpd doesn't offer suExec as a module.

Additionally, to complicate matters, we wanted the web server to run as www-data when accessing the web root for the server with PHP running as an Apache module, not as a CGI. It took a little debugging but we got it working, see below.

Our solution was to disable lighttpd on port 80 and install Apache with all the required modules, including suphp so PHP scripts could run as the same user as each user directory with no additional configuration.

These are the steps we followed to get everything up and running:

Modify /etc/lighttpd/lighttpd.conf. Add the following line:

server.port = 8080

There is probably a more elegant way to tell lighttpd to stop listening on port 80, but this worked and in our environment does not open any real security issues. We then restart lightttpd

service lighttpd reload

Then we install Apache and all required modules, and enable them.

apt-get install apache2 libapache2-mod-suphp suphp-common libapache2-mod-php5
a2enmod userdir
a2enmod rewrite

There is one change that needs to be made to /etc/suphp/suphp.conf. Find the line that says check_vhost_docroot=true and change it to check_vhost_docroot=false

Now we edit the suphp config file as needed /etc/apache2/mods-enabled/suphp.conf. Turn off suPHP_Engine everywhere you see it turned on (only one instance if I recall correctly).

suPHP_Engine off

Then wrap the <FilesMatch> section in a <Directory> section so it looks like this:

<Directory /home/*/public_html>
    <FilesMatch "\.ph(p3?|tml)$">
        SetHandler application/x-httpd-suphp
    suPHP_AddHandler application/x-httpd-suphp


Wrapping this code in <Directory> sections limits the implementation to just the user directories, not the whole server.

Then tell the userdir module (/etc/apache2/mods-enabled/userdir.conf) to enable PHP (well, suPHP) for each user. Simply add suPHP_Engine on inside the <Directory> section of the userdir.conf file.

Finally, restart Apache to make the setting stick:

service apache2 restart

At this point everything should just work, but there is one final tweak you probably need to make to minimize headaches. Samba implements oplocks to speed up network connections. Unfortunately, we've foudn that this interferes greatly with Apache as Apache respects these locks and they aren't usually released until the user disconnects from the server. Thus, if your users open the file server and modify a file, Apache may not be able to read the file as it believes it is locked (well, it *is* locked).

We disabled oplocks in the webmin interface:

Servers->Samba Windows File Sharing->homes->Miscellaneous Options->Enable oplocks (set to No)

And now everything runs spectacularly well and students are able to browse to their folders, make changes to their PHP files, test them, share them with others in the class, and everything just works as expected. No hassles. Thank you!

I hope others find this useful.


Ted Stresen-Reuter

Jeremy Davis's picture

Great work Ted and thanks so much for documenting and sharing your detailed instructions. I suspect that whilst on face value your usage scenario may be a bit of an edge case it is still highly valuable information and that especially educators (such as yourself) could really benefit from your writeup.

Thanks again! :)

PS Out of interest, I assume that Ajaxplorer (which uses LigHTTPd) still works, but on an alternative port now...?

Ted Stresen-Reuter's picture

Actually, I tried connecting on the new port and it didn't respond, but I suspect it's because of a firewall issue. Since I don't use Ajaxplorer (can never figure out what username I'm supposed to use) and I don't really want to encourage it's use in our environment, I didn't bother researching it. It should work, though, once you get the firewall issue resolved.


Jeremy Davis's picture

Thanks again! :)

Add new comment