Hi,

I'm trying to set up a virtual host configuration in apache2. I have a 360 with a single IP. Ports.conf has:

Listen 80
NameVirtualHost *:80

There are two files in sites-enabled. One has:

<VirtualHost *:80>
    ServerName something.com
    ServerAlias *.something.com
    DocumentRoot /home/domains/something.com/public_html
</VirtualHost>

The other has:

<VirtualHost *:80>
   ServerAdmin webmaster@localhost
   Alias /bluewhales /usr/share/phpmyadmin
   
   DocumentRoot /var/www
</VirtualHost>

... but the site that shows up when I type in the server's IP is something.com, not the desired content in /var/www. I tried adding a ServerName directive, but that simply broke the stylesheet and image links when I viewed something.com by typing in the server's IP into my browser.

I also tried putting the /var/www vhost before the loading of the sites-enabled files in apache2.conf. Same result as adding a ServerName directive.

What am I doing wrong here? Thanks in advance.

what is the order those are loaded in sites-enabled? Make sure the one without something.com is loaded first (eg, link it as 000-default)

Ok, I renamed the link to 000-default, and the other to 001-something.com. Same result - the something.com vhost loads (but its images and css don't).

First, stupid question, but did you restart after that, right?

If so, then I think it looks like you need a ServerName in the first one. Without one, it's invalid. Try putting in webserver.something.com or even the linode defined default reverse (if you haven't changed it).

Yes, tried both of those things. It eventually started working once I removed a rewrite directive from the something.com one. Not really sure exactly why though. Thanks!

Try changing the first VirtualHost setting:



To look like this:

<VirtualHost something.com:80>
    ServerName something.com
    ServerAlias *.something.com
    DocumentRoot /home/domains/something.com/public_html
</VirtualHost>

Using "*:80" is basically a wildcard "any server name on port 80" directive. Your two VirtualHost configs are fighting for control. Not sure what the rules are on selection order within the Apache config parser, but it should be unambiguous anyway.

Good luck.
Lou

Bzzzzt! Wrong!
Indeed, it is counter intuitive, but the whole setup for name based (as opposed to ip-based) vhosts goes
[code]
# only once, not for every <VirtualHost> block!
NameVirtualHost theip:80

<VirtualHost theip:80>
ServerName thehostname
#optionally, zero or more of:
ServerName otherhostname
#DocumentRoot, or whatever you need for this vhost
</VirtualHost>

<VirtualHost theip:80>
ServerName secondhostname
#optionally, zero or more of:
ServerName yetanotherhostname
#DocumentRoot, or whatever you need for this vhost
</VirtualHost>
[code]
theip may be one specific IP (so you can put name-based vhosts on one of your interfaces, and do ip-based on others) or a *, and you can have more than one NameVirtualHost X <VirtualHost X></VirtualHost> sets, for different values of X. But you need to keep the value consistent.

So, skyraider's setup is right, and yours, keyslapper, wouldn't work.

Skyraider, the first-found VirtualHost block is the one that executes for names that not match. So, you need to put your "default" block as first, as glg said. And rewrites are tricky.

_________________
rsk, providing useless advice on the Internet since 2005.

I stand corrected. Using the IP instead of the server name is preferred. It's the absence of a ServerName directive in the second VirtualHost block that makes things not work quite right.

Do I get this right?

Always happy to learn that I still have a lot to learn

And there's this from the Apache VHosts docs:

If no ServerName is specified, then the server attempts to deduce the hostname by performing a reverse lookup on the IP address. If no port is specified in the ServerName, then the server will use the port from the incoming request. For optimal reliability and predictability, you should specify an explicit hostname and port using the ServerName directive.

So, with no ServerName, Apache is doing a reverse lookup. I'm guessing that would resolve back to the ServerName given on the first VirtualHost block, breaking some of the other links mentioned by the OP.