Wedge

Yup. All the virtual hosts are defined as being * but without any port designation, while you clearly state that Named Virtual Hosts should use *:80 in ports.conf.

(And yes, this is Apache 2, httpd.conf is deprecated in favour of apache2.conf and lots of sub configuration files)

It actually shouldn't matter, Apache is bound to port 80 through the Listen directive so it should just be a case of Apache complaining but still actually serving files correctly.

You're right! ;)
I changed all websites to *:80 and the error disappeared. :D

Now it's time to test if the virtual hosts actually work. So I have 3 available websites (let's say example.com/org/net), I just need to point their A records to the server IP? I think I need to do something with the /etc/host.conf file too.. currently it has only these lines:

Yup, you just point all the records at the server and let the HTTP request indicate which one it wants.

You don't need to change /etc/host.conf (I think you mean /etc/hosts), you just need to make sure whatever you're using for external DNS points to the right server, and that each of your virtual hosts has the proper ServerName defined like yours does.

What happens is that each request will come in with the Host header set as part of the request, Apache will look through all the name based virtual hosts for any server whose ServerName matches the Host header as indicated, and will work with that one if it's matched.

If no matches are found, I forget exactly what Apache does but I believe it goes to the last one defined as a fallback.


(Interesting: the link still gets processed even inside a code tag >_<)

Seems magic! :D
So it doesn't matter the name of the "available-website", but just the one specified in "ServerName"? I could have the website named sadsadsasad.com but the ServerName set to the right domain?
ServerAlias takes care of the www and non-www version, right? :)

Correct. The name in available-sites (at least that's the default Apache folder name) is only an internal name for your reference.

ServerName is the directive that tells Apache what to look for and ServerAlias is for declaring alternative variations of the same handler, exactly as you indicate - you can declare ServerName example.com and ServerAlias www.example.com and Apache will match either to find that host. ServerName must be declared once per host, but you can have as many aliases as you want.

A little late to the party, and a little OT. I applaud you using 12.04 (guessing this was a new VPS/VM), but as a warning to existing LTS users I wouldn't recommend upgrading to it (yet). It's very "unstable" at present; *lots* of updates... Needs a few months to settle down then it'll be good to dist-upgrade to.

Great! Everything works fine! My website loads from my virtual server! :D
Now that this new available-site works, what happens if I delete the default one? What would be displayed if I try to reach my IP?

Are there any security tecniques to adopt (apart from permissions) or configurations to make to improve security?
So far I just added these lines to apache.conf (dunno if are of any help..):

There are a couple of things you can do, one is run every site in their own user/group using suPHP/PHPSuExec/PHP-FPM (one of these, fpm being recommended). Apart from that you can install php suhosin and enable open_basedir (even though this shouldn't be required if you got user/group properly configured, but never hurts). There are a few other things that I'm probably forgetting, but search around.

I'll agree with FPM (especially as it means you can run nginx instead of Apache), but I can't in good conscience recommend suhosin. The number of times I've found software randomly break for no apparent reason just because of suhosin, I find it's more effort than it's worth.

Groups/users is sort of irrelevant if you have software that can update itself through the admin panel since that requires making the software writable by the web server user. (Yeah, I know that suPHP and PHPSuExec are supposed to do this but rarely seem to work properly in that respect)

I haven't really had a problem with suhosin, but to each it's own. Group/user is more for preventing a site from accessing other site (so one site's weak site weak security doesn't result in all of the sites getting hacked). Plus FPM will make the instance of apache run in that user/group so it doesn't need to be writable by nobody, but only the user of the site itself.

Wait... how will FPM make Apache run in that user/group? FPM is what you use to run a pool of PHP processes that nginx can use...

(I've not used FPM with Apache. But the design of FPM is fundamentally stronger than doing it any other way because things aren't just shoved at FPM the way they are with other routes)

Slightly incorrect wording there, FPM doesn't make Apache run in that user/group but it does make apache's user/group irrelevant. From what I understand with FPM Apache/Nginx just routes the request to FPM/FCGI and then FPM processes the request. At that point Apache's user/group doesn't matter anymore since FPM/FCGI is running the PHP process, so the scripts are executed with FPM's user/group. And FPM has the ability to have different user/group for different ports/sites. Hence, once can change the user/group php runs in and prevent those files from accessing files of other user/group, just make sure you don't have everything 777.

Hmm, I suppose that makes sense. Need to check on that, though, because I didn't think FPM did the whole different user thing.

I've been using that setup as an alternative to suExec/PHPSuExec (since both haven't received any updates in years) in my new server. Plus [Unknown] recommended a nice permission setup which IMO is fairly logical and I have been using it for well almost a year. Basically, make all the web server files chown'd to site-user:site-user and make the web process run as site-user-www:site-user (user being different and group being same). Then chmod all files which are primarily read only to 640 and the folders which require write to 750/770 (don't remember properly, should be 750), and make sure that these folders cannot execute PHP scripts. That way, all the other user's are completely locked out, and at the same time you don't sacrifice complete access to the files but still lock PHP out enough to maintain control. Plus if someone gets in, they cannot modify a PHP file or run a script and hence run it securely.