Remove junk from a default Debian Linux install

Just some stuff to get rid of when building a basic-ish LAMP server in a VM:

 

Upgrade iWeb “SmartServer” from Debian Lenny to Squeeze

iWeb currently only offers Debian Lenny as a pre-install option on these servers, but since Lenny is dead as of February 2012 I wanted to start with Squeeze.  I tried the upgrade process from the debian.org site linked below first, but my server didn’t reboot properly after the GRUB2 install and I couldn’t even connect to the VNC console of my VM.  Since the hardware is about a bazillion miles away I don’t know if there’s anything I could have done from the console to fix grub and rescue the install; my only option was the auto re-image in the iWeb control panel.  I re-imaged the server with Lenny and while that was happening I did a bunch of reading about other people having fun with the new grub.

This is just a quick step-by-step.  Basically the standard instructions break grub-pc (GRUB2) on this Xen-based system.  Follow along until the end, then remove grub-pc and re-install grub-legacy.  Your system will then be ready to go!

All of this information is here: http://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html but this page is far less reading.

Also, if your system is not a “stock” Lenny install, i.e. with 3rd party deb sources and a bunch of custom stuff, your mileage may vary.  I did this to a fresh, new server before anything else.

*Answering “NO” here tells the installation script to just go ahead and fully install GRUB2 and not mess with the legacy grub .conf file and fart around with chainloading and stuff.  I just felt better uninstalling a “complete” GRUB2 install rather than a half-assed hodge-podge of grubbery.

OpenVPN Bridge under VMware ESXi

So, as these things go, I spent 2 days looking at my OpenVPN config files and bridging setup before finding the solution to my problem was elsewhere.

A little background: I created a new OpenVPN VM using the Debian Squeeze net install CD, configured it to match what was already working on a physical Windows XP box, but only had limited success. I was able to connect to the VPN, ping the OpenVPN server on the network, but couldn’t connect to anything else. Trying to ping another server from the VPN client, and running tcpdump on that other server showed that it was receiving ICMP requests and replying, but they were not making it back to the VPN client. I tried a hundred different ways of creating the bridge on the OpenVPN server, but nothing worked. Finally, good old Google found the answer. The ESXi virtual switch drops promiscous packets by default. To fix it, open the vSphere Client, click on the ESXi host on the left side, click on the “Configuration” tab on the right, click “Networking” in the Hardware box, click on “Properties…” at the top-right of your “Virtual Switch: vSwitch#” graphic. Now on the “Tools” tab of this popup window, select the “vSwitch” and click the “Edit…” button. In this popup, click on the “Security” tab and change “Promiscuous Mode” from “Reject” to “Accept”. Click “OK” then “Close” and you should be all set.
Read more

VMware Performance Tuning : Disabling System Restore in Windows Guests

Snapshots are available with VMware Workstation, VMware Fusion, VMware Server and ESX/ESXi.

Windows has a feature called system restore.  The idea behind System Restore is to revert to a point in history in case something goes wrong – i.e.: patch Tuesday. It’s an undo feature for your Windows OS. There is overhead for this undo feature, especially on the IO front which is generally acceptable for a dedicated desktop but not ideal for VMs.

One can approximate the function of System Restore with snapshots. Snapshots should be used only when modifying a VM, i.e. patch Tuesday, new software, etc… The idea is “I know I’m making a change so I snapshot the VM”, I execute the change, and test. Once testing reveals no issues and everything works as expected, the snapshot is removed.  (Of course this is now a manual process instead of an auto magic one so it’s a compromise)

Snapshots should not be persistent! They should only have a life of a few hours to a few days.  It is important to remove the snapshots since it creates a delta VMDK file and can grow quite large.  Also, if one creates many snapshots this can affect performance of the guest.

Personally I usually snapshot when the guest is powered down – this gives me the cleanest possible snapshot and I can revert to it with confidence.   It also means the snapshot is created instantly since the file system does not need to be quiesced.  Additionally, it is important to remember your VMware hypervisor can quiesce the file system (so long as VMware tools installed) but not necessarily the applications running in Windows.  i.e.:  SQL cannot be snapshotted reliably.

It is also very important to remember Snapshots are not backups in anyway shape or form. For “backup” purposes the entire VM package should be copied and compressed and stored on a medium other that the host running the VM.  i.e.:  I store my VM archives on my DIY NAS.

Disabling System Restore in XP: Right-Click My Computer and select properties and click the system restore tab, Select “Turn off System Restore” and click OK.
Disabling System Restore in Windows 7: Right-Click My Computer and select properties, click the System Protection link, Click the Configure Button and select “Turn off system Protection”, OK, OK

In conclusion, one can use snapshots in lieu of system restore to gain some performance in the Windows guest but it’s a compromise since the taking and deleting of snapshots is a manual process.