Novell Support Advisor (NSA) ( is a tool that can do analysis of your environment’s servers and apply logic to retrieved data to determine if problems are currently happening or potentially could happen in the future. Check out other articles of mine or the NSA website for information on the general idea behind the tool. One of the more-interesting features of the tool is the ability to discover servers on your network for you. The tool currently lets you scan and discover a standard class-C network (anything that matches a or /24 netmask anyway). When the network address is specified and the IP range within that network is also input the tool stats going through the sockets sequentially attempting to make connections to what is presumably a set of SSH servers.

While doing some testing of this feature I was looking around on Novell’s network for servers against which I could use this tool. Of course I had my own systems setup and they worked just fine, but I was a bit more interested in a variety of setups as provided by coworkers and others with different administration habits or knowledge bases. While NSA’s ability to scan is useful if you have thousands of boxes to find entering them by hand is too slow and scanning is only a little better. There are free tools available for the job of finding open sockets and I figured I could use one of those to do the scanning job. The next step was to get NSA to know about everything that was found, but only those sockets found, so it could do what it does best (run patterns against retrieved configuration files).

So first let’s look at the tools involved. NSA maintains a list of servers in its user-specific data directory under ‘servers’ so on my system the directory is /home/ab/.supportAdvisor/servers and the file is serverList.xml which contains the XML NSA uses to keep track of servers found or used in the past. A snippet of this file follows:

      <arch> i686 GNU/Linux</arch>

As you can see the structure is fairly simple. The ‘name’ and ‘arch’ fields can actually be left empty and the ‘rundate’, ‘username’, and ‘sshkey’ are not required for the initial population of the file. If we can come up with text in the format like the following for a system then we could be set to easily create this file:


We need that repeated once per system and then to wrap the entire block of text with the open and close tags for ‘servers’ and ‘serverList’. So let’s move to the tool to find open systems. One of the best tools that every network administrator should have is called <a href=””>NMAP</a>. The tool is for doing network analysis and that includes port scans. It turns out that with very little work we can get a list of systems that have open ports back to the command line similar to the following:

nmap -p 22 #Here I am telling NMAP to scan from 1 to 254 on the network for anything listening on TCP port 22.

The results resemble the following:

Starting Nmap 4.75 ( ) at 2009-04-28 23:26 MDT
Interesting ports on
22/tcp closed ssh

Interesting ports on
22/tcp open  ssh

Interesting ports on
22/tcp closed ssh

Nmap done: 254 IP addresses (3 hosts up) scanned in 2.20 seconds

So there are some interesting data here. First, it found three systems (not just the ones with port 22 open) and then tells me one of the three has port 22 open while the other two have it closed. What’s really exciting, though, is that it scanned 254 IP addresses in just over three seconds. Watching this in tcpdump is just fun and I recommend it to see how it actually works but needless to say it is quick and efficient. From here we need to only isolate systems that have open ports, so now we’ll start piping data around. For your own information I’ll add the ‘-n’ flag to NMAP so it does not try to do reverse lookups on IP addresses as that just muddles things later on needlessly. I’ll also redirect STDERR to /dev/null when I can to avoid weird issues there.

nmap -n -p 22 2>/dev/null| grep open -B 2 2>/dev/null

So here we are scanning all IPs on the network and grabbing any lines that have the word ‘open’ in them as well as the two lines previous. The second line above ‘open’ is where the IP address we care about is, so now we’ve gotten rid of any data about closed ports. Let’s focus in on the line with the IP address in a quick way and then print out the fourth field (space-delimited) on that line, which is the IP address:

nmap -n -p 22 2>/dev/null| grep open -B 2 2>/dev/null | grep Interesting 2>/dev/null | awk '{print $4}'

Now we have almost exactly what we need, but it’s actually giving us a colon after the IP address so we’ll remove that now.

nmap -n -p 22 2>/dev/null| grep open -B 2 2>/dev/null | grep Interesting 2>/dev/null | awk '{print $4}' | sed -r 's/(.*?):/\1/g'

Okay, so now with just an IP address returned on every line let’s expand on the ‘sed’ command and actually have it build the rest of our XML for us to go into the serverList.xml file:

nmap -n -p 22 2>/dev/null| grep open -B 2 2>/dev/null | grep Interesting 2>/dev/null | awk '{print $4}' | sed -r 's/(.*?):/<server><ip>\1<\/ip><port>22<\/port><name\/><arch\/><\/server>/g'

So what is our result from this? A big long space-less string that does the job, such as the following:


So if we have multiple entries they are all concatenated together and even though the result isn’t formatted prettily that doesn’t matter as the data are XML and whitespace doesn’t matter between tags. So what’s next? Well we can either copy/paste the monstrosity into the serverList.xml file or we can actually add the leading and trailing tags and overwrite the serverList.xml file directly. Backup your old file first if you’d like, though if you don’t mind recreating it then there’s nothing lost if you don’t. The following is the complete example for your user:

echo ‘<serverList><servers>’`nmap -n -p 22 2>/dev/null| grep open -B 2 2>/dev/null | grep Interesting 2>/dev/null | awk ‘{print $4}’ | sed -r ‘s/(.*?):/<server><ip>\1<\/ip><port>22<\/port><name\/><arch\/><\/server>/g’`'</servers></serverList>’ > ~/.supportAdvisor/servers/serverList.xml

So with one line we can scan an entire network in about two seconds. This can be expanded to do an entire class B network quickly as well by simply expanding the range given to NMAP from ‘’ to ‘192.168.1-254.1-254’. Keep in mind the more you do the longer it will take, of course, but it should get you going and give you a lot of data if nothing else. Before too long you’ll be spending too much time watching configs run and get retrieved and longing for a way to simply cron the process or running supportconfig and uploading data remotely to a central data repository (which you can do with supportconfig) but this is a neat way to get started if you just want to find all your boxes quickly. Taking this a couple levels further you could use the NMAP output to dynamically push supportconfig (the RPM) to your boxes, install it, and then schedule it to run via ‘cron’ with a setting to auto-upload the results to a central repository. As a result you do not need to actually use the NSA client specifically for gathering data but instead can use it for what it does best, which is pattern analysis of configs that are already retrieved. A powerful shell makes all of this fairly trivial to do thankfully.

(Visited 1 times, 1 visits today)
Tags: ,
Category: SUSE Linux Enterprise Server, Technical Solutions
This entry was posted Monday, 11 May, 2009 at 5:27 pm
You can follow any responses to this entry via RSS.


  • richardma says:

    Most companies block access to / from youtube type sites, so why do you put the demo there?

  • Leave a Reply

    Your email address will not be published. Required fields are marked *