Implementing Server Aliases

Implementing Server Aliases

Implmenting Server Aliases Mini How-To
Jeff Lasman, [email protected] 09/22/04 08:13

Often we have to make a site available to a client before his/her DNS has propagated; sometimes even before it's changed to point to the new server.

Some of us have had problems using the standard method built in to DA, which requires a URL something such as this:

http://www.example.com/~username

Often this won't work because of issues with php, perl, etc.

Here's how to set up a url such as:

http://username.example.com

with your user's name as username, and a domain under your control as example.com.

First log in to your control panel as admin.

Then click on "Custom HTTPD Configurations".

Then click on the domain name for which you wish to create a Server Alias.

In the customization window (the top window), type (as a new line):

ServerAlias username.example.com

again, where username is same as your user's name, and your domain name as example.com.

Then click on "Save".

Now, still logged in to the DA control panel as admin, navigate to the "DNS Administration" screen, and then to the domain name you've substituted for "example.com".

Note: This is NOT the same as the domain name you used when you set up the ServerAlias, but rather the working domain name under your control you used when you set up the Server Alias.

Add an CNAME record for username.example.com pointing to example.com.

Once it's added you can log out of the control panel.

You should be able to use the ServerAlias immediately.

If you can't, these are the steps to check:

1) make sure you've followed the steps correctly.

2) verify if you've tried username.example.com before you set it up. If you have, you may have to restart your browser, or even your system or local network, or you might have to wait until your ISP clears it's cache.

Please report any difficulties in following this How-To, so we may correct any errors.

Thanks!

I agree this is a much nicer format than the standard userdir with horrid tilde gubbins.

For utter simplicity, on one of my servers I've been using a single VirtualHost with a wildcard ServerAlias, in combination with a VirtualDocumentRoot. eg.

<VirtualHost 10.20.30.40>
DocumentRoot /home/mainwebuser/www/somedomain.com
ServerName somedomain.com
ServerAlias *.somedomain.com
UserDir public_html
Options FollowSymLinks Indexes

# Give all the users on this machine access to their home dirs
# via the subdomain host request
VirtualDocumentRoot /home/%1/public_html

</VirtualHost>


Just one virtual host lets all of my users serve web content via a subdomain.

(I should mention that this also requires a wildcard A record for *.somedomain.com)

------

I have a question about how this way of doing things sits with DA, but I'll start a new thread.

Domain shared by multiple machines?

I am attempting to implement server aliases essentially as described, but I want to not use a different domain suffix for each server. For example, suppose we have three machines running Directadmin, called aaa.example.com, bbb.example.com, and ccc.example.com. I want to give each user on each of these three machines a URL of the form http://joe.example.com/ . (Obviously usernames will be chosen so they are unique across all three machines.)

So far, it seems to me that if the domain suffix "example.com" is assigned to the control of a reseller-admin on machine aaa, then Directadmin will configure machine aaa to hold the entire DNS zone for "example.com' This then prevents "example.com" from also being used in the same way on machines bbb and ccc.

Is there any way of telling Directadmin to allow a reseller-admin to use subdomains within "example.com" but WITHOUT trying to control DNS for example.com? Then the DNS pointers can be set up on external name servers separately from under Directadmin control, and the same domain suffix (here "example.com") can be used site-wide as oppposed to only machine-wide.

Rahul

If I understand you correctly, don't add the CNAME on the machine holding the new domain, but do add it manually on the machine where the example.com domain exists.

Jeff

I think I need to correct my question, as my assumptions were wrong. Here is the corrected question.

A reseller called "joe" logs into his Directadmin control panel and creates a new user called "sue". On the user creation screen, he specifies the domain for "sue" as: "sue.example.com". This results in a new user "sue" whose domain is "sue.example.com". And separately, we go to the nameserver(s) for example.com and add an "A" record for "sue.example.com" pointing to the server that holds "sue". So far so good. Sue ought to be able to access her web site as http://sue.example.com/ .

The problem is that Directadmin will ALSO create a new DNS zone called "sue.example.com" and add it to the nameserver(s) over which Directadmin has control. In the best case this is an orphan zone as no NS records anywhere else point to it. But in the worst case something bad might happen due to the existence of this superfluous DNS zone, even though I do not know what that might be.

So the question is: How do we tell Directadmin to not create a new DNS zone called sue.example.com? We need to do this selectively, because there might be other domains added for which we do want Directadmin to create a DNS zone.

Rahul

We've never deleted these; they'll only cause problems if they get out of sync and if someone is using the server for DNS resolution (you shouldn't be; you should be using your ISP's caching nameserver), or if you're server (perhaps a form on the server) is trying to send mail, and the MX record on your server is wrong.

But it's easy enough to delete the records; the site admin can delete any DNS zone.

Jeff