Posted on 03-26-2012 07:10 PM
Is there a file or folder we can target to accurately identify when a Mac was imaged? If so we can create an Extension Attribute to display that date. Hoping for some ideas from the list gurus. :)
Don
Posted on 03-26-2012 11:08 PM
This solution was given to me by David Whiteley and all thanks go to him for his solution.
the_date=`date "+%Y-%m-%d %H:%M:%S"`
/usr/bin/defaults write /Library/Preferences/com.mycompany.config ImageBuildDate "$the_date"
#!/bin/sh
the_date=`defaults read /Library/Preferences/com.mycompany.config ImageBuildDate`
if [ $? -eq 0 ]; then
echo "<result>$the_date</result>"
else
echo "<result>Not Available</result>"
fi
Posted on 03-28-2012 10:21 AM
We do something similar but we create it using a different method.
The first thing we do is create a /usr/local/casper directory. We put small text files in here that provide information about a machine. Among these are deployment date, originally deployed operating system version, and date of OS upgrade.
As part of the imaging or upgrade, we just put in a simple script that does something like this (using date of upgrade as the example):
#!/bin/bash
date > /usr/local/casper/upgradeDate
Then we have an extension attribute that reads the date from that file.
#!/bin/bash
dateCheck=/usr/local/casper/upgradeDate
if [ -e $dateCheck ]; then
echo "<result>cat $dateCheck | awk '{ print $2, $3, $6 }'
</result>"
else
echo "<result>Not available</result>"
fi
This is very similar to the solution above but I just thought I'd throw it out there as another alternative. We've found that creating the /usr/local/casper directory provides a lot of flexibility in how we capture information about a machine.
Posted on 03-28-2012 03:55 PM
@Kumarasinghe and @bbass Thanks for the ideas. Most of the Macs are not going to be "refreshed" for 1/2/3 years, so what we are trying to do is get date/time from an existing file that we are sure will show the imaging date/time.
Don
Posted on 03-28-2012 05:53 PM
So this is a bit of a hard one, as to my knowledge asr does not store this data in the file system itself, and if you used a OSInstall.mpkg the /var/log/install.log might be rotated by the time the script runs. So I think you would have to do this in directly. My first impulse was to look at the /System directory, but then it occurred to me that the date there comes from the image not the first boot. So the best I could come up with would be the date the key for your system keychain was generated as this should happen at first boot most days.
Its a bit of a shot in the dark but I would be curious if would be accurate. Technically this would be first boot rather then reimage but i think thats mostly the same idea if I understand your question.
#!/bin/bash
declare -x perl="/usr/bin/perl"
declare -x date="/bin/date"
declare -xi FIRST_BOOT_EPOCH="$($perl -e 'print ((stat($ARGV[0]))[9]);' /var/db/SystemKey)"
declare -x FIRST_BOOT_GUESS="$($date -r $FIRST_BOOT_EPOCH "+%Y-%m-%d %H:%M:%S")"
printf "<result>%s</result>
" "$FIRST_BOOT_GUESS"
https://gist.github.com/2231987
I happen to be reimageing and this was accurate on a machine in front of me.
Posted on 03-28-2012 10:01 PM
So it also occurred to me that as long as you use casper imaging could maybe track this by the original install date of the jamf binary. As it should not be included in your image and would in fact be installed at time of imaging. The syntax of the awk has an exit to only take the first install rather then subsequent updates.
#!/bin/bash
declare -x awk="/usr/bin/awk"
declare -x date="/bin/date"
declare -x pkgutil="/usr/sbin/pkgutil"
declare -xi MANAGE_EPOCH="$($pkgutil --file-info /usr/sbin/jamf |
$awk '/install-time/{print $NF;exit}')"
declare -x FIRST_BOOT_GUESS="$($date -r $MANAGE_EPOCH "+%Y-%m-%d %H:%M:%S")"
printf "<result>%s</result>
" "$FIRST_BOOT_GUESS"
https://gist.github.com/2233513
I think this is much less likely to have errors then the prior posted solution but you could use both.
Should note this is 10.6+ compatible
Posted on 03-31-2012 01:25 PM
Hey Don,
Were you looking for something a bit more specific or perhaps robust than the regular imaging logs that the JSS already has built in? Though, that would increase the size of your database if you reimged a lot, and of course if you flushed them over time you would lose the records.
Thanks,
Tom