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

Cisco ASA VPN and RSA SecurID Appliance

I recently set up an RSA SecurID Appliance as a authentication source for a Cisco ASA 5510 running 8.0.x firmware. The basic setup of the box was pretty straightforward. It runs a stripped down Linux distribution with a 2.6.24.x kernel.

Anyway, after setting up an authentication source using a Windows 2003/2008 Active Directory domain controller and importing a batch of time based RSA key token, I set up the ASA to authenticate off the Radius server. Here's the necessary config on the ASA:

aaa-server rsaapp protocol sdi
aaa-server rsaapp (INSIDE) host 10.14.14.50 MY_PASSWORD_FOR_RADIUS_CLIENT

tunnel-group employees type remote-access
tunnel-group employees general-attributes
address-pool employees-pool
authentication-server-group rsaapp
default-group-policy operations
tunnel-group operations ipsec-attributes
pre-shared-key *

Here are several important things to do:

1. set up DNS entries for the RSA box and the ASA, both forward and reverse/PTR. The box seems to be looking for its FQDN. You can use the host file for setup.

2. make sure the ASA, RSA box, and domain controller all have accurate time (via NTP, etc.)

3. setup a radius client on the RSA box and use the same pass phrase you used in the ASA aaa-server config

4. assign token devices to users... start off with one user for testing.

5. Re-synchronize the token. I'm not 100% sure this is necessary, but I tried several tokens, and this seemed necessary.

6. Have the user log into the self-service console:

https://myrsaappliance.mydomain.local:7004/console-selfservice

He or she should log into the console with their active directory username and password. He or she should then set a PIN on the token.

7. Wait for a minute or a two, and then have the user log into the VPN appliance with the Cisco client. This seemed to be necessary, as the token didn't seem to work at first. After running through the configuration again, I tried waiting, and this worked.

Entourage 2004 Crashes After Updates on OS X 10.5.8

I recently set up a new Mac Pro. I installed Office 2004 and copied the user's files over. Entourage started fine, and the user's Exchange mailbox seemed to open correctly.

I patched the installation of office, and Entourage started crashing shortly after launching it. I then removed Office 2004, and reinstalled it. This time, Entourage said that it could not open this version of the database. I patched 10.5.2 to 10.5.8, to no avail.

I tried various fixes other people suggested on the web. In the end, I patched 2004 with the latest patch, killed the Microsoft Database process. Since the user did not keep a PST, I simply moved the user's Entourage data in documents (In a Microsoft folder) to another location - and then reconfigured the entourage client for exchange.

Entourage opened with no issues.