For example, take this simple BASH ‘for’ loop:

for DERP in /dev/tty*; do echo ${DERP}; done

This should return a list of all the files matching /dev/tty* since BASH’s built-in file globbing expands as the list parameter of ‘for’ .   Now, try this:

[bdowney@tlfmgt1 ~]$ for DERP in /dev/heraderp*; do echo $DERP; done
/dev/heraderp*

Now the ${DERP} variable expanded to “/dev/herpaderp*”, but why?   The answer is that since /dev/herpaderp* did not naturally expand into a list of matches (because none matched) the pattern itself becomes the list parameter.   Makes sense once you understand what is happening, but seems a bit counterintuitive while programming.

I think most shell programmers would assume (myself included) the for loop would execute zero times upon no glob match.

So it would seem the correct way to handle this is by executing a subshell with a command that properly handles no-match globs, namely “ls”.   In this case, it works perfectly and as expected–but we have yet another caveat:

for DERP in $(ls /home/bdowney/*.mp3 2>/dev/null); do echo $DERP; done

If we run into a file name with a space, say something like “01 – track1.mp3″, this version of the loop will still enumerate down to three separate list items because of the spaces, namely “01″, “-”, and “track1.mp3″.    We cannot escape the subshell with double quotes, either.   So we’re back to the plain globbing again without the subshell.   So how do we resolve this?   As follows:

for DERP in /dev/tty*; do
 [[ -f ${DERP} ]] || continue
 echo $DERP
 done

Just test the loop iteration to see if it matches a file. Problem solved in all situations!

Basically, install 32 bit OMSA on 64 Bit CentOS, and all will be well.   Go Dell!

For now, visit the site and sign up for the mailing lists!   We’re still in the early phases, so be sure to suggest ideas and comments for the focus of the group.

I’ll be off at the liquor store buying lottery tickets!

The problem is tricky–we must leave FTP and SSH open to the entire world, but at the same time be selective on what we black list.   How do you make that determination?  Strictly on bad login credentials?

We could, but that would mean that we’d inadvertently lock out real users.  A better solution we found has to do with timing connection attempts.   With IPTables, we can keep a counter based upon source IP–and track how many new socket attempts are made within a certain span of time.     For instance, if we detect the IP address 1.2.3.4 making 5 connection attempts within 60 seconds, there is a darn good chance it isn’t someone mistyping a password.

Here is how we did it, based upon another script we found out in the Internets:

#!/bin/bash
/sbin/iptables -N SSH
/sbin/iptables -N SSH_BLACKLIST
/sbin/iptables -A SSH_BLACKLIST -m recent --name SSH_COUNTER --set -j LOG --log-level warn --log-prefix "Blocked: "
/sbin/iptables -A SSH_BLACKLIST -j REJECT
/sbin/iptables -A SSH -m recent --name SSH_COUNTER --update --seconds 300 -j REJECT
/sbin/iptables -A SSH -m recent --name SSH --rcheck --seconds 60 --hitcount 5 -j SSH_BLACKLIST
/sbin/iptables -A SSH -m recent --name SSH --rcheck --seconds 2 -j LOG --log-level warn --log-prefix "Added: "
/sbin/iptables -A SSH -m recent --name SSH --update --seconds 2 -j REJECT
/sbin/iptables -A SSH -m recent --name SSH_COUNTER --remove -j LOG --log-level warn --log-prefix "Removed: "
/sbin/iptables -A SSH -m recent --name SSH --set -j ACCEPT
/sbin/iptables -A INPUT -m state --state NEW -p tcp -m tcp --dport 22 -j SSH

This creates two new tables, SSH and SSH_BLACKLIST.   Upon the intial connection attempt, the IP is added to the SSH_COUNTER counter.   If the same IP address is seen again within 60 seconds, it is duly noted–however no action is taken until the hitcount reaches 5.   In that case, the rules jump to the SSH_BLACKLIST table, it is logged, and subsequent connections from that IP are dropped for 5 minutes until things calm down.   In order to do this for FTP, just rename the targets as appropriate and change the target port to 21 on the last line.

The nice thing about this set up is that it is auto-cleaning.  After 5 minutes of no activity, the counter forgets about the IP address and things return to normal.   We’ve found that this is just enough protection to drastically reduce bruteforce attempts, yet not get in the way of normal usage by our customers.  Over time, this has become our favorite technique and we’ve begun to implement it on any Internet-facing machine with open SSH ports.

One of the things that annoyed me out of the gate is the lack of SSH support.   It’s there in the underlying operating system, just not enabled.   Here’s how to turn it on:

1. Get on the console of the ESXi server.
2. Press ALT-F1 to get to the OS system console
3. Type “unsupported”
4. Enter the root password at the password prompt.
5. Edit /etc/inetd.conf with vi, and uncomment the SSH line
6. Run:  kill -1 $(cat /var/run/inetd.pid)

And viola!  SSH to your ESX box.   Enjoy!

Imagine a script wherein a process needs to be checked for proper exit. Let’s say “mysqldump”. Typically I’d do something like this, for example:


#!/bin/bash
STATUS=1
while [ ${STATUS} -ne 0 ]
do
mysqldump -uroot -psomepass --all-databases > sql-backup.sql
STATUS=${?}
done


exit 0


That’ll work just fine–the special reserved variable ${?} contains the exit code of the last run command. Mysqldump is kind enough to use non-zero ones on any kind of error, so if it doesn’t work in our script we’ll retry.

But for instance, let’s say our script looks like this:


#!/bin/bash
STATUS=1
while [ ${STATUS} -ne 0 ]
do
mysqldump -uroot -psomepass --all-databases | gzip > sql-backup.sql
STATUS=${?}
done


exit 0


The problem here is that ${?} now contains the exit code for gzip, not mysqldump! Will gzip respond properly if mysqldump doesn’t provide an input stream from the pipe? Maybe, maybe not. Bottom line is that it isn’t reliable, and not what I’d consider good shell programming.

Instead, check out this solution:


#!/bin/bash


STATUS=1
while [ ${STATUS} -ne 0 ]
do
mysqldump -uroot -psomepass --all-databases | gzip > sql-backup.sql
STATUS=${PIPESTATUS[0]}
done


exit 0


The BASH reserved array ${PIPESTAUTUS[x]} contains the exit codes for all programs in the array. In this example, ${PIPESTATUS[0]} is mysqldump, and ${PIPESTATUS[1]} is gzip.

I think the best part is the solution they came up with… check it out.

Tip #1 – Start and stop your VMs from the command line

If your VMware server is headless and gui-less (you didn’t install a GUI did you?) it’s handy to be able to start and stop your VM processes with a command line tool over ssh. Use the vmware-cmd tool for this:

vmware-cmd /path/to/vmxfile.vmx stop <hard|soft>

or

vmware-cmd /path/to/vmxfile.vmx start

The third option is the powerop mode. ‘soft’ uses the VMware tools within the guest OS, while ‘hard’ simply powers on and off the VM without the tools.

Tip #2 – Re-install your VM Tools quickly

After upgrading your kernel on Linux-based virtual machines, you’ll also have to re-compile vmware tools’ kernel modules. Upon initial installation, you probably executed the usual:

/usr/bin/vmware-config-tools.pl

But did you know you can speed up the process and make it automatic by using the default options? The next time you need to recompile your tools, use this instead

/usr/bin/vmware-config-tools.pl -default

Tip #3 – Fine-grain your VM’s priority

VMware Server does not provide the flexibility of ESX, but you can get it part-way there by using the Linux scheduler to prioritize your virtual machines. By default, VS gives all vmware-vmx processes a nice value of “-10″. In Linux, processes with “-20″ have the highest priority for system resources, and “20″ have the lowest. By adjusting your busy VMs to a higher negative number (e.g. -15) and your less-intensive VMs to a higher positive number (e.g 0) you can more finely tune your server’s performance and ensure timeslices on the host are more accurately granted.

To do this, use the `renice’ command. First, find the PIDs of your vmware-vmx processes, by using `ps’:

[root@tlfvm5 ~]# ps -ef | grep vmware-vmx

root      3374     1 13 Mar18 ?        2-20:03:36 /usr/lib/vmware/bin/vmware-vmx -C /vmware/tlfmonitor/tlfmonitor.vmx -@ ""

root      4833     1 15 Mar18 ?        3-04:09:11 /usr/lib/vmware/bin/vmware-vmx -C /vmware/DellMonitor/DellMonitor.vmx -@ ""

Then renice the appropriate PID. For example, to give the “tlfmonitor” a bit of a bump to “-12″:

renice -12 33

Like all good things, moderation is key. Start with smaller increments and note the change, then if needed bump it again. It should be noted that your reniced values will disappear as soon as the PID terminates. You can also give it a default higher priority via the .vmx file in the prority.grabbed and priority.ungrabbed directives (see http://sanbarrow.com/vmx/vmx-config-ini.html).

Tip #4 – Manage and extend your virtual disks

VMware Server comes with a tool to completely manage your .vmdk disks. The vmware-vdiskmanager tool can create, defrag, extend, and convert vmdks from one type to another. For example, to expand a vmdk from 10GB to 15GB, power off the VM and issue this command:

vmware-vdiskmanager -x 15Gb /path/to/vmdkfile.vmdk

Note that this extends the raw disk, but not the guest file system. For instance, after doing an extend in Linux on an ext3 file system, use “resize2fs” to adjust it accordingly. You may want to run the vmware-vdiskmanager command without arguments to see some help on the different options, as well as some examples.

Tip #5 – Install VMware tools from the command line

You don’t need to click “VM -> Install Vmware Tools…” on the Server Console to mount the virtual media. Do it from the command line!

vmrun installtools /path/to/vmxfile.vmx

This does precisely what clicking in the GUI does. Once this has been run from the host, go to your VM and mount up the /dev/cdrom device and find your tools RPM ready to go.

That’s it for now. Do you have any tips that are useful for other VMware Server administrators? If so, let me know!