Introduction to Novell Support Advisor 1.0.0
Lately if you have been in the Novell Communities pages or reading the Novell Press Release information it is likely you have come across a blurb or two about a new application or tool known as Novell Support Advisor (NSA).
While the press and articles released from the Marketing folks is likely full of pretty screen shots and terms that let you know it will increase your productivity by millions of percent (give or take) I imagine a few in the audience really want to know what it is and how it works, and some of the details I’ve come across on my own are not yet obvious to the casual observer.
I also have an agenda; I want this to become something that those interested can dive into and start using actively, offering suggestions for improvements, getting it to work just right for them, and basically do whatever is best for them. The tool is cool, that much is certain, so let me show you why it’s cool, how it works, and what you can do to make it yours.
So what is NSA? From the NSA website:
What is Novell Support Advisor – Novell Support Advisor is an automated self-help tool used to support and diagnose SUSE® Linux Enterprise Server, Open Enterprise Server (Linux) and associated products. This tool provides customers with a streamlined way to perform both pro-active and reactive system diagnostic tasks typically provided by Novell Technical Services, but in a local, secure and automated fashion.
Novell Support Advisor will be incrementally and automatically updated every two to three months. Customer feedback is essential and welcomed as we consider the next set of features for implementation. You can view the planned set of features and projected timelines below.
Let’s start with the high level stuff and get a bit more serious towards the end. NSA is a graphical tool that checks your environment(s) for known issues. This helps to speed up resolution times of issues.
With its ability to auto-update and get current data via patterns it is a way to be informed of relevant, applicable configuration or security issues quickly and specifically for your systems. It’s a way to help cut your costs and get you focusing on things that cannot be done by a brainless computer.
NSA, if implemented properly and things work the way everybody wants them to, will find known issues in your environment based on data that can be collected via supportconfig but that otherwise you (as an administrator) do not fully understand or know how to find.
The total sum of everybody who writes a pattern is transferred to the person running the pattern on the data gathered from the server. For example if condition A and condition B can cause badThing C and those conditions can be detected via a supportconfig then a pattern can be written to check for the conditions and throw a warning before badThing C even takes place. Not only are solutions able to be found via NSA if used reactively, but they can be prevented if NSA is used proactively.
To go into a bit of the background for the NSA tool we need to know a bit more about supportconfig. For those who are NetWare experts and know about the ‘config.nlm’ module supportconfig is designed to be the same sort of thing, but for Linux. When it runs it goes to various parts of the system by running commands, capturing file contents, and basically poking all around, to get data that will be useful for troubleshooting. These data are put into text files that can be analyzed by administrators, support engineers, developers, or any others interested in the data.
For more information or the ability to download the tool separately check out the supportconfig webpage: http://www.novell.com/communities/node/2332/supportconfig-linux
So getting into some of the nuts and bolts of the tool we find that somehow supportconfig must be placed on the server (or workstation) from which the data are being collected. This is currently done, if used from within the NSA tool, via SSH. The NSA client is supported on Linux (or even windows) client machines and from there can reach out to the (currently only) SLES servers and upload/download data or run commands.
When NSA is launched the user (a system administrator most-likely) is able to enter an IP address or DNS information for a remote system. Armed with these data (the connection information and credentials for authentication) the NSA client then reaches out over the network and connects to the server. The client installs the RPM which contains supportconfig (the RPM is currently named supportutils) and eventually runs supportconfig with some predetermined parameters.
The net result of running supportconfig via the NSA client is a gzipped TAR file which is then copied back to the NSA client where the rest of the analysis is completed (by default supportconfig creates bzipped TAR files so this is a slight different with the 1.0.0 release of the NSA tool).
The NSA tool keeps an archive of all of the “configs” it retrieves forever and breaks them down by date so you can run patterns against a config yesterday and another today and see what may be different (perhaps after you applied patches, or implemented fixes). After running the tool against a server and having the “config” locally in the client the connection to the server is closed and the rest of the magic is executed via patterns.
Going into this process a little, some administrators of *nix for a while may be wondering how the RPM is installed, supportconfig is executed, and various other components happen. Which credentials are used for this? What if I don’t want to use ‘root’ specifically because that account is disabled for direct SSH access (as it should be for all systems)?
Well those are all fair questions. The default credentials entered are for ‘root’ and the default port for access is 22, though both are configurable. If a user besides the ‘root’ user is to be used then that user must have a fair bit of power granted via ‘sudo’. From my own system the ‘nsauser’ is granted rights via the following line in /etc/sudoers:
Syntax: <username> <machineHostname> = NOPASSWD: /bin/uname, /bin/mkdir, /bin/rpm, /usr/bin/env, /sbin/supportconfig, /bin/mv, /bin/ls, /bin/chmod, /bin/rm Example: nsauser systemNameHere = NOPASSWD: /bin/uname, /bin/mkdir, /bin/rpm, /usr/bin/env, /sbin/supportconfig, /bin/mv, /bin/ls, /bin/chmod, /bin/rm
The documentation for NSA actually instructs the user to set things up a bit more generically, though that is simply because it’s the minimal way to get things going. The settings above were found by checking the /var/log/messages file after running with the line below to see which ‘sudo’ commands were executed by the user.
nsauser systemNameHere=(ALL) NOPASSWD: ALL
To see the interaction via /var/log/messages the following may be useful; keep in mind this is for the 1.0.0 version of the NSA client:
Apr 2 13:01:30 systemNameHere sshd: Accepted keyboard-interactive/pam for nsauser from 184.108.40.206 port 55898 ssh2 Apr 2 13:01:30 systemNameHere sudo: nsauser : TTY=unknown ; PWD=/home/nsauser ; USER=root ; COMMAND=/bin/uname -srpon Apr 2 13:01:30 systemNameHere sudo: nsauser : TTY=unknown ; PWD=/home/nsauser ; USER=root ; COMMAND=/bin/mkdir /opt/nsa/ Apr 2 13:01:30 systemNameHere sudo: nsauser : TTY=unknown ; PWD=/home/nsauser ; USER=root ; COMMAND=/bin/mkdir /var/log/nsa/ Apr 2 13:01:31 systemNameHere sudo: nsauser : TTY=unknown ; PWD=/home/nsauser ; USER=root ; COMMAND=/bin/rpm -e ntsutils Apr 2 13:01:31 systemNameHere sudo: nsauser : TTY=unknown ; PWD=/home/nsauser ; USER=root ; COMMAND=/bin/rpm -Uvh /home/nsauser//supportutils-1.01-40.1.noarch.rpm Apr 2 13:01:31 systemNameHere sudo: nsauser : TTY=unknown ; PWD=/home/nsauser ; USER=root ; COMMAND=/bin/mkdir /opt/nsa/ Apr 2 13:01:32 systemNameHere sudo: nsauser : TTY=unknown ; PWD=/home/nsauser ; USER=root ; COMMAND=/bin/mv /home/nsauser/nsa.conf /opt/nsa/ Apr 2 13:01:32 systemNameHere sudo: nsauser : TTY=unknown ; PWD=/home/nsauser ; USER=root ; COMMAND=/usr/bin/env SC_CONF=/opt/nsa/nsa.conf /sbin/supportconfig -bg Apr 2 13:03:09 systemNameHere zmd: NetworkManagerModule (WARN): Failed to connect to NetworkManager Apr 2 13:03:20 systemNameHere sshd: fatal: Timeout before authentication for 220.127.116.11 Apr 2 13:03:31 systemNameHere zmd: Daemon (WARN): Not starting remote web server Apr 2 13:04:14 systemNameHere kernel: device-mapper: table: 253:0: mirror: Device lookup failure Apr 2 13:04:14 systemNameHere kernel: device-mapper: ioctl: error adding target to table Apr 2 13:04:40 systemNameHere kernel: pnp: Device 00:09 disabled. Apr 2 13:04:40 systemNameHere kernel: parport 0x378 (WARNING): CTR: wrote 0x0c, read 0xff Apr 2 13:04:40 systemNameHere kernel: parport 0x378 (WARNING): DATA: wrote 0xaa, read 0xff Apr 2 13:04:40 systemNameHere kernel: parport 0x378: You gave this address, but there is probably no parallel port there! Apr 2 13:04:40 systemNameHere kernel: parport0: PC-style at 0x378 [PCSPP,TRISTATE] Apr 2 13:04:40 systemNameHere kernel: pnp: Device 00:09 activated. Apr 2 13:04:40 systemNameHere kernel: parport: PnPBIOS parport detected. Apr 2 13:04:40 systemNameHere kernel: parport0: PC-style at 0x378 (0x778), irq 7, using FIFO [PCSPP,TRISTATE,COMPAT,EPP,ECP] Apr 2 13:04:40 systemNameHere kernel: lp0: using parport0 (interrupt-driven). Apr 2 13:04:40 systemNameHere kernel: ppa: Version 2.07 (for Linux 2.4.x) Apr 2 13:04:52 systemNameHere sudo: nsauser : TTY=unknown ; PWD=/home/nsauser ; USER=root ; COMMAND=/bin/ls /var/log/nsa/ Apr 2 13:04:52 systemNameHere sudo: nsauser : TTY=unknown ; PWD=/home/nsauser ; USER=root ; COMMAND=/bin/chmod ugo+r /var/log/nsa/nts_systemNameHere_090402_1301.tgz Apr 2 13:04:53 systemNameHere sudo: nsauser : TTY=unknown ; PWD=/home/nsauser ; USER=root ; COMMAND=/bin/rm -r /var/log/nsa/ Apr 2 13:04:53 systemNameHere sshd: Received disconnect from 18.104.22.168: 11: Closed due to user request.
As you can see the client connects and then runs ‘sudo’ to do a variety of operations from making a directory (specifiable in the NSA’s settings), removing the previous supportconfig’s package, upgrading the current supportconfig package, moving things around, and finally running supportconfig. At the end you can see it cleans up the data on the system. The data in between the sudo sections are probably caused by running supportconfig (perhaps via the hwinfo command).
While the log shown above illustrates a connection to the server via username and password it is also possible to use the NSA client to bind via SSH using public/private keys which SSH supports natively. This is setup on the server side like any server-side SSH connection via the ~/.ssh/authorized_keys file for the identity being logged in via SSH. In the NSA client, before connecting, simply check the ‘Use SSH Keys’ checkbox and optionally (depending on whether or not the private key is protected by a passphrase) enter in a passphrase for the private key file you will specify. Browse to the key file and then you should be able to connect without using a password at all.
This addresses concerns regarding running with the ‘root’ user directly, but it may also be a concern that these privileges are ever given to a user who can access the system in this way. Some of the commands required are indeed very powerful and without further restriction could let a malicious user damage the system. It may be that you would like to give one person with NSA the ability to run patterns but keep them from having any way of accessing the system directly in any fashion.
For these cases, recall that the NSA client stores the configs in an archive from which the client can read configs to run patterns over and over again. This archive is organized out of the box first by hostname and then by time, but the client basically displays the directory structure of the archive however it is created so it can be created by you and then pointed-to for access later via the client.
In this way it is possible to have one user with rights, or a cron job with the rights, run supportconfig manually or automatically and then store the supportconfig results in a directory accessible by other users. An administrator can setup supportconfig to automatically upload its results to a file server from which a helpdesk user could pull the read-only archives and run patterns against them as part of a daily routine.
Security of the supportconfig output is important because of the configuration information contained therein but not as important as having full ‘root’ privileges secured on a server. supportconfig already supports the ability to upload its results to a repository of some kind securely. See its documentation for more information.
So going back to the NSA client a bit more I mentioned it is supported on Linux and even on windows. Written in Flex and AIR (Adobe) as well as in Java (Sun, er, Oracle) cross-platform support comes naturally. On the server side supportconfig must be able to install and run which requires the use of RPMs. I believe supportconfig works on both SLES and RedHat though NSA is only currently supported with SLES 9, 10, and 11. It can also run on SLED though currently it is targeted for servers more than desktops.
The patterns themselves are written in Perl and can be viewed at any time in the NSA client’s ‘patterns’ directory. Writing new patterns of your own for your environment can be accomplished with a little Perl and supportconfig knowledge; stay tuned for an article on the same. Once a custom pattern is developed place it in the ~/.supportAdvisor/custompatterns directory.
This option is not in the 1.0.0 release but is in subsequent releases. Custom patterns in 1.0.0 requires a little more tinkering that I’ll cover later if there is enough interest but in the meantime using a newer client will probably be much simpler. Analyzing the shipping Novell -created patterns is possible by simply viewing the script files in ~/.supportAdvisor/patterns with your favorite text editor. Patterns are divided up into directories based on what they do; for example there is a directory for Clustering, Connectivity, eDirectory, OES, Print, SLE, Update, Security, and Virtualization currently.
When running either an old or a new config is loaded the list of patterns NSA knows about is shown. These patterns that come from Novell are sent from a Novell update server if automatic updates are enabled or updates are requested from the NSA client. The update feature will update not only the patterns but can also update the full client or the Novell Support Advisor piece (or all of the above).
If an upgrade to the full client is needed the NSA client prompts for privileged user credentials for the client machine and then starts the installer automatically. The patterns that come from Novell are developed primarily by Novell employees (exclusively by them, so far) and are tested against the configs that have been retrieved previously to ensure valid results or at least a lack of potential damage to the system on which they run.
Pattern ideas as well as full patterns can be proposed/submitted via Novell’s BugZilla site (http://bugzilla.novell.com/). Patterns must be able to determine what is needed from just the output of supportconfig so if that is not possible supportconfig can also be enhanced to retrieve data (if possible) to better meet this goal.
The supportconfig tool via NSA supports plugins which can be used to gather data outside what supportconfig is designed to retrieve out of the box so that may help significantly with implementations specific to your environment.
As mentioned earlier the client and its patterns are made to run on a client machine and not on servers directly (though that is possible as well). While this limits the options of the NSA tool for data retrieval it also means that the client cannot hurt the server easily and that the patterns in the client never have access to the remote system.
Patterns written could potentially have adverse affects on the client system if they were written poorly, though there is no reason to run the NSA client with a privileged user so that should be a minimal risk as well for the most part. Part of the reason for testing patterns against all of the previously-collected configs is to ensure the output is appropriate for the data sent into the pattern. Patterns typically should not error out (have a syntax/runtime error) and should account for possible data in any form (including no data).
The NSA tool on the client does require a privileged user to do the client install due to dependencies on Adobe Air and Flex. The installation is located in the /opt section of the filesystem. Once running as an unprivileged user the NSA client keeps user files in the user’s home directory including patterns, archive, and runtime data. The following is a directory listing from the 1.0.2 beta client on my SLED 11 laptop:
aburgemeister@ablaptop0:~> ll ./.supportAdvisor/ total 16 -rw-r--r-- 1 ab users 585 2009-04-27 18:33 advisorConfig.xml drwxr-xr-x 30 ab users 4096 2009-04-24 12:44 archive drwxr-xr-x 2 ab users 6 2009-04-02 10:05 custompatterns drwxr-xr-x 12 ab users 4096 2009-04-15 07:54 patterns drwxr-xr-x 2 ab users 27 2009-03-17 16:50 servers drwxr-xr-x 3 ab users 34 2009-04-27 18:33 work
The advisorConfig.xml file stores configuration information and looks like the following on my system:
<?xml version="1.0" encoding="UTF-8"?><AdvisorConfig> <buildid>17332441844015282</buildid> <remote_config_path>/opt/nsa/</remote_config_path> <remote_rpm_path>/root/</remote_rpm_path> <archive>/home/ab/.supportAdvisor/archive/</archive> <pattern_url>https://nu.novell.com/NSA/</pattern_url> <perl_path>/usr/bin/perl</perl_path> <update_enabled>yes</update_enabled> <custom_pattern_path>/home/aburgemeister/.supportAdvisor/custompatterns/</custom_pattern_path> <custom_patterns>false</custom_patterns> <survey_enabled>yes</survey_enabled> </AdvisorConfig>
The ‘work’ directory is for the current run of the NSA client against a config and can be opened after the NSA tool is used to view the supportconfig output in its extracted form for manual review of the files themselves. The ‘servers’ directory contains a serverList.xml file which contains the list of servers which have been added to the NSA client for config retrieval and analysis. Passwords passphrases, and keys are currently never stored in the NSA client.
My ‘work’ directory currently looks like the following (recursive listing):
ab@mybox0:~/.supportAdvisor> ls -alR ./work/ work/: total 4 drwxr-xr-x 3 ab@mybox users 34 2009-04-27 18:33 . drwxr-xr-x 8 ab@mybox users 124 2009-04-27 18:33 .. drwxr-xr-x 2 ab@mybox users 4096 2009-04-27 18:33 nts_lab35_090317_1940 work/nts_lab35_090317_1940: total 12848 drwxr-xr-x 2 ab@mybox users 4096 2009-04-27 18:33 . drwxr-xr-x 3 ab@mybox users 34 2009-04-27 18:33 .. -rw-r--r-- 1 ab@mybox users 2076 2009-04-27 18:33 basic-environment.txt -rw-r--r-- 1 ab@mybox users 15429 2009-04-27 18:33 basic-health-check.txt -rw-r--r-- 1 ab@mybox users 1335 2009-04-27 18:33 basic-health-report.txt -rw-r--r-- 1 ab@mybox users 152434 2009-04-27 18:33 boot.txt -rw-r--r-- 1 ab@mybox users 7239 2009-04-27 18:33 chkconfig.txt -rw-r--r-- 1 ab@mybox users 172 2009-04-27 18:33 cimom.txt -rw-r--r-- 1 ab@mybox users 175 2009-04-27 18:33 crash.txt -rw-r--r-- 1 ab@mybox users 9125 2009-04-27 18:33 cron.txt -rw-r--r-- 1 ab@mybox users 81 2009-04-27 18:33 dns.txt -rw-r--r-- 1 ab@mybox users 40870 2009-04-27 18:33 env.txt -rw-r--r-- 1 ab@mybox users 148766 2009-04-27 18:33 etc.txt -rw-r--r-- 1 ab@mybox users 50254 2009-04-27 18:33 evms.txt -rw-r--r-- 1 ab@mybox users 1078 2009-04-27 18:33 fs-autofs.txt -rw-r--r-- 1 ab@mybox users 8078 2009-04-27 18:33 fs-diskio.txt -rw-r--r-- 1 ab@mybox users 425 2009-04-27 18:33 fs-iscsi.txt -rw-r--r-- 1 ab@mybox users 568 2009-04-27 18:33 fs-softraid.txt -rw-r--r-- 1 ab@mybox users 257014 2009-04-27 18:33 hardware.txt -rw-r--r-- 1 ab@mybox users 86 2009-04-27 18:33 ha.txt -rw-r--r-- 1 ab@mybox users 81 2009-04-27 18:33 ib.txt -rw-r--r-- 1 ab@mybox users 1542 2009-04-27 18:33 ldap.txt -rw-r--r-- 1 ab@mybox users 54028 2009-04-27 18:33 lvm.txt -rw-r--r-- 1 ab@mybox users 17301 2009-04-27 18:33 memory.txt -rw-r--r-- 1 ab@mybox users 381206 2009-04-27 18:33 messages.txt -rw-r--r-- 1 ab@mybox users 415323 2009-04-27 18:33 modules.txt -rw-r--r-- 1 ab@mybox users 11607 2009-04-27 18:33 mpio.txt -rw-r--r-- 1 ab@mybox users 33580 2009-04-27 18:33 network.txt -rw-r--r-- 1 ab@mybox users 1173 2009-04-27 18:33 nfs.txt -rw-r--r-- 1 ab@mybox users 175 2009-04-27 18:33 novell-edir.txt -rw-r--r-- 1 ab@mybox users 87 2009-04-27 18:33 novell-lum.txt -rw-r--r-- 1 ab@mybox users 91 2009-04-27 18:33 novell-ncp.txt -rw-r--r-- 1 ab@mybox users 100 2009-04-27 18:33 novell-ncs.txt -rw-r--r-- 1 ab@mybox users 87 2009-04-27 18:33 novell-nss.txt -rw-r--r-- 1 ab@mybox users 1113 2009-04-27 18:33 ntp.txt -rw-r--r-- 1 ab@mybox users 88 2009-04-27 18:33 ocfs2.txt -rw-r--r-- 1 ab@mybox users 398558 2009-04-27 18:33 open-files.txt -rw-r--r-- 1 ab@mybox users 12736 2009-04-27 18:33 pam.txt -rw-r--r-- 1 ab@mybox users 11482 2009-04-27 18:33 print.txt -rw-r--r-- 1 ab@mybox users 32200 2009-04-27 18:33 proc.txt -rw-r--r-- 1 ab@mybox users 118521 2009-04-27 18:33 rpm.txt -rw-r--r-- 1 ab@mybox users 12452 2009-04-27 18:33 samba.txt -rw-r--r-- 1 ab@mybox users 84 2009-04-27 18:33 sar.txt -rw-r--r-- 1 ab@mybox users 10678 2009-04-27 18:33 security-apparmor.txt -rw-r--r-- 1 ab@mybox users 86 2009-04-27 18:33 slert.txt -rw-r--r-- 1 ab@mybox users 9178 2009-04-27 18:33 slp.txt -rw-r--r-- 1 ab@mybox users 80 2009-04-27 18:33 smt.txt -rw-r--r-- 1 ab@mybox users 1485 2009-04-27 18:33 ssh.txt -rw-r--r-- 1 ab@mybox users 6573 2009-04-27 18:33 supportconfig.txt -rw-r--r-- 1 ab@mybox users 484310 2009-04-27 18:33 sysconfig.txt -rw-r--r-- 1 ab@mybox users 20682 2009-04-27 18:33 udev.txt -rw-r--r-- 1 ab@mybox users 132665 2009-04-27 18:33 updates-daemon.txt -rw-r--r-- 1 ab@mybox users 181666 2009-04-27 18:33 updates.txt -rw-r--r-- 1 ab@mybox users 0 2009-04-27 18:33 updates.txt.rug.1237340515.SEMAPHORE -rw-r--r-- 1 ab@mybox users 16 2009-04-27 18:33 updates.txt.rug.1237340515.SEMAPHORE.out -rw-r--r-- 1 ab@mybox users 970 2009-04-27 18:33 updates.txt.rug.1237340515.SEMAPHORE.sh -rw-r--r-- 1 ab@mybox users 84 2009-04-27 18:33 web.txt -rw-r--r-- 1 ab@mybox users 86 2009-04-27 18:33 xen.txt -rw-r--r-- 1 ab@mybox users 47255 2009-04-27 18:33 x.txt -rw-r--r-- 1 ab@mybox users 9894176 2009-04-27 18:33 y2log.txt 2009-04-27 22:52:26 Jobs:0 Err:0 ab@mybox0:~/.supportAdvisor>
You can see that the supportconfig output is extracted here under the name of the host and the other timestamp information used to name the supportconfig output. These files are purely text-based so reading the contents they contain is trivial. The ‘patterns’ directory listing follows:
ab@mybox@mybox:~/.supportAdvisor> ll patterns total 124 drwxr-xr-x 2 ab@mybox users 44 2009-04-15 07:54 Clustering drwxr-xr-x 2 ab@mybox users 4096 2009-04-15 07:54 Connectivity drwxr-xr-x 2 ab@mybox users 4096 2009-04-15 07:54 eDirectory -rw-r--r-- 1 ab@mybox users 1263 2009-04-15 07:54 nsa.conf drwxr-xr-x 2 ab@mybox users 26 2009-04-15 07:54 OES drwxr-xr-x 2 ab@mybox users 26 2009-04-15 07:54 Print drwxr-xr-x 2 ab@mybox users 48 2009-04-15 07:54 SDP drwxr-xr-x 2 ab@mybox users 4096 2009-04-15 07:54 Security drwxr-xr-x 2 ab@mybox users 4096 2009-04-15 07:54 SLE -rw-r--r-- 1 ab@mybox users 34649 2009-04-15 07:54 SPMan.xml -rw-r--r-- 1 ab@mybox users 63252 2009-04-15 07:54 supportutils-1.01-40.1.noarch.rpm drwxr-xr-x 2 ab@mybox users 4096 2009-04-15 07:54 Update drwxr-xr-x 2 ab@mybox users 69 2009-04-15 07:54 Virtualization 2009-04-27 22:55:40 Jobs:0 Err:0 ab@mybox@mybox:~/.supportAdvisor>
The ‘nsa.conf’ file may be one of interest in this case. It specifies all of the options that may be used by NSA when running supportconfig by default. A snippet follows:
#################################### # Default Options #################################### OPTION_APPARMOR=1 OPTION_AUTOFS=1 OPTION_BOOT=1 OPTION_CHKCONFIG=1 OPTION_CRASH=1 OPTION_CRON=1 OPTION_DISK=1 OPTION_DNS=1 OPTION_EDIR=1 OPTION_ENV=1 OPTION_ETC=1 OPTION_EVMS=1 OPTION_HA=1 OPTION_ISCSI=1 OPTION_LDAP=1 OPTION_LUM=1 OPTION_LVM=1 *snip* ADD_OPTION_RPM_VFULL=0 ADD_OPTION_SLP_FULL=0 VAR_OPTION_BIN_TIMEOUT_SEC=300 VAR_OPTION_CONTACT_COMPANY="" VAR_OPTION_CONTACT_EMAIL="" VAR_OPTION_CONTACT_NAME="" VAR_OPTION_CONTACT_PHONE="" VAR_OPTION_LINE_COUNT=500 VAR_OPTION_LOG_DIRS="/var/log/nsa /tmp" VAR_OPTION_MSG_MAXSIZE=500000 VAR_OPTION_PENGINE_FILES_LIMIT=250 VAR_OPTION_SAR_FILES_LIMIT=30 VAR_OPTION_SILENT=0 VAR_OPTION_UPLOAD_TARGET="ftp.novell.com:/incoming"
As you can see this specifies which modules in supportconfig run and optionally where a resulting supportconfig can be sent. The current supportconfig version is also stored in the patterns directory and updated should something change and a new version is pushed out to customers.
Some current scripts do things such as determine if time is drifting far from the NTP sources that are configured. Another reports on high memory utilization in the eDirectory process. Another checks for existing core files from eDirectory so you can be informed of previous crashes, especially crashes within the past week. Others check for known security issues based on versions of the product, installed components, and the system kernel. The options for patterns are vast and can be extended to almost any part of the system.
After a script is executed there are a few possible results. The three main results are Good, Warning and Critical. Good is surprisingly indicated by a green color, and so it is naturally passed over. There are data in the entry that is green providing some information but typically this is not the point of focus for the NSA tool. Warning shows up as a Yellow entry in the table of results and is something to check into that is more important than a Green entry but not yet something deemed Critical bythe writer of the pattern. A Critical pattern result means something is definitely wrong according to the pattern logic. This is a situation needing to be resolved or perhaps something to be purposefully skipped in the future due to environment irrelevance.
There are other error conditions that basically indicate a pattern is needed to run or it errored out in a way it never should have which we’ll skip for now. The table entries, regardless of their color, currently provide a button labeled ‘View Solution’ that will take you to a TID or other online document with the solution for the issue.
For example if you are having an eDirectory problem where your ndsd service is chewing up too much RAM the TID that is linked is one to help you tune your memory settings for the ndsd process. By providing a link to the solution after the analysis for a particular issue experienced Linux administrators can work on fixing things with their background and Novell’s documented expertise and new or migrating users can at least jump in, see how troubleshooting is done, and possibly get an issue resolved without having to call Novell directly.
Another bit of integration with the rest of Novell is done via the Novell Customer Center (NCC). This portal is a central place for a customer to see their products, entitlements, others in their company tied with the support organization, Service Requests (SR), and multiple other aspects of their Novell relationship.
The shipping 1.0.0 version of NSA has its own tab dedicated to have some integration with the NCC so that opening an SR or looking at your systems is possible and done in an easy fashion. The client even tells you via a little padlock icon at the top of the screen whether or not you are authenticated to Novell’s site. Note that the only reason you may need Internet access while using the NSA tool is for this feature along with receiving updates or otherwise interacting with third parties over the Internet. The NSA tool only requires, to run, access to the supportconfig output.
In the future some major enhancements are planned for the NSA tool. For example currently all patterns chosen are executed against the config even if they do not make sense. A future plan is to check for required packages on the system before running the patterns so errors about Samba or NFS not being configured are ignored on machines where there is no need for Samba or NFS.
Another project in the works is to be able to analyze the configs that come directly from NetWare and provide patterns for that platform for the same purpose as for Linux. Support for other platforms including Windows is also being investigated, though without a robust shell and command-line environment in all windows versions (like the various shells available in Linux and Unix) the data collection needs to be done via other means.
Other enhancements may include support for the ability to automatically run patterns and return data, or integration with other Novell products for a more complete overall solution. With the supportconfig output the presence of applied patches can be confirmed as installed or other system errors could be sent to a centralized helpdesk system for automatic ticket creation and resolution.
Work is also in progress for the creation of a tool that will allow those without programming experience to start with pattern development. The BugZilla system is open to the public and ideas are encouraged to be submitted to the development team at any time.
Feedback is also encouraged at runtime of NSA. There is a button within NSA that provides a way to respond directly about the most-recent use of NSA when closing the client down as you can see in the XML configuration file shown above. After selecting a pattern’s result and seeing the resulting Solution button you are also prompted for data regarding the accuracy of the patterns to increase accuracy and usability.
The NSA also has its own public forum which is encouraged for any questions you have and is located at http://forums.novell.com/novell-product-support-forums/novell-support-advisor/ for review or contributions.
Hopefully this provides a decent introduction to the various components of NSA. Feel free to ask questions via the comments section of this article if there are bits I have missed.