Lately I’ve been building lab environments using Linux virtual machines. I start by installing a model system to use as my source. In this case I’m using a custom install of Ubuntu Server 11.04.  The usual process is to copy the vm file to create the clones then make basic network adjustments such as changing the host name, IP address and MAC address.  Some vm environments will detect that you’re operating from a copy and dynamically assign a new MAC address for you.  If not, you’ll need to generate a new address in the NIC properties.

One obstacle you’re likely to encounter is that your networking fails to work after changing the MAC address.  The likely cause is that your system detected this new address and assumed it to be a new ethernet connection but your IP settings are still assigned to your original ethernet interface, probably eth0.

The solution is to make your original network configuration aware of your new MAC address.

Locate the udev rules file for network devices:

/etc/udev/rules.d/70-persistent-net.rules

This rules file should contain a single entry for every ethernet interface in your system.  My original vm just had eth0, but after booting my clone, the new MAC address of 00:1c:42:ab:fe:96 was detected and added as eth1.

# PCI device 0x8086:0x100f (e1000)SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?", ATTR{address}=="00:1c:42:de:60:fb", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth", NAME="eth0"
 
 # PCI device 0x8086:0x100f (e1000)SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?", ATTR{address}=="00:1c:42:ab:fe:96", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth", NAME="eth1"

Since the original ssytem was setup with eth0, ifconfig doesn’t know about eth1 so it simply needs to be removed and the new MAC address needs to be assigned to eth0.  Edit 70-persistent-net.rules and remove the first entry containing the original MAC address and change the second entry to eth0.

# PCI device 0x8086:0x100f (e1000)SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?", ATTR{address}=="00:1c:42:ab:fe:96", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth", NAME="eth0"

So, there you have it.  Reboot the system to affect the change.

Fixing a network account lockout on Mac OS X 10.5

Today while doing some routine network administration on an Apple network I stumbled into a vexing problem. Making a simple password changes on a network account locked out one of the Leopard clients. The solution was to reset permissions on the users home folder using the Terminal.

The network is running Snow Leopard Server, (OS X 10.6.5) with Open Directory, DNS and DHCP. The affected client workstation is running Leopard (OS X 10.5.8.) After changing the passwords of a few user accounts using Workgroup Manager, this particular Leopard user got fully locked out. Any attempt to log into his computer was rejected by the shaking login panel.

Finding solution is often a case of removing obstacles. First, rule out the obvious– a mistyped password, a damaged user account, a bad network connection, or a failed binding to Open Directory. So, my first test was to log in with my own network account. It worked perfectly. Next, I verified authentication to a share point on the file server using the affected user account. No problem there. So, other network accounts work fine, the OD binding is normal and the affected user account authenticates OK at the server. A check of the system logs on the client and server revealed nothing helpful so at this point it’s clear that something is amiss on the client, perhaps a problem parsing the home folder, a damaged .plist, incorrect file permissions or a problem in locally cached credentials.

I tried moving all the users .plist files out of ~/Library/Preferences but to no avail so I pursued the question of file permissions. I did a quick check of the home folder via the Terminal:

ls -al /Users/Kohki

Although it looked normal here with the user having read/write and proper ownership, I went ahead with a full reset of the file permissions:

sudo chmod -R 744 /Users/Kohki

And then on to the verdict– I logged out of my account and went back in as the user. It worked! The user login went without a hitch and all his preferences and data were perfectly intact.

The shortest distance between problem and solution isn’t always a straight line but in the end I reached my destination. This reveals a potential weakness in the networking functionality of Leopard and it’s wise to upgrade users to 10.6 whenever possible.

In business networks it can be very beneficial to setup centralized document storage so that all users can easily store their data on a file server. If you manage Windows computers that are part of a Windows Domain you may know that you can use Group Policy to redirect your user’s “My Documents” folder to a file server, but what if your site doesn’t have a Windows Domain? Perhaps they prefer to use Linux or Mac OS X for servers instead. Who can blame them, but In such environments they can’t use Group Policy to push configuration changes to Windows clients.

I recently encountered this situation but I wanted to get the benefit of centralized document storage so came up with a script to solve the problem. The script makes a few simple registry changes to set the location where you’d like to store the documents and will copy the users documents for you.

The script can be downloaded from http://epiphia.com/files/mydocs-network-redirect.bat.zip

To use the script, edit the altMyDocsPath variable in line 8 to set the path you wish to redirect to.  For example if users have a home drive of h:\ and you’d like to redirect their document there, you could use:

set altMyDocsPath=h:\Documents

You can also use a UNC path, i.e. \\server\path, and may use a variable to represent the username, for example,

set altMyDocsPath=\\FileServer\Users\%USERNAME%\Documents

How it Works

The script will copy the users files from their “My Documents” to the path you set above. Then it will change the registry keys necessary to set the new path to their documents.  The two registry keys being changed are:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Personal
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Personal 

In the above paths the “personal” keys set the path to the “My Documents” folder.  Before it makes changes a backup of these keys is saved to c:\.  If you need to restore the backup just find the two .reg files and double-click them to import into the registry.

After the script runs the user must log out and log back in for the change to take effect.

Deploying Over the Network

My prefered way to push out the changes is to place the script on a server and call it from a logon script. You could send it out in an email and instruct users to run it, or put it somewhere on the network and have them run it.

Only Runs Once

The script is designed to check whether it has already been run so that you can use it in a logon script indefinitely. This allows you to leave it in place for a period of time until all your users pick up the changes.