Computer related mumbo jumbo

Updated versionThis is an updated guide for Ubuntu 12.04. If you use an older version of Ubuntu, then you might want to check out the old guide, that was written for Ubuntu 8.04.

Information
The steps in this post shows how to configure the DHCP server to automatically update the DNS records when giving out a new lease to a client computer. All on the Ubuntu 12.04 Precise Pangolin server.

Before continuing
These steps assumes that you already have a working copy of isc-dhcp-server and bind9 installed. If you don’t have that I suggest that you first read my two other posts on how to install them:

Apparently the Ubuntu server is installed with an AppArmor profile that prevents bind to write to the /etc/bind directory. The default profile suggests that these files should be put in /var/lib/bind. If you have followed the steps in my previous post you might have your zone database files in /etc/bind/zones. We will start by copying the files so we have a backup remaining if anything goes wrong:

1.1 Copy the zone database files:

sudo cp /etc/bind/zones/* /var/lib/bind/

1.2 Change the owner and group of the files to bind, so that bind will have file permissions that allows it to write to the files:

sudo chown bind:bind /var/lib/bind/*

2. Create a secret shared between the DHCP server and the DNS

We don’t wont just anybody to be able to update our DNS, so we need to create a secret key that the DCHP server must know in order to be able to update the DNS.

2.3 Now copy the key to the clipboard so that you can paste it into the configuration file later on.

3 Configure the DNS

We now need to add the key to the bind configuration and tell it what zones that we want it to allow updates on. I’ve included the whole contents of my file here and marked the changes that I’ve made in bold.

3.1 Edit /etc/bind/named.conf.local:

sudo nano /etc/bind/named.conf.local

3.2 Changes are marked with bold:

# The secret key used for DHCP updates.
key DHCP_UPDATER {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
# Important: Replace this key with your generated key.
# Also note that the key should be surrounded by quotes.
secret "asdasddsaasd/dsa==";
};
zone "home.lan" {
type master;
# Change the path of the database file to the writable copy in /var/lib/bind
file "/var/lib/bind/home.lan.db";
# Tell this zone that we will allow it to be updated from anyone
# that knows the secret specified in the DHCP_UPDATER key.
allow-update { key DHCP_UPDATER; };
};
zone "0.168.192.in-addr.arpa" {
type master;
# Change the path of the database file to the writable copy in /var/lib/bind
file "/var/lib/bind/rev.0.162.198.in-addr.arpa";
# Tell this zone that we will allow it to be updated from anyone
# that knows the secret specified in the DHCP_UPDATER key.
allow-update { key DHCP_UPDATER; };
};

Database files being rewritten by bind
The dns database files are now being rewritten by the bind service. Some people have mentioned that they think that bind messes up these files so that they are impossible to maintain. I don’t think that they are that bad and personally I don’t have any problem editing them after that bind has rewritten them. I’m not sure how often that bind rewrites these files, but at least it seems to always happen when you stop the bind service.

What I think is more important is to always freeze the zone file before editing it, otherwise they might be overwritten by bind.

Examples of how to freeze and unfreeze a zone:

sudo rndc freeze home.lan.
sudo rndc unfreeze home.lan.

Also, do not forget to change the serial in the zone file if you change anything in it.

If you want to avoid the problem with bind rewriting the files and the need to freeze and unfreeze zones, then you could split your domains into two sub domains, for example dyn.home.lan. and static.home.lan. You could then have the DCHP server to only update the dyn.home.lan domain. But I didn’t want this and I’m not going to update these files that often that it matters to me.

Key generation
When using the dnssec-keygen to generate the secret key I passed it the parameter “-r /dev/urandom”. I’ve seen some pointers about that this will generate a less secure key. But for me the dnssec-keygen would just halt without that parameter. One other suggestion that I’ve seen it that you should switch to another terminal window on the server and run some commands that make some work on the server, to make it fill up the default /dev/random. I think that I would have done this if I would set this up in a corporate environment. But for my own home network I really think that the /dev/urandom will be sufficient.

Troubleshooting
There must be many more ways to troubleshoot any problems. But I managed to get it working by checking the system log for clues when a service didn’t start or when the DHCP server didn’t update the DNS records:

tail /var/log/syslog

That’s it!
I’ve really tried to make these steps as accurate as possible, following my own steps to get this to work. Please let me know if you think that I’ve missed something. Thank you.

Acknowledgments
* Thanks to Phil who commented on the previous version of this guide with this tip on rndc freeze and unfreeze.
* Thansk to Soeren Hedemand who also commented on the previous version of this guide with information about changing the group and owner of dhcpd.conf to dhcpd to solve the problem with the dchpd sometimes not starting as it should.

2.2: Set INTERFACES=”” to the name of the network interface that you want to enable the DHCP server on:

INTERFACES="eth0"

3.1: Edit the DHCP server configuration:

sudo nano /etc/dhcp/dhcpd.conf

3.2: The contents of my configuration file, for me the comments already in the file was what I needed to make the necessary changes:

# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;
# option definitions common to all supported networks...
option domain-name "home.lan";
option domain-name-servers ubuntu.home.lan;
default-lease-time 600;
max-lease-time 7200;
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;
# This is a very basic subnet declaration.
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.100 192.168.0.200;
option routers router.home.lan;
}

This is my updated step by step procedure that I took to setup my local dns server for our local network at home using Ubuntu 12.04. If you have an older version of Ubuntu you might want to instead check out the old guide, that was written for Ubuntu 8.04.

Step by step instructions

1: Make sure that the latest version of bind9 is installed (that’s the dns-server software):sudo apt-get install bind9

2.2: Uncomment or add the forwarders section and replace the x:es with the ip-address to the primary and secondary dns of your isp:

forwarders {
x.x.x.x;
x.x.x.x;
};

Tip: I use OpenDNS as my forwarders, currently 208.67.222.222 and 208.67.220.220.

3.0: Make the server use its own DNS for look-ups:
How to specify which DNS server to use depends on if you are using a dynamic or static ip address:

3.DYNAMIC.1: Edit dhclient.conf:sudo nano /etc/dhcp/dhclient.conf

3.DYNAMIC.2: Uncomment or add the following line:prepend domain-name-servers 127.0.0.1;

Note: 127.0.0.1 points to the local machine, making the DNS requests go through our DNS server that we are setting up.

[OPTIONAL]
You might want to also add a search directive to eliminate the need of typing the FQDN when looking up local records. But you should only do this if you cannot control this information in the DHCP server. If you setup the DHCP server as well, then you should make sure that the DHCP server provides the search directive. It would then be automatically used by the DHCP client.

Note 1: home.lan is the domain name of our local network in this guide. A DNS search directive is used to eliminate the need of typing the FQDN when looking up local records.

Note 2: This setup must also be done for other Ubuntu clients that use a static IP. But then it should point to the IP of our DNS server. If you have a DHCP server you should specify your DNS IP in its settings, as well as the search domain.

4.1: Define the zones for the local domain:sudo nano /etc/bind/named.conf.local

Note: Make sure that it’s literal quotes that are used, so that they aren’t converted if you copy and past them to the terminal. You get literal quotes on a Swedish keyboard by pressing “Shif+2”, on an English keybord it might be “Shif+,” ?

; Use semicolons to add comments.
; Host-to-IP Address DNS Pointers for home.lan
; Note: The extra “.” at the end of the domain names are important.
; The following parameters set when DNS records will expire, etc.
; Importantly, the serial number must always be iterated upward to prevent
; undesirable consequences. A good format to use is YYYYMMDDII where
; the II index is in case you make more that one change in the same day.
$ORIGIN .
$TTL 86400 ; 1 day
home.lan. IN SOA ubuntu.home.lan. hostmaster.home.lan. (
2008080901 ; serial
8H ; refresh
4H ; retry
4W ; expire
1D ; minimum
)
; NS indicates that ubuntu is the name server on home.lan
; MX indicates that ubuntu is (also) the mail server on home.lan
home.lan. IN NS ubuntu.home.lan.
home.lan. IN MX 10 ubuntu.home.lan.
$ORIGIN home.lan.
; Set the address for localhost.home.lan
localhost IN A 127.0.0.1
; Set the hostnames in alphabetical order
print-srv IN A 192.168.0.9
router IN A 192.168.0.1
server IN A 192.168.0.5
ubuntu IN A 192.168.0.2
xbox IN A 192.168.0.3

You should have a firewall between this server and the internet and make sure that the dns port (53) is not forwarded to your Ubuntu server. Otherwise your dns server will be open for anyone in the world to use. With this setup it is only intended to be used within your local network.

Do not forget to update the serial every time you make any changes to a zone file.

This is an updated guide for Ubuntu 12.04. You might want to check out the old guide if you are using an older version of Ubuntu. The old guide was written for Ubuntu 8.04.

This new version is updated with the command “service ssh reload” instead of “/etc/init.d/ssh reload”. And I have also learned of better way to test connecting via ssh without using the key file (-o PubkeyAuthentication=no, for testing purposes).

Ubuntu ssh step by step guide

1. Generate the ssh key pair on your client computer:ssh-keygen

2. Copy the public key to the server:scp ~/.ssh/id_rsa.pub user@10.10.10.1:

5. Edit the ssh server configuration to make sure that public key authentication is enabled (it should be enabled by default):sudo nano /etc/ssh/sshd_config

5.1 These entries must be set to yes:RSAAuthentication yes
PubkeyAuthentication yes

6. Reload the configuration:sudo service ssh reload

7. Disconnect from the server:exit

8. Try connecting without the need to give the password to the ssh-client:ssh user@10.10.10.1

You might need to give a password now to access your private key file, but you should not need to give the password to the ssh program.

9. Disable password authentication:sudo nano /etc/ssh/sshd_config

9.1 The following settings should be set to no:ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

9.2. Reload the configuration:sudo service ssh reload

10. Test that password authentication really is disabled:
10.1 Disconnect from the server:exit

10.2 Try to reconnect to the server with key file authentication disabled:

ssh user@10.10.10.1 -o PubkeyAuthentication=no

This should produce a permission denied message: “Permission denied (publickey).”

Done 🙂

Troubleshooting

If you ran into any problems it might help to check out the pointers in the comments of the old guide. I highly value the constructive comments that I have received, as I often learn something new from them.

1.2: Change from dhcp to static:Note that the changes below are edits, not the complete file. We change the word on the first line from dhcp to static. The rest of the file should be kept intact with the loopback interface settings.

2: Remove old configuration files used to generate resolv.conf:
The file resolv.conf should no longer be edited by hand. It is updated by the resolvconf script. To prevent resolvconf to still generate our resolv.conf file with our old dhcp settings we have to delete these two files:sudo rm /run/resolvconf/interface/eth0.dhclient
sudo rm /run/resolvconf/interface/original.resolvconf

3: Uninstall the dhcp client (otherwise it will overwrite our changes on the next renew cycle):sudo apt-get remove isc-dhcp-client

4: Restart the network to use the new settings:
The command “networking restart” has been deprecated. We can instead bring the interface down with ifdown and back up again with ifup to reload the settings. If we do it over an ssh connection we will lose connectivity when we bring the interface down. To solve this problem we can chain the two commands together. But doing so will prevent us from seeing the messages outputted from the commands, which can be useful in case something went wrong. We can then use the nohup command to direct the output to the file nohup.out:

5. Check that everything is working ok:
5.1 The resolv.conf should now only contain the dns settings that we provided for our interface (eth0), check with:sudo cat /etc/resolv.conf

The result should look like this:# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 208.67.222.222
nameserver 208.67.220.220
search home.lan

Ubuntu 9.10 alpha 3 comes with the latest GDM (The GNOME Display Manager, which is the default login manager shipped with Ubuntu). Unfortunately the latest version, 2.27.4, is an unstable version that still is heavily under development and still lacks a graphical configuration dialog.

So if you, like me, decided that you actually wanted to login automatically in GNOME instead of the manual login that you choose in the installation process, or vice versa. Well then it’s back to the configuration files. The default configuration values used by GDM is located in the XML file named ‘/etc/gdm/gdm.schema’. The documentation does however state that any changes to the default values should be made to the ‘/ect/gdm/custom.conf’ file, which is in keyfile format.

Configuration explanation

Note that the [deamon] directive must be included in the file, it tells GDM in what section we want to override the keys. The AutomaticLoginEnable key can be set to either true or false, to disable or enable the automatic login into GNOME. And finally the AutomaticLogin key should be set to the username of the user that should be loged into GNOME automatically, in the example above my username is lani.

I thought that it worked at first, I did several tests, downloading in 100 mbit from the internet using 10 different connections and transfering files from my server in 275 mbit. But today the network connection has dropped twice for me. If this works for you, then I’m happy for you. If you have another solution, please leave a comment. Thank you.

I have an on-board Marvell Yukon 88E8053 PCI-E gigabit ethernet controller (rev 15), which kept dropping the network connection during heavy load using the sky2 driver. I tried to compile the sk98lin driver instead, but I couldn’t get it to compile successfully on my system. That’s when I found out that MSI might not be correctly implemented, fortunately the MSI feature can be easily turned off in the latest sky2 driver using the disable_msi option.

Permanently disable MSI

1. Open the /etc/modules file for editing:

sudo gedit /etc/modules

2. Add the following new line:

sky2 disable_msi=1

3. Restart your computer. And viola, hopefully your NIC will now have stopped dropping your connection all the time.

Temporarily disable MSI

If you would like to test if the diable_msi option works for you before disabling it “permanently”, or to avoid a restart. Then you can unload the sky2 driver manually and load it with the disable_msi=1 option.