The DHCP server has a pool of addresses that it is allowed to hand out to clients, and it will often hand out these addresses sequentially. In some cases, the address chosen for a particular client may be based on some sort of hash function on the client’s MAC address (so that the client will always be assigned the same address, unless there is a hash collision).

Of course, sometimes it’s nice to assign a particular device on your network a specific IP address (a “static” or “fixed” IP address). This way, you will always know without any doubt what the IP address or your printer or file server or whatever is. Of course, you can just set the address manually on the device, taking care to place it outside of the DHCP pool.

Another way to go about it is to reserve a specific IP address for your device on your DHCP server using the device’s physical (or “MAC”) address. This is handy if you have many devices that you would like to assign fixed addresses to – if, for whatever reason, you ever want to change the IP address of something on your network, you just make the change on the DHCP server and you do not have to bother touching the device itself. The change will take place the next time the device renews its DHCP lease.

Using the DHCP server included with Ubuntu Server, if you would like to assign a fixed address to a particular device, just add some lines like this to /etc/dhcp3/dhcpd.conf:

host aaron-vmware {
    hardware ethernet 00:0c:29:f8:47:3e;
    fixed-address 192.168.100.81;
}

Restart the DHCP server configuration using sudo service dhcp3-server restart and you’re all set.

Unable to restart Named: dnsmng failed: dnsmng failed: dnsmng: Service /etc/init.d/bind9 failed to restart

(What a great error message.)

Whoops. Turns out there’s a problem with the default Plesk configuration of the DNS server BIND (run it in a chrooted environment) and Ubuntu’s configuration (run it with AppArmor, explicitly configuring which files it is allowed to open). You have to give BIND permission to open the files in its chroot environment. The solution to this problem is to edit the file /etc/apparmor.d/usr.sbin.named and add these lines before the closing brace at the end of the file:

/var/named/run-root/etc/* rw,
/var/named/run-root/var/* rw,
/var/named/run-root/dev/* rw,

Then, reboot the machine and you should be good to go.

The problem: You’ve enabled automatic security update installation, and yet, security updates are not being automatically installed.

First possible solution: This one is easy. Check the file /etc/cron.daily/apt and make sure that it is marked executable. Permissions on this file should look like rwxr-xr-x (755). This file somehow lost its executability when I upgraded from one Ubuntu release to the next, which broke the daily update check and thus no automatic security update installation.

In the more recent occurrence of this problem for me, the daily update check was obviously happening. I would connect to the server via SSH and see something like…

Welcome to the Ubuntu Server!
* Documentation: http://www.ubuntu.com/server/doc

5 packages can be updated.
5 updates are security updates.

So, the daily update check was happening, but the automatic update installation was not. What could cause this?

Well, it turns out that the script that does the update installation will only proceed to that point if the check for updates was successful (no errors at all). This leads us to…

Second possible solution: Run a sudo aptitude update or sudo apt-get update and see if there are any errors. If there are, address them, and hopefully that will resolve the problem. In my case, I had a third-party repository that had become inaccessible, so although the main Ubuntu repositories were updating fine, this error still prevented automatic security update installation.

If you want to know how to set up automatic security updates, there are (at least) three possible ways:

• When first installing the system, you will be given the option to enable automatic security updates.
• Follow the directions on this page in the Ubuntu Wiki. I recommend the apt.conf.d method (which is what will be set up for you using either of the other options presented here), but, the cron method may help you get around other similar issues that prevent automatic updates from working.
• You can set it up using the GUI method like you would with a desktop version of Ubuntu. First, install Synaptic (sudo aptitude install synaptic). Then, make sure that you are connected to your server via SSH with X11 forwarding (by adding the -Y parameter to ssh when you connect). Then, run Synaptic on the server as root (just type “sudo synaptic” at the terminal) and the Synaptic window should appear on your desktop. Then, select “Settings -> Repositories” from the menu, click on the “Updates” tab, and configure automatic updates as you see fit.

Update: November 12, 2010

There is a bug in Ubuntu 10.10 that seems to only affect 32-bit installations but prevents automatic security update installation.  See here for details.  A fix is already available upstream in Debian; hopefully it will be pushed on to Ubuntu users soon.

I recently replaced the machine that powers this very web site with a better one.  This was my first migration since switching to Ubuntu Server last winter.  I essentially took the hard drive out of the old machine and plopped it in the new one, booted it up, and hoped for the best.  Since Linux is not as picky as Windows about being moved to a new set of hardware, I figured it would work out fine.

Sure enough, Ubuntu booted right up on the new machine without so much as a complaint.  However, network connectivity was gone.  The old machine was using a PCI Ethernet card, while the new machine had an on-board controller that I hoped to use.  Anyway, I took the PCI card from the old machine and put it in the new machine, and then the network connectivity was back.

Why wouldn’t Ubuntu just start using the on-board controller, though?

Well, it turns out Ubuntu Server, in its default configuration, remembers which MAC address goes with which Ethernet device.  (This as opposed to the default configuration on the desktop version, where NetworkManager handles this dynamically.)  This information is stored in /etc/udev/rules.d/70-persistent-net.rules, and looks something like this:

# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x14e4:0x4401 (b44)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

Here, my old Ethernet card (e100) and my new card (b44) are listed as eth0 and eth1.  In /etc/network/interfaces, I only had a configuration for eth0.  Thus, no network connectivity when that card was not present.

The solution is simply to modify /etc/udev/rules.d/70-persistent-net.rules so that the card you want is eth0, or to add an appropriate configuration for eth1 in /etc/network/interfaces.  Of course, the entry in the rules file for the adapter that is no longer present should be commented out or erased. Anyway, after making these changes and bouncing the Ethernet kernel modules (or just rebooting the machine), things should work how you like.