Uploading Logs to Jamf Pro with the API
Something I learned early on while doing a large scale deployment is that it is really difficult to get logs off of computers when you either don’t have network access, or you have 10,000 Macs to get logs from. There have been plenty of discussions on Jamf Nation about logging for scripts or gathering logs from users (there has to be a better way than waiting on users to send the logs in).
Somewhere on Jamf Nation I found a method for using the Classic API to upload files to the computer record. This was great because now I could utilize any number of methods for logging data on the Mac and then uploading that to the computer record. This would put the log file close at hand so I could troubleshoot an issue without having to SSH into a machine or ask the user to send it to me.
Once you have figured out how you want to generate logs in your scripts (I’m partial to Dan Snelson’s method here), you’ll want to create a user that has access to upload files to the Jamf Pro Server. If you are a fan of encrypting the credentials you can go grab Jamf’s Encrypted Script Parameters scripts off of GitHub and use that code to scramble the creds. But, if you’re like many, simply creating a use specific user with privileges to do only what that account needs to do (upload files in this case) is sufficient security.
Jamf Pro Setup
So first step is to setup your user. Go into System Settings and then into Jamf Pro User Accounts & Groups on your JPS. Click the New button and choose to create a new Standard Account. Fill in the particulars like Username and Password, and set the Privilege Set to “Custom”:
Now go to the Privileges tab and enable Create, Read, and Update for File Attachments.
Now that we have our user created we can add the necessary API calls to our scripts to upload log files.
Add To Your Scripts
In any script that you wish to log output for, create a logging mechanism that saves to a local file on the system. We will not get into the specifics of which method is better than another. Instead I will show you a down and dirty method for capturing all output to a log file.
Once you have determined where to save the log file, you’ll want to make sure the path is available (unless you are putting this in a standard location like /var/log or even /tmp), and you’ll want to redirect output to the log or echo into the log. The following code will create a log file at /tmp/mylog/ and set the shell to output all commands using the UNIX ‘set’ command.
#!/bin/zsh
mylogpath=/tmp/mylog
mylog=$mylogpath/myawesomlog-$(date +%Y%m%d-%H%M).log
[[ ! -d ${mylogpath} ]]; mkdir -p $mylogpath
set -xv; exec 1> $mylog 2>&1
That last line is the magic. That line enables shell debugging with verbosity and re-directs ‘stdout’ (1) and ‘stderr’ (2) into our log file. Anything that our script does below this part will be output to our log file.
Upload our Log
To upload our log file we need to know the JSS ID of the computer. This can be found in the JPS by looking at the URL of a computer or by looking for the “Jamf Pro Computer ID” on the General tab of the comptuer record. We’re going to use the computer serial number and the API to determine the ID.
We first grab the serial number from System Profiler:
| serial=$(system_profiler SPHardwareDataType | awk '/Serial\ Number\ \(system\)/ {print $NF}'); |
Now we make an API call to get the ID and use ‘xpath’ to sort it all out:
| JSS_ID=$(curl -H "Accept: text/xml" -sfku "${jss_user}:${jss_pass}" "${jss_url}/JSSResource/computers/serialnumber/${serial}/subset/general" | xpath /computer/general/id[1] | awk -F'>|<' '{print $3}') |
update: macOS Big Sur introduces a new version of the ‘xpath’ binary, and with it a new format for the query. Rather than explain it here I’ll point you over to Armin Briegel’s excellent blog post about it here. So now instead of just having the above line, somewhere at the top of your script (or just before the line that uses ‘xpath’), you’ll want to have a function block to use the proper ‘xpath’ command based on macOS version. Follow Armin’s instructions in that post for where to put the block and what the block should look like.
Now that we have our ID we use a ‘curl’ call to the API to upload the log file:
| curl -sku $apiUser:$apiPass $jpsURL/JSSResource/fileuploads/computers/id/$JSS_ID -F name=@${mylog} -X POST |
And just like that, we have a log file attached to the computer record for troubleshooting.
Computer Record
Where is this stored on the computer record? Well, it’s stored down towards the bottom of the tabs, just past the Printers tab on a tab called “Attachments”.
That’s it, that’s all that has to be done to get a log file attached to your computer records. You can use this in any of your shell scripts to upload log files. You could even write a Self Service policy that users could run that would ship log files of your choice up to the computer record.
I hope you get something out of this and are able to see the power of this feature.
| #!/bin/zsh | |
| mylogpath=/tmp/mylog | |
| mylog=$mylogpath/myawesomlog-$(date +%Y%m%d-%H%M).log | |
| [[ ! -d ${mylogpath} ]]; mkdir -p $mylogpath | |
| set -xv; exec 1> $mylog 2>&1 | |
| ... do some stuff ... | |
| # Upload our log using API | |
| jss_user="apifileuploaduser" | |
| jss_pass="MysUPerL33tpAssW0rd" | |
| jss_url="https://jps.mycompany.com" | |
| # get computer serial number to lookup the JSS ID of the computer | |
| serial=$(system_profiler SPHardwareDataType | awk '/Serial\ Number\ \(system\)/ {print $NF}'); | |
| # get ID of computer | |
| JSS_ID=$(curl -H "Accept: text/xml" -sfku "${jss_user}:${jss_pass}" "${jss_url}/JSSResource/computers/serialnumber/${serial}/subset/general" | xpath /computer/general/id[1] | awk -F'>|<' '{print $3}') | |
| # upload the log to the comptuer record | |
| curl -sku $jss_user:$jss_pass $jpsURL/JSSResource/fileuploads/computers/id/$JSS_ID -F name=@${mylog} -X POST |
How To Quickly Open a Policy in Jamf Pro
We have a lot of policies. I mean over 1,000 policies in our Jamf Pro Server. Don’t ask. Part of it is out of necessity, but I’ll bet some of it is just because we were running so fast in 2018 to get systems enrolled and agencies under management, that we didn’t have time to, as Mike Levenick (@levenimc) recently put it, “trim the fat”. That’s what 2019 is all about. But I’m missing the point of this post: how to quickly open a policy. You can imagine how long it takes to load the list of policies when you have over 1,000 of them.
There are a couple of tools you’ll need. First up you’ll want a tool like Text Expander to create snippets or macros. I’m sure there are some free alternatives out there that will expand a text shortcut into something but Text Expander is what I’ve been using for many years, of course I’m using version 5 which is a perpetual license version and not the current subscription model. (Here’s an article about text expansion apps)
The second tool you’ll need is jss_helper from Shea Craig (@shea_craig). This will help us pull a list of the policies in our system, including the ID of the policy.
Now that you have your tools in place, the first thing you want to do is grab the URL of one of your policies. Just open a policy and copy the URL. Now go into Text Expander (or whatever tool you chose) and create a new snippet from the contents of the clipboard. Edit the URL removing everything after the equals (=) sign in the URL. Give your new snippet a shortcut and voila! You now have an easy way to get 90% of the way to quickly opening policies. Your URL snippet should look similar to this:
https://jss.yourcompany.com/policies.html?id=
Now let’s turn our attention to jss_helper. Once you have it installed and configured to talk to your JPS, you’re going to want to pull a list of the policies in your system. Open up Terminal (if it isn’t already) and run jss_helper with the following options:
jss_helper policies > ~/Desktop/policy_list.txt
Obviously you want to name that file whatever you want, but the cool thing is that you now have a list of every policy in your JPS along with its ID. If you open that file up in Excel or a text editor, you’ll see something like this:
ID: 2034 NAME: Installer Adobe Acrobat DC 19 ID: 1214 NAME: Installer Adobe Acrobat DC Reader ID: 2030 NAME: Installer Adobe After Effects CC 2019 ID: 2031 NAME: Installer Adobe Animate CC 2019 ID: 2032 NAME: Installer Adobe Audition CC 2019 ID: 2033 NAME: Installer Adobe Bridge CC 2019 ID: 638 NAME: Installer Adobe Codecs ID: 532 NAME: Installer Adobe Creative Cloud Desktop elevated App ID: 314 NAME: Installer Adobe Creative Cloud Desktop Non elevated App
Now let’s put it together. Open up your web browser and in the address bar type whatever shortcut you created for the policy URL above. Once the URL expands, before pressing enter, type in the ID number of the policy you want to open and then press enter. The policy should open up without having to wait for the list of policies to load or having to search the web interface for the specific policy.
Hopefully this will help speed up your game and help you become quicker and getting stuff done.
Using AWS Lambda To Relay Jamf Pro Webhooks to Slack
I recently got interested in utilizing webhooks in Jamf Pro but had no idea where to start. I went and watched Bryson Tyrrell’s (https://twitter.com/bryson3gps) presentation from JNUC 2017 Webhooks Part Deaux! and then went over to take a peek at Jackalope on the Jamf Marketplace. I read the docs, I tried to figure out how to do this in AWS ElasticBeanstalk, but I just couldn’t get it going. Just too much going on to devote enough time to it. So, I went over to Zapier and signed up for their free account so I could get this going. I got it working, but I quickly got throttled because I decided to enable the “ComputerCheckIn” webhook to make sure it worked. I think we flooded the 100 connection limit within 30 seconds and wound up having thousands of items in Zapier.
Well, that wasn’t going to work, so I changed it to “ComputerAdded” and waited for my month of Zapier to renew so I’d get 100 new “zaps”. That worked, until we went over the 100 limit again and had to wait. There had to be a better way that wasn’t going to cost me a ton of money. So I went Googling and came across an article on how to use AWS Lambda to do what I wanted to do: AWS Lambda For Forwarding Webhook To Slack.
I walked through the steps outlined on the page to setup the function in Lambda and everything worked great until I got to the part where I was making requests out to Slack. Lambda had a problem with the request method. Specifically this line of code:
var post_req = https.request(post_options, function(res) {
So another round of Googling and I came up with the Node.js docs page on HTTPS and I figured out how to properly make the call:
| const req = https.request(post_options, | |
| (res) => res.on("data", () => callback(null, "OK"))) | |
| req.on("error", (error) => callback(JSON.stringify(error))); | |
| req.write(post_data); | |
| req.end(); |
Once I was able to get past the https connection issues, I was able to utilize the rest of Patrick’s example to get my webhook from Jamf feeding into a Slack channel. We uploaded a custom emoji to our Slack channel and used the Slack documentation on basic message formatting and on attachments to get the notification to look how we wanted.
Ultimately we created two Lambda functions, one for ComputerAdded and another for ComputerInventoryComplete, each feeding into their own channel in our Slack. This was fairly easy to accomplish, the next step is to find a way to feed DataDog, or some other service, the ComputerCheckIn webhook so I can get a count of how many check-ins we have each day.
The code we used is below, but I wanted to point out one or two things. Where I got hung up the most was how to pull things like Computer Name or Serial Number from the JSON we were getting from the Jamf Pro server. Since the JSON contains two arrays, “webhook” and “event”, it took me a little bit to understand how to grab that data. To be honest, my skills here are lacking considerably so it took me longer than it should. Ultimately I figured out that you just have to dot walk to get the data you want. So to get the Computer Name it’s:
body.event.deviceName
“body” is the JSON object that we parse the webhook into. Once I figured that out I was all set to grab whatever data from the event, or webhook, array that I needed. Hopefully my head banging will help others not stumble quite so much.
Here’s the Node.js code we used as the template:
| var https = require('https'); | |
| exports.handler = (event, context, callback) => { | |
| console.log("MYLOG" + JSON.stringify(event)) | |
| var body = JSON.parse(event.body); | |
| var name = body.event.deviceName; | |
| var sernum = body.event.serialNumber; | |
| var user_name = body.event.username; | |
| var building = body.event.building; | |
| var curr_time = Math.floor(new Date() / 1000); | |
| var post_data = JSON.stringify({ | |
| "username": "Jamf Pro Server", | |
| "icon_emoji": ":balloon:", | |
| "channel": "#<yourslackchannelname>", | |
| "text": "Computer Enrolled", | |
| "attachments": [ | |
| { | |
| "color": "good", | |
| "fields": [ | |
| { | |
| "title": "Computer: " + name, | |
| "value": "Serial number: " + sernum | |
| + "\nUser name: " + user_name | |
| + "\nBuilding: " + building, | |
| "short": false | |
| } | |
| ], | |
| "footer": "Jamf Webhook", | |
| "footer_icon": ":balloon:", | |
| "ts": curr_time | |
| } | |
| ] | |
| }); | |
| var post_options = { | |
| host: 'hooks.slack.com', | |
| port: '443', | |
| path: '/services/YOURWEBHOOK', | |
| method: 'POST', | |
| headers: { | |
| 'Content-Type': 'application/json', | |
| 'Content-Length': Buffer.byteLength(post_data) | |
| } | |
| }; | |
| const req = https.request(post_options, | |
| (res) => res.on("data", () => callback(null, "OK"))) | |
| req.on("error", (error) => callback(JSON.stringify(error))); | |
| req.write(post_data); | |
| req.end(); | |
| var details = { | |
| "status": "OK" | |
| } | |
| var response = { | |
| 'statusCode': 200, | |
| 'headers': { 'Content-Type': 'application/json' }, | |
| 'body': JSON.stringify(details) | |
| } | |
| console.log("LOG:: " + JSON.stringify(response)) | |
| callback(null, response); | |
| }; |
JNUC 2018 – Slides And Scripts
The slides, scripts, images, and video from my presentation “10 Things Not To Do in a Large Scale Deployment” are available on GitHub now:
Using lpoptions To Identify Printer Options
In my previous post on adding printers via script I mentioned using lpoptions to identify the different option settings for a printer. Let’s open up Terminal and get started with identifying the options. You’ll need to have the printer already installed on the system, so if it isn’t installed go follow my previous post and get it installed.
First, let’s find the name of the printer. For that we will use lpstat -a:
Now that we know the name, Wayne_HOLD, let’s figure out what the options are that we can set. For that we’ll use lpoptions -p Wayne_HOLD -l. Now this list is way too much information to post here, so I’ll just cut it off at a few lines:
Wow, and there’s plenty more information beyond this. This part of setting the options can be a bit trial and error. We probably aren’t going to want to set everything, but we will want to add any options like the “Fiery Graphic Arts Package” that is installed, or the “Output option”, or perhaps the “Xerox high capacity feeder”.
One way we can figure out what option we need to set is by using grep along with the lpoptions command. For example, to know which option sets the “Fiery Graphic Arts Package” we might try this:
lpoptions -p Wayne_HOLD -l | grep -i "graphic arts"
This gives us the following:
That’s great, but what does “GA2” and “GA1” mean? Open up the Options & Supplies window for the printer by going to System Preferences -> Printers & Scanners -> click on the printer and then click on the Options & Supplies button. For this printer, we can see that “GA1” is the “Fiery Graphics Arts Package”.
What happens when we change that in the GUI to:
This is what we see from Terminal:
So now we know that the “GA2” option is the “Fiery Graphics Arts Package, Premium Edition”.
For other settings we need to do some investigation in the Print pane when printing a document. For most printers we’ll want to see what the default view is in the Print dialog window and then make the change in the Terminal using lpoptions and finally go back to the Print dialog window to see what that change did.
In our case we want to set the Output option and the High Capacity Feeder option from their default settings:
To use a high capacity paper source, and to put the output in a different tray:
Notice that in the second screen shot we now have Tray 6 available to us. We can acheive this using the lpadmin command to set the settings (note: the lpoptions command works most of the time, but I have far more success using lpadmin).
By figuring out which settings we want to use, we can now configure all of the options for a printer from a script. One more example would be setting a color printer to default to B&W and duplex print. This is often done as a cost savings measure.
| lpa='/usr/sbin/lpadmin' | |
| ${lpa} -p CopyThat -E -o printer-is-shared=false -v lpd://10.89.170.5 \ | |
| -P "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 7855.gz" | |
| ${lpa} -p CopyThat -o Duplex=DuplexNoTumble -o XROutputColor=PrintAsGrayscale |
I hope this has inspired you to dive further into setting up printers via script.
Identify EFI Fiery Driver
In this post I talked about how we can use the lpadmin command to add a printer via script. In this post we will cover how we can identify the driver for an EFI Fiery RIP. Note: all Fiery RIPs do not use the same driver, so you will want to follow this process for any Fiery you may have in your environment.
Open your favorite web browser and enter the IP address (or DNS name) for the printer. This should take you to the Fiery RIP webpage.
Now, click on the Configure tab, then on the “Check for product updates” link.
This will open up a new tab in your browser that will take you to the EFI Fiery live update page. From here you’ll want to click on the Printer Drivers tab and then scroll to locate the latest printer driver.
We’ve scrolled down to locate the latest driver that handles macOS 10.14 Mojave.
We can then click the Download link to download the latest version of the Fiery driver for our specific model of Fiery.
One Last Thing
Now that you have your driver downloaded, I would strongly suggest heading over to Foigus’ post, Trial By Fiery, to find out how to use AutoPKG to create a driver package that will install via a management tool, and not have update dialogs popping up.
Deploying Printers via Script
Deploying printers on the Mac in an enterprise environment, or heck, just in a small office environment, can be done in multiple ways. If you don’t have a management tool, or ARD, you’re going to be running around doing it by hand. If you have a management tool, like Munki or Jamf, then you can deploy printers in a more automated fashion. My preferred method is to use a Bash script to deploy printers because it provides me a little more flexibility
Identify The Driver
The first thing to do is to identify the printer and the driver that is required. For most printers this is pretty simple, just navigate to the IP address of the printer to verify the make and model, then head over to the vendor’s website to download the latest driver. Once you have the driver, install it on your machine and then go find the driver file on your system. On the Mac, most printer drivers are stored in:
/Library/Printers/PPDs/Contents/Resources
If your printer has a “RIP”, or “Raster Image Processor“, identifying those drivers can be a little trickier. Head over to this post on how to identify the driver, and download it, on an EFI Fiery RIP. Drivers for an EFI Fiery or other RIP are usually stored in:
/Library/Printers/PPDs/Contents/Resources/<localization folder>
For us here in North America, that folder path would be:
/Library/Printers/PPDs/Contents/Resources/en.lproj
Once you have identified the driver, copy the full path of the driver file (Option-Command-C, or hold down Command then Edit->Copy as Pathname, or right click while holding Command) to your clipboard.
Build The Command
The next thing we need to do is figure out the command to run to add the printer. Fire up Terminal and let’s figure out the commands to use. We will utilize the lpadmin command to get the printer on the system. For this post this is what our command will look like:
sudo lpadmin -p <name> -E -o printer-is-shared=false -v ipp://1.1.1.1 -D "<name>" -P "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 5955.gz"
That looks a little daunting, so let’s break it down a little bit.
-p <name> This flag sets the name of the printer as seen by the cups process. Use a name with no spaces, or substitute underscores for the space.
-E This flag enables the printer to accept jobs
-o printer-is-shared=false The -o flag allows us to pass options to the printer. In this case we are making sure the printer is not shared on the network.
-v ipp://1.1.1.1 The -v flag sets the URI of the printer.
-D <name> Where -p set the name the cups process saw, the -D flag sets what I call the “friendly” name, the name that is visible in the GUI.
-P <driver path> Pretty self explanatory, the -P flag sets the path to the driver.
Now that we have everything, run the command in Terminal to add the printer. You can verify the printer added by using the lpstat -a command. With the printer added, open up a program and send a test print to the printer. It is important for us to do this step so that we know our handy work is working properly.
Put It In A Script
Let’s get to the script to add the printer. Open your favorite code editor (TextMate or Sublime Text for me) and start a new script. I utilize Bash, but you could just as easily do this in Python if you prefer. First we want to make sure the proper driver is on the system, and if it isn’t we want to install it.
| if [[ ! -f "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 5955.gz" ]]; then | |
| /usr/local/bin/jamf policy -trigger xeroxGenericDriver | |
| fi |
If the driver file is not on the system, we call the jamf binary to trigger our install policy. Adjust this to fit your management toolset.
Now with the driver check complete, we use a case statement to choose the printer (or printers) to install. We pass the choice to the script using Script Parameters in our Jamf Pro server policy. Here’s an example showing how we can install one printer, or multiple printers in an office.
| lpa='/usr/sbin/lpadmin' | |
| case $printer in | |
| Printer1) | |
| ${lpa} -p Printer1 -E -o printer-is-shared=false -v ipp://10.1.1.1/ipp/print \ | |
| -D "Printer1" -P "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 5955.gz" | |
| ;; | |
| Printer2) | |
| ${lpa} -p Printer2 -E -o printer-is-shared=false -v ipp://10.1.1.2/ipp/print \ | |
| -D "Printer2" -P "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 5955.gz" | |
| ;; | |
| OfficePrinters) | |
| ${lpa} -p Printer1 -E -o printer-is-shared=false -v ipp://10.1.1.1/ipp/print \ | |
| -D "Printer1" -P "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 5955.gz" | |
| ${lpa} -p Printer2 -E -o printer-is-shared=false -v ipp://10.1.1.2/ipp/print \ | |
| -D "Printer2" -P "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 5955.gz" | |
| ;; | |
| esac |
You can hopefully see the flexibility this provides us for using one script to install multiple printers. Sure, we still have multiple policies in the JPS, but rather than have multiple printers or multiple scripts as well, we can do this with just the one. And, when a printer needs to change, we just edit the script.
Bonus Round
What about adding printer options, like paper trays or output trays or setting a printer to B&W instead of color? We can use lpoptions to figure out what those options are and to set them. Since that can be a daunting task, head over to this post about using lpoptions to identify the settings.
Hopefully this post has helped you evaluate the use of a script to add printers and has given you a new tool for your toolbox.
Custom Theme Fonts Office 2016 Mac
I was given the task of deploying a custom theme for Office 2016 the other day. Not having done this before, I did what I always do: I searched Google for the answer. I was able to figure out where to place the theme file, so I went about my merry way packaging up the theme (along with a script to move it into place) and the fonts that were part of the them, and then I deployed it.
Today I started getting reports that the fonts were not working in the theme. It turns out that when you use custom fonts in a theme, you have to deploy a special XML file that describes those fonts. I headed back over to Google only to find out that Office 2016 on the Mac does not support the creation of themes with fonts in them. Well, it doesn’t give you an easy way to customize the fonts
Fortunately, with a little searching, I found a web site that explained how to hack together a Theme Font file: XML Hacking Font Themes. So I started off and created a new XML file to get the fonts into the theme.
The easiest thing to do, as is explained in that article, is to grab an XML file out of the app bundle:
Just grab one of those XML files and copy it to your desktop. Once you’ve done that, edit the file, replacing the font inside the <a:latin> bracket with the name of the font you need. Do this for the Major and Minor font sections, then save the file. Name the new file the name of the font you are using to make it simple to find. My completed XML file looks like this:
| <?xml version="1.0" encoding="utf-8" standalone="no"?> | |
| <a:fontScheme name="Arial" xmlns:a="http://schemas.openxmlformats.org/drawingml/2006/main"> | |
| <a:majorFont> | |
| <a:latin typeface="Montserrat"/> | |
| <a:ea typeface="" /> | |
| <a:cs typeface="" /> | |
| </a:majorFont> | |
| <a:minorFont> | |
| <a:latin typeface="Montserrat"/> | |
| <a:ea typeface="" /> | |
| <a:cs typeface="" /> | |
| </a:minorFont> | |
| </a:fontScheme> |
Now that you have your XML file and your theme, you need to place them in the correct folder. Office 2016 keeps themes inside the user’s home folder in the following path:
/Users/<user>/Library/Group Containers/UBF8T346G9.Office/User Content/
We’re going to throw the theme into the Themes folder in that path, and the font XML file will go into the Theme Fonts folder in that path:
Voila! You now have a working theme in Office 2016 that can be used in PowerPoint, Word, or Excel.
Pre-Loading AWS S3 Buckets With Jamf Pro
It’s been far too long and way too much has been going on. I took a new position back in February with our corporate office with the lofty goal of migrating 15,000 endpoints into a centralized Jamf Pro instance. We worked with Jamf and with our internal resources to determine where to place the infrastructure and finally settled on AWS. I’ll go into more detail in other posts because for now, I wanted to talk about sideloading packages in S3.
Most of us have dev or test environments. Ours is in AWS alongside our production environment. With the release of Jamf Pro 10 this past week, it meant it was time to upgrade our dev instances to 10. Not only do we host the servers in AWS, but we also host the distribution point for our dev instance on S3. As you may be aware, each time you create a new cloud distribution point with Jamf Pro a new S3 bucket is spun up. That’s fine, but what if you have a bunch of test packages already in a dev S3 bucket that you want to use? That’s where I found myself this evening, and I figured out how to move those into the new S3 bucket that Jamf Pro created.
After spinning up your new Jamf Pro servers and creating your S3 bucket in Jamf Pro, head over to the AWS Console to manage your S3 buckets. Locate your original bucket and select all of the files in the bucket.
Next go under the More button and choose Copy.
Now go find the new bucket that was created by Jamf Pro and go under the More button in the bucket and choose Paste.
After getting the files over, we now have to tell Jamf Pro that the packages are there. Using the AWS CLI from your computer, grab a listing of your bucket:
| aws s3 ls s3://<yourbucketaddress> >> ~/mypackages.txt |
Now that you’ve got a list of all packages in that S3 bucket, you’ll want to get rid of all of the extra data so that you only have the package filename. I used Excel to delete columns and combine columns if there were spaces (use the Open menu in Excel and choose “Delimited” and use Spaces as your delimiter). Once you have a clean list, save that out of Excel and then open it in your favorite text editor. TextMate is my go to for this. You’ll want to save the text out as a CSV with LF only.
We now have a clean list that we can send through a handy API script to stub out the packages in Jamf Pro. We will use the following script to import this data into the Jamf Pro server. Be sure to edit the JSS address in the script before running.
| #!/bin/sh | |
| # Name: addPackages.sh | |
| # Date: 27 Mar 2018 | |
| # Author: Steve Wood (steve.wood@omnicomgroup.com) | |
| # Purpose: used to stub out packages in the Jamf Pro database | |
| # The CSV file needs to be saved as a UNIX file with LF, not CR | |
| # Version: 1.1 | |
| # Update: 27 Mar 2018 - fixing an error in the counter | |
| # A good portion of this script is re-purposed from the script posted in the following JAMF Nation article: | |
| # | |
| # https://jamfnation.jamfsoftware.com/discussion.html?id=13118#respond | |
| # | |
| args=("$@") | |
| #jssAPIUsername="${args[0]}" | |
| #jssAPIPassword="${args[1]}" | |
| jssAPIUsername="apiuser" | |
| jssAPIPassword="apipass" | |
| jssAddress="https://yourserveraddress.com" | |
| file="${args[0]}" | |
| #Verify we can read the file | |
| data=`cat $file` | |
| if [[ "$data" == "" ]]; then | |
| echo "Unable to read the file path specified" | |
| echo "Ensure there are no spaces and that the path is correct" | |
| exit 1 | |
| fi | |
| totalqty=`awk -F, 'END {printf "%s\n", NR}' $file` | |
| #Set a counter for the loop | |
| counter="0" | |
| duplicates=[] | |
| echo $data | |
| #Loop through the CSV and submit data to the API | |
| while [ $counter -lt $totalqty ] | |
| do | |
| counter=$[$counter+1] | |
| line=`echo "$data" | head -n $counter | tail -n 1` | |
| package=`echo "$line" | awk -F , '{print $1}'` | |
| apiData="<package><id>0</id><filename>${package}</filename><name>${package}</name></package>" | |
| output=`curl -sS -k -i -u ${jssAPIUsername}:${jssAPIPassword} -X POST -H "Content-Type: text/xml" -d "<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>$apiData" ${jssAddress}/JSSResource/packages` | |
| echo $output | |
| error="" | |
| error=`echo $output | grep "Conflict"` | |
| if [[ $error != "" ]]; then | |
| duplicates+=($serialnumber) | |
| fi | |
| done | |
| echo "The following packages could not be created:" | |
| printf -- '%s\n' "${duplicates[@]}" | |
| exit 0 |
Let’s open up terminal and run our script, feeding it our cleaned up text file.
| /path/to/script/addPackages.sh <jssuser> <jsspass> /path/to/textfile.csv |
That’s it. As that script runs it will add the packages to the Jamf Pro server so you don’t have to. This will help speed up the process of creating new dev instances each time.
In some of my next posts I’ll discuss how we are using the Server app on machines as distribution points, and utilizing simple scripts with LaunchDaemons to keep them in sync.
Collecting Data Using Plist Files
At our recent Dallas area Casper User Group meeting, we got into a discussion around collecting data during a Casper recon. Specifically we were discussing the use of Extension Attributes to collect information about virtual machines.
Extension Attributes are a way to capture information from your systems. You can use scripts to pull information or drop downs or text boxes to store static information in the database. In the instance of collecting info about virtual machines, a script would be run on the systems during the recon to gather the information. Running a script on the system each time a recon happens can be processor heavy, depending on the data that is being gathered. For example, gathering home folder size by running “du” each time a recon happens can be taxing.
Rather than run the script each recon, you can use a policy to run the script once a week, once a month, or just one time, to gather the information you need and place it in a plist file somewhere. During the standard recon period, you can then use an Extension Attribute to read the information in that plist file. This is much less taxing on the systems than running the script during a recon.
Stash The Data
For our example, rather than run through grabbing info about virtual machines, let’s work on grabbing the home folder size for the logged on user. We will store the info in a plist file that we will stash in /Library/IT_Data.
First we need to find the logged in user name. There are plenty of ways to do this, but we’ll use the “Apple approved” method, using a Python one liner. Okay, it’s not really a one liner, it’s just built like one.
| loggedInUser=`python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "\n");'` | |
| view rawcontents.sh |
Now that we have our logged in user, we just need to find the user’s home folder and use du to grab the data. We’ll use dscl to grab the home folder location and then du to get the home folder size.
| homeDir=`dscl . read /Users/$loggedInUser NFSHomeDirectory | awk '{ print $2 }'` | |
| homeSize=`du -hs ${homeDir}` |
The next thing we need to do is to store this information into our plist file. Using the defaults command, we can write as much data as we want into the plist file, We can use different keys to store whatever data you want, and then recall it during recon by asking for those specific keys.
| defaults write /Library/IT_Data/com.mycompany.homesize.plist HomeFolderSize -string "${homeSize}" |
Retrieve The Data
Now that we have the data stashed away, we just need to grab it during the recon process. To do this, we’ll use the defaults command again, to grab the data. We’ll use some variables for the folder path and the plist name, that way we can re-use this code fairly easily. We also want to make sure the file actually exists before trying to read data from it, hence the If statement.
| if [[ -e ${dataFile} ]]; then | |
| homeSize=`defaults read ${dataFile} HomeFolderSize` | |
| fi |
Once we’ve read the data, all that’s left is to echo it out into the EA.
| if [[ ${homeSize} ]] | |
| echo "<result>${homeSize}</result>" | |
| else | |
| echo "<result>No Results Found</result>" | |
| fi |
That’s All Folks
That’s pretty much all there is. Now that we know how save data to a plist and then read it back, this method could be used for any data we only need to gather once, or gather at infrequent times.
The full script to write the data and to then read the data are below.
| #!/bin/bash | |
| loggedInUser=`python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "\n");'` | |
| homeDir=`dscl . read /Users/$loggedInUser NFSHomeDirectory | awk '{ print $2 }'` | |
| homeSize=`du -hs ${homeDir}` | |
| # check for our storage folder, and create if missing | |
| if [[ ! -d "/Library/IT_Data" ]]; then | |
| mkdir "/Library/IT_Data" | |
| fi | |
| defaults write /Library/IT_Data/com.mycompany.homesize.plist HomeFolderSize -string "${homeSize}" |
| #!/bin/bash | |
| dataFolder="/Library/IT_Data" | |
| dataFile="${dataFolder}/com.mycompany.homesize.plist" | |
| if [[ -e ${dataFile} ]]; then | |
| homeSize=`defaults read ${dataFile} HomeFolderSize` | |
| fi | |
| if [[ ${homeSize} ]]; then | |
| echo "<result>${homeSize}</result>" | |
| else | |
| echo "<result>No Results Found</result>" | |
| fi |
The Geeky Gordo 