Thursday, May 23, 2013

Updating VMware Tools quickly multiple Linux servers

Ever want to update a bunch of servers quickly?   ESX updates come once every 2-3 months (give or take) and it can be annoying to update all of the servers.  What I do is I will pull down the update and place it on a webserver that is accessible.  You can even change this step to SCP but that involves setting up SSH keys for a simple file grab.

You'll have to initiate the VMtools update at least once, so you can pull down the files from VMWare vSphere.  I place the new updates in the same location each time, symlinking the new files to "vmtools-linux-latest.tar.gz".

Once the initial "prep" is done, I'll usually use SSH from my management server where the SSH keys are already setup to each box then SSH using a text file like so:

cat "/path/to/textfile.txt" | while read a; do ssh root@$a /path/to/; sleep 5; done

I put 'sleep 5' in between each iteration so I can kill the script if I need to.   CTRL+C while the update is running will only kill the update and move onto the next server.

Script "":


WGET="`which wget`"

if [ -z "`which wget`" ]; then
if [ -z "`which yum`" ]; then
echo "YUM utility is not installed.  Will attempt to install."
yum install -y wget

# Only these Linux distro's
RES="`cat /etc/*release |egrep -i \"centos|red hat|fedora|ubuntu\"`"

if [ $EXITCODE -gt 0 ]; then
   echo "Cannot use this utility here (Wrong distro)."

wget --no-check-certificate -q "" -P /tmp
if [ "$?" -gt 0 ]; then
echo "wget of vmtools-linux-latest.tar.gz failed."

rm -rf /tmp/vmware-*
tar xvzf /tmp/vmtools-linux-latest.tar.gz -C /tmp
rm /tmp/vmtools-linux-latest.tar.gz
/tmp/vmware-tools-distrib/ -default
rm -rf /tmp/vmware-*

echo "vmtools updated on `hostname`" | mailx -s "`hostname`: vmtools updated"

Thursday, May 16, 2013

Server not responding to reboot?

I am sure there has been times where many of you have had to walk over to the server room and powercycle a linux box that doesn't seem to be responding to "reboot" or "shutdown -r now".

Maybe it'll broadcast a message that it is shutting down for a reboot and then seem to keep going about its usual business.  When that happens it may be that init isn't able to shutdown some of the processes that is keeping it hung (nfsd, I'm looking at you).

If this happens to you, then try this:  "reboot -f" (forcibly reboot, don't call the shutdown script).  This will reboot the system without attempting to shutdown gracefully.  Some INIT scripts runs a final "reboot -d -f -i" on runlevel 6 when rebooting.

This might save you a trip to the server room.


Thursday, May 9, 2013

Duplicate entries in Mac OSX "Open With..." - Bash Script

If you're like me, you probably install-test-remove a plethora of apps on a weekly basis.  One of these annoying issues that pop up on Mac OSX is the duplication of apps in the "Open With..." menu.  Let me show you what I mean.  Here I am, trying to edit a Python script.

Fortunately, the solution is easy.   The "Open With" dialog is controlled by OSX's LaunchServices framework.  Create a shell script in your path - let's call it "FixOpenWith".   Put the following text in your new file.


echo 'Now removing duplicates in the "Open With" menu in Mac OS X'

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -domain local -domain user

killall Finder
echo "Open With has been rebuilt, Finder will relaunch"

Next,  using Terminal,  cd to the file you just created.  Type chmod +x FixOpenWith to make it executable.  Then run it: ./FixOpenWith.  If the script is in your $PATH, you can just leave off the leading ./ This will take a few seconds or happen immediately, depending on your system.

Your Finder window should re-open and your issue will disappear.

Output in your terminal:
# ./FixOpenWith
Now removing duplicates in the "Open With" menu in Mac OS X
Open With has been rebuilt, Finder will relaunch