Putain, vingt ans…

Il y a dix ans, j’ai publié un article sur ce blog, sobrement intitulé… Dix ans !

Dix ans plus tard, ce site affiche donc vingt années au compteur. Ça commence à faire beaucoup. Je ne referai pas toute l’histoire du site, tout a été dit dans le susdit article, ainsi que dans cet autre billet.

Soyons cependant honnête : gete.net a bien perdu de sa superbe. Je n’ai plus la même énergie à écrire sur le web, étant plus présent sur les réseaux sociaux et en particulier Twitter comme tant d’autres. J’ai également été absorbé par l’écriture de différents bouquins (dont je suis particulièrement fier, j’avoue). D’autres projets m’ont également accaparé, comme DiskMaker X (oui, une mise à jour ne saurait tarder, et oui, il y aura sûrement une version pour macoS Mojave).

J’ai un peu (beaucoup) perdu la fibre de l’écriture au long court. Peut-être qu’elle reviendra. Qui sait ?

Malgré tout, j’ai toujours un petit peu de nostalgie de cette époque où j’étais capable de rédiger des longs dossiers techniques, de traiter en profondeur certains sujets. Et j’arrive encore à alimenter de temps en temps ce qui est peut-être à ce jour le plus vieux site Mac francophone (y’en a peut-être un autre, mais là comme ça je ne vois pas. Ah si, la page des Logiciels Internet Macintosh en français de l’inestimable Jean-Pierre Kuypers, que je salue bien bas s’il me lit par ici..

J’ai aussi pas mal de projets inachevés. Parce que s’il y a un mot que je déteste parmi tous, je pense, c’est le mot FIN.

Ce blog, ce site, ne seront donc jamais totalement finis. Ils resteront pour toujours un morceau essentiel de mon passage sur cette chic planète. C’est aussi grâce à gete.net que ma vie a basculé, comme je l’expliquais il y a quelques mois.

Alors, je voudrais juste vous remercier, vous tous les fans d’Apple depuis vingt ans ou plus, les gens qui m’ont lu sur fr.comp.sys.mac, qui m’ont soutenu, ceux qui m’ont fait confiance pour écrire sur leurs sites web, dans leurs magazines, ou dans leurs émissions. Vous qui êtes souvent devenus des amis, des proches. Tous ceux qui ont aimé lire mes conneries, qui ont pu être dépannés par les centaines d’astuces publiées ici ou là. Qui continuent de venir de temps en temps voir si y’a pas un nouvel article sur ce site. J’aime à me dire qu’à travers gete.net, j’ai pu aider des centaines (milliers ? millions) d’utilisateurs Apple dans le monde entier. Et que j’ai peut-être contribué à rendre l’Univers un poil meilleur (c’est très présomptueux, je sais).

Et je vous donne donc rendez-vous dans dix ans…

Qui sait.

5266821

Slides from the “Providing the best Mac experience possible, from the Apple CoE team with ♥” session at Penn State MacAdmins 2018

For those who wanted a copy of my Mac management session at at the Penn State MacAdmins 2018 conference, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/PSU2018SAPPDF

Keynote – http://tinyurl.com/PSU2018SAPKeynote

Automating AutoPkg and JSSImporter setup

As part of building my autopkg-conductor solution for automating AutoPkg runs, I also wanted to automate the setup of AutoPkg and JSSImporter. My colleague Graham Pugh has written a setup script for his environment, which I was able to adapt and extend for my own needs. For more details, please see below the jump.

This script is designed to set up a Mac running macOS 10.13.x or later with the following:

  • AutoPkg
  • JSSImporter
  • The AutoPkg recipe repos defined in the script.

The script checks to see if the following components are installed. If any are missing, they’re installed on an as-needed basis:

It also installs the following Python tools and modules on an as-needed basis:

The script also includes the following features:

  • The ability to set JSSImporter to use a Jamf Pro cloud distribution point as the master distribution point

Screen Shot 2018 07 10 at 9 37 35 AM

  • The ability to install either the latest release of JSSImporter or JSSImporter 0.5.1.

Screen Shot 2018 07 10 at 9 37 49 AM

 

The reason that JSSImporter 0.5.1 is set as a specific install option is that JSSImporter 1.0 does not currently support uploading to a Jamf Pro cloud distribution point. JSSImporter 0.5.1 does support uploading to a cloud distribution point, so while the upload issues are being worked out with JSSImporter 1.x, using the older JSSImporter 0.5.1 is the currently recommended workaround.

Once these tools and modules are installed, the script does the following:

1. Configures AutoPkg to use the recipe repos defined in the AutoPkg repos section.

Autopkg repos variable

 

2. Configures JSSImporter to connect to the desired Jamf Pro server with the correct distribution point settings.

This script should not be run with root privileges or you will receive the following warning:

Screen Shot 2018 07 10 at 10 46 07 AM

Instead, the script should be run by an account with sudo privileges, so that entering the account’s password will allow sudo to run specified processes with root privileges. If you try to run this script using an account without sudo privileges, you will receive the following warning:

Screen Shot 2018 07 10 at 11 33 52 AM

If the script is successfully run, the script output should look similar to what is shown below.

If a Jamf Pro cloud distribution point is set as the master distribution point:

Screen Shot 2018 07 13 at 6 11 00 AM

If a Jamf Pro file share distribution point is set as the master distribution point:

Screen Shot 2018 07 13 at 5 44 19 AM

The script is available below. It’s also available from GitHub using the following link:

https://github.com/rtrouton/autopkg_setup_for_jamf_pro

Joining Apple’s AppleSeed testing program

In addition to Apple’s Developer Connection program for developers, Apple also has a program called AppleSeed for IT, which is geared towards working with enterprise customers to help them test new Apple software.

During recent conversations about AppleSeed for IT, I was told that it was better for AppleSeed members to submit bug reports and feature requests through AppleSeed’s Feedback Assistant. This would be in place of sending those bug reports and feature requests through Apple’s regular bug reporting at bugreport.apple.com.

Why? Two reasons:

  1. Bug reports and feature requests sent through AppleSeed’s Feedback Assistant are routed to a dedicated queue for IT.
  2. There’s a smaller absolute number of items being sent through AppleSeed’s Feedback Assistant, which means that there’s less communication volume for Apple to sort through to get to your issue.

How to join AppleSeed for IT

There’s no cost to join AppleSeed for IT and you will not be asked to pay for anything, but you do need to be invited by Apple. This takes the form of an invitation code that you must provide when registering for AppleSeed.

If your company, school or institution has purchased an AppleCare Preferred, AppleCare Alliance and AppleCare Enterprise support plan, you should be given an opportunity to enroll into AppleSeed. If you haven’t been asked already, contact the Apple rep for your support plan and request an invitation.

What if your shop hasn’t purchased an AppleCare support plan? You are still able to request an invitation. To do so, use the following procedure:

  1. Log into the MacAdmins Slack. If you’re not familiar with the MacAdmins Slack, please see this post by my colleague Armin Briegel.
  2. Go to the #appleseed channel.
  3. Politely ask how you can get an invitation to join AppleSeed.

Note:

One thing that’s important to know is that discussions about AppleSeed-provided software should not take place in the #appleseed channel. The reason is that AppleSeed software is covered by Apple’s NDA for AppleSeed, where participants in the program agree not to publicly discuss the software or their experiences with it.

 

Slides from the “Escaping the ‘Tech Whisperer’ Trap” session at Penn State MacAdmins 2018

For those who want a copy of the documentation talk given by myself and my colleague Nikki Lewandowski at the Penn State MacAdmins 2018 conference, here is a link to the slides in Keynote format.

Keynote slides: https://goo.gl/nHWg3Z

Automating AutoPkg runs with autopkg-conductor

About two weeks ago, I noticed I had an SSL error cropping up with one of my AutoPkg recipes:

[Errno socket error] EOF occurred in violation of protocol (_ssl.c:590)

When I investigated what it meant, I wound up at this lengthy issue opened for Python’s requests module. In the end, it seemed to boil down to four issues:

  1. I was running AutoPkg on macOS Sierra 10.12.6.
  2. The recipe I was running used a processor which called Python’s urllib2 library.
  3. Python’s urllib2 library was calling the OS’s installed version of OpenSSL to connect to a server using TLSv1.2 .
  4. The version of OpenSSL included with 10.12.6 does not support TLSv1.2 for the urllib2 library.

When I looked into the situation on macOS High Sierra 10.13.5, Apple had addressed the problem by replacing OpenSSL with LibreSSL. Among other improvements, LibreSSL allowed Python’s urllib2 library to be able to connect to servers using TLSv1.2. Problem solved!

Until I ran into another problem.

I had been using AutoPkgr as my way of managing AutoPkg and scheduling AutoPkg runs. However, when I set up AutoPkgr on a 10.13.5 VM and scheduled my AutoPkg nightly run, nothing happened except my CPU spiked to 100% and AutoPkgr locked up with the pinwheel of patience.

OK, maybe it was something with my VM. No problem, set up a new macOS 10.13.5 VM.

Same problem.

Maybe it was because I was trying to run the VM on VMware’s ESXi? Set up a new VM running in VMware Fusion. Same problem.

Maybe AutoPkgr was getting confused by Apple File System? I set up a 10.13.5 VM which used an HFS+ boot volume. Same problem, replicated on both ESXi and Fusion.

No matter what I tried, trying to run recipes using AutoPkgr on macOS 10.13.x resulted in the following:

  • The VM’s CPU spiking to 100%
  • AutoPkgr locking up with the pinwheel of patience
  • My AutoPkg recipes not running

I was able to eliminate AutoPkg itself as being the issue, as running recipes from the command line using AutoPkg worked fine. With that information in mind, I decided to see if I could replicate what I most liked about using AutoPkgr into another form. In the end, my needs boiled down to three:

  1. I wanted to be able to run a list of AutoPkg recipes on a scheduled basis. These recipes would be .jss recipes for uploading to a Jamf Pro server.
  2. I wanted to be able to post information about those AutoPkg recipes to a Slack channel
  3. I wanted all the error messages from an AutoPkg run, but I didn’t care about all the information that came from a successful AutoPkg run.

With that, I decided to draw on some earlier work done by Sean Kaiser, a colleague who had written a script for managing AutoPkg in the pre-AutoPkgr days. For more details, please see below the jump.

Sean’s solution relies on a script and LaunchDaemon running on a Mac, where it runs hourly and is set up to only send him emails if the AutoPkg logs are different from previous runs. The email notifications are a diff against the previous logs, so only the true differences get sent.

For those interested, Sean’s script is available from here:

https://github.com/seankaiser/automation-scripts/tree/master/autopkg

I was more focused on a once-daily run, so I didn’t want to use the diff methodology. After some more research, I found that my colleague Graham Pugh had written pretty much exactly what I needed: An AutoPkg post-processor named Slacker which could be used with an AutoPkg recipe list of .jss recipes to post the results to a Slack channel.

I forked a copy of the Slacker post-processor and (with Graham’s help) made some edits to it to have the output appear exactly the way I wanted it to.

New package message:

AutoPkg new package message

No new package message:

AutoPkg no new package message

Along with the Slacker post-processor, I also found a script for sending multiline output to a Slack channel. This would allow me to send the complete error log from an AutoPkg run to a specified Slack webhook.

Using all of this, I wrote a script named autopkg-conductor which is designed to do the following:

1. Detect a list of AutoPkg recipes at a defined location and verify that the list is readable.
2. If the AutoPkg recipe list is readable and available, run the following actions:

A. Verify that AutoPkg is installed.
B. Update all available AutoPkg repos with the latest recipes.
C. Run the AutoPkg recipes in the list.

The AutoPkg run has all actions logged to ~/Library/Logs, with the logfiles being named autopkg-run-for- followed by the date.

Screen Shot 2018 07 05 at 10 38 32 PM

If the optional slack_post_processor and slack_webhook variables are both populated, any AutoPkg .jss recipes should have their output sent to the Slack webhook specified in the slack_webhook variable.

Screen Shot 2018 07 05 at 10 13 10 PM

If only the slack_webhook variable is populated, all output from the AutoPkg run is sent to the Slack channel. No filtering is applied, everything is sent.

Screen Shot 2018 07 05 at 9 14 08 PM

If neither the slack_post_processor or slack_webhook variables are populated, no information is sent to Slack. All AutoPkg run information will be in the logs stored in ~/Library Logs.

Screen Shot 2018 07 05 at 10 38 32 PM

For scheduled runs, I recommend the following:

  1. Set up a user account named autopkg to run AutoPkg in.
  2. Copy the autopkg-conductor script to /usr/local/bin/autopkg-conductor.sh and set the autopkg-conductor.sh script to be executable.
  3. Set up a LaunchDaemon to run /usr/local/bin/autopkg-conductor.sh at a pre-determined time or interval.

For this example, the LaunchDaemon shown below will run /usr/local/bin/autopkg-conductor.sh as the autopkg user once a day at 2:00 AM.

The autopkg-conductor script is available below. It’s also available from GitHub using the following link:

https://github.com/rtrouton/autopkg-conductor

Automating Jamf Infrastructure Manager setups on Red Hat Enterprise Linux

As part of a project, I needed to build an automated setup process for a Jamf Infrastructure Manager (JIM). Thanks to the help of some folks at Jamf, I have a process which runs non-interactively and which does the following on Red Hat Enterprise Linux 7.x:

  1. Installs the JIM software
  2. Enrolls the JIM with a Jamf Pro server

For more details, please see below the jump.

The key information I needed from Jamf was how to run an non-interactive enrollment of the JIM with a Jamf Pro server. This can be done with the following command:

/path/to/jamf-im enroll --hostname jim_hostname_goes_here --jss-url https://jamf.pro.server.here --password jamf_pro_account_password_goes_here --username jamf_pro_account_username_goes_here

This does require placing a password in the clear, so I recommend setting up an account on your Jamf Pro server which only has the required rights to enroll a JIM.

Once you’ve enrolled, you should be able to check /var/log/jamf-im.log and verify that enrollment has been successful. If it was successful, you should see log entries similar to what’s shown below:

You should also see the new JIM appear listed in your Jamf Pro server. To check this, use the following process:

1. Log into the Jamf Pro server using an admin account.
2. Go to Management: Server Infrastructure and select Infrastructure Managers.

Screen Shot 2018 06 22 at 10 16 30 PM

3. You should see the new JIM listed there.

Screen Shot 2018 06 22 at 10 14 29 PM

Screen Shot 2018 06 22 at 10 14 39 PM

 

To help automate the process, I’ve written a script for CentOS 7.x / RedHat Enterprise Linux 7.x which does the following:

  1. Checks to see if Java is installed and installs OpenJDK 8.x if it isn’t.
  2. Checks for the JIM installer at a defined location
  3. If the JIM installer is available, installs the JIM software.
  4. Verifies that the JIM software has been installed.
  5. Enrolls the JIM with a specified Jamf Pro server, using credentials provided in the script.

Pre-requisites

  • A JIM installer .rpm file for CentOS / RedHat Enterprise Linux stored in the location defined in the script.
  • Credentials for the specified Jamf Pro server

When successfully run, the output of the script should appear similar to that shown below:

Screen Shot 2018 06 22 at 9 26 25 PM

The script is available below, and also available on GitHub at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/jamf_infrastructure_manager_automated_setup

Creating a least privileged Jamf Pro user account for Jamf Infrastructure Manager setups

As part of working with the Jamf Infrastructure Manager (JIM), I wanted to see if I could find a least-privileged way to enroll a JIM with a Jamf Pro server. As it turns out, it’s pretty straightforward. For more details, please see below the jump.

To set up a JIM, three account privileges are required:

Jamf Pro Server Objects: Infrastructure Manager Instances: Create, Read, Update

Screen Shot 2018 06 22 at 3 35 14 PM

To set up a user account with the specified privileges, please use the procedure below:

1. Log into your Jamf Pro server using an account with administrator rights.
2. Go into Management: System Settings: Jamf Pro User Accounts & Groups

Screen Shot 2018 06 22 at 10 57 43 PM

3. Click the New button.

Screen Shot 2018 06 22 at 10 55 06 PM

4. Select Create Standard Account and click the Next button.

Screen Shot 2018 06 22 at 10 55 11 PM

5. Set up a new account with the following account privileges:

Infrastructure Manager Instances:

Create, Read, Update

Screen Shot 2018 06 22 at 10 55 57 PM

Screen Shot 2018 06 22 at 10 56 16 PM

 

6. Once the new account has been set up and configured as desired, click the Save button.

Screen Shot 2018 06 22 at 10 56 17 PM

 

The account should now be available to help set up new Jamf Infrastructure Manager instances.

Screen Shot 2018 06 22 at 10 56 47 PM

Updated MigrateADMobileAccounttoLocalAccount script now available to fix migration bug

A couple of years back, I wrote a script to assist with migrating AD mobile users to local users. In my testing in 2016, everything seemed to work right and I didn’t see any problems with it on OS X El Capitan.

Fast forward a couple of years and a colleague of mine, Per Oloffson, began running into a weird problem with upgrading Macs from Sierra to High Sierra. When he upgraded Macs from macOS Sierra to macOS High Sierra, he was finding that Macs that had been migrated from AD mobile accounts to local accounts were having those same accounts break.

After a considerable amount of troubleshooting, he was able to narrow it down to the macOS High Sierra installer changing the password hash on those accounts. But why was it changing them?

In short, it was changing them because of a bug in my original MigrateADMobileAccounttoLocalAccount.command interactive migration script. Sorry, Per. For more details, please see below the jump.

The problematic sections are highlighted below. When the script backed up the AD mobile account’s password and then restored it, it was adding single quotes to the beginning and end of the password hash string.

Screen Shot 2018 06 15 at 7 32 06 PM

The password hash string should have looked like this:

Screenshot 2018 06 15 13 31 17

Instead, it looked like this:

Screenshot 2018 06 15 13 31 18

The odd part of the situation is that macOS Sierra was seemingly OK with the extra characters in the password string. It wasn’t until the macOS High Sierra installer re-checked and altered the account plist that the problem occurred.

To fix the migration process, I’ve updated the script to better handle the account password backup and restoration process. The backup process is now querying dscl for the correct XML output and restoring it, which should address the problem with the script.

Screen Shot 2018 06 15 at 7 55 24 PM

In my testing, the password hash is now appearing correctly in the account’s plist file.

Screen Shot 2018 06 15 at 8 23 03 PM

Testing

This script has been tested and verified to migrate AD mobile accounts to local accounts on the following versions of macOS:

  • macOS 10.13.5

In that testing, I did the following:

Testing on logged-in AD mobile user account:

  1. I set up an AD-bound VM and created an AD mobile account with admin privileges.
  2. I logged into the AD mobile account and ran the script while logged in as that account.
  3. Once the account had been migrated, I rebooted and verified that I could log in at the OS login window.
  4. I changed the password for the local account to a new one and rebooted.
  5. I verified that I could log in at the OS login window with the new password.

Testing on logged-out AD mobile user account:

  1. I set up an AD-bound VM and created an AD mobile account with admin privileges.
  2. I logged into the VM using a local account which was not the AD mobile account and ran the script while logged in as that account.
  3. Once the account had been migrated, I logged out and verified that I could log in at the OS login window with the just-migrated account.
  4. I changed the password for the newly-migrated local account to a new one and rebooted.
  5. I verified that I could log in at the OS login window with the new password.

Note: I did not test with FileVault-enabled accounts.

Advisory: Older versions of OS X and macOS were not tested and I have no idea if the script will work on those older OS versions.

Warning: I was able to test in my shop’s AD environment and verified that everything worked. That does not guarantee it will work in your environment. Test thoroughly before deploying in your own AD environment.

The updated script is available below, and also available on GitHub at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/migrate_ad_mobile_account_to_local_account

Sending Jamf Pro notifications to Slack

One of the features offered by Jamf Pro is the ability to send notifications of various events to specified email addresses. Any Jamf Pro user account can be set up to receive these emails, so they’re a convenient way to be notified about events affecting your Jamf Pro service.

These notifications include the following:

  • An instance of the Jamf Pro web application in a clustered environment fails
  • An updated patch reporting software title is available
  • Computer is enrolled using PreStage
  • Database backup fails
  • Database backup succeeds
  • Error occurs during imaging
  • Error occurs when policy runs
  • Jamf Pro account is locked out because of excessive failed log in attempts
  • Jamf Pro fails to add file to JDS instance or cloud distribution point
  • License limit is exceeded
  • One or more Memcached Endpoint(s) are not reachable
  • Restricted software violation occurs
  • Smart computer group membership changes
  • Smart mobile device group membership changes
  • Smart user group membership changes
  • SSL certificate verification is disabled
  • Tomcat is started or stopped
  • VPP token is approaching expiration date

Screen Shot 2018 06 14 at 9 26 49 AM

That said, I get enough emails on a daily basis that I’d prefer to have these notifications go to a channel in Slack. That way, my whole team can be notified about issues and there’s a searchable log of when events occurred.

There are solutions for sending notifications directly to Slack, but I wanted to avoid using middleware in favor of using the built-in notifications in Jamf Pro. Fortunately, there’s a way to do that using tools available from Slack. For more details, see below the jump.

As part of its paid plans, Slack includes an app integration called Email. This Slack app will give you an email address to send to and allow you to select a channel where the emails should appear.

As an example, you may want to set up a channel in your team’s Slack instance named #jamfpro-notifications and then configure the Email app so that it provides an email address associated with the #jamfpro-notifications channel.

Any emails sent to the specified address would appear in the #jamfpro-notifications channel. You can also configure a specific icon to be associated with the posted messages.

Screen Shot 2018 06 13 at 8 34 20 PM

Once you have the Slack email address, you can then set up a local user in Jamf Pro to send the notifications. This user account can have no account privileges at all, as no privileges are needed to receive email notifications. To set up the user, please use the procedure below:

1. Log into your Jamf Pro server using an account with administrator rights.
2. Go into Management: System Settings: Jamf Pro User Accounts & Groups

Screen Shot 2018 06 14 at 10 17 01 AM

3. Click the New button.

Screen Shot 2018 06 13 at 8 41 19 PM

4. Select Create Standard Account and click the Next button.

Screen Shot 2018 06 13 at 8 41 24 PM

5. Set up a new account, with the email address from Slack as the account’s email address.

Note:No account privileges need to be assigned to this account.

Screen Shot 2018 06 13 at 8 42 42 PM

6. Once the new account has been set up and configured as desired, click the Save button.

Screen Shot 2018 06 13 at 8 42 43 PM

7. Log out of your Jamf Pro admin account and log into the newly-created account.

Screen Shot 2018 06 13 at 8 44 17 PM

8. If no privileges were set for the account, verify that everything is coming up as Access Denied.

Screen Shot 2018 06 13 at 8 44 33 PM

Screen Shot 2018 06 13 at 8 44 35 PM

Screen Shot 2018 06 13 at 8 44 38 PM

9. Click the account drop-down menu and select Notifications.

Screen Shot 2018 06 13 at 8 44 51 PM

10. Select your desired notification options. Once finished, click the Save button.

Screen Shot 2018 06 13 at 8 45 29 PM

11. Log out of Jamf Pro.

Once that this has been configured, you can go to your Slack channel and see the notifications appear.

IMG 8956