Posted on 06-15-2015 10:30 AM
So with some help I've got a script that checks the date and if the date is before 2015 it then sets the date to 2015 then turns off wireless then turns on wireless and then sets the time back to network time.
I'm now trying to get this check to happen at startup via a launch daemon and I cannot seem to get it working Getting an Error 13. Im storing the script in the /Library/Application Support/JAMF folder.
Would also be great to have this be triggered by a wake from sleep as well.
Is it possible that I have the permissions wrong? root is the owner of both files and both are set to 644.
The reason for this is our wireless controller issues a certificate that was created in 2012 and when a mac runs totally out of power it resets to a date before 2012 and then cannot rejoin the network until the date gets back within the certificate period (2012-2025). This script fixes this issue but I just can't seem to get the script called correctly.
Any help will be greatly appreciated!
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>org.pps.setdateandtime</string>
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<false/>
<key>ProgramArguments</key>
<array>
<string>/Library/Application Support/JAMF/setdateandtime.sh</string>
</array>
</dict>
</plist>
This is the script:
#!/bin/bash
macdate=$(date +"%Y%m%d")
comparison="20150101"
if [ $comparison -ge $macdate ]; then
date 0102010115
networksetup -setairportpower en1 off
networksetup -setairportpower en1 on
sleep 15
ntpdate -u time.apple.com
fi
Solved! Go to Solution.
Posted on 06-15-2015 10:46 AM
First, try removing the "" character in the Program Arguments path. I know this seems ridiculous and unintuitive, but believe it or not, launchd jobs don't require spaces in paths to be escaped, at least not with the ProgramArguments key. This has bitten me in the past, which is why I now always use an application like LaunchControl to create my launchd jobs. It takes the guesswork out of this stuff and saves your sanity while trying to get a launchd job to work.
Since I assume you may have created this plist file manually, the second thing to do is check the permissions on the LaunchDaemon and the script. Arguably, the permissions on the LaunchDaemon are more important than the script, but they should be set to:
LaunchDaemon: Owner/Group: root/wheel POSIX: 644 Script: Owner/Group: root/admin POSIX: 755
Check all that (make sure to correct the path in the ProgramArguments) and try it again.
Posted on 06-15-2015 10:34 AM
Try adding "sh" (without the quotes) as the first argument, and the path to the script as the second
Posted on 06-15-2015 10:46 AM
First, try removing the "" character in the Program Arguments path. I know this seems ridiculous and unintuitive, but believe it or not, launchd jobs don't require spaces in paths to be escaped, at least not with the ProgramArguments key. This has bitten me in the past, which is why I now always use an application like LaunchControl to create my launchd jobs. It takes the guesswork out of this stuff and saves your sanity while trying to get a launchd job to work.
Since I assume you may have created this plist file manually, the second thing to do is check the permissions on the LaunchDaemon and the script. Arguably, the permissions on the LaunchDaemon are more important than the script, but they should be set to:
LaunchDaemon: Owner/Group: root/wheel POSIX: 644 Script: Owner/Group: root/admin POSIX: 755
Check all that (make sure to correct the path in the ProgramArguments) and try it again.
Posted on 06-15-2015 10:57 AM
Regarding the sleep trigger, we've used a launchdaemon called sleepwatcher in the past, I believe it's on github. It can trigger scripts when the Mac is woken from sleep. Has been working great for us for the past few years.
Posted on 06-15-2015 11:26 AM
@mm2270 So looked like it was a combo of permissions and the extra designating the space in the Application Support folder causing the issues. This seems to be working properly now as a daemon running at startup.
@davidacland Ill have to check out sleepwatcher. Weird that apple doesn't have a rule in the launchd that looks at wake from sleep. I saw another one based on network connection.
Thanks for all your help...I think I can push this out in the next day or two to solve this issue!
Gabe Shackney
Princeton Public Schools