Dave's Blog

The old Athlon 64x2 I had been using as my VMware server was having more than a little trouble running a virtual server and several virtual clients for my IPv6 tests and experiments. Although the hardware was not on the VMware compatibility list, the only thing I had to do to make it compatible was to install an Intel gigabit ethernet card and VMware installed and worked well. I decide that something with more cores and more RAM would probably "greatly enhance" my VMware experience so I bought an AMD Phenom II x6 CPU and supplied it with 16GB of RAM on a Gigabyte motherboard. Big mistake.

Morning: A time of mental anguish, emotional pain and suffering, and sorrow. Not to be mistaken with mourning which is when you have similar feelings because someone has died as opposed to just having to get out of bed.

W00t!!!!

Yes, you can take that as it's sort of working. It took finding one more level of the systems doing something that wasn't quite what I had in mind. This time it was the "memory" built into the DHCP implementation that meant that changes made by me weren't taking effect. It seems that DHCP lease information is cached on both the client and the server as a means for either to just put things back into place after a reboot. This is great except the check for "is the last set up still good?" failed to take into account the possibility that the configuration had changed. Once I started clearing the client and server leases before testing things became a lot clearer.

CentOS 5.6 has been released. The updates have been downloaded but I will need to reboot the server at some point. Dave's Blog will be unavailable for at least long enough for my server to reboot. Based on past experience, there will probably be some issues that I will need to fix before the server will be fully "back to life."

Update as of 23:25 9 April 2011:

Up and running again. This time I used find to find all of the .rpmnew files and brought forward my old settings to the new file. I probably missed something but at least httpd, named and sendmail seem to be working.

I ended Part 5 of this saga with the observation that I needed to do more investigating to find out why I could get IPv4 DDNS entries and I was somehow able to force some IPv6 DDNS entries but these entries weren't apparently getting created by the network initialization scripts. My suspicion soon fell on NetworkManager (a.k.a. network-manager). I attempted to force Network Manager to use the dhclient.conf file that worked for me from the command line only to find out the NetworkManager dynamically creates its own dhclinet configuration file (in /var/run/nm-dhclient-ethX.conf). So what was happening was dhclient was sort of doing the right thing when I ran it from the command line but was not doing the right thing when run by NetworkManager. This mean that NetworkManager had to go at least until I found a working configuration for dhclient.

Success (sort of)!!!!!

As I mentioned in Part 4, I pulled down an evaluation copy of Red Hat Enterprise Linux (RHEL) 6 and made that my new server. That was an interesting adventure but all I had to show for my efforts was DHCP dynamically creating the DNS forward entry for my Ubuntu Natty Narwhal test system. I attempted to debug the problem (no reverse DNS entry) using nsupdate which at least let me know that there was some sort of "authorization" problem. The interesting quirk of the problem was that IPv4 DHCP was working flawlessly for both forward and reverse DDNS and was also successfully updating resolv.conf.

I ended Part 3 of this series stating that I would look into "building my own" version of the Internet Software Consortium (ISC) client for my Ubuntu 10.10 system or just moving to an early version of the next Ubuntu release. Let's just say that building my own DHCP client and integrating it into the Ubuntu network start-up scripts was a bigger undertaking than I had imagined. Instead I pulled down an alpha version of Ubuntu "Natty Narwhal". The Natty release is surprisingly stable for an alpha but, unfortunately, had the same problem as 10.10: I still got the message, "client6_recvreply: unexpected reply."

My ultimate goal in this endeavor is to have my real home network running on IPv6 with no loss of functionality as compared to how I have things working now with IPv4. In particular, I want to be able to configure tools like amanda or use ssh using host names; not IPv6 addresses. Since I currently accomplish this functionality with tools like DHCP and dynamic DNS updates, I wasn't expecting to encounter any problems. It turns out that this functionality is still somewhat in flux when it comes to IPv6.

Part 1 described the preliminaries of just getting an IPv4 network set up using virtual machines (VMs) under VMware ESXi. This included configuring the CentOS 5.X VM as a server/router and establishing two more client VMs, one running Ubuntu and the other also running CentOS 5.X. The Ubuntu VM was upgraded from 9.04 to 10.04 once connectivity was established. Once the VMs were all functioning and stable, it was time to start playing with IPv6.

While getting the initial IPv4 configuration of the VMs established, I was reading the IPv6 Deployment Guide. This gave me some excellent background and a desire to actually see how things worked.

I haven't done anything all that interesting with my home network for quite a while. Everything "just works" which is nice but really boring. At some point in the future when CentOS fully supports it I will implement DNSSEC. In the meant time I decided to see how far I can move toward IPv6. Besides being interesting, it might actually make me a little more employable.