!/bin/sh

@Kevin I just double checked mine, and they seem to be working fine. JSS is at 9.82 and our CP install is at 5.01:

#!/bin/sh

# Modified 1/24/13

# Third-Part Product page for CrashPlan PROe - https://jamfnation.jamfsoftware.com/viewProduct.html?id=217



CP_ServerAddress="https://cppe.mydomain.com:4285"

CP_AdminUsername="myadminuser"

CP_AdminPassword="myadminpass"



if [ "$CP_ServerAddress" == "" ] || [ "$CP_AdminUsername" == "" ] || [ "$CP_AdminPassword" == "" ];then

        echo "<result>Please ensure all variables are set in the extension attribute script.</result>"

elif [ -f /Library/Application Support/CrashPlan/.identity ];then

        SERVER=`echo $CP_ServerAddress | sed 's|/$||'`

        GUID=`cat /Library/Application Support/CrashPlan/.identity | sed -n 's/guid=//p'`



        DATA=`curl -q -u "$CP_AdminUsername:$CP_AdminPassword" -k "$SERVER/api/Computer?guid=$GUID&incBackupUsage=1" | sed -n 's/.*lastBackup":"([^"]*).*/1/p'`        



        FORMATTED=`date -j -f "%Y-%m-%dT%H:%M:%S" "$DATA" "+%Y-%m-%d %H:%M:%S"`

        echo "<result>$FORMATTED</result>"

else

        echo "<result>Not installed</result>"

fi

@Kevin This part of the script you posted looks wrong to me:

result=/bin/date -j -f "%Y-%m-%dT%H:%M:%S" "$value"

Looks like you have an extra "T" between %d and %H. Its likely skipping the %d for the day value when doing the time conversion since its seeing %dT instead of just %d

Edit: Actually I see now that @stevewood's script also has this? What kind of time format is that? I've never seen %dT before. Looking at the man page and some other documentation on date and I'm not seeing anything related to that.

Edit 2: OK, just realized that's probably a literal "T" as it comes down from the curl command. Never mind. It must be something else its getting tripped up on, but since you're seeing a date conversion error, I wonder if its in fact getting confused because of that.

@Kevin I notice you have a different link to @stevewood

If I try Steve's link it works, if I try yours I get an empty page. An empty page will be the wrong format, e.g.

DATA=""; date -j -f "%Y-%m-%dT%H:%M:%S" "$DATA" "+%Y-%m-%d %H:%M:%S"

Failed conversion of ``'' using format ``%Y-%m-%dT%H:%M:%S''

date: illegal time format

OK… I tried Steve's and it failed with the same error.

(Thank you Steve for responding!)

I critically looked at it to see where we were different–there had to be something!

Here's Steve's:
CP_ServerAddress="https://cppe.mydomain.com:4285"
CP_AdminUsername="myadminuser"
CP_AdminPassword="myadminpass"

I had used the fields straight from JAMFs template:
CP_ServerAddress="EditFromTemplate_CrashPlan_Server_Name"
CP_ServerPort="4285"
CP_AdminUsername="myadminuserv"
CP_AdminPassword="myadminpass"

I took out the…
CP_ServerPort="4285"
…line and added the full server address with port.

The "illegal time format" error went away!

I meant this part:

Yours:

/rest/computerUsage?sourceGuid="$GUID"

Steve's:

/api/Computer?guid=$GUID&incBackupUsage=1

Possibly worth you confirming in case someone else runs into this!

If you, like my org, aren't too comfortable storing admin passwords in plaintext xml, I wrote a different method of checking backup dates. Needs some better error checking, but here's what I've got:

#!/bin/sh



cpLog="/Library/Logs/CrashPlan/history.log.0"



if [ -f "$cpLog" ]; then

    cpDate=$(/usr/bin/grep -e "Completed backup" $cpLog | /usr/bin/tail -n1 | /usr/bin/awk '{ print $2,$3 }')

    cpResult=$(/bin/date -j -f "%m/%d/%y %l:%M%p" "$cpDate" "+%Y-%m-%d %k:%M:%S")

else

    cpResult="1901-01-01 00:00:01"

fi



echo "<result>${cpResult}</result>"

Basically it'll grep the last match of the "Completed backup" string in the most current CrashPlan history log, grab the timestamp and format it to fit the EA's date formatting. Failures result in a default 1901-01-01 00:0:01 time to fit with the date search format, otherwise a string would be excluded from smart group criteria. Essentially 1901 date = "Not installed"

Again, probably need better + more error checking. I haven't tested this in production yet.