It helps to create an SSH key pair and add your public key to the /home/user/.ssh/authorized_keys file.


Initiated VMware Tools install or upgrade. Target: servername. Error Upgrading VMware Tools


Check your current kernel version, and compare it to the kernels in /boot. If your current kernel version is not the same as the newest one in /boot, reboot, and try again!

Example:

# uname -r
2.6.18-194.11.4.el5
# ls /boot/vmlinuz*
/boot/vmlinuz-2.6.18-194.11.4.el5 /boot/vmlinuz-2.6.18-194.17.1.el5 /boot/vmlinuz-2.6.18-194.17.4.el5
# shutdown -r now


Since my currently running kernel is not the newest one, the auto-updater throws up on the upholstery and quits. After rebooting (which by default loads the newest kernel, unless you’ve set up something odd), I was able to auto-update VMware tools without a problem.

All of these options are explained in the snmpd(8) manpage. The one that interests you should be the localhost address, 127.0.0.1. In order to listen for connections to snmpd from the outside world, remove the address, so the line looks like this:

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid '

While you’re at it, specify where your snmpd.conf file can be found:

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid -c /etc/snmp/snmpd.conf'

Extract the contents of your initrd:

# mkdir ~/tmp
# cd ~/tmp
# gunzip < /boot/initrd.img | cpio -i --make-directories
# ls
bin dev etc init lib proc sbin sys sysroot


The modules included in this initrd are located under the lib directory.

Slightly More Information

The initrd is a compressed cpio archive created to act as an intermediary step from the boot loader to the kernel. Its sole purpose is to provide a small environment with the modules and tools necessary to load your root filesystem. If your system root uses the ext3 file system, and ext3 support is not built in to your kernel, you will need to be sure the ext3 module is included in the initrd.

More Information

• Linux-Filesystem-Hierarchy entry about /initrd
• Novell SLES Administration Document on the initramfs
• IBM’s DeveloperWorks page on creating a custom initrd by hand


[root@swerver ~]# cat /proc/cmdline
ro root=/dev/VolGroup00/root rhgb


From this, we can glean that the root device is /dev/VolGroup00/root, and it was mounted read-only during boot time. The kernel for this server was passed the option rhgb, enabling Red Hat’s pretty GUI boot screen.

While this seems pretty mundane, it has come in handy when troubleshooting your coworker’s running server. Also, you can make fun of your coworkers for requiring a pretty GUI boot screen.

History

vga16fb was removed from the blacklist-framebuffer.conf file on 2 Dec 2009:

“* Remove vga16fb from the framebuffer blacklist, we’ll want this to be loaded if there are no better framebuffers available.”

https://launchpad.net/ubuntu/+source/module-init-tools/3.11.1-1

According to this post in Ubuntu’s kernel-team list, vga16fb will be removed from Maverick. I’m not sure with what it will be replaced. The /etc/modprobe.d/ files are managed in the module-init-tools package, so keep an eye on the changelog to watch for developments.

As of module-init-tools 3.12-1ubuntu1, the Maverick package still has vga16fb out of the blacklist-framebuffer.conf file, so this fix is probably still valid.

When you make a new init.pp file for your modules, make sure you don’t have any extra noise in your new lines. Windows likes to use the carriage return/line feed combo, while Puppet really only likes to see line feeds.

If you happen to notice an error along the lines of
Puppet could not match '}' ...
guess what? You probably have some carriage returns in there. Using Notepad++ in Windows, go to Settings -> Preferences -> New Document/Default Directory and change the format to Unix. Create a new file, and copy your old content into it. If you enable Show Symbol-> End of Line, you will now see nice pretty LFs where before you had CR/LFs.

Not really worth a post, but honestly, I wanted to remember it somewhere.

This gives a table formatted output of the available updates, from what source/catalog they originate, and the version of the patch. A web search usually doesn’t turn up much by using the number provided in the version column and the name of the patch.

Enter the option patch-info. An example is probably better fitting for this one:

# zypper patch-info slesp3-openssl
Restoring system sources...
Parsing metadata for SLES10-SP3-Online...
Parsing metadata for SLES10-SP3-Updates...
Parsing metadata for SUSE Linux Enterprise Server 10 SP2...
Parsing metadata for SLES10-SP3-Pool...
Parsing metadata for http://wouldn'tyouliketoknow.com/repos/sles10sp3/CD1...
Parsing RPM database...

Information for patch slesp3-openssl:
Name: slesp3-openssl
Version: 6944-0
Arch: noarch
Status: Needed
Category: security
Created On: Fri 26 Mar 2010 07:53:40 AM MDT
Reboot Required: No
Package Manager Restart Required: No
Interactive: No
Summary: Security update for OpenSSL
Description:
This update adds support for RFC5746 TLS renegotiations to address vulnerabilities tracked as (CVE-2009-3555). It also fixes a mishandling of OOM conditions in bn_wexpand (CVE-2009-3245).
Installation notes
This update is provided as RPM packages that can easily be installed onto a running system by using this command:
rpm -Fvh openssl.rpm openssl-32bit.rpm openssl-64bit.rpm openssl-debuginfo.rpm openssl-devel.rpm openssl-devel-32bit.rpm openssl-devel-64bit.rpm openssl-doc.rpm openssl-x86.rpm
Provides:
patch: slesp3-openssl == 6944-0
Requires:
atom: openssl == 0.9.8a-18.42.2
atom: openssl-devel == 0.9.8a-18.42.2
atom: openssl-doc == 0.9.8a-18.42.2


What strikes me as cool is the explanation of whether the system will need to be restarted, whether it is interactive, what RPMs it affects, and of course, to which CVE this patch is linked.

I usually don’t have nice things to say about zypper on SLES, but in this case, they’ve provided an fine way to manually inspect the patch pre-installation.

Apparently this is a known issue with SLES 10 SP3 and VMWare VSphere, after installing VMWare Tools in VSphere. Here’s the TID. The fix for this problem is in the TID, so I don’t think I should duplicate their effort and miss something in the transcription.

The preventative fix:

I manage many servers in VSphere, not just one. I’ve prevented this messed up initrd problem with the following steps:

Edit your /etc/sysconfig/kernel file, remove any duplicate lines of INITRD_MODULES, and replace the line
INITRD_MODULES="vmxnet"


with something that includes the modules you need. (Hint: LVM requires dm_mod to be in the initrd):

INITRD_MODULES="vmxnet piix mptspi processor thermal fan reiserfs dm_mod edd pcnet32"

Save the file, then rebuild your initrd files:
mkinitrd


This generates a bit of output, and finally a new initrd with the proper modules included. Now you’re safe to reboot.

More on the problem:

The idea is that vmware-config-tools.pl is supposed to iterate through your /etc/sysconfig/kernel file until it finds a line that stats with INITRD_MODULES. It takes that line, sticks vmxnet in the front of the parameter list, and then echoes out the new parameter list, to make the line look something like this:

INITRD_MODULES="vmxnet piix mptspi processor thermal fan reiserfs dm_mod edd pcnet32"

This happens every time you run vmware-config-tools.pl in SLES, with or without the –compile flag. The original INITRD_MODULES line is left intact, leading to multiple entries of INITRD_MODULES in the /etc/sysconfig/kernel file, each appended to the bottom. That’s not the problem, however.

Occasionally, vmware-config-tools.pl botches the job and only puts “vmxnet” in the list, killing off all your other modules on the subsequent mkinitrd:

INITRD_MODULES="vmxnet"

I am unsure why this is, but this can cause problems for a number of reasons, not least of all being the lack of dm_mod in your initrd, leaving your system without the device-mapper and without any logical volumes. The best solution I’ve found is the one I’ve listed above: find a similarly configured VM, and replace the borked INITRD_MODULES line with the one that works. Thankfully, the VMs tend to have similar “hardware”, so the above fix has been sufficient for me.

I should note that, while I’ve focused on SLES 10 SP3, that is only because that’s what I’ve been using. It’s very likely this problem exists in other SP levels of SLES 10, or even in SLES 11. I now check my /etc/sysconfig/kernel file after each update/install of VMWare Tools on my SLES servers. The VMWare team’s work is generally not erratic from what I’ve seen, so it made tracking this problem down even more intriguing.

I found the support definitions from both the RHEL lifecycle and SLES lifecycle pages. Here’s a break down, as I see it:

The similarities:

• both offer patches, updates and support through seven years after the product’s initial release.
• both offer ‘minor revision’ updates (SLES calls them Service Packs, RHEL calls them Minor Releases) that include all hardware refreshes, patches and enhancements made to the product up to that point.
• both offer asynchronous patching (where the patches are available for download when they are ready)
• both RHEL and SLES require a subscription to access patches and updates.

The differences between RHEL and SLES support:

• SLES offers “Self Support” through ten years after the product’s release date

The Self Support for SLES seems fishy. Here’s a description of what it offers:

• Knowledgebase Search
• Novell Support Advisor
• Free Support Forums
• Documentation
• Electronic Service Requests
• Report a Product Defect
• Submit an Enhancement Request

From what I can tell, they are saying you can go RTFM for up to ten years after the initial SLES release date, and they will support your research by allowing you to RTFM. There are other benefits listed here, but they seemed to be features available outside any product’s lifespan (generically available, if you have a license with Novell).

To me, the benefit of support between years 7 and 10 with a SLES server are not too special. For me, I conclude RHEL and SLES support are equally footed. I’ve never actually contacted tech support at either facility, so I can’t comment on either groups efficiency, but the available support features for their flagship Linux distributions seem equal.

Unfortunately, this post had nothing to do with lightcycles. Man, I can’t wait until December!