Log files and monitors.

In episode III I’m going to be talking about some ways to use monitors and log files to deliver some non standard types of user information.

If you’ve been through the examples, or used Splash buddy, you will be familiar with this kind of monitor.

a screen capture of a monitor

And there is nothing wrong with this of course but it’s simply a list of apps being installed and doesn’t show any other type of progress.

So lets build on this…

Playing with the logs.

When a monitor is defined you can specify it to monitor a few different things, one of them is a type called Jamf which is designed to monitor the Jamf log file for installs. This is the only type I will be talking about here as it’s the only one I have played with. I’m sure the Airwatch log can be manipulated in a similar manner.

There are a couple of things to consider:

  1. You don’t actually have to have the log items come from Jamf itself.
  2. You don’t actually have to use the Jamf log at all.

What is Octory looking for?

The important thing to remember is that Octory is looking for a specifically formatted entry in a log file. So if the monitor had been set to look for teamviewer in the Name setting using a script line like:

echo "Octory:Installing teamviewer-v2.10.4.pkg..." >> $LOG

would turn the monitor 🟡, the keyword is installing.


echo "Octory:Successfully installed teamviewer-v2.10.4.pkg..." >> $LOG

would tun it 🟢, the keyword is installed.

An optional key for the monitors dictionary is JamfLogPath. Using this the monitored log file can be set to any file desired just for the job in hand, which can be created and deleted just for this run so not cluttering up the real Jamf log.

if you repeatedly test Octory windows without clearing the log the indicators can give false displays as it reads the log at startup, so if the monitored line is already written it will change state immediately.

A different kind of monitor.

Consider this example:

Screenshot 2020-05-14 at 17.14.45
Stage based monitor

In this example the build is split into broad stages. The monitor for each stage would be setup to use a word like stage1 or security_apps.

The controlling script would then send a log entry when it started and completed each block of tasks using the method shown previously.

echo "Octory:Installing security_apps-v2.10.4.pkg..." >> $LOG


Mix and Match.

If you do use the actual Jamf log it is possible to mix and match your methods. In the example above you could use scripted log entries for the stages but monitor the actual office install for that one.

What’s next?

Coming next will be some other cool uses of monitors to set variables and dynamically change what is displayed in context with progress… I bet you can’t wait!



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s