As part of preparing for Yosemite, I’ve started testing Casper 9.5.1. As part of my testing, I wanted to address an issue that first appeared for me in Casper 9.4: The blue Featured banner in Self Service.
I use the Featured setting to publish items to the Self Service landing page. When I upgraded my test environment to Casper 9.4, I noticed that all of my Featured items now had a blue Featured banner. Since everything on the main landing page is set to be Featured, in my opinion the banner is distracting and does not add value.
I have submitted a feature request to be able to turn off the blue Featured banner, but as of 9.5.1 this feature request is marked as UNDER REVIEW and has not been implemented. Since I anticipate that I’ll have Macs running Yosemite within the next month, I’ll likely need to deploy Casper 9.5.1 and I wanted to be able to stop this banner from appearing in 9.5.1’s Self Service.
The approach I adopted was to take a copy of the appropriate PNG file on the Casper server and use Preview’s Instant Alpha tool to make all content in the image transparent. In effect, I wanted to have the Featured banner file still be there (to help avoid failures in the event that something in Self Service was checking for the file’s presence) but have the banner itself be completely invisible to my users. This approach worked just fine in my testing and it appears to be similar to what Christopher Collins is using in his shop.
For those who want a copy of the transparent PNG file that I created, I have it available for download here. Once downloaded and uncompressed, it’ll be a PNG file named casper_95_featured.png.
Using the downloaded PNG file, here’s how to deploy on a Casper server to make the Featured banner transparent:
NOTE: The instructions below are for a Casper server running on Red Hat Enterprise Linux, where the JSS Tomcat directory is stored in /usr/local/jss and the Tomcat server has an associated tomcat7 user. The JSS Tomcat directory may be installed in a different location and the Tomcat user may not be named tomcat7 on operating systems other than RHEL . When in doubt, contact JAMF Support for assistance.
1. Log into the Casper server using an account that can use root privileges.
2. Copy casper_95_featured.png into /usr/local/jss/tomcat/webapps/ROOT/images/selfservice2
3. Rename the existing featured.png in /usr/local/jss/tomcat/webapps/ROOT/images/selfservice2 to now be named featured_bak.png
4. Rename casper_95_featured.png to now be named featured.png
5. Run the following command with root privileges:
chown tomcat7:tomcat7 /usr/local/jss/tomcat/webapps/ROOT/images/selfservice2/featured.png
6. Start Self Service and verify that the blue Featured image does not appear.
If the blue Featured banner is still appearing in Self Service, the Featured banner may be cached on individual Macs To fix this, you can clear the Self Service cache on the affected machines by following the procedure below:
1. Quit Self Service
2. Remove the com.jamfsoftware.selfservice folder from /Users/username/Library/Caches/
3. Relaunch Self Service
The blue Featured banner should no longer appear in Self Service.
As part of Firefox 31’s release, Mozilla made a change to enable support for NT LAN Manager version 1 (NTLMv1) network authentication when connecting to sites that are using HTTPS to allow encrypted communication via SSL between Firefox 31 and the website in question. This is to address the change made in Firefox 30, which disabled support for NT LAN Manager version 1 (NTLMv1) network authentication for sites using either HTTP and HTTPS.
NTLMv1 authentication to sites using HTTP is still disabled by default. For more information on why HTTPS is now enabled while HTTP remains disabled, this Mozilla bug report discusses the issue.
A way to tell if the NTLMv1-using site you’re trying to access is using HTTP or HTTPS is to check the connection address. If it begins with https://, you should be OK. If it begins with http:// , Firefox 31 will still block NTLMv1 authentication.
If you need to enable NTLMv1 authentication for an HTTP site that uses NTLMv1 authentication, Mozilla has provided a workaround to non-Windows users of Firefox, in the form of a setting that can be toggled to allow NTLMv1 authentication. This workaround should allow Mac and Linux users to continue using NTLMv1 authentication on HTTP sites, which will allow access again to SharePoint-based or IIS-backed web applications. For those folks who need it, I have the workaround documented here.
Since Casper 9.x was first released, I’ve been preparing for my shop’s own upgrade from Casper 8.x to 9.x. As of the morning of Saturday, June 28th, those preparations have ended with my shop’s successful upgrade to Casper 9.32. When I mentioned this on Twitter, I heard from a few folks who mentioned that they were planning to also do this in the near future and @theycallmebauer asked if I was going to post about my experience.
I thought that was a good idea, so please see below the jump for the details.
As part of Firefox 30’s release, Mozilla made a change to disable support for NT LAN Manager version 1 (NTLMv1) network authentication. This change affects sites using Microsoft’s SharePoint or IIS services. The Windows version of Firefox 30 should switch to using NTLMv2 authentication automatically, but NTLMv2 is not supported by Firefox on non-Windows platforms.
Update – 7-22-2014: Mozilla has released Firefox 31, which now allows access on non-Windows platforms to Sharepoint and IIS sites using HTTPS. For more details, see this post.
The result for non-Windows platforms is that access may be blocked when Firefox 30 users try to access those kinds of sites.
Mozilla has provided a workaround to non-Windows users of Firefox, in the form of a setting that can be toggled to allow NTLMv1 authentication. This workaround should allow Mac and Linux users to continue using NTLMv1 authentication, which will allow access again to SharePoint-based or IIS-backed web applications. For more details, see below the jump.
One of my users at work asked me recently about symlinking his network home folder to /home on his Mac running 10.9.2 and wanted to check to see if it was safe to do so.
In this case, the person in question works on both Fedora Linux, where his network home directory was mounted as /home/username, and on OS X. His network home directory was available via SMB on his Mac as smb://servername/home$/username. He wanted to be able to mount smb://servername/home$/username to /home/username on his Mac, so that it matched the mountpoint of his network home on his Fedora box.
At the time, here’s what I knew about /home:
1. Nothing appears to be stored in it by default
2. It’s listed in /etc/auto_master as a mountpoint
After some VMware host issues that were out of my control, the RHEL VMs that my production and test Casper servers are hosted on were unexpectedly rebooted a couple of times. When I checked the VMs afterwards, everything appeared to be OK. I figured that I had been fortunate, until my Casper test server sent me the nightly “Successful backup of the Casper database” email and my production server didn’t.
When I checked the directory when my production server stores its backups of the Casper database, there wasn’t a backup from the night before. I immediately launched the JAMF Database Utility application and had it make a backup of the production database. A task which normally would take 10 minutes or so now took 40 minutes.
To lighten the load on the database, I went into the JSS and had it manually flush all but the last week’s worth of logs (I normally retain 30 days of logs.)
Once the log flush had completed, I then rebooted the box. On reboot, the JSS initialized and then hung halfway through the JSS startup process.
Really not good.
For the details of how I fixed this, see below the jump.
A while ago, I needed to script a method for binding Macs running 10.6.x and later to our Linux-based OpenLDAP server. Recently, we needed to move our OpenLDAP domain to a different OpenLDAP domain as part of a larger directory service migration project. A small part of that project was moving the LDAP-bound Macs to the new LDAP domain, preferably with as little disruption as possible.
One enormous advantage I had with this LDAP move was the following:
All UIDs, GIDs, usernames, passwords and group names were going to be identical between the two LDAP domains.
As a consequence, I would not need to do any permissions changes, rebuild accounts, make sure people got new passwords or a host of other things normally associated with a directory service change. My task was essentially to tell the Macs “Stop talking to the OpenLDAP service at that address, start talking to this other OpenLDAP service at this address”
As part of the project, I also wanted to accommodate two separate Active Directory domains differently. I wasn’t binding to AD as part of this process, but if a particular Mac was bound to Domain A, I wanted to unbind. If a Mac was bound to Domain B, I didn’t want to unbind but I did want the new LDAP server to be the primary authentication source.
Using my previous OpenLDAP binding script as a starting point, I was able to build a script to handle moving our Macs without downtime or account changes. See below the jump for details.