Creating a Central Supportconfig Repository
FTP Server Configuration
The supportconfig tool gathers system information to troubleshoot problems and reduce resolution time. The troubleshooting process is enhanced when you can compare a working server to a broken one, especially when you can compare the working and broken states of the same server. One challenge is, the supportconfig tar ball is saved local to the server. It would be best to copy the tar ball off the server in case it has problems in the future. This article discusses a method of creating tar balls and uploading them to a different server. It should be noted that supportconfig is not inventory management software. It is troubleshooting software. There are plenty of excellent software packages designed for inventory management. The general idea is to create a local FTP server that supports anonymous uploads. Next, configure each server in your enterprise to automatically upload it’s supportconfig tar balls to this central FTP server. We’ll start with the central FTP server configuration.
FTP Server Configuration
I will be using a SUSE Linux Enterprise Server 10 (SLES10) SP2 base install. Since this is a machine dedicated to supportconfig tar balls, it does not need any extra RPM packages, except an FTP server.
Figure 1 – Basic FTP Server Configuration
- Install the pure-ftpd FTP server with it’s dependent packages.
Figure 2 – Installing the pure-ftpd Package
Figure 3 – Accept pure-ftpd Dependencies
- Edit /etc/pure-ftpd/pure-ftpd.conf to allow anonymous uploads. Just change “AnonymousCantUpload yes” to “AnonymousCantUpload no.”
- Configure the pure-ftpd service to start at boot time.
jrecord5:~ # chkconfig pure-ftpd on jrecord5:~ # chkconfig -l pure-ftpd pure-ftpd 0:off 1:off 2:off 3:on 4:off 5:on 6:off xinetd based services: pure-ftpd: off
- Either run rcpure-ftpd start or reboot the FTP server.
jrecord5:~ # rcpure-ftpd start Starting pure-ftpd done
- Create a tar ball repository mount point.
jrecord5:/srv/ftp # mkdir /srv/ftp/repository
- If needed, mount the file system to the repository mount point.
jrecord5:~ # grep repo /etc/fstab /dev/repo/sctb /srv/ftp/repository reiserfs acl,user_xattr 1 2 jrecord5:~ # mount /srv/ftp/repository/
- Change the repository directory owner and permissions. Make sure you do this after mounting the file system, otherwise only the mount point will have changed, and FTP won’t work right.
jrecord5:/srv/ftp # mount | grep ftp /dev/mapper/repo-sctb on /srv/ftp/repository type reiserfs (rw,acl,user_xattr) jrecord5:/srv/ftp # chown ftp.ftp repository/ jrecord5:/srv/ftp # chmod 775 repository/ jrecord5:/srv/ftp # ls -l total 0 drwxrwxr-x 4 ftp ftp 112 May 12 11:57 repository
- Create a file, and FTP it to the server for a quick test.
Figure 4 – FTP Test Transfer
The host is any server you have in your enterprise that will run supportconfig and upload it’s tar ball to the FTP Server configured above. Each and every server that uploads a tar ball will need to be configured as follows:
- Install the supportutils package.
- Modify the /etc/supportconfig.conf file with the correct FTP Server address assigned to VAR_OPTION_UPLOAD_TARGET. You can also add your company, name and contact information to include in each supportconfig as shown in Figure 6.
Figure 5 – Before supportconfig.conf Changes
Figure 6 – After supportconfig.conf Changes
- Run supportconfig -u.
Figure 7 – supportconfig -u
- You can also configure cron to run a supportconfig on a monthly basis and automatically upload the file to your FTP server.
- Login as root.
- Create a cron entry for root to run the supportconfig in quiet mode on a monthly basis.
jrecord1:~ # crontab -e jrecord1:~ # crontab -l # Run supportconfig in quiet mode on the first day of the month at 11:36pm 36 23 1 * * /sbin/supportconfig -Qu
- NOTE: Don’t forget to change the VAR_OPTION_UPLOAD_TARGET. Novell really doesn’t want your monthly supportconfig tar balls on their FTP server, and will automatically purge them.
It is always good to have system information while the server is running well. It’s even better to have this information offloaded from the server. Creating a supportconfig tar ball repository will allow you to compare the current server state, with previous known good states. When and if you have a problem that needs to be reported to Novell, you will also be able to attach a good and bad version of the supportconfig to your service request, reducing resolution time.
Could you include extra examples for HTTP, SCP, etc, besides FTP?