Remote Desktop Clients, 32Bit Applications, and Windows 2008 R2

I recently ran into a problem with Remote Desktop Services on Windows 2008 R2 (formerly known as Terminal Services from Windows NT 4 through Windows 2008). The problem occurs when someone configures an RDP session that automatically launches a 32 bit application on connection. As you may know, Windows 2008 R2 is 64bit only. The problem I was seeing was that there was frequently a delay after exiting the application.

What should happen is that the RD session should drop after the application closes. What often happens is that the user sees a blue screen for up to two or three minutes, then the session completely drops.

I figured out the cause by using the Remote Desktop Services Manager. I launched a client session that launched the 32bit app upon login. I then closed the application, and the session hanged. Looking in the RD Services Manager, I noticed that there was a service from the session called "splwow64.exe." I killed that process, and the session dropped.

The Fix



The fix is pretty simple. It requires a regedit. Perform this regedit at your own risk! You should backup the registry before you start.

Navigate to the registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\SysProcs

Add the following 32 bit DWORD:
splwow64.exe

and set the value to 0

The fix worked instantly, at least for me. Your results may vary, of course. As far as I understand, you can create other dword values in there to terminate other programs that are stalling the exit of remote desktop sessions.

Apparently, splwow64.exe is used in thunking (in this context, converting memory addresses from 32 bit to 64 bit.)

Bacula 5.0

Bacula 5.0 has been out for a little while. Apparently, the developers decided to skip 4.x to differentiate the community edition from the enterprise edition. The new features list is here. I'll be setting it up soon and will likely post some sample configurations.

Linksys Managed Switches - Console Port

I had to set up a Linksys SRW2048 switch recently. It's a 48 port gigabit layer 2 switch. It's primarily web managed, but there is a limited CLI.

Anyway, the console port did not appear to be a standard pinout. I opened the RJ45 to DB9 connector they provided, and discovered it has this pinout:

Pin 1	Pin 2	Pin 3	Pin 4	Pin 5	Pin 6	Pin 7	Pin 8	Pin 9
x	black	yellow	brown	red (+green)	orange	white	blue	x

This is the same as the pinout as I used for the type "A" RJ45-DB9 connector in this article: here.

From my testing, you simply need to make two of the type "A" adapters I mentioned in the linked post, attach a cat5 cable to both ends, and you should be able to connect to the serial port. The Linksys uses 38400 baud - unlike the usual 9600.

Nagios, Passive Service and Host Checks

I recently had to set up a remote nagios installation that would connect back to a central server via NSCA. I followed the standard Nagios documentation for distributed monitoring here. The passive service checks worked fine.

The problem was that I wanted passive checks for hosts, too, and not just services, as the central server would not be able to ping the remote hosts directly in the event that the data is considered stale. I set up all the checks on the central server side to be the service-is-stale check - so any staleness results in an alert, "the check data is stale." Unfortunately, the nagios documentation is a little vague about the ohcp command (the final paragraph on the nagios link above.) I couldn't find any real answer on passive host checks on the web, either.

Here's what I did on the remote side (and not the central collector server.) I copied the submit_check_result script in the documentation, modified it, and saved it as /etc/nagios/bin/submit_host_result. The final version:

# Arguments:
# $1 = host_name (Short name of host that the service is
# associated with)
# $2 = host check output (0, 1, 2, etc.)
# $3 = plugin_output (A text string that should be used
# as the plugin output for the service checks)
#
# Convert the state string to the corresponding return code
central_server=ip.address.or.hostname.of.your.central.nsca.server

/usr/bin/printf "%s\t%s\t%s\n" "$1" "$2" "$3" | /usr/sbin/send_nsca -H $central_server -c /etc/nagios/send_nsca.cfg


I then added the following entry to the command definition file:

define command{
command_name submit_host_result
command_line /etc/nagios/bin/submit_host_result $HOSTNAME$ $HOSTSTATEID$ '$HOSTOUTPUT$'


}

I then modified the nagios.cfg file like so:

obsess_over_hosts=1
# OBSESSIVE COMPULSIVE HOST PROCESSOR COMMAND
# This is the command that is run for every host check that is
# processed by Nagios. This command is executed only if the
# obsess_over_hosts option (above) is set to 1. The command
# argument is the short name of a command definition that you
# define in your host configuration file. Read the HTML docs for
# more information on implementing distributed monitoring.
ochp_command=submit_host_result

Of course, it took a bit of work to figure that out. So, the end result is that both service and host checks are passive on the central server. You might want to make the remote server the parent of all the other remote servers as if it's down, inaccessible, there's no way you'll receive check data for the other hosts, and you'll probably get some unnecessary alerts. I'm sure I'll see some more issues, and will likely post again on this issue.

Setting Up VRRP on Netgear Managed L3 Switches

Preliminary steps

1. Make sure your two switches are connected together, preferably via port-channels (lag)

2. make sure the VLANs you want to apply VRRP to are enabled on the port channels so that they span both switches



Configuration

In this example, we'll create a new routing VLAN (VLAN 15 for this example) on two switches, switch-a and switch-b. The primary ip will be 192.168.211.1, and the secondary will be 192.168.211.2. the VRID for the VRRP will be 15 (for convenience - but not strictly necessary. VRID 1 would work as well, I just find it easier to name it after the vlan.) The virtual IP will be 192.168.211.254.

Master switch

1. log into switch-a

2. enable

3.

vlan database
vlan 15
vlan routing 15
exit

4.

configure
ip routing
ip vrrp
interface vlan 15
ip address 192.168.211.1 255.255.255.0
ip vrrp 15
ip vrrp 15 ip 192.168.211.254
ip vrrp 15 preempt
ip vrrpt 15 authentication simple my_pass
ip vrrp 15 mode (enables vrrp on this interface)
exit
exit

5. verify that VRRP 15 is behaving correctly:

sh ip vrrp interface vlan 15 15
Primary IP Address............................. 192.168.211.254
VMAC Address................................... 00:00:5e:00:01:50
Authentication Type............................ None
Priority....................................... 100
Advertisement Interval (secs).................. 1
Pre-empt Mode.................................. Enable
Administrative Mode............................ Enable
State.......................................... Master

Backup Switch

1. log into switch-b

2. enable

3. enter the following commands:

vlan database
vlan 30
vlan routing 30
exit

4.

configure
ip routing
ip vrrp
interface vlan 15
ip address 192.168.211.2 255.255.255.0
ip vrrp 15
ip vrrp 15 ip 192.168.211.254
ip vrrp 15 priority 1 (makes this a secondary - it defaults to 100)
ip vrrp 15 preempt
ip vrrpt 15 authentication simple my_pass
ip vrrp 15 mode (enables vrrp on this interface)
exit
exit

5. verify that VRRP is working correctly

sh ip vrrp interface vlan 15 15
sh ip vrrp interface vlan 15 15
Primary IP Address............................. 192.168.211.254
VMAC Address................................... 00:00:5e:00:01:50
Authentication Type............................ None
Priority....................................... 1
Advertisement Interval (secs).................. 1
Pre-empt Mode.................................. Enable
Administrative Mode............................ Enable
State.......................................... Backup

Automount Home Directories Over NFS in Linux

On RedHat Enterprise/CentOS...
assuming your home server is called "fs1" and is sharing out /home over NFS. You'll also want to make sure that both your home directory server and the server you're running autofs on has the same passwd/user info - ids, gids.

1. Make sure autofs is installed and running:

sudo chkconfig autofs on
sudo service autofs start

2. add "/home /etc/auto.home" to /etc/auto.master

3. create the file /etc/auto.home and add these lines:

* -fstype=nfs,rw,nosuid,soft fs1:/home/&

4. if you already have a /home dir, move it out of the way:

sudo mv /home /home.old

5. reload autofs

sudo service autofs reload

6. ls /home

You should see the users' home directories.

Building Bacula Client RPMs for CentOS 5.x

This is a quick and dirty explanation of the process. I'm building as root - which you should probably avoid doing.

Download and install the srpm file from bacula's site (sudo rpm -ivh name-of-srpm.srpm)

You'll need to install the rpmbuild utility:



sudo yum -y install rpm-build


To build the client only:

Install a couple of prerequisite rpms:
sudo yum -y install ncurses-devel libtermcap-devel

rpmbuild --define build_client_only=1 --define build_centos5=1 -bb /usr/src/redhat/SPECS/bacula.spec