How to gather and send support info on a Suse system…

To help someone (like me, for instance) remotely diagnose your Suse system, sometimes you need to send him or her diagnostic info from that system.  Fortunately, Suse has a toolset called “supportutils” to do just that.  This article outlines one of my preferred ways of generating and sending such info.  Note that the examples in this article are targeted toward my existing customers, but you can obviously change the examples to suit.  Or, you can *become* a customer…  😉

First, su to root, and check to see if the support utilities and sysstat package are installed:

zypper se sysstat supportutils 

…if the result for each has an “i” (for “installed”) at the far left of the package, it is already installed.  Otherwise, if the package(s) are not already installed, run this to install the sysstat package and the support utilities included with your Suse distro:

zypper in sysstat supportutils

Or, if you wish to run the latest version of the supportutils package (see “comment” below about versions), run this to install/upgrade to the latest version at the time of this writing:

rpm -Uvh http://download.opensuse.org/repositories/Novell:/NTS/SLE_10/noarch/supportutils-1.20-1.1.noarch.rpm

(Please see the Supportutils project page at http://en.opensuse.org/Supportutils for the latest info and versions.)

COMMENT:  Unfortunately, I have discovered that the info collection part of some modules seems to be broken on some versions; I’m not sure why.  You’ll know they need to be skipped if you run the tool and it hangs for a long time.  I’ve seen the DNS module hang on most systems with the older package, the SYSFS module hang on Opensuse with the latest version, the NSS modules hang on OES servers, and so forth.  Personally, and take this for what it’s worth, I like the distro-provided supportutils package on OpenSuse, and the latest download-able on available for SLES10 and/or OES servers… all with the caveats, of course…

So, to get around the sticking/hanging problem, we need to modify the configuration file to skip the info collection for those modules that get stuck  (of course, it is also possible that you want to modify the config file to exclude certain things for other reasons, as well).  For this example, I disable the DNS info collection (which has since been repaired in newer versions).  You can do it interactively with vi or gedit like this:

vi /etc/supportconfig.conf

…(or via gui, gedit /etc/supportconfig.conf) and change this line:

OPTION_DNS=1

…to…

OPTION_DNS=0

…or do it non-interactively with this example command set:

mv /etc/supportconfig.conf /etc/supportconfig.conf.bak
sed s/OPTION_DNS\=1/OPTION_DNS\=0/ /etc/supportconfig.conf.bak > /etc/supportconfig.conf

Now back to the program; whether you upgraded, modified the config file, or not….

Next, create the output with this command:

supportconfig

When completed, it gives you a nice info summary.  One of the first lines in the summary is the resulting tar ball file size.  If it is reasonably small, like under 10MB, feel free to send it to me via email it to me this way (if it is larger than 10MB, I can provide an alternate method of delivery):

echo "See attached." | mailx -a /var/log/nts*`date +%y%m%d_%H`*.tbz -s "Support Config file from $HOSTNAME" jpavlov@yourLinuxGuy.com

…Note that the above command will send all of the result files that were generated in the current hour; you can take off the “%H” if the file you wish to send was generated in a different clock hour.

If you’re curious, when I get it, I download from my email and unzip it in a temp directory for review:

cd /tmp/support
tar -jxvf nts_lt1101010_100106_1010.tbz

And that’s it!  I hope it helps.  And, I hope I can help you…
🙂

Leave a Comment

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