Implementing log rotation for the Jamf Infrastructure Manager logs on Red Hat Enterprise Linux

A while back, I had set up the Jamf Infrastructure Manager (JIM) in a VM running Red Hat Enterprise Linux (RHEL) to provide a way for a Jamf Pro server hosted outside a company’s network to be able to talk to an otherwise inaccessible Active Directory domain. The JIM software has been running fine since I configured it, but I recently needed to take a look at the JIM logs as part of diagnosing another issue.

For those not familiar with the JIM software, it has several log files and those logs are available in the following location on RHEL:

/var/log/jamf-im-launcher.log
/var/log/jamf-im.log
/var/log/jamf-im-pre-enroll.log

When I checked the logs, I noticed that /var/log/jamf-im.log had grown to almost 500 MBs in size.

Considering this log is a plaintext file, that’s a big log file and it seemingly had been not been rotated or otherwise changed since I first installed the JIM software. To help make sure that the host VM would not eventually run out of space because of this growing log file, I needed to implement log rotation for the JIM logs. For more details, see below the jump.

Identifying the Jamf Pro server set in CasperCheck using an Extension Attribute

As part of my Jamf Pro testing process, I will often set up a VM using a production setup workflow then enroll that newly-setup VM into my test Jamf Pro server. However, as part of my production workflow setup, I will usually install my CasperCheck self-repair solution in order to make sure the machine stays enrolled with my Jamf Pro server.

Unfortunately, this can lead to the following chain of events:

1. Test VM is enrolled in the test Jamf Pro server
2. CasperCheck runs on its pre-set schedule and detects that it is not enrolled with the Jamf Pro server specified in the script.
3. CasperCheck runs its repair functions and enrolls the test VM in the production server.
4. I wonder why my test VM isn’t talking to the test Jamf Pro server.
5. I check the CasperCheck log, grumble when I notice that CasperCheck has done its job, and then install the test server’s CasperCheck script on the test VM.
6. Reboot the test VM to trigger the test server’s CasperCheck script to enroll the test VM into the test server again.

This situation happened infrequently enough in the past that I usually just dealt with it on an individual basis, but I finally decided to fix it by writing a Jamf Pro Extension Attribute to help me identify which Jamf Pro server was specified in the installed copy of CasperCheck . For more details, see below the jump.

Creating Jamf Pro QuickAdd installer packages which do not install the Jamf Pro management user account

Jamf Pro-managed Macs usually have a management account on the Mac, which is normally created as part of the Mac’s enrollment in the Jamf Pro service. This may cause issues in some Mac environments, where the creation of local user accounts is tightly controlled to help minimize opportunities for malicious third parties to compromise unused accounts.

To help protect against the Jamf Pro management account being compromised, Jamf has added some protections. These protections include including the ability to set a random password for the account on a per-machine basis and the ability to rotate the password on a regular basis.

Depending on your needs though, it is also possible avoid setting up the Jamf Pro management account on Macs. The reason for this is that the Jamf Pro agent by and large does not need the Jamf Pro management account in order to work properly.

As of Jamf Pro 9.99.0, the Jamf Pro management account is used for the following:

• To provide SSH connectivity for Jamf’s Remote application
• To provide the option of enabling the management user account for FileVault 2

If you are not using Jamf’s Remote application for remote screen sharing, or enabling the Jamf Pro management account for FileVault 2, it is not necessary to install the Jamf Pro management account on Jamf Pro-managed Macs at all. For more details, see below the jump.

Installing and configuring the Jamf Infrastructure Manager on Red Hat Enterprise Linux

I recently needed to configure Jamf’s Jamf Infrastructure Manager (JIM) to provide a way for a Jamf Pro server hosted outside a company’s network to be able to talk to an otherwise inaccessible Active Directory domain.

The documentation on how to set up an Infrastructure Manager covers the essentials of how to do it, but doesn’t include any screenshots or have information about how to access the logs to help debug problems. After some research and working with the JIM a bit, I was able to figure out the basics. For more details, see below the jump.

Identifying which Active Directory account is logged into Enterprise Connect

As more Mac environments move away from binding Macs to Active Directory and using AD mobile accounts, and towards using local accounts in combination of tools like NoMAD and Apple’s Enterprise Connect, it’s become more challenging to identify which people are logged into which computers. While mobile Active Directory accounts will use the username and password of the person’s AD account, there is no such certainty with local user accounts.

Fortunately, my colleague Joe Chilcote recently let me know that it’s possible to query the logged-in user’s login keychain and get the username of the Active Directory account which is logged into Enterprise Connect. This can be accomplished by running the following command as the logged-in user:

/usr/bin/security find-generic-password -l "Enterprise Connect" $HOME/Library/Keychains/login.keychain | awk -F "=" '/acct/ {print $2}' | tr -d "\""

That should produce output similar to that shown below:

computername:~ username$ /usr/bin/security find-generic-password -l "Enterprise Connect" $HOME/Library/Keychains/login.keychain | awk -F "=" '/acct/ {print $2}' | tr -d "\""
AD_username_here
computername:~ username$

It’s also possible to leverage this technique to update the User and Location section of a particular computer managed by a Jamf Pro server. For more information, see below the jump.

Running multiple Jamf Pro policies via custom trigger

As a follow-up to my previous post about running multiple Jamf Pro policies via the API, my colleague John Kitzmiller pointed out that it was possible to achieve similar functionality by using a custom trigger. For more details, see below the jump.

Running all Jamf Pro policies in a specified category via the API

As part of a project I’m working on, I need to run several policies from a Jamf Pro server using a script which is using the Jamf Pro agent to run policies. However, I also want to maintain maximum flexibility and retain the ability to add, remove or change policies as required without needing to change the script.

My colleague Marc provided a solution for this by letting me know that it was possible to use the Jamf Pro API to pull down a list of policies associated with a specific category and then running those policies in the order provided by the API. For more details, see below the jump.

Creating a Jamf Pro Cloud Distribution Point using Amazon Web Services

In a number of environments, Mac admins are transitioning from hosting their Mac-supporting services in on-site datacenters to now hosting them with various cloud service providers. These service providers can include Jamf Cloud, Amazon Web Services, Akamai or Rackspace.

For Mac admins using Jamf Pro, one way to start this transition is to use a Cloud Distribution Point (CDP). This allows a Jamf Pro server to use several specific cloud services’ content delivery networks to host installers and (if applicable) in-house developed applications and eBooks.

For my own needs, I was looking into setting up a CDP on Amazon Web Services (AWS). Jamf provides some documentation on how to set a CDP up with AWS, but doesn’t provide specific guidance. After some research and testing though, I was able to figure out the process for Jamf Pro 9.97x. For more details, see below the jump.

Providing access to Apple software updates from Jamf Pro’s Self Service

For shops that want to help their customers stay on top of Apple software updates without forcing those updates to be applied, there is a convenient URL that can be used:

macappstore://showUpdatesPage

When this URL is called from the command line using the open command, the following actions take place:

1. The App Store application launches
2. The Updates page loads.
3. The Mac automatically checks for Apple OS updates and updates for applications purchased through the Mac App Store (MAS).

The relevant command is shown below and can be run without root privileges:

open macappstore://showUpdatesPage

For folks using Jamf Pro (the management solution formerly known as Casper), this command can be leveraged to provide a way for customers to easily check for Apple and MAS software updates on their own schedule. For more details, see below the jump.

Providing access to Mac App Store applications via Self Service policies

In my shop, we’re not currently using Apple’s VPP program for purchasing applications from the Mac App Store (MAS). However, we do want to make it convenient for our users to be able to access and install some commonly used applications which are available from the App Store. Casper 9.4 and later natively supports providing access to MAS applications, but this approach is more focused on VPP-purchased applications. In my shop’s case, our customers are more likely to purchase apps from the MAS using Apple’s consumer payment model and then get reimbursed.

To help with this, I originally used a process similar to this one developed by Bryson Tyrell. I wanted to make the process more modular though, where I only needed to supply a URL from the MAS and have a scripted solution handle the rest. For more details, see below the jump.