Padd Solutions

When I was setting up my server, I was faced with the problem of configuring subdomains to work with a dynamic DNS service such as DynDNS or No-IP. I recently had a user on the Ubuntu Forums ask me how I ended up getting things to work, so I wrote this article to explain.

The first step is to configure settings with your dynamic DNS service. The following instructions are for No-IP, but they should be very similar to other services such as DynDNS:

1. Navigate to the settings page for your domain.
    
2. Find the "Enable wildcards" option and enable it. This directs all domain requests, no matter the subdomain, to Apache. Here is a picture for No-IP:

After configuring your provider, next we need to configure Apache. In order to direct to the right location on the server, you need to configure Apache to know where each subdomain should be directed.

1. On your server, navigate to /etc/apache2/sites-available. This path is for Ubuntu, you will probably need to work with httpd.conf on other systems. This is where Apache gets information about sites and subdomains on Ubuntu.
    
2. If you have not already done so already, create a new .conf file. Although you can name it whatevery you want, it is useful to name it with the format, [yourdomain.com].conf. This file will be used instead of default because it is easer (for me at least) to start from scratch for something like this.
    
3. Open up the file, and add the following lines:

   <VirtualHost *>
   DocumentRoot /var/web/www
   </VirtualHost>

   This is the main entry, it directs all of the undefined subdomains (which we will define later - be patient) to /var/web/www. Of course, you will need to add your own configuration like log files; this is just the bare minimum to get you going. The path can be whatever you like. Note that your changes will not be added until step #6, so hang out.
    
4. Now you can define other subdomains and their paths. Here is an example for foo.clustur.com:

   <VirtualHost *>
   ServerName foo.clustur.com
   DocumentRoot /var/web/foo
   </VirtualHost>

   Notice the only difference is the ServerName attribute. You can add as many of these directives as you would like into your .conf file.
    
5. Now we need to enable the settings we just made:

   sudo a2dissite default
   sudo a2ensite [yourdomain.com].conf

   The first line disables the old default configuration file, and the second line enables your new .conf file, whatever you named it.
    
6. Finally, we can restart apache:

   sudo /etc/init.d/apache2 graceful

   Now all of your subdomains should work! If you're stumped or have any suggestions, please feel free to comment - I'll do my best to help you out.

My server used to have a 16GB hard drive, and did not receive regular automated backups. I wanted to upgrade the drive to an 80GB one and use the old drive for automatic backups. This switch required that I somehow move the entire server installation from the old to the new, larger drive. So I decided to use a tool called Clonezilla. I cloned the old drive onto the new drive, and set the new drive to the master. Booting up with the new drive worked fine. I put in the old drive (which still had the server installation) as a slave for backups. It was then that I ran into an interesting problem: no matter what I did, the old drive would always boot instead of the new one. After some probing, I found out that GRUB was run on the new drive, but it always pointed to the old drive. After about 6 hours of banging my head against the wall, I finally figured out that the UUIDs for the two drives were the same since they were cloned. Instead of using the generic (hd0,0), the Ubuntu distribution uses UUIDs by default to point to the drive that should be booted from. The UUIDs were not so universally unique anymore, and GRUB got confused and booted the old drive. So I guess the moral of the story is always make sure you change the UUIDs whenever a cloned drive is used. Anyways, sorry if this notice came too late. I hadn't expected to run into such trouble.

For reference, here's the steps to change a duplicate UUID:

1. Run uuidgen to generate a new UUID.
    
2. Type in tune2fs /dev/hdaX -U [newuuid] to actually update the partition's UUID. Be sure to replace hdaX with the correct partition and [newuuid] with the UUID given by uuidgen.
    
3. Verify that the UUID was changed properly with vol_id /dev/hdaX.

All bundled up, the command is uuidgen | xargs tune2fs /dev/hdaX -U ; vol_id /dev/hdaX. If you just need to clear out the old drive with the duplicate ID, reformatting it would do the trick, too.

If some of you are wondering, this is the source of the recent downtime my server went through. The sites that were affected included this one, and my NXT++ and Linux4nano wikis. The sites were on and off for about a period of 24 hours. I hope this short tutorial helps some people solve the problems I experienced.