Recently I was asked to make some relevant system information available to other individuals (1st level support, management) in our company.
Rather than installing X servers across the board and use our BMC monitoring toolset, I wrote this little script that gives out some basic information (daemon status, disk usage, number of users and licenses, etc.).

The script outputs in HTML format, so it can easily be posted on the (intra)net. As a frame in a fully dressed up main page, it actually looks pretty nice.

I thought it was worth sharing. Let me know if you can think of any worthwhile additions to it (or better yet, POST your worthwhile additions).

Instructions: The damn thing _should_ just run and if not it _should_ tell you why not (a man can still dream, right?).
I am in no position to test this script on any other system than my own (solaris 2.5), so I depend on your feedback for fixes and improvements.
Create a header and footer file (html) if desired. The script will produce a file called adm_msg.html.
Schedule the scrip to run and ftp it to a webserver (or mail it out).

Thanks to Pat, Mark and Victor for their contributions so far.

Francesco,

It's a good script to share but I think it only runs really well on Solaris platforms as the 'du' command behaves differently under the various UNIX flavours. Opportunity for enhancements here :)

Also my KSH (HP-UX 11i) is tripping over the double equal bars '=='. I have never seen that before in KSH syntax!?

Thanks for posting it though!

What can I say? I'm a Solaris kinda guy ;)

Thanks for the response, Pat.

Do you have any suggestions for a df alternative (or can you give me some different results)?

To the best of my knowledge, == is part of the '93 Korn shell, but I have been wrong before (...I remember it clearly, it was a cold October day in the late 70's...).

How would you substitute that line to make it run on your flavor?

We are running Solaris and it almost worked just fine for me. The only problem I had was the bshell${TOOLSVERSION} and with the licd${TOOLSVERSION}. When I do a ps I see the bshells as plain old bshell and not bshell6.1. And when I tried the licd6.1 command it comes back with a message about branding the software. Do you need to be root or bsp to run this command?

Thanks for the post!

Mark

Originally posted by mark_h
We are running Solaris and it almost worked just fine for me. The only problem I had was the bshell${TOOLSVERSION} and with the licd${TOOLSVERSION}. When I do a ps I see the bshells as plain old bshell and not bshell6.1.

Strange, that substitution should work. Did you change the line TOOLSVERSION=6.2 in TOOLSVERSION=6.1?

And when I tried the licd6.1 command it comes back with a message about branding the software. Do you need to be root or bsp to run this command?

You need to be root to run licd6.1 (starting the license daemon), but that command is not in the script. It only looks if licd is an active process. The licmon6.1 command (if that's what you're referring to), does not require root normally, but of course the permissions can be set differently on your system.

Actually, it is a good idea to build in a permission scan and adjust the results accordingly.

I did change the TOOLSVERSION from 6.2 to 6.1. Then I ran the script. I knew bshells were running so I just changed the BSHELL assignment to BSHELL="bshell". Worked just fine after that.

On the licd6.1 - oops. Did not look at this real close today. Anyway - I have looked for license daemons on both of our systems and do not see them. I did a grep on bsp,root, and lic. Did not find anything close to a licd6.1 running. As a matter of fact the only thing I see running with 6.1 is ipc_boot6.1 - one for each user.

Thanks

Mark

No license daemon? shhhh....Baan's CEO reads this board these days ;)

ipc_boot6.1 must be the logon script you guys use to kick off the bshell. Does the bshell not use the 6.1 extension either? That would explain the first part not working.

I guess I'm a little out of my league here, not being very familiar with Baan versions between triton 2.0 and Baan Vb. There must be a license daemon out there somewhere on your network.

The script was built for a server running in strict host mode (mine). I never considered daemons running on different machines.

I can't think of a way to test daemons on a remote box off the top of my head. Suggestions are welcome.

Originally posted by mark_h
I did change the TOOLSVERSION from 6.2 to 6.1. Then I ran the script. I knew bshells were running so I just changed the BSHELL assignment to BSHELL="bshell". Worked just fine after that.

On the licd6.1 - oops. Did not look at this real close today. Anyway - I have looked for license daemons on both of our systems and do not see them. I did a grep on bsp,root, and lic. Did not find anything close to a licd6.1 running. As a matter of fact the only thing I see running with 6.1 is ipc_boot6.1 - one for each user.

Thanks

Mark

Since you mentioned it - I do believe that we are running a separate license server. I know for most of our apps there is a application server, database server and a license server. And as far as I know all apps use the same license server. I do not have logon access to any of these puppies, so I can not check them. I wish more people at my company would use this board. Sigh.

Anyway I still appreciate the post.


Mark

Originally posted by Francesco
What can I say? I'm a Solaris kinda guy ;)

Thanks for the response, Pat.

Do you have any suggestions for a df alternative (or can you give me some different results)?

To the best of my knowledge, == is part of the '93 Korn shell, but I have been wrong before (...I remember it clearly, it was a cold October day in the late 70's...).

How would you substitute that line to make it run on your flavor?
I will be working on Solaris more as well in the future so it's time for me to start picking up some SUN books :)

As to df: the Solaris' 'df -kt' matches output of HP-UX's 'bdf'. So a simple check at the start of the script could set the correct 'df' command based on the running OS (uname -a)

As to the double bars: the KSH incarnation we run has no double bars so I am not sure as to which standard it adheres to (I just double-checked the man page). But then I checked O'Reilly's UNIX in a Nutshell for the KSH syntax and bingo you're right. It should support the C-style '=='. So I guess the anomaly is on the HP-UX side :) On HP-UX, it should be a single bar '='.

I will be writing shell scripts for cross UNIX platforms soon. It surely is going be fun to make then work on all!

Originally posted by Francesco
ipc_boot6.1 must be the logon script you guys use to kick off the bshell. Does the bshell not use the 6.1 extension either? That would explain the first part not working.
...
I can't think of a way to test daemons on a remote box off the top of my head. Suggestions are welcome.


The ipc_boot6.1 it's the first binary that is called when a BW -> rexecd connection is made, this one reads the data from ipc_info and then starts the processes accordingly...

To check for other machines daemons, you could pick up the servers from the lib/licence6.1 file and then do remsh's/rexec's to the other machine(s).

Originally posted by victor_cleto


The ipc_boot6.1 it's the first binary that is called when a BW -> rexecd connection is made, this one reads the data from ipc_info and then starts the processes accordingly...

yea..umm..I meant to say that ;)

To check for other machines daemons, you could pick up the servers from the lib/licence6.1 file and then do remsh's/rexec's to the other machine(s).

Excellent!! Easier said than done, but challenges are only successions for opportunists (or something like that). I'll get on it right away.

Build a script local_check.ksh that checks locally what you need and outputs to a file /tmp/check.<server_name>.

Then build a global_check.ksh one that calls the local_check.ksh [local info gathered], gets all the servers from the license6.x file and then does a rcp local_check.ksh to each server /tmp and then runs it there [remote run], then a rcp to get the output [other servers check].

Just join all the outputs /tmp/check.<server_name> into one and that's it, full servers information!

I found this page that talks about portable scripts in the korn shell.
It mentions discrepancies between the '88 and '93 version as well as differences in operating systems and ksh flavors.
It even touches the = vs == issue. ;)

http://www.raycosoft.com/rayco/support/porting.html#korn

worth looking at.

Thanks for posting that link Francesco! Some really interesting notes indeed. I was a bit surprised myself by the comments on the echo command. Ah well, back to square 1 :)

I incorporated all you guys' suggestions.
With a little more insight in ksh portability (good luck to you, Pat. lol), I feel a lot better about this version.

The rexec option from Victor was nice, but then I found out that our system administrator has removed the rexec command for security reasons (he better leave the server alone), or at least...I couldn't find it.

Then I DUHd myself into using licmon's standard functionality and let it do the work for me.

Anyway...I uploaded the new and improved version. I got a ton of enhancement ideas and a lot of positive feedback, so this won't be the last.

Originally posted by Francesco
Recently I was asked to make some relevant system information available to other individuals (1st level support, management) in our company.
Rather than installing X servers across the board and use our BMC monitoring toolset, I wrote this little script that gives out some basic information (daemon status, disk usage, number of users and licenses, etc.).

The script outputs in HTML format, so it can easily be posted on the (intra)net. As a frame in a fully dressed up main page, it actually looks pretty nice.





You should probably also look at the Baan support-eye product. Part of this does a similar task and is free from Baan. (At least this part of it is)

Hi Francesco,

I got a chance to execute your shell script today.

As I am working with HP Unix, I ran into few issues with the == syntax's which I fixed.

I got some unable to find files error messages on the header and adm_mesg,

debugging with set -vx commands, I found that there is some problem with the exec commands -

exec 1>adm_msg

I commented it and redirected the command outputs to the file.

print "STATISTICS AND INFORMATION<p>" >> adm_msg

Another issue I always found a problem with the unix term and the baan ksh is with the cut command -

if I run this shell script at the unix term it hangs up -

grep -v Filesystem
+ cut -f2 -d

at that statement.

and it executes successfully with the baan ksh option.

Any more ideas ?

Nick,
I have never found any use in the (free) version of Luminux or Support-Eye.

My tool that currently runs under the working title 'Baan Administration System Thermometer, Analyst and Ratio Detector', is designed to display the vital signs of a Baan system in the blink of an eye and as such does a pretty good job (the latest version, coming soon, actually exeeds my own expectations and I find myself using it daily)

However, it is funny that you bring it up because I am using an old Luminux version as an httpd server for it, which saves me the trouble of ftp-ing the output to a webserver and allows me to operate within our paranoid corporate security restrictions. (maybe a good tip)

NPRao,
I believe I solved the portability problems with HP in the latest version (which replaced the old version in my original post).

If there is an issue with exec 1>file, than maybe that is related to your ksh version (rather than Unix), although I have never heard of it being a problem. The statement is only there to satisfy my personal lazyness so I can get by without specifying >> after every print. That works well as a workaround though.

I have seen the hanging cuts on Solaris as well, and it usually seems to be a matter of file permissions.

I am currently running version 3.x, with a lot of new goodies, email notifications, etc. I will post it as soon as I have the time to strip some company specific lines out.

As for future enhancements, I am working on including IO specs, memory and CPU usage but this will most likely result in a Solaris only version. (although it shouldn't be too hard to update it to different flavors).


Thanks for the feedback

Here is the updated version (3.2 but who's counting?) of the script.

As always, portability issues will probably bubble up for everybody not using Solaris but (un?)fortunately that is all I have to work on.

Added features include:
- monitoring multiple servers
- indication of hung messages, processes and licenses
- critical TCP error detection
- print queue monitoring
- improved email notification

To install, untar the file admin_info.zip in your preferred directory and follow the instructions in the readme.

enjoy.

ps
I had to rename the extention to .zip because .tar is not a valid extention for uploads to this board.
May I suggest that the good moderators add .tar and .Z to the list?

There is a small error in the script, namely when dumping the locks (ttadv998). A few portingsets ago, Baan suddenly decided to add two header lines, in the format:

2003-09-04 16:26:12.826
#$!pre-dump!$#00017cv
Thus, the total count of locks is wrong by two!

Fixing it is easy, adding a couple of commands between the following lines:
bdbpre${TOOLSVERSION} -t'|' -o ${HOME}/tmp -Nttadv998 -C000 2>/dev/null
integer TOTAL_LOCKS=$(cat ${HOME}/tmp/tttadv998000.S | wc -l)Namely:
mv ${HOME}/tmp/tttadv998000.S ${HOME}/tmp/tmp.$$
egrep -v "^200|pre-dump" ${HOME}/tmp/tmp.$$ > ${HOME}/tmp/tttadv998000.S
rm ${HOME}/tmp/tmp.$$

In getting the size of $BSE ; $BSE_TMP we get the size of the disk and not of the directory.

A better idea is using the 'du' command, you get the real size of the directory.

Syntax HP-UX du -kd $dir
Syntax AIX du -kd $dir
Syntax Linux du -ks $dir