FSVS ignore patterns (v1.1.5)

Here's a list of the current ignore patterns that I use on my CentOS5 box.

# fsvs ignore dump
./backup
./dev
./home
./lost+found
./media
./mnt
./proc/**
./root/.mozilla/firefox/**/Cache/**
./root/.thumbnails/**
./selinux
./sys
./tmp
./var/cache/**
./var/lock/**
./var/log/**
./var/named/chroot/proc
./var/run/**
./var/spool/**
./var/tmp/**

There are a few commands that I use to keep my sanity:

# fsvs dump ignore | sort > /root/fsvs-ignore.txt
# sort /root/fsvs-ignore.txt | fsvs ignore load

I find that keeping my ignore files in a .txt file under /root makes it easier to work with them. I'm able to edit the text file, load the ignore patterns into FSVS and see whether it does what it should. If it's wrong, I re-edit the text file and load them back into FSVS.

...

After mucking with a new box for a week, here's the set of ignore filters that I'm using on another CentOS5 box. On this particular box, I'm only versioning configuration data (/etc, /var/named).

[root@fw1-shimo /]# fsvs ignore dump | sort
./backup/
./bin/
./dev/
./home/
./lib/
./lib64/
./lost+found
./media/
./mnt/
./proc/
./root/
./sbin/
./selinux/
./srv/
./sys/
./tmp/
./usr/bin/
./usr/include/
./usr/kerberos/
./usr/lib/
./usr/lib64
./usr/libexec/
./usr/local/bin/
./usr/local/include/
./usr/local/lib/
./usr/local/libexec/
./usr/local/share/
./usr/local/src/
./usr/sbin/
./usr/share/
./usr/share/applications/
./usr/share/backgrounds/
./usr/share/dict/
./usr/share/doc/
./usr/share/i18n/
./usr/share/info/
./usr/share/locale/
./usr/share/man/
./usr/share/pixmaps/
./usr/share/X11/
./usr/share/zoneinfo/
./usr/src/
./usr/tmp/
./usr/X11R6/
./var/cache/
./var/lib/
./var/lock/
./var/log/
./var/named/chroot/dev/
./var/named/chroot/proc/
./var/named/chroot/var/run/
./var/run/
./var/spool/
./var/svn/
./var/tmp/
./var/www/
[root@fw1-shimo /]#

Identifying bandwidth abusers in Linux

# /sbin/ip link

This Linux command will display information about your interfaces. When doing network analysis, the primary information that we're interested in is whether the interface is running in promiscuous mode. An adapter that is running in promiscuous mode can capture any packets that pass by on the wire, not just the ones destined for its MAC address. Here's an example of a ethernet adapter that is in promiscuous mode:

3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:16:ff:ff:ff:25 brd ff:ff:ff:ff:ff:ff

If you're in a situation where there are multiple hosts on the WAN side and you want to monitor traffic for them, you'll need to use an interface in promiscuous mode. You'll also need to be connected to the same hub as those units, or connected to the same switch where your port is configured in monitoring mode.

# /sbin/ifconfig

Use this command to find out which interface is your WAN link and which interface is your LAN link (in the case of multi-homed systems).

/usr/bin/nload -t 10000 -u H -U H -i 1750 -o 1750 eth0

The nload utility is a console application that will graph the inbound and outbound activity on your network interface. You'll have to download and install this software yourself as it is not included in most distributions. If you have "rpmforge" configured on your CentOS5 installation, this is as simple as "yum install nload". Some key arguments are shown above. "-t 10000" sets the update time to every 10 seconds, "-i" and "-o" set the graph maximum height in kilobits per second (1750 works well for a 1.5Mbit T1).

/usr/sbin/nettop -d 5 -i eth0

This is another console utility that you can add to a Linux firewall. Nettop displays a tree-like listing of all activity on a particular interface, with the packets grouped by protocol and then port/service. This gives you a quick idea of what services are abusing your bandwidth.

Remote GUI administration of CentOS5 using Windows

Over the years, I've become very spoiled by Windows Terminal Services that we use to administer our Windows 2000 and Windows 2003 servers. It's fast, it's slick, it allows copy-paste and with a bit of command line fu you can connect to the physical display (instead of one of the two virtual sessions). It also uses built-in Windows authentication and offers encryption.

So, now that I'm rolling out CentOS 5 servers - I need something similar that allows me to look at the graphical UI on the box from elsewhere. From what I can tell, my options are:

KVM that supports TCP/IP

Probably one of the holy grails of remote administration. It allows you to see everything from the BIOS setup screen onward without needing to be physically at the machine. The downside is cost. So while I will eventually be hooking one of these up, it's not in the budget for this quarter.

VNC over SSH

I have a love/hate relationship with VNC. On the Windows clients, we use UltraVNC with built-in Windows authentication and the AES encryption plug-in.

But if you want to wrap VNC with SSH, you have to configure port forwarding all the time in PuTTY. Which turns connecting to a remote server into a multi-step process. With Windows' RDP, I just say "connect to IP address X" and I'm done (and I can connect in as anyone that I want). For PuTTY+VNC, I have to jump through a lot more hoops.

There's also the (possible) issue that VNC is nowhere as efficient over the network as RDP. Once you use Terminal Services' RDP, you'll be spoiled and never want to use older technologies. It (almost) never glitches, it's lightning fast and responsive, and it's just pure remote GUI goodness (except for being a MS-only protocol).

X11 over SSH

This is where I'm heading at the moment. It uses SSH for authentication, so we can lock things down that way (forcing the use of public keys).

Now, a word of caution. A misconfigured SSH or X11 server is a security breach waiting to happen. Pay close attention to chapter 9 in SSH, The Secure Shell, The Definitive Guide by Barrett, Silverman & Byrnes (published by O'Reilly).

Installing Xming on Windows

In order to do X11 on Microsoft Windows, you need to install "X Server" software on the Windows box. While there are pay options out there, I'd suggest starting with Xming which is free (GPLv2). You'll want to download and install both Xming and Xming-fonts.

Configuration of sshd and X11

In order for the local X Server (Xming - running on your Windows system) to talk to the remote Linux server, you'll need to verify some settings on the Linux server. First up is configuration of the sshd daemon (typically /etc/ssh/sshd_config for OpenSSH). Look for the following 2 lines and make sure they are configured correctly:

X11Forwarding yes
#X11UseLocalhost yes

By default, OpenSSH ships with X11Forwarding set to "no" but the default for X11UseLocalhost is "yes". So you should only have to add the "X11Forwarding yes" line.

Create a PuTTY session

I'll make the assumption that you're going to use a PuTTY public-key pair. If you need to install a generated PuTTY key (maybe you want to use a separate PuTTY key for X11 forwarding), then here are the directions for OpenSSH.

(login as yourself or as root and then "su" to your username)
# cd ~/.ssh
# cat > machinename@svn.pub
(paste in PuTTY key)
# ssh-keygen -i -f machinename@svn.pub >> authorized_keys
(Ctrl-D to exit)

1. Right-click on the Pageant icon in the system tray and choose "New Session".
   
2. Enter the hostname (i.e. 192.168.1.1)
   
3. Go to the Connection -> SSH -> X11 tab
   
4. Turn ON "X11 forwarding"
   
5. Display location should be: localhost:0
   
6. Go back to the Session tab
   
7. Enter a name in the Saved Sessions text box (i.e. "MyHost-X11") and click on "Save"
   
8. Click the "Open" button to connect to the server
   

If all goes well, you should see a line like:

/usr/bin/xauth: creating new authority file /home/thomas/.Xauthority

Which tells us that SSH is ready to do some X forwarding.

Fire up Xming

If you haven't already ran Xming you should run XLaunch and just roll through the defaults. Now, in the PuTTY window that is sitting at a command prompt, try:

# xeyes

And you should see the xeyes application open up on your Windows system. If you want to continue to start up other X applications, put an ampersand (&) at the end of the line.

More advanced stuff

1. Fire up XLaunch
   
2. Select "One window" and click "Next"
   
3. Select "Start a program" and click "Next"
   
4. The start program should be either "gnome-session" or "startkde"
   
5. Select Run Remote using PuTTY (plink.exe) and turn on the compression option.
   
6. Enter the IP address or hostname in "Connect to computer" of the Linux box that you are connecting to
   
7. Enter your username in the "Login as user"
   
8. Click the "Next" button
   
9. In the "Additional parameters", enter "-screen 0 1024 768" which will set screen zero to be 1024x768
   
10. If you run your SSH server on a non-standard port, enter "-P port" in the PuTTY extra options field (run "plink" at a Windows command prompt to see the possible options)
    
11. Save your configuration file and click "Finish"
    

If all goes well, you should see the Gnome desktop!

Final thoughts (for the moment)

Now, it's still not as slick as Terminal Services. But it seems to work just fine and gives me a GUI desktop. I still plan on doing most of my administration from the command line, but this provides a nice GUI for those who follow in my footsteps.

UltraVNC (Server) Install on Windows XP

Installing UltraVNC (see also "UltraVNC Installation")

1. Download UltraVNC for MS Windows
   
2. Run the setup program (currently this is: UltraVNC-100-RC203-Setup.exe)
   
3. Accept the license agreement and read the Information screen
   
4. Use the default install destination location
   
5. Choose "Complete Install"
   
6. Use the default Start Menu Folder
   
7. Turn ON "Register Ultr@VNC Server as system service"
   
8. Turn ON "Start or restart Ultr@VNC service"
   
9. Turn OFF the (3) options that create desktop icons
   
10. Turn ON "Associated .vnc files with Ultr@VNC Viewer"
    
11. Click "Install" to start the installation.
    

WinVNC: Default Local System Properties (see "configuration for details)

1. Turn OFF "Enable JavaViewer"
   
2. Turn ON "Display Query Window", Set the timeout to 60 seconds, with "Accept" as the default action.
   
3. Under "Multi viewer connections", CHANGE to "Keep existing connections"
   
4. Under "Authentication", set a secure default password
   
5. Under "Authentication", turn ON "Require MS Logon", turn ON "New MS Logon"
   
6. Click on "Configure MS Logon Groups", Add, enter "Administrators" (note the plural) and click "OK". Grant that group full control and click "OK" to close the UltraVNC Security Editor window.
   
7. Most other options can be left "as is"
   

AES Encryption plugin (a.k.a. DSM)

1. Download the AESV2 Plugin (currently: AESV2Plugin100.zip)
   
2. Extract the .DSM file to the program folder where you installed UltraVNC (usually: C:\Program Files\UltraVNC), see "DSM quick start" for more information.
   
3. Re-open the "Default Local System Properties" window for the UltraVNC server (Start -> UltraVNC -> UltraVNC Server -> Show Default Settings). Alternately, start up the service helper systray app (Run Service Helper) and go to "Admin Properties")
   
4. Under "DSM Plugin", turn ON the "Use:" checkbox and select "AESV2Plugin.dsm" from the list.
   
5. Click "OK"
   

VNC Resource Links

Various links about VNC

Virtual Network Computing (VNC) - Wikipedia entry about VNC.

Taking your desktop virtual with VNC by Tim Waugh

VNC FAQ-o-Matic

Making VNC more secure using SSH

Free and Easy Remote Access with VNC Reverse Connections

Geek to Live: Secure VNC with Hamachi

Secure VNC with two-factor authentication