CasperCheck

You'd install these files the same way you'd install anything:

Build a package that includes these files as the payloads to the right places.

Use your favorite deployment tool to install the pkg.

I'm not currently using it, but from my understanding, you should only need to drag the script and the LaunchDaemon from your Mac that its set up on into a new Composer package (tip: drag them into the Composer sidebar after opening the application). It will copy the files into the Composer source, including their paths. Double check any permissions on them. LaunchDaemons need to be owned by root and group set to "wheel" with 644 POSIX permissions. The script should be similar, but can be 755 for POSIX.
Once all done, create a package installer from Composer for those items. Upload that into your Casper repository.

Then make sure to create the QuickAdd.pkg, zip it and upload to a http sharepoint somewhere that the script can pull down from. Create the manual policy as he outlines in the github page. I believe that should be it, but I only glanced quickly through the process, so I may be missing a step. Read through Rich's instructions on setup to be sure.

Thanks all for the responses, I new it was something simple I was overlooking...I over complicated the task :/ You were all correct, Composer is the way to go. Thanks again. :)

Carlos,

I packaged up the script and plist using Composer. One thing to remember is that you will want to make sure the permissions are:

plist - root:wheel, mode 644
script - root:wheel, mode 755

This worked for me .

Revisiting an old thread with another possible solution.

While getting ready to package up CasperCheck, I decided to not package. I've noticed that sometimes a package install will fail in certain circumstances in our environment...But scripts under the same circumstances never failed.

I had been using payload free packages for most script installs. After seeing the issues in certain circumstances, and remembering that scripts are stored in the database, not on CasperShare, I was able to embed the scripts to be installed inside of scripts.

I write the script that I need, SCRIPT A, then insert it into another, SCRIPT B, that will write the desired SCRIPT A to a file, using mostly 'echo' for the plists and 'cat' for the longer scripts.

echo "plist 
goes 
here" > /Library/LaunchDaemons/com.name.of.plist

or

cat > /Library/Scripts/myscript.sh << "EOF"
#!/bin/bash
# rest of script goes here
EOF

I've been very successful using this method to install CasperCheck. In fact, we are using it for almost all our script installs.
Don't forget to include the proper chown and chmod settings after having the script write out the files.

@kevinfriel I have found that heredoc (cat) method is much better.

You can use it for creation of .py scripts, LaunchAgents, plist files, etc.
heredoc with single quoted EOF to preserve $ variables without variable expansion.

/bin/cat << 'EOF' > /path/to/yourscript.sh

@Kumarasinghe The single quoted EOF solves some of the issues I ran into.
Definitely a cleaner method, thanks!

Hello and help.

I have been messing with this for days to no avail.

I implemented CasperCheck months ago, yet come to find out it only works when a Mac reboots, not at the specified interval. So I could have Macs not checking in that have not been rebooted.

So I researched and came here, and as echoed here, permissions issues.

Went to a brand new imaged test machine, and after setting permissions properly on both caspercheck.sh and com.companyname.caspercheck.plist, I got it to load by running:

launchctl load /Library/LaunchDaemons/com.companyname.caspercheck.plist.

I actually changed this plist to net.companyname.caspercheck.plist,so it is easer to spot in launchctl list

And it works. I specified a new interval, 10 minutes (600) seconds, and every 600 seconds caspercheck.sh runs.
I can see this in Console, /var/log caspercheck.log

The issue is, I have to load the plist with the load command, so I was thinking in Composer, use a post-install script command with the launchctl load /Library/LaunchDaemons/com.companyname.caspercheck.plist.

Haven't even got that far in Composer though.

Once the plist is loaded, it's loaded, Until....

On either reboot or login, the plist won't load. I have to manually load it.

Something is up.

Thx in advance,

john

@johnklimeck,

You mentioned you edited the LaunchDaemon file. Would you please post it somewhere that I can take a look at it?

rtrouton,

Sure thing, here it is:

<?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>net.fngit.caspercheck</string> <key>ProgramArguments</key> <array> <string>sh</string> <string>/Library/Scripts/caspercheck.sh</string> </array> <key>RunAtLoad</key> <true/> <key>StartInterval</key> <integer>600</integer> </dict> </plist>

The same behavior occurs with the com.fngit.caspercheck.plist

I was going to go back to your original files, and test again. See what happens. Thx

The launchdaemon file looks like it's OK and Lingon's not tossing up any flags.

Is the file named net.fngit.caspercheck.plist and is it stored in /Library/LaunchDaemons?

Is the file named net.fngit.caspercheck.plist and is it stored in /Library/LaunchDaemons?

Yes, that is it.

I guess the question is, why is this plist not loading automatically.

I think this could still be a permissions issue?

ls -l total 48 -rw-r--r-- 1 root wheel 462 Aug 26 07:28 com.adobe.fpsaud.plist -rw-r--r-- 1 root wheel 737 Sep 22 13:42 com.jamfsoftware.jamf.daemon.plist -rwxr--r-- 1 root wheel 474 Sep 22 13:42 com.jamfsoftware.startupItem.plist -rw-r--r-- 1 root admin 528 Sep 22 13:42 com.jamfsoftware.task.1.plist lrwxr-xr-x 1 root wheel 103 Sep 22 13:47 com.oracle.java.Helper-Tool.plist -> /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Resources/com.oracle.java.Helper-Tool.plist -rw-r--r--@ 1 root wheel 448 Sep 22 13:54 net.fngit.caspercheck.plist FNG143301:LaunchDaemons foxadmin$ cd /Library/Scripts FNG143301:Scripts foxadmin$ ls -l total 24 drwxr-xr-x 10 root wheel 340 Sep 9 2014 ColorSync drwxr-xr-x 15 root wheel 510 Sep 9 2014 Folder Action Scripts drwxr-xr-x 7 root wheel 238 Aug 13 11:53 Folder Actions drwxr-xr-x 7 root wheel 238 May 10 19:00 Font Book drwxr-xr-x 8 root wheel 272 Jan 22 2015 Printing Scripts drwxr-xr-x 14 root wheel 476 Sep 9 2014 Script Editor Scripts drwxr-xr-x 7 root wheel 238 Sep 9 2014 UI Element Scripts drwxr-xr-x 5 root wheel 170 Aug 13 11:50 VoiceOver -rwxr-xr-x@ 1 root wheel 11954 Sep 22 14:00 caspercheck.sh FNG143301:Scripts foxadmin$

What is the @ on the caspercheck.sh file, attributes or something?

Yes, @ indicates extended attributes. I don't know that that would cause it not to load automatically, but you can try the following to read the extended attribute from the file:

xattr /Library/LaunchDaemons/net.fngit.caspercheck.plist

Then, see if you can get them removed with:

sudo xattr -c /Library/LaunchDaemons/net.fngit.caspercheck.plist

I don't think this is it either, but on a whim, run the following to see if somehow that launchd job is showing up in the overrides file. It would normally throw an error when trying to load it with launchctl load if its there, but check anyway.

sudo defaults read /private/var/db/launchd.db/com.apple.launchd/overrides.plist

See if there's an entry for net.fngit.caspercheck and if it has Disabled = "1"; after it. Again, I don't think that's it, but better to rule it out.

I think I got it. It looks like OS X terminal will not let you see all the services in launchd (launchctl), in order for me to see the specific net.fngit.caspercheck.plist, one has to sudo -s, then launchctl list

I also removed the xattr, that may have helped.

When I do PKG this with Composer, I am going to do this:

enable root user, and log in as root user.

And edit these files, logged in as root. That way there can be no ownership / permission confusion, already logged in as root.

Much obliged

John

Trying to get CasperCheck to run correctly, I can get both the plist and the script itself loaded into the correct places but on execution of the script this appears in the caspercheck.log:

======== Starting CasperCheck ========
Checking for active network connection.
Network connection appears to be live.
Pausing for two minutes to give WiFi and DNS time to come online.
Access to site network verified
Machine can connect to uni-jss.its.utas.edu.au over port 8443. Proceeding.
Downloading Casper agent installer from server.
Downloaded zip file appears to be corrupted. Exiting CasperCheck.
======== CasperCheck Finished ========

and if I run caspercheck.sh locally in terminal I get this output:

Connection to jss.server port 8443 [tcp/pcsync-https] succeeded!
[/tmp/quickadd.zip] End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of /tmp/quickadd.zip or /tmp/quickadd.zip.zip, and cannot find /tmp/quickadd.zip.ZIP, period.

I have tried this on 10.9.5, 10.10.5 and 10.11 computers with the same result.

JSS - RHEL 6.7, JSS 9.81
JDS - OSX 10.10.5, JDS 9.81

Anyone with ideas as to what is going on, I can unzip the archive locally without errors?

@dmw3,

What's up, I feel you. I have a similar issue.

After updating our JSS to 9.81 and then creating a new 9.81 QuickAdd.pkg with Recon 9.81, I thought all I would have to do is copy the new QuickAdd.pkg.zip to our DMZ JSS server, simple, easy. Not.

CasperCheck.sh and the corresponding plist are working. The plist is loading and the caspercheck.sh is running and loading the plist. (This actually was not working properly in the JSS 9.73 a few weeks ago when I posted). I got that working and Macs where reporting in with the "Casper is Up"

I had to do a postinstall script to this pkg and have launchctl force unload the old plist and force reload the new plist (with the new 90000 seconds, 25 hour check interval), as well as have the correct permission set via Compser. All was working until 9.81 and the new 9.81 QuickAdd

I can monitor in caspercheck.log and I see the new QuickAdd downloads:

I get the, "downloaded zip file appears to be corrupted. Exiting CasperCheck", message or I was getting the, Installed, but not getting the full log message of "Reinstalling Casper agent to fix problem of Casper not being able to run policies". That is what I want to see.

Must be something with the 9.81 QuickAdd.pkg.zip

I am compressing / zipping the QuickAdd the same way as in OS 10.10x, right-click Compress.

Wonder if others are seeing this, perhaps it is this new 9.81 version of Recon and how it makes the QuickAdd.pkg, or 10.11 in it's compress / zip. Something's up in 9.81 and / or OS 10.11 concerning this.

Those are the two changed variables

John

@dmw3 What's the file size of the downloaded QuickAdd on the client computer? It's possible your download is not working properly.

OK, finally got this working.

The fix I had to do was to use https for the web server where the QuickAdd.pkg.zip was placed.

This was because we are using the JDS server as a repository for sharing.

fileURL="https://our.server/QuickAdd.pkg.zip"