Thoughts from the abyss

Like my last post mentioned, I had a script to download ClamWin’s daily and main update files to a local server, where I point my local ClamWin installations to update from. The old way simply downloaded the file regardless if the file had actually changed or not, which resulted in a lot of bandwidth waste over time.

I re-worked the script to use zsync so file comparisons are actually done, just like rsync. Here’s the script in case anyone wants it. Just a Bash script, so make it better if you want, or don’t. Put it in crontab or something so it runs every so many hours.

# crontab -e
01      */4     *       *       * /usr/local/bin/mirror_clamav_zsync

#!/bin/bash

#Mirror 1 & 2
MIRROR1="database.clamav.net"
MIRROR2="db.local.clamav.net"

#Daily file
DAILY="/var/www/html/daily.cvd"

#Separate .zsync files for each mirror
ZSYNCD1="/var/www/html/daily.cvd.zsync"
ZSYNCD2="/var/www/html/daily.cvd.local.zsync"

#Main file
MAIN="/var/www/html/main.cvd"

#Separate ./zsync files for each mirror
ZSYNCM1="/var/www/html/main.cvd.zsync"
ZSYNCM2="/var/www/html/main.cvd.local.zsync"

#Your email address for failures
EMAIL=you@youremail.com

#Log files
DAILYLOG='/var/www/html/logs/clamsync_daily.log'
MAINLOG='/var/www/html/logs/clamsync_main.log'

#Ping mirror 1, if successfull, do the zsync.
if /bin/ping -c 1 -w 1 $MIRROR1 >/dev/null; then
	cd /var/www/html
	/usr/bin/zsync -i $DAILY $ZSYNCD1 -o $DAILY > $DAILYLOG
	/usr/bin/zsync -i $MAIN $ZSYNCM1 -o $MAIN > $MAINLOG
	else
#Ping mirror 2 if mirror 1 fails, if successful do the zsync.
	if /bin/ping -c 1 -w 1 $MIRROR2 >/dev/null; then
		cd /var/www/html
        	/usr/bin/zsync -i $DAILY $ZSYNCD2 -o $DAILY > $DAILYLOG
        	/usr/bin/zsync -i $MAIN $ZSYNCM2 -o $MAIN > $MAINLOG
#If both mirror 1 & 2 are down, send an e-mail message to let you know.
		else
			/usr/bin/printf "Both main and daily updates failed. Both mirrors appear to be down." |	/bin/mail -s "Virus Update Sync Failed" $EMAIL
			exit 0
	fi
fi

#Allow Apache to own so it dishes it out correctly.
/bin/chown -R apache.apache /var/www/html/logs /var/www/html/*.cvd

My boss wanted me to set up a link aggregation, otherwise known as NIC Teaming, Ethernet Trunking, and a bunch of other terms, between our VMware ESX 3.5 Standard installation and a 3COM 4200G switch. This gives you the benefit of load sharing bandwidth, as well as failover in case a link goes down. It took me awhile yesterday to figure it out, since I’ve never done much with it, so I figured I’d document it a bit.

You’ll need to change a few settings that appear to work for me in VMware ESX. Add a second virtual NIC under the networking settings. If you already have one virtual switch, you should be good with just adding a second NIC, and making a few setting changes.

VMware_NIC

After you add another NIC, click on the properties button above it, highlight the vSwitch, and choose edit at the bottom. Under the NIC Teaming tab, change the Load Balancing selection to Route based on ip hash. Ensure Network Failover Detection is set to Link Status only and also make sure that Notify Switches and Failback are both set to yes. Click OK, and then close the vSwitch properties window. If everything looks like the following image, that should be all you need to do with VMware.

VMware_Options

Next, login to your switch. In my example, I’m using a 3COM 4200G switch and 3COM happens to call it Link Aggregation. If you’re using Cisco, or some other brand of switch, consult their documentation on how to set this up. The first thing you have to do is set the ports you are going to aggregate to be of a trunk link type, and enable flow control. On the command line, it should be something like this:

# telnet switch
<4200G>system-view
[4200G] interface GigabitEthernet 1/0/6
[4200G-GigabitEthernet1/0/6] port link-type trunk
[4200G-GigabitEthernet1/0/6] flow-control

Now, do the same for the other port(s) you want in the aggregation. For me, I wanted port 6 and 12 of the switch aggregated.

[4200G] interface GigabitEthernet 1/0/12
[4200G-GigabitEthernet1/0/12] port link-type trunk
[4200G-GigabitEthernet1/0/12] flow-control
[4200G-GigabitEthernet1/0/12] save

If you go to the web interface, you can find the same settings here and change them in one shot: Port -> Administration -> Setup

Highlight the port numbers you want to change, and choose the appropriate drop-down box settings above. Make sure you click Apply down below, and then save the configuration from the menu on the left-hand side.

The last step is to configure the actual link aggregation group. On the command line, do the following for each port you want added to the group.

[4200G] link-aggregation group 1 mode manual
[4200G] interface GigabitEthernet 1/0/6
[4200G-GigabitEthernet1/0/6] port link-aggregation group 1
[4200G-GigabitEthernet1/0/6] interface GigabitEthernet 1/0/12
[4200G-GigabitEthernet1/0/12] port link-aggregation group 1
[4200G-GigabitEthernet1/0/12] save

That’s it. Do do the same on the web interface, go to Port -> Link Aggregation -> Create. Then, choose Manual and highlight the ports that you want in your aggregation. Choose Apply and then save the configuration.

My understanding is that you use LACP between switches, or between devices that have LACP protocol enabled. This allows two devices some automagical detections and what not. From what I read, VMware’s NIC Teaming is not LACP, so don’t be confused. This is why I used the manual LACP disabled mode for the 3COM Link Aggregation. If you know better than I do, please leave a comment and correct me.

Once you have this all done, you should be able to go ahead and pull one of your links down, and your systems will continue to work. In my setup, my VMware ESX server was plugged into the network on port 12 of the 4200G switch. So, I added port 6 and then bundled 6 and 12 together. For a test, I unplugged the original connection port 12, and not so much of a burp happened. The network on VMware ESX failed over and used port 6. Also, I can tell that they are sharing the two NICs now, because if you log into the switch you can issue a status command. Both transmit and receive lights are blinking on both NICs as well.

[4200G]display link-aggregation summary

Aggregation Group Type:D -- Dynamic, S -- Static , M -- Manual
Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
Actor ID: 0x8000, 001a-c160-6e40

  AL  AL   Partner ID            Select Unselect Share Master
  ID  Type                       Ports  Ports    Type  Port
--------------------------------------------------------------------------------
  1   M    none                  2      0        Shar  GigabitEthernet1/0/6

A more detailed view can be gathered from this command:

[4200G] display link-aggregation summary

Remember, you can add as many of these as you want, so long as you have NICs available. And also remember you can use this method to tie switches together as well, in case you don’t have the special fiber connections between the 3COM switches.

Here’s a new guide for CentOS/RHEL lovers.

OCS Inventory NG is a client/server program with a web based management end used to inventory computer equipment. This guide assumes version 1.01 and also has a section demonstrating importing the OCS data into GLPI.

http://www.maxsworld.org/index.php/how-tos/ocs-inventory-ng-on-centos

Enjoy. As usual, feel free to correct me or point out anything that needs added.

I played with OCS Inventory a few years ago, but it wasn’t very mature when I last touched it, so I kind of abandoned using it around the office. I was made known, however, on the CentOS mailing list that it integrates into GLPI’s tracking software. It’s now able to pull over the database of all kids of goodies for hosts hooked up with OCS. I’m excited now.

http://www.ocsinventory-ng.org/

I’m in the middle of deploying a system at work. I’ll be typing up a new how-to guide in case anyone cares to use it. I’ll post it as soon as it’s complete, and also I’ll add it to the CentOS wiki. I’m concentrating on version 1.01 of OCS instead of 1.02, because I tried out 1.02 and wasn’t able to get it working well. Perhaps it’s my doing, but 1.01 works nicely, so I’ll stick to that.

I haven’t written anything, or even updated any of the guides for that matter, in awhile but I setup rsnapshot for my new laptop last night. Since I’ve never used rsnapshot before, except minimal exposure at work, I typed up a guide to installation and use on CentOS/Fedora/RHEL OS systems. My example of the rsync exclude file is limited and based off of what it used from someone I know, so please feel free to correct me or improve upon anything. As always, please comment on any issues you have. Happy backing up.