The 2011 version of our autodesk software has arrived, with a new licencing system which will have to work alongside the old one (hopefully). I’ll be testing it this week.
I’ve spent a bit more time working with printui.dll to install printers, and found some interesting things:
1. Adding a printer to the machine doesn’t seem to automatically make it available to active directory accounts. It does allow the AddWindowsPrinterConnection command from the Wscript.shell object to set up the printer.
2. It can only be run once on a machine for a given printer without giving an error, making it impractical to put into a login script for users (but possibly useful for a remote command or new machine script).
At the moment, I’m leaving it out of the login scripts and just manually adding the printers for windows 7 boxes. If group policy managed print management in windows 2008 works out, I’ll switch to using that to set up printers instead.
I had originally seen this error when I copied a vm image to a larger drive – the ethernet interface had a static I.P. but stopped working. When I created a new interface that worked fine. This time, I look around on the web to figure out what was happening. It turns out that the copied images would change the mac address. Under debian, this would cause the udev system to create a new ethernet interface for the mac address, mapped to ethX (where X is 1 plus the last network adapter it created). By the time I started it on my new vmware server, I had two ethernet addresses, so it created two new interfaces, eth3 and eth4. I was using eth1 for networking so changing it to eth4 enabled internet access.
In /etc/udev/rules.d/70-persistent-net.rules is where the information about the ethernet cards and their mac addresses was stored. I compared this to the information from the .vmx config file for the virtual machine to determine what network card was mapped to each ethX interface.
I’ve found some interesting things out about how vmware server works on debian 5.0 . Apparently there is problem with the vmmon module throwing an error when it is higher than version 138. Here’s the error message:
[localized] Version mismatch with vmmon module: expecting 138.0, got 168.0
Several fixes on the internet are available, which patch the source for the vmmon module to allow it to compile. I was successful when I applied the following patch from this link:
http://www.insecure.ws/2008/07/24/vmware-anspecific-specific-557-and-kernel-2626
I applied it after the vmware-any-any-update117d patch I found here:
NEW “How to install VMWare in 2.6.26 linux kernel”
I’m actually sure if the 117d patch was required or not. Doing a diff on the vmmon source, it appears that thevmware-update-2.26-5.5.7.tgz file adds a little perl function that determines what the vmmon version should be, to deal with the issue above.
Install procedure on fresh debian 5 machine:
Still more updating and last minute work to help with the siggraph Asia paper deadline.
• Updating dgpis40 server
• matlab license update
• install octave on cluster
• file server and office 2010 research