This post now lives here: 

http://www.tacplan.com/2008/09/windows-events-to-syslog/

This fix took me forever to find, so I thought I'd just throw it on here for the masses.  ...Not that many of the "masses" come to my blog.

I upgraded VMware Server on two of our Redhat 4 systems here in the last week.  The first was a test run, and went flawlessly.  The actual production upgrade went fine, but then I couldn't log in to the new web-based management interface for VMware.

I could open the login page by going to "https://servername:8333".  Then I'd enter the username and password, and promptly be presented with the error "Web service not available."  After much searching, I finally found the answer for my scenario:

Apparently, my hosts file had "localhost" pointing to the actualy IP address of the server, and not "127.0.0.1".  I corrected this, and voila!  I was instantly able to log in to the management interface.

That's it.  Short and sweet.  I hope this post helps some of you out there who are upgrading to VMware Server 2.

More Sun Website Problems

Yet again, Sun is having problems with their website. Today, I am unable to lookup BugID's to see if a particular patch will resolve some issues I've been having. ...Awesome.

Disk Health Monitoring With Smartmon

Today, I've decided to load the smartmontools package on one of my Solaris 10 file servers. This toolset allows an administrator to make use of the extra features in all S.M.A.R.T. capable hard drives. What I am interested in doing is configuring a storage server to run the smartd daemon and email me when a disk is throwing errors. Hopefully, this will help me to preempively replace disks before an issue arises.

Before we begin, I have to give credit to "Matty" for both of these posts: Blog O' Matty #1 and Blog O' Matty #2. Without them, I would probably still be trying to figure this out.

Here are the refined steps I used to set this up on one of my Solaris 10 storage systems. Enjoy.

Installing Smartmon on Solaris 10

Download smartmontools from here.

# wget http://downloads.sourceforge.net/smartmontools/smartmontools-5.38.tar.gz

# gunzip smartmontools-5.38.tar.gz |tar xvf -

# cd smartmontools-5.38

# ./configure --sbindir=/usr/sbin \
--sysconfdir=/etc \
--mandir=/usr/share/man \
--with-docdir=/usr/share/doc/smartmontools-5.38 \
--with-initscriptdir=/etc/init.d

# make

# su

# make install

Create three service scripts in /usr/local/bin: smartd.start, smartd.stop, and smartd.restart:

#!/bin/sh
/etc/init.d/smartd start

#!/bin/sh
/etc/init.d/smartd stop

#!/bin/sh
/etc/init.d/smartd restart

Now create a new xml file called "smartd.xml":

<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<service_bundle type='manifest' name='smartd'>

<service
name="application/smartd"
type="service"
version="1">

<create_default_instance enabled="true"/>

<exec_method
type='method'name='start'
exec='/usr/local/bin/smartd.start'
timeout_seconds='3'>
</exec_method>

<exec_method
type='method'
name='stop'
exec='/usr/local/bin/smartd.stop'
timeout_seconds='3'>
</exec_method>

<exec_method
type='method'
name='restart'
exec='/usr/local/bin/smartd.restart'
timeout_seconds='3'>
</exec_method>

</service>
</service_bundle>

Save the file and test it with svccfg:

# svccfg validate smartd.xml
# echo $?
0

If you get the utterly unuseful error "svccfg: couldn't parse document", use xmllint to find the offending portion:

# xmllint -valid smartd.xml

correct any errors and revalidate with svccfg.

Now import the new manifest:
# svccfg import smartd.xml

List the properties of the new service for verification:
# svccfg -s application/smartd listprop

Edit /etc/smartd.conf to your liking, so that it will run whatever tests you require for your environment. For my purposes, I simply added a line for every disk in the server:

/dev/rdsk/c1t0d0 -d scsi -o on -a
/dev/rdsk/c1t1d0 -d scsi -o on -a
/dev/rdsk/c1t2d0 -d scsi -o on -a
/dev/rdsk/c1t3d0 -d scsi -o on -a
/dev/rdsk/c3t0d0 -d scsi -S on -o on -a
/dev/rdsk/c3t1d0 -d scsi -S on -o on -a
/dev/rdsk/c3t2d0 -d scsi -S on -o on -a
/dev/rdsk/c3t3d0 -d scsi -S on -o on -a
/dev/rdsk/c3t4d0 -d scsi -S on -o on -a
/dev/rdsk/c3t5d0 -d scsi -S on -o on -a
/dev/rdsk/c3t8d0 -d scsi -S on -o on -a
/dev/rdsk/c3t9d0 -d scsi -S on -o on -a
/dev/rdsk/c3t10d0 -d scsi -S on -o on -a
/dev/rdsk/c3t11d0 -d scsi -S on -o on -a
/dev/rdsk/c3t12d0 -d scsi -S on -o on -a
/dev/rdsk/c3t13d0 -d scsi -S on -o on -a
/dev/rdsk/c3t14d0 -d scsi -S on -o on -a
/dev/rdsk/c3t15d0 -d scsi -S on -o on -a
/dev/rdsk/c5t0d0 -d scsi -S on -o on -a
/dev/rdsk/c5t1d0 -d scsi -S on -o on -a
/dev/rdsk/c5t2d0 -d scsi -S on -o on -a
/dev/rdsk/c5t3d0 -d scsi -S on -o on -a
/dev/rdsk/c5t4d0 -d scsi -S on -o on -a
/dev/rdsk/c5t5d0 -d scsi -S on -o on -a
/dev/rdsk/c5t8d0 -d scsi -S on -o on -a
/dev/rdsk/c5t9d0 -d scsi -S on -o on -a
/dev/rdsk/c5t10d0 -d scsi -S on -o on -a
/dev/rdsk/c5t11d0 -d scsi -S on -o on -a
/dev/rdsk/c5t12d0 -d scsi -S on -o on -a
/dev/rdsk/c5t13d0 -d scsi -S on -o on -a
/dev/rdsk/c5t14d0 -d scsi -S on -o on -a
/dev/rdsk/c5t15d0 -d scsi -S on -o on -a

Enable the new service and verify that it's running as expected:
# svccfg enable application/smartd
# ps -elf |grep smartd

Originally, I was going to use the "-m" function to send email alerts, but I found that smartd works quite well with syslog. Since I already have a centralized syslog server, I'll just add a swatch statement to watch for smartd entries and then send email alerts from there.

Looks like Google is having issues this morning. Any search result I click on, with the exception of a Google-hosted site, is issuing a malware warning. Let's see how long it takes to resolve. The issue started for me at 9:34AM EST:

Syslog on Solaris 10 - Remote Loghosts

Just a quick note here to help others that may run into the same issue. I have had a Solaris 10 FTP server running for several years. I have grossly neglected it and only recently decided to give it any attention whatsoever.

I wanted to have the server send syslog messages to a remote loghost. Normally, this is very simple. I would just add a line in /etc/hosts to define the remote loghost, and then add a line in /etc/syslog.conf to tell syslogd which events to send to the loghost.

My problem was that syslogd kept determining that the local system was "loghost", and not the server that I defined in /etc/hosts. I could verify this by killing the syslogd process and then running it manually with the "-d" parameter.

It turns out that there was another entry on the system, defining the localhost as "loghost" in the file /etc/inet/ipnodes.

I simply removed the line altogether, restarted syslogd and voila! The remote loghost started receiving messages from my estranged FTP server.

Bah! Why does Sun Microsystems force the Solaris community to log into a website to download patches and patch clusters? Why can't they just have an FTP site we can get the updates from?

I constantly have problems with the sunsolve site; It's frequently slow as hell, and just throws error messages at me all the time. Today, I can't even get a patch cluster:
Meh. I know this is an unproductive post, but no one else I know will care about this problem. Maybe one of the billions out there on the Internet will feel my pain.

Update- Apparently, I'm not alone afterall:
http://ptribble.blogspot.com/2007/08/sunsolve-needs-makeover.html