Automating VMWare Tools reconfiguration | arfore dot com

One of the pains that come with kernel updates in Linux is the necessity to rebuild vendor kernel modules or custom written kernel modules.

As time goes by many vendors are adding support for the Dynamic Kernel Module Support (DKMS) framework.  Recent releases of both the ATI Catalyst and the NVIDIA drivers support DKMS at some level.  VMWare is currently exploring this and you can turn it on (if you have DKMS support installed) however, it is still marked as experimental.

On my production servers we don’t encourage widespread use of experimental features so this has not been enabled with the VMWare Tools installation.  Unfortunately this means that during the patching process it is possible to lose network connectivity due to the need to rebuild the VMWare Tools configuration after a kernel update.

I found one solution to this on the LinuxDynasty site.  The problem with this particular method is that the file that is being checked for “not_configured” only gets written in a small set of circumstances.  In my case, the VM was partially configured, so this file wasn’t written.

Here is my alteration of the solution linked to above.

Update the code in the vmware-tools startup script

In the following file:

Add the following line after the vmblockfusemntpt variable declaration

rebuild_tools=”/etc/vmware-tools/rebuild_needed”

Then add the following line in the end of the start case for the service (around line 1370)

Add the check code to the rc.local startup script

In the file

Add the following to the end of the file

 rkernel=`uname -r`
if [ -e /etc/vmware-tools/rebuild_needed ]; then
echo “vmware-tools not configured for running kernel $rkernel”
echo “running vmware-config-tools.pl”
/usr/bin/vmware-config-tools.pl -d
echo “vmware-tools now compiled for running kernel $rkernel”
echo “restarting vmware-tools”
/etc/init.d/vmware-tools restart
echo “vmware-tools restarted”
echo “restarting networking”
/etc/init.d/network restart
echo “network restarted”
rm /etc/vmware-tools/rebuild_needed
exit 0
fi

Now the next time you reboot your Linux box after updating the kernel, the vmware tools will be properly reconfigured and the appropriate services restarted automatically.

Fixing my Olevia 237-T12 LCD television | arfore dot com

So the other night when I got home I found a sad situation.  My LCD television wouldn’t display a picture. The backlight would come on when the power button was pressed (on the tv or the remote), but nothing else was happening.

The first fix I tried was what some forums were calling an EEPROM reset. To do this follow these steps:

  1. Turn on the tv (blue led should go off)
  2. Unplug the tv from the main power
  3. Leave unplugged for 5-10 minutes (varies on exact model)
  4. Turn off the main power supply switch (located next to the power port)
  5. Plug the tv back in to main power
  6. Turn the main switch back on

In my case this procedure elicited no change to the problem, so I continued looking for other answers.  In one forum I found a reference to replacing the backlight, mainboard, or power supply. In my case the backlight was working fine and the power supply was as well.  After looking in the service manual for the 237-T11, I did find that the mainboard was fairly accessible, so if I had to get a new board it wouldn’t be that difficult to replace it.

Before taking the hardware fix route I decided to see if my problem could be resolved by a firmware update.  Olevia helpfully included a USB port on the back panel of the unit to allow for a firmware upgrade.  Since my purchase of the unit in November of 2007 at Target’s Black Friday sale, I had not applied any of the firmware updates.

Unfortunately in 2008, Syntax-Brillian, the manufacturer of the Olevia brand, filed for bankruptcy.  This made getting my hands on the firmware files, update software and instructions a little difficult.  After some diligent research I found a thread on AVSForum that had the files I needed.

The driver files didn’t work properly for my Windows 7 laptop, however they are easily obtained from the Prolific USA website (there are also drivers for Linux and MacOS X).

After following the instructions for updating I powered off the unit, waited a minute or two then powered it back on.  Success!  I was greeted with the familiar white and blue Olevia logo screen.

As an additional backup for the benefit of any other user’s, here are links to the necessary files:

Resurrecting G3 iBook with Linux | arfore dot com

linuxmint-150x150-4564720At work we are in the process of sorting through some old books, documents and equipment in the run-up to moving into a new building.

During this process I ran across an old Mac iBook.  The model I found was a stock configuration iBook G3/800, model number A1005.  After turning it on I discovered that it was running Mac OS X 10.2.8.  My manager suggested that we just discard it since it was not upgradeable to the latest OS level and since the hardware specs were so low.  Given my penchant for playing with old, sometimes admittedly obsolete hardware, I decided to see what I could do to resurrect the little guy with Linux.

After investigating the various options available, I settled on Linux MintPPC.  This particular distribution is a port of the Linux Mint LXDE project to Debian/PPC.  The reasons behind this choice were:

  1. Use of lightweight X11 window manager, which is important given the paucity of memory and hardware resources in the iBook
  2. This distro is based on the Linux Mint project and Debian/PPC Linux

Installation

The installation couldn’t be much easier.  I downloaded the latest Debian/PPC net install iso image, then started up the laptop from the CDROM.  At the boot prompt enter the following:

auto url=mintppc.org

After this it’s a simple matter of walking through the standard installation process for Debian then letting the network install complete on it’s own.  After approximately an hour, I had a fully functional Linux install working on the iBook!

Post-Install Niceties

Right Mouse Click

After the installation was completed and the laptop had rebooted I began a few post-installation configuration changes.  This model iBook didn’t have the multi-touch capabilities that Apple introduced in later models, so it was limited to left-button only operations unless you add in keyboard modifiers.  The default configuration for the left and middle button operation is to use the F11 and F12 keys to operate the buttons.  Since MintPPC includes the mouseemu daemon, I wanted to configure the system to use the Mac OS X configuration of control-click to operate the right mouse button since this was the mode I was used to.  Here’s how to accomplish that:

  1. Open the terminal and become root
  2. cd /etc/default
  3. vi mouseemu (you did backup the original right?)
  4. Add the following to the end of the file:
    RIGHT_CLICK="-right 29 272"
  5. Restart the mouseemu daemon:
    kill -HUP `cat /var/run/mouseemu.pid`
  6. Enjoy the new configuration!

Turn Off Login Ready Beep

By default the system is configured to beep when the system is ready for login.  Since I work in a cube farm, I wanted to observe better cube etiquette by disabling this.

  1. Open up the Login Window preferences: Menu -> Preferences -> Login Window
  2. Enter the admin password into the authentication dialog (this is root, not your sudo password!)
  3. Click on the Accessibility tab
  4. Uncheck the box next to Login screen ready

Openbox Configuration Tweaks

There are a number of configuration tweaks that can be made to the default Openbox setup to improve rendering performance on machines at the low-end of the spectrum.  Here are a few that I have made.

  1. Menu -> Preferences -> Openbox Configuration Manager
  2. Appearance
    1. Uncheck Animate iconify and restore
  3. Move & Resize
    1. Uncheck Update the window contents while resizing
  4. Desktops (very subjective change with negligible performance benefit)
    1. Set Number of desktops to 2

I am still working on the final configuration to fit the hardware footprint on the iBook G3, so there will be more updates along these lines soon.

Starting NRPE via launchd | arfore dot com

Last week I posted on how to setup NRPE on Mac OS X Server.  Here is what you need to do to make it start up at system boot.

On a Linux or Solaris machine you can just include the call to the daemon in an init script like rc.local and it will be started when the OS boots.  Unfortunately, Apple has made this a little more difficult on Mac OS X with Tiger and Leopard.  The standard startup processes (cron, inetd, xinetd, etc.) have been rolled into a single process known as launchd.

The first step is to create a symbolic link to the NRPE config file from the default location to the root of the NRPE directory.

  1. cd /usr/local/nagios/
  2. ln -s etc/nrpe.cfg nrpe.cfg

The next setp is to ensure that the NRPE daemon will be able to connect with Nagios server.  There are two ways to do this.  One way is to add a line to the

file to allow for an open port for NRPE.  The second way is to open the port as part of the launchd process.

Method One – edit the /etc/services file

  1. cd /etc/
  2. sudo vi /etc/services
  3. add the following line to the end of the file:
    5666/tcp # Nagios NRPE client

Method Two – use the launchd process

This method involves including a dictionary key into the launchd plist file that sets the socket type and port number for the NRPE service to use for listening.  The plist code is shown below:

Sockets Listeners SockServiceName 5666 SockType stream SockFamily IPv4

Solaris 10 Password Policy Enforcement | arfore dot com

Image Credit: Ohio State University

I was recently handed a baseline policy that was to implemented for all users on the Solaris 10 systems that I support.  After a small amount of research I was able to find the various pieces that needed to be altered.

Desired Policy

After discussion between the security officer and the other management level staff, the following policy was decided upon:

Normal User Password Requirements

  • at least 8 characters in length
  • no more than 20 characters in length
  • contain at least on letter
  • contain at least one number
  • forced to change at least every 180 days
  • 15 minute lockout after 5 unsuccessful attempts

Most of the restrictions were fairly basic and could be easily accomplished.  The only one that I could find no mechanism for control of in Solaris 10 is the automatic unlock of an account after the specified 15 minute lockout.  While it is possible to determine when an account has been locked by looking at the timestamp in the syslog, there is no automated method for unlocking the account after a certain amount of time has elapsed.  I suppose it would be possible to write a script to check the entries in the shadow file then grep the syslog then do some math on the timestamp, but honestly I am not worried about it.

Implementation

The implementation process involves editing two files that are key to the functionality of user login security.  As always when altering system files it is a good idea to make backups of the originals in case things go wrong.  The files involved are:

  1. /etc/default/login
  2. /etc/default/passwd

Setting the account lockout (aka Three Strikes)

Generally the default on a Solaris 10 system is to set the account lockout to three password retries before an account is locked.  We decided to relax this a little and allow for five retries.

  1. Open /etc/default/login in your favorite editor
  2. Search for the line reading RETRIES=3
  3. Change the line to read RETRIES=5

Configuring the complexity rules

The password complexity ruleset for Solaris 10 is fairly understandable.  The rules are defined in /etc/default/passwd and the values to be tweaked are:

  • MINDIFF
  • MINALPHA
  • MINNONALPHA
  • MINUPPER
  • MINLOWER
  • MAXREPEATS
  • MINSPECIAL
  • MINDIGIT
  • WHITESPACE

The desired policy decided upon was to require at least one number and one letter.  There was some discussion about special characters, but it was decided to not require any special characters for normal user accounts.  Given these requirements the following process is used to implement the complexity ruleset:

  1. Open the file /etc/default/passwd in your favorite editor
  2. Set the password complexity tunables to look as follows
MINDIFF=3
MINALPHA=1
#MINNONALPHA=1
#MINUPPER=1
#MINLOWER=1
MAXREPEATS=0
#MINSPECIAL=0
MINDIGIT=1
WHITESPACE=YES

Setting the password expiration and length rules

Configuring account lockouts and password complexity is a great start, however it is not the complete picture.  While reasonable complexity rules will allow users to set passwords that they can readily remember, and a flexible lockout value will give some room for fumble fingers, if users are not required to change their passwords every so often then the security of the system can suffer as well.

You also should consider password length.  A shorter password, regardless of complexity, is going to be easier to crack from an algorithmic standpoint.  This is simply due to the mathematical requirements.  The problem is that user’s tend to not like long passwords.  As you increase the password length, you increase the likelihood the passwords will use dictionary words (we can account for that as well).

The agreed upon setting for normal users on our systems was 180 days.  Unfortunately Solaris 10 uses a setting measured in weeks and not days.  What this means is that the setting will have to be slightly longer.  The password length was decided to be at least 8 characters and no longer than 20 characters.  Also, Solaris 10 has no setting to enable a maximum password length.

  1. Open /etc/default/passwd in your favorite editor
  2. Set the value for MAXWEEKS to be the value of number of days divided by 7, rounding up
  3. Set the value for PASSLENGTH to be the value of the minimum number of characters

Important Notes and Considerations

Password Length

The default algorithm used for passwords under Solaris 10 is crypt_unix.  This algorithm is not considered sufficiently secure, even by Oracle.  You should investigate using a different algorithm such as MD5 or Blowfish instead.  The default will not allow for passwords that are longer than 8 characters.  You can set the password to be longer, but all characters after the eighth position will be discarded during the authentication check process.

Retroactive Usage

Changes to the password expiration policy is not immediately retroactive.  For the expiration requirements to take effect on existing accounts you will need to initiate a manual password change for the shadow file entry to be updated.

Dictionary Words

When Solaris 10 was introduced one of the changes made to PAM was the ability to use a comma-delimited list of dictionary files to avoid usage of common words during password selection.  This can be configured with the DICTIONLIST variable in the /etc/default/passwd file.

Applying lockout to the root user

While this is not the default, you can apply the lockout rule to the root user account by editing the /etc/user_attr file and changing the lock_after_retries value for this user to yes.  Be warned this is not recommended since a locked account can only be unlocked by the root user.  If your root level account becomes locked then you will need to have an account that allows sudo access or you will end up going to some extreme lengths to re-enable access to the system.

References

Of course, none of this information is really unique.  Here is the list of resources I used to put all of this together:

For more commentary on password length, complexity, etc., see a few of these sites:

Sony needs to fix the PSN billing system | arfore dot com

So I just finished Prince of Persia on my PS3.  I decided that I would go and purchase the $9.99 Prince of Persia: Epilogue DLC from the PSN (PlayStation Network) store so that I could have some more PoP game time.

Turns out that I can’t purchase anything using my Bank of America debit card, because Sony’s billing and account system is seriously messed up.

First I tried just entering in my account information in the PSN store interface as a direct purchase.  I put in the card information and billing information.  I get an error back that says “Credit card is invalid. Check your entries.”  Thinking that I may have punched something in wrong when relying on my memory, I go get the physical card and verify that all the data was correct.  Hit continue.  Same error.

I then tried to just enter the billing information into the account management thinking that maybe that would work.  Same error.

I tried logging into my PSN account over the web on my laptop and entering the information there.  Same error.

Having now exhausted all the possible avenues for entering in my information, I search the Google to find out if others have had this problem and what the fix might or might not be.  Turns out there have been numerous people with the same problem.

The first thread I listed had the most information.  They were discussing the possible values necessary in the address fields, etc.  I checked all my information.  Here’s what you need to double-check:

  1. Make sure your console has been activated using the System Activation item in the dashboard
  2. Make sure that if your billing address is a post office box that you are not adding in punctuation
  3. Make sure that your zip code is matching exactly with the bank records, especially if your bank uses an address verification system
  4. Make sure that your phone number, if listed, matches the bank records

The problem is that I checked all of this and none of it helped.  So I called the Sony Computer Entertainment America support number (800-345-7669) and waded through the menu system to get a support representative.  I have to give kudos to the support representative, because she was very calm and nice, and she didn’t even have a problem with the fact that I had already checked everything that she had on her checklist for me to check.

Unfortunately, she said “Sometimes the PO Box addresses just don’t work.  The only suggestion I can make is that you use a different credit card or go buy a PlayStation Network Card.”  She was very sorry that it wasn’t working, but there was nothing she could do to help.

I am not blaming the support folks, but that kind of answer is really pretty unacceptable.  I use my BoA card online, in stores, and over the phone all the time with no problems at all.  To make matters worse, when I logged in to my BoA account over the web I had a $1 pending transaction for each of my attempts to connect my card to the PSN store.  The customer service representative did assure me that they would drop off since a complete account transaction had never occured.

This is unexcusable.  Why even bother creating an online store for your game console if it doesn’t reliably work to purchase things?  Someone at Sony really needs to get this ironed out.