Copying symbolic links

Sometimes it's useful to copy a directory that contains symlinks. The default cp behaviour is to follow the symlink and copy the file the symlink points to. If you want to preserve the symlinks as symlinks, then the flags the cp command uses depends on the operating system:

Solaris 10 and Linux:

$ cp -rP dir1/* dir2

The -r is recursive (in case dir1 has subdirectories) and the -P preserves the symlink.

AIX 5.2:

$ cp -rh dir1/* dir2

The -r is the same as Solaris, the -h preserves the symlink.

Does XenServer have a future?

Citrix has made their hypervisor based virtualisation product, XenServer, available for free. There has been a free "Express" version out for a while, but this was limited in the number of VMs it could support and came with a limited subset of functionality (similar to ESXi).

The new release makes most of the Advanced functionality available for free, including multi-server management and live migration between hosts. This competes with VMware very well, to the point that a virtualised Citrix (XenApp) solution I am working on will most probably run on the free XenServer and not on the pay-for ESX.

So why do I wonder whether XenServer has a future?

Citrix are looking to get customers hooked on XenServer with the aim of upselling a management suite called "Citrix Essentials for XenServer". The thing that concerns me is they also have a product called "Citrix Essentials for Hyper-V".

On the one hand this makes sense. By providing the same management tools for both XenServer and Hyper-V, Citrix are trying to make the underlying hypervisor a commodity item. The real advantage is in the management layer.

But development of XenServer is not free, and Citrix get no money directly from it. So why bother continuing development in the long term, when they can "superset" on top of Hyper-V, a hypervisor that Citrix don't have to spend any development funds on.

I hope I'm wrong, because XenServer looks interesting, but it wouldn't surprise me to see a future announcement where Citrix drop XenServer and adopt Hyper-V as their favoured hypervisor.

WSUS under Server 2008

I configured a WSUS server under Server 2008 and created a GPO to instruct all the other Windows VMs in my test environment to point to it. Although the GPO was being pushed out, the WSUS console did not detect any computers.

After speaking to some colleagues about this (thanks Rob!), I tried manually running a Windows Update from one of the clients. This produced the following error: 80072EE6

Googling this suggested the problem was an "unknown protocol" and one post suggested checking that the GPO settings for the intranet server included the "http://" prefix before the hostname. I checked and found I didn't have that setting. Adding it in and then forcing a gpupdate worked and the clients have started to appear.

Joining an OpenSolaris CIFS server to an AD domain

These notes are rough, but might prove useful in the future (or to someone else who had the same problem). I wanted to join my newly created OpenSolaris 2008.11 installation to my experimental Windows Server 2008 Active Directory. I followed the tutorial in the Solaris CIFS Administration Guide, but when I attempted the actual join command, it failed with LOGIN_FAILURE.

Here's the answer:

Firstly, make sure you have the IP address setup correctly, name added in /etc/hosts, DNS setup correctly in /etc/resolv.conf and /etc/nsswitch.conf. You make sure you are on the same domain as the Active Directory ("windows.zone" in my case).

Secondly, make sure your system clock is synchronized with the domain controller:

# ntpdate dc01.windows.zone

Then setup Kerberos by editing /etc/krb5/krb5.conf. This is documented in the manual.

Install the SMB Server using the package manager and start it up using:

# svcadm enable -r smb/server

Then try to join the domain:

# smbadm join -u administrator windows.zone

For me, this is where it failed. The mailing lists suggest that the problem might be related to smb signing. On the DC, I opened up the Group Policy Management tool and changed the following:

Computer Configuration\Policies\Administrative Templates\System\Net
Logon\Allow Cryptography Algorithms Compatible with Windows NT 4.0 -> Enabled

I then ran a gpupdate /force.

Finally, I read that the sharectl command on the OpenSolaris server should be run to use NTLMv2 authentication:

# sharectl set -p lmauth_level=2 smb

I re-ran the join command, and it worked properly. OpenSolaris CIFS server now part of the Active Directory domain.

Installing OpenSolaris into VMware ESXi

I've just created a very small VM for installing OpenSolaris onto my ESXi box. The ISO CD booted in live mode to the desktop and I selected the option to install to disk.

The installer loaded, but at the point of "Finding Disks", the installer seemed to hang and no disk was found, even though format was displaying the disk okay.

Upon further investigation, I realised that the amount of RAM I had assigned to the VM (512MB) was causing a problem. By increasing this to 1GB, the disk was found and the installer worked as expected.

My guess is that this is due to Solaris deciding that with only 512MB of RAM, that some swap would be necessary, but it's not able to create it. Only a guess, but at least I now have a workaround.

Getting NFS4 permissions working correctly

Following the installation of the OpenSolaris server, I've had some problems with the NFS mounts. I've created an export for a fileserver (datapool/filestore) and although I have setup identical UID/GID maps between my clients and servers, when I mounted the filesystem on my Linux server, I found that files created were owned by nobody:nobody.

At first I thought this was due to some configuration problem in the OpenSolaris installation, but after trying it with the Mac as well, I realised that the mapping was fine. This then pointed to the OpenSUSE 11.1 installation.

The problem turned out to be the Domain setting in /etc/idmapd.conf. The value in this file was different from the OpenSolaris NFS domain. Changing that and restarting the idmapd process (which I did by rebooting the server as I had a kernel update to do), fixed the problem and I now map correctly.

The next step is getting a Samba and Windows client to authenticate me correctly with the OpenSolaris CIFS server. That might be more difficult, but I'll update here when it's done...

Building a test lab

Thanks to the Technet subscription that work has provided for me, I'm now in a position to build my own test Windows network. The purpose of this is to help me get a grip on Windows Server 2008, some Active Directory, Terminal Services etc., and potentially some other non-MS tech such as Citrix XenDesktop [Express].

I've been thinking through the planning of this test lab and recognise that I need to create a network. I can either create a new, completely virtual network and put my VMs on it, routing this to my physical network using a dual homed VM appliance, or I can create the test network in a different address range as my "live production" network and assign the IP addresses so that they don't overlap.

The latter seems the easiest way of doing it (although I may be proven wrong when it's built!).

So, assume my local network is 192.168.0.0/24 (it's not, but I'm not stupid enough to put my real subnet on the 'net!). I'm going to slice up the subnet as follows:

192.168.0.1 - 192.168.0.99 = static range for production network
192.168.0.100 - 192.168.0.150 = DHCP range for production network
192.168.0.151 - 192.168.0.200 = static range for test lab network
192.168.0.201 - 192.168.0.254 = DHCP range for test lab network

How do I determine whether a plugged in device gets a production or test DHCP address? Ultimately it will depend on which DHCP server responds, but the reality is that it shouldn't really matter. Both servers will allocate an address that is routable to the Internet and will resolve the DNS. For anything that will be permanent, I'll allocate a static IP anyway.

My production network has the DNS suffix of local.zone, and I contemplated creating the Active Directory as a sub-domain (windows.local.zone). I think that it will be easier though if I simply create a new domain (e.g., windows.zone) and manually create a DNS forwarder to local.zone when appropriate. This keeps the production network (primarily non-Windows based Solaris, Linux and Mac OS X with a non-domained Vista) from interfering, or depending on, the test lab.

If either of my readers(!) spots anything obviously wrong here, please let me know!