U of S Single Sign-on SSO Monitoring Script
Fri, 2008-09-05 17:26 — ToddTrann
Attached is the perl script that we use to monitor SSO connections across all of our Luminis servers. We run it from a completely separate server, just in case there are problems that could not be spotted by running it on the same box as Luminis. It is called via cron every 12 minutes.
The script used to be used with the old style "Banner Authenticator" method of single sign-on, and it is now working for us using the new "MidTier" method.
I think it should be commented sufficiently well so that you can make this work in your environment, but feel free to ask questions.
Todd
- ToddTrann's blog
- Login or register to post comments
Hack Your Knowledge
Recent blog posts
- Luminis IV GCF Single Sign On with OSX=Failure PC=Working
- Cisco 4710 - Load Balancer
- First CPIP - ERROR
- Luminis Developer Job Available w/ Stable Organization
- Luminus Developer Job
- SSO to SSB mixed content error in IE
- Avoid email sending when add or delete user from group
- Luminis components
- Luminis 4 & Groupwise 7
- Luminis Developer Needed for Position w/ Stable Organization
Developer Links
Poll
What version of Lumins / OS are you running in production?
Luminis 4.x - Linux
21%
Luminis 4.x - Windows
8%
Luminis 4.x - Solaris
31%
Luminis 3.x - Windows
17%
Luminis 3.x - Solaris
19%
Luminis 3.x - Linux (if so - we need to talk) <G>
4%
We gave up on Luminis - I just like this site !
0%
Total votes: 52
- Login or register to post comments
- Older polls
Syndicate
Comments
Nice
We have a service that monitors http connectivity but I was wondering how to check the SSO to banner as we sometimes have glitches with the SCT authenticator. The process stays up but SSO is dead. This will definitely help. I reconfigured the script for one server frontend and to use the sct banner authenticator method. I am not sure why but the script will always send the recovery email even though the SSO was never down previously. I tried changing to 1 failure from 3 failures in the script (I assumed it was from your front ends) but to no avail. What should I look for to fix this?
Thanks
Tony
suggestions
The 3 failures versus 1 failure isn't for the number of front ends.... its for how many times in a row there must be a failure before it will be reported. We chose 3 so that transient problems wouldn't set off false alarms. You can leave it at 1,2,3,4..... whatever you choose so that you balance the responsiveness that you need against not getting false alarms.
Did you check to make sure that the control files are writable by the script? Is there anything in them? Also the script will attempt to save cookies in a file named "cj" in the current directory. If the script cannot write that file, then you'll also have problems. You can change where the cookies are stored if you need to.
/usr/bin/curl -s -k -c cj
becomes
/usr/bin/curl -s -k -c /path/to/cookies.txt
You can remove the "unlink" commands as well to see the cookie jar contents after the script is run.
And finally, of course you can set debug=1 and then some temporary files will be saved along the way for you to view.
Todd
Todd