scheduling – St. Ignatius College Prep Tech Blog

Getting osTicket to schedule ticket creation from emails

If you go to Admin Panel > Emails > Settings > Incoming Emails, right now (as of release 1.10.4—the latest stable release as of this writing), you'll see something called Fetch on auto-cron, which isn't super useful, because it will fetch emails only if an agent is logged into osTicket.

There is an external scheduler option. Unfortunately (again, as of 1.10.4), that Using External Task Scheduler link is broken. I believe it's supposed to go to RECURRING TASKS SCHEDULER (CRON JOB).

There, you see on a *nix system, you're supposed to put in a cron job of

*/5 * * * * nobody /path/to/php /path/to/api/cron.php

but that didn't work for me on Ubuntu 16.04.5 (Xenial). If I ran the command

sudo /path/to/php /path/to/api/cron.php

manually, it would fetch the emails and create a ticket. And, even when a ticket wasn't automatically created, I could still see in /var/log/syslog the cron job actually having been run.

I even tried changing the user to root instead of nobody (but if you create a cron job using

sudo crontab -e

it runs as root anyway... not really sure what nobody is suppposed to do there.

It didn't work until I substituted in this line instead:

5 * * * * /usr/bin/php /path/to/api/cron.php

Now, again, I don't really know what that nobody was supposed to do. According to the Ubuntu community docs, having the username in there is supposed to run it as that user, but when I had nobody or even root as the specified user, the command would run, but no ticket would be created.

I had to leave out the user altogether. Also, again according to the Ubuntu community docs, you should be able to put an */# in front of the four asterisks to run it every # minutes, but I found the command executed properly if I just put a single number in there.

Any cron job experts out there who can explain this, I'd love to learn more of the nuances of how this all works (or doesn't work)?

Keeping up to date using Munki without bothering users

Munki is a great tool for distributing software and creating little mini App Stores for organizations, so users can do self-service installs of Mac software.

But Munki is also a great tool for keeping software up to date. Some software updates are primarily about adding new features. Many updates, however, include bug fixes or security patches (for example, Adobe Flash needing to be patched recently).

Instead of pestering users with emails "Make sure ya'll install this Flash update" or hoping users heed the pestering of the app itself, Munki can do a lot of updates to applications automatically.

Every now and then, though, you may need to bother your users to install an update. How can you get that good balance of keeping things up to date and not bothering your users too often?

Check for Munki updates at a scheduled time each day

By default, Munki checks in with the server about once every hour or so. If you have desktop computers you know will be on at a certain time (and not in use), you may want to schedule them to run at a specific time once a day when users are logged out.

For example, we have some shared desktop computers that boot up in the early morning every day. So, we have them scheduled to check for updates once every morning well before school begins, so no students should be logged into any of the machines, and Munki is free to install software updates, even ones that require a logout or reboot.

To change the time of the checkins, make a copy of the /Library/LaunchDaemons/com.googlecode.munki.managedsoftwareupdate-check.plist file (your new one can be com.googlecode.munki.managedsoftwareupdate-check.revised.plist):

sudo cp /Library/LaunchDaemons/com.googlecode.munki.managedsoftwareupdate-check.plist /Library/LaunchDaemons/com.googlecode.munki.managedsoftwareupdate-check.revised.plist

and then edit it:

sudo nano /Library/LaunchDaemons/com.googlecode.munki.managedsoftwareupdate-check.revised.plist

and modify the --delayrandom and StartCalendarInterval so it will run once a day at a certain time instead of every ten minutes delayed up to some random time of roughly an hour.

Here's an example of running once a day around 6:10-6:30 AM:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.googlecode.munki.managedsoftwareupdate-check.revised</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/munki/supervisor</string>
<string>--delayrandom</string>
<string>900</string>
<string>--timeout</string>
<string>43200</string>
<string>--</string>
<string>/usr/local/munki/managedsoftwareupdate</string>
<string>--auto</string>
</array>
<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>
<integer>6</integer>
<key>Minute</key>
<integer>10</integer>
</dict>
</dict>
</plist>

On the Apple website, you can find more details on the StartCalendarInterval parameters.

Then you want to make it so the original .plist doesn't run:

sudo launchctl unload -w /Library/LaunchDaemons/com.googlecode.munki.managedsoftwareupdate-check.plist

Increase the interval between user notifications

You can see in the Munki documentation about preferences that there is something called SuppressUserNotification, which defaults to false. You can change that to true instead, but I prefer to keep it as is and use the DaysBetweenNotifications parameter in /Library/Preferences/ManagedInstalls to notify users less frequently (say, once every two weeks). I've since changed my position on this, and SuppressUserNotification actually seems to be the way to go (at least for me, working in a school environment). More details in Not bothering teachers with Managed Software Center notifications during the school day. That, combined with, on the server, marking most software as unattended_install items (more details under Pkginfo Files).

If a package is marked as an unattended install, Munki will try to update in the background without notifying the user. To prevent data loss, you may want to make certain applications have a blocking application or an installs array in the pkgsinfo .plist file to make sure the app doesn't die while the user is using it. The major plugins (Java and Flash) seem to be fine to update even while the user is using them, but be sure to test before you mark anything as an unattended install.

Schedule the suppression of login window installs

This works for only computers you know will be logged out of fairly often (for example, shared machines bound to Active Directory). You can have a nopkg that runs every Munki run and toggles the SuppressLoginwindowInstall preference flag depending on the time of day. Here's an example.

That way, at the beginning of the day (or end of the day—however you want to schedule it), you can disable the suppression of login window installs, have those installs happen, and then background unattended installs can happen throughout the day without bothering users or covering up the login screen with a Managed Software Center progress dialogue.

Make updates available less frequently

One way to not bother users with updates is simply not to update very frequently. So if you have Autopkg fetching new versions of applications, you can schedule Autopkg to run only once a week or once every couple of weeks. Or you can schedule Autopkg to run every day and load into the testing catalog but then not mark updates as available in your production catalog until two weeks later.

Creating an installation package for a scheduled Adobe Remote Update Manager

This is kind of a dual-purpose Mac tutorial—how to automate Adobe Remote Update Manager and how to create an installation package using a point-and-click graphical interface.

Automating Adobe Remote Update Manager

You can find the Adobe Remote Update Manager on Adobe's Creative Suite Enterprise Deployment page. Just scroll down a bit until you find it.

When you launch up what appears to be an installer, it's not an installer at all. It's just a folder with a bunch of files in it.

For our purposes here, the only file that matters is RemoteUpdateManager. That is the actual executable binary that initiates the updates. You don't really need to install the RUM man(ual) page. If you want to find the update options (including how to use a proxy instead of getting updates directly from Adobe), you can find those on Adobe's website.

Remember where the RemoteUpdateManager file is. We'll need that file later.

Then create a text file called local.rum.plist and put in the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>local.rum.plist</string>
<key>ProgramArguments</key>
<array>
<string>/Library/Scripts/RemoteUpdateManager</string>
</array>
<key>StartCalendarInterval</key>
<dict>

<key>Hour</key>
<integer>18</integer>
<key>Minute</key>
<integer>15</integer>

</dict>
</dict>
</plist>

You'll see that day, month, and weekday are commented out. You can uncomment those and pick a particular recurrence. Right now it's also set to run every day at 18:15 (or 6:15pm), but you can change those values as well.

The text file you just created is the launch daemon that will run the Adobe Remote Update Manager (RUM) once a day at 18:15 (or with whatever frequency you set up).

Creating the distributable package

If there are multiple machines you want to set this up for, you don't want to be manually copying files to two different locations on each computer. We're going to set it up so you can install a .pkg file on each computer, or distribute the .pkg file to each computer using something like Munki.

Apple provides its own official documentation on how to build a .pkg file. If you can use those instructions, good on you.

I found it much easier to use a program called Packages to do it the point-and-click way.

When you go to the Packages website, click the Download link.

Once you open the download, double-click Install Packages.pkg.

Click Continue.

After you read the agreement, click Continue again.

Click Agree.

Click Install.

Authenticate and then click Install Software.

Click Close.

Now that it's installed, go ahead and launch up the Packages program.

For this situation (Adobe RUM), we're just going to select Raw Package and then click Next.

Name your project accordingly.

By default, the project will be a subdirectory of your /Users/username folder, so you may want to pick a different directory. If you're fine with the default, just go with it.

In Settings you can change the Identifier to represent your actual company/school/organization instead.

Click on Payload and then select LaunchDaemons (under Library) and the plus sign below it to add to that folder (sorry—I accidentally cropped the plus sign out of this screenshot).

Then go find the RemoteUpdateManager binary you downloaded from Adobe earlier.

Click Add.

The default permissions should be fine here (644 or -rw-r--r--).

Click on Scripts (under /Library) and the plus sign below.

Then select your local.rum.plist file you created earlier.

Click Add.

These permissions should be fine. It just means any user will be able to run RemoteUpdateManager, which is fine. Only the script will probably run it, but there's no harm in the users being able to invoke it manually, too, if they want.

Go ahead and save the project.

Then click Build and select Build.

The project should build successfully (and fairly quickly).

Then you'll see your installer file in the directory you should earlier, under the subdirectory build. If you're using Munki to distribute, then you can do a munkiimport directly on this .pkg file.