Apache's Userdir With Very Own Cgi-bin the non-virtualhost way

Main reason for doing this, a lot of guessing answers and not a lot of real answers, so I'm just keeping it real.

OK this will just be a short one. (like all my short ones)

Everyone gets to that stage in life when they feel they must install their very own web server, you know? that stage, where you just wake up one day and say, wouldn't it be cool if I could turn my computer into a web server (be on the lookout for my easy to abuse guide for a lot of open source web software you could install on your computer to make it webbed out to the max, now you're tingling).

So you sit down at your computer and hit the internet (The Internet is a place where people can come together to b!@#h about movies and share pornography with each other. - Jay and Silent Bob's told definition), start googling, yahooing, exciting those engines and you get sites suggesting web server software but you don't see those All-In-One packages, and why not? (was that your keyword?, then that's your answer), guess you didn't know they existed (now you do) and that's why you go off and dowload these single packages, trying to put it all together to form your own DIY AIO (...and on that farm, he had a, ahem...) package, yet the documentation is in a foreign language, so you should have checked english only sites (if that's not foreign to you), So armed with documents you can understand it right?, right? why isn't anyone putting their hands up?

This is where the All-In-One packages can help you, I highly recommend XAMPP from https://www.apachefriends.org/index.html , which will give you most packages you would want to be running on your very own server, they really do take the hassle out of the Do It Yourself method, but the advantage over a Do It Yourself method, is you learn while you pray for it to work, and in this learning process, you learn how you can administer/administrate (strike out the incorrect term, English Test #1) web servers.

There's also, more flexibility as in where you want to store each individual package, although these All-In-One packages do a good job, it comes down to installing everything how you want, or letting someone else install their package how they wanted it, even if their logic is controlled by their relation (I wear the pants round here, she tells me which ones!).

So the moral of telling you about XAMPP, well if you don't already have a web server installed, then what are you waiting for, the next morning where you rise and say "I want a web server", because it only happens once, and now is that time.

So now that this is out of the way, I take it you've read the documentation, you understand the developers logic/relation with where each stored file is, because I am not going to physically tell you directories, I will just give you pointers and you decide on how to go about it. I hope you would know which Apache modules you'll require for this and have them already enabled.

OK, but to the real meaning of this thread, So you've ran your server, but what if you would like to add users onto your server and let them have their own directories and create their own sites? Well, this is another stage you get to in your life, where you wish upon a star hoping that one day, other users will have their own web folders and can do their own things with it.

For this, we need to edit our httpd.conf, of course this file will be different for Windows users and Linux users, and the others who are users too.

In this, we are looking for UserDir, this specifies the location to go to the user's web root in the user's directory, how are users seen? They are seen by their username prefixed with a ~ (tilde), here's what I mean http://somedomain.com/~abuser1/, this well direct you to abuser1's web root, and with DirectoryIndex set, you'll see either index pages hopefully, as long as they exist in that users web root. Another thing is, ~abuser1 has to be a user that computer recognises, so before we start editting our httpd.conf file, lets add a user, you know how to do this right? could use your own user if you wanted to. You added a user, good.

Now that users needs a place to store his HTML files, some Operating Systems do this for you, some don't so you must do it yourself.

for my example:

I have a user and in his directory I created two more directories called www and inside this folder, public_html because I wanted to keep all the www information for this user in it's own folder instead of having folders all inside his documents and I want to set the document root for this user as public_html. Now create your cgi-bin folder in www, outside of our docroot, why? because we can, and it's a lot safer this way too. What permissions are needed: User's Directory 711, www 711, cgi-bin 755, public_html 733,

So back to httpd.conf, now edit/create these lines

UserDir disabled root
UserDir www/public_html

(Windows will have a different way for this, look at the comments for the information on how to do this, don't worry, I'm sure the comments and examples will help you and you'll figure it all out)

This says that the user root will be disabled (excluded) and that the docroot of UserDir is found at <User's Directory>/www/public_html

Next we search for ScriptAlias and add [above] it (don't delete/remove the existing ScriptAlias):

ScriptAliasMatch ^/~([^/]*)/cgi-bin/(.*) /home/$1/www/cgi-bin/$2

What this is, is a regular expression match for requests made to the server. The first set of brackets becomes $1, basically it's capturing our username, the second set of brackets is $2 and that is capturing the cgi-script used.

so as you can see, it's going to our User's path, then the www directory then the cgi-bin and then executing the script that was put into $2.

Next we go right down to the bottom of the page and add:

<Directory "/home/*/www/public_html">
Options Indexes SymLinksIfOwnerMatch IncludesNoExec
AllowOverride None
Allow from all
Order allow,deny
</Directory>

<Directory "/home/*/www/cgi-bin">
Options ExecCGI
SetHandler cgi-script
AllowOverride None
Allow from all
Order allow,deny
</Directory>

Save the httpd.conf file and restart apache, then we need to create a test file to test it.

Write this in a text editor (not a fancy editor that adds formatting information, it must be plain text)

#test.pl
#!/usr/bin/perl
print "Content-Type: text/html\n\n";
print "It worked!";

now save it as test.pl in your user's cgi-bin, change it's permission to 755 and open up LOCALHOST/~username/cgi-bin/test.pl

Things you may have to look into if there are problems, SetHandler cgi-script makes the directory it resides in, only accept cgi-scripts to be there and executed. So if what you want is not cgi-script related and resides inside the cgi-bin then you might want to remove SetHandler.

AddHandler cgi-script .cgi .pl .whatever_other_cgi_extensions_you_have.

Correct slashes and paths for your Operating System.

AllowOverride, can be configured better than this, to allow your users to be able to use .htaccess files, I'll let you decide what they should or shouldn't have.

When I mean look into them, I mean you should research your problem, The famous 500 Server Internal Error can result from incorrect permissions, ScriptAliasMatch not matching correct location, the (#!/usr/bin/perl) shebang line is not right for your OS.

If it's just displaying text, then the mime-type isn't correct, it was uploaded as binary not ascii.


Well, that's another exhausted short tutorial. With this, you'll surely know how you could go about doing this for VirtualHosts, but that's something you should find out for yourself, or read my book when I release it.


Cheers,


MC

Comments

Apache's Userdir With Very Own Cgi-bin

Replying to mastercomputers

After scouring the net for a reasonable pointer on setting up individual accounts to have web access with their own cgi-bin directories, I was about to quit with frustration when I decided to make one more search which led me to your post.

Thank you for the clean and clear instruction. I followed your ricipie and it worked like a charm the first time! No hassel, no conflicting directives, no contradiction with the existing set up!

The detail was just right and there was no "minor" thing assumed and left out! My satisfaction was complete!

Thank you for the effort.

Feseha A.

UNH, Genetics program

-reply by Feseha A