Dejal Home

Simon icon Simon
Flexible server monitoring

Introducing Simon 5!

Simon version 5 is now available. It is a massive update, introducing a much-requested feature: syncing the Simon data between multiple Macs, plus a Simon Status service, a Link Checker filter, improved Find filter, iMessage and Speak Error notifiers, a new app icon, and much more.

Important: please note that Simon 5 requires a minimum of macOS 10.12 (Sierra), and is a paid upgrade from Simon 4. Purchasers since September 1, 2020 automatically get a version 5 license (that also works in previous versions).

Read the Simon What's New page for details.

Best method of testing AFP, SMB and LDAP

Wed, 2007-06-06 03:55 — billc

We are new to Simon and are establishing ways of using it to our advantage.

We manage an Education network of around 20 High School servers and around 150 Primary School Mac servers. These servers all provide AFP/ODM for Mac and a Primary Domain Controller for PCs.

The most common issues we have to deal with are failures of AFP, SMB, and LDAP. We want to be able to detect these as quickly as possible.

As it stands Simon doesn't appear to feature built-in tests for AFP and LDAP. Additionally the built-in SMB test utilises the Samba client which, as far as I was last informed by Apple, isn't the code used by the Finder (the relevance of this will become apparent). I appreciate that Windows uses neither the Samba SMB client nor the Finder's method.

We are attempting to construct tests for these. Rather than use a shell script, which may bypass code that the Finder uses, we chose to use AppleScript for the AFP and SMB tests. Keeping it simple and ensuring we use the same frameworks the system itself would be using here's what we're using:

tell application "Finder"
mount volume "afp://{Username}:{Password}@{ServerIP}/{TestShare}"
delay 5
eject disk "{TestShare}"
end tell

Interchange "afp://" and "smb://" in the above for the SMB test.

We've setup dedicated test share points and a Simon test account on each server. Each test share has a unique name to avoid the eject command failing.

This works for the most part, but we're seeing almost random failures in this method. Perhaps timing clashes. Finder issues. Sometimes Simon and/or the Finder appears to lock-up after it has been running for several hours. If an error occurs then Simon can't continue and begins to think that failures are occuring "all over the shop". We are having to "babysit" Simon on a daily basis.

Is it a case of missing error detection and correction in our script? Does anyone have any suggestions for how to better handle this?

For the LDAP test we're trying a simple query with the ldapsearch command combined with the smart change detection. It seems to work ok for the moment. Should we perhaps be using dscl for this?

Can I suggest building in good AFP and LDAP tests in the future? Have you considered it already but found it difficult to find the best method like us? Perhaps Simon could tie into the AppleShareClient framework?

We have not yet begun trying to support the 150 primary servers yet. I am beginning to think that our AFP/SMB method is not going to work at all for such a large number of tests. How can we do these tests reliably with 170 systems???

Thanks in advance.

‹ Suggestions for next version Batch edit on Tests (and possible other items) ›
Wed, 2007-06-06 11:53 — Daniel Ellis

AFP Support

What good timing for your suggestion! I'm in the beginnng stages of adding AFP test support for Simon. Hopefully we can get it realeased as part of an update in a few weeks.

In order to give the best benefit, I am interested in getting thoughts from users as to what features they'd like to see from an AFP bsed test. It sounds like you're a little familiar with the AFP client framework. Any feedback about what you'd like to see would be much appreciated. We want to see you get the most out of Simon after all.

So, if anybody has any ideas, don't be shy.

Daniel

Fri, 2007-06-08 04:49 — billc

How to tell Simon a failure occurred

I have begun to try and refine the AppleScript we're currently using. I'm completely amateur at this. So any help gratefully received. Here is where I'm at now:

tell application "Finder"

if exists disk "{TestShare}" then
try
eject disk "{TestShare}"
on error
display alert "The volume {TestShare} failed to unmount" as informational buttons "OK" default button "OK"
end try
else

try
mount volume "afp://{Username}:{Password}@{ServerIP}/{TestShare}"

on error
display alert "The volume {TestShare} failed to mount" as informational buttons "OK" default button "OK"

end try

delay 5

if exists disk "{TestShare}" then
try
eject disk "{TestShare}"
on error
display alert "The volume {TestShare} failed to unmount" as informational buttons "OK" default button "OK"
end try
end if

end if

end tell

That's a little more graceful than the original. We only have the dialog appearing in the above because I don't know what else to do with an error.

We still need to figure out how to tell Simon when a failure occurs. We don't want the Finder informing the user. We want to inform Simon. I'm sure this is just a matter of knowing AppleScript. How do we get the script to return a result that will then feedback to Simon and trigger a fail without displaying a dialog in the Finder.

This is a significant issue because if one server fails for a random reason, it holds up the Finder and all subsequent tests begin to fail. This results in our Simon notification forum becoming flooded with failures - when there aren't any out there in the real world. Example failures are authentication failures. This seems to occur for some unknown reason. That's another issue. This triggers a dialog which insists on a human response. Meanwhile Simon can't use the mount command again it begins to fail everybody else. I have also contacted Apple regarding the mount command perhaps ungracefully handling failing mounts. It actually causes a lock-up of the Finder.

Thanks.

Fri, 2007-06-08 05:10 — billc

Could be working actually

I have just completed some tests of the above. I hope I'm not jumping the gun. It appears that the errors are being gracefully handled by Simon. After a 2 minute timeout Simon fails the test and no disturbing errors hold everybody else up.

My only concern now is the timings clashes. It does appear that when the mount fails there is a two minute timeout which may prevent subsequent mounts during that two minute period.

I will leave this to soak and we'll see what happens next.

Fri, 2007-06-08 12:30 — David Sinclair
David Sinclair's picture

Re: How to tell Simon a failure occurred

That looks pretty good. The piece you're missing is the return statement: instead of displaying an alert, just call return 10 (or any number you like), and add a result line in the Script service for that result number. On success, call return 0, and have that as the Success result in the Script service.