Dealing with EFI Fiery Drivers for OS X El Capitan

Can you use composer to snapshot an uninstall then go back into the "Snapshots" folder and use the items listed in "Deleted Files" to create an uninstall script? You can even right click on the Deleted Files list and it will offer to make a post flight script for you.

You could either load that script in an empty package and run it as an uninstaller or load it as a preflight script in the new install package you make.

Just an idea. I've had to do it for bluecoat in the past when they were using .app installers and uninstallers.

If you're on Twitter or MacAdmins slack, hit up @swy and @foigus as they just deconstructed these installers (for purposes of using with Munki, but). At least searching the archives, you wouldn't have to totally reinvent the wheel, as far as knowledge goes.

@RobertHammen What channel on Slack? I haven't used it before so I'm still kinda of navigating. I see a few tweets from them though regarding the installer, but nothing that I'm looking for in regards to the uninstaller.

@hkabik I'm aware that's always an option, but its.....dirty. I would lose the logic built into the uninstaller which knows how to detect its own drivers whether old or current along with print queues using those drivers. It's bad enough their installer has to be modified to be deployed properly, but if I follow this then I'm essentially attempting to recreate their uninstaller which may or may not cover every scenario of what drivers/versions may be installed on the client....

This isn't meant at you of course, but.....is it too much to ask to have command line options available when your customers are in the enterprise? Its nuts that we pay for this POS.....

Whoa!!!! And I just checked on my thread on the EFI forums and they posted helpful information!!!

Here's the link:
http://fieryforums.efi.com/attachment.php?attachmentid=1342&d=1447370372

and the text for historical archiving:

Fiery Software Uninstaller [Commandline]
During silent uninstallation, FSU will not ask for any confirmation from user like closing 
running applications, asking for retaining preferences etc.

In case if any application is running, it will close it and proceed for uninstallation without 
any confirmation from the user.

Usage:
sudo FSU -s CurrentUserName Flag [options]

*CurrentUserName can be provided as ”$USER” or `whoami`. It is used to get the location of 
the user specific Library/Preferences folder.

*FSU = /Fiery Software Uninstaller.app/Contents/MacOS/Fiery Software Uninstaller

*Flags-
-rmAll -> Remove all Fiery Applications, printers and drivers.
-rmApps -> Remove all Fiery Applications.
-rmPrints -> Remove all Printers.
-rmDrivs -> Remove all Drivers.
-a “App1 , App2” -> Remove specified applications. Application names must be 
separated by comma and complete list should be enclosed within “ “.
-arp "App1, App2" -> Remove specified applications but retain their preference files. 
[Ex: For "Fiery Command WorkStation"]
-p “Printer1 , Printer2”-> Remove specified printers. Printer names must be separated 
by comma and complete list should be enclosed within “ “.
-d “Driver1 , Driver2” -> Remove specified drivers. Driver names must be separated by 
comma and complete list should be enclosed within “ “.
-getAllInstalledProducts -> Get a list of all installed products.
-getInstalledDrivers -> Get a list of all installed Fiery Drivers.
-getInstalledPrinters -> Get a list of all printers using Fiery Drivers.
Examples:
sudo FSU -s “$USER” - rmAll
sudo FSU -s “$USER” -rmApps
sudo FSU -s “$USER” -rmPrints
sudo FSU -s “$USER” -rmDrivs
sudo FSU -s “$USER” -getAllInstalledProducts
sudo FSU -s “$USER” -getInstalledDrivers
sudo FSU -s “$USER” -getInstalledPrinters
sudo FSU -s “$USER” -a “Command WorkStation 5 , HotFolders”
sudo FSU -s “$USER” -p “10.210.12.24 , 10.210.34.45”
sudo FSU -s “$USER” -d “Driver1 , Driver2”

This makes a bit more sense too. The other day I took the uninstaller binary and opened it in a text editor which actually shows some of this code. Except a lot of it garbled up and not really readable (at l;east not readable enough to make sense of all the flags and usage, syntax, etc). I'm not saying I'm elated, but at least I have something to play with tomorrow.

I'll throw out that the "need to uninstall the previous driver" has been a statement in EFI's previous Fiery installer Read Me's, so that's nothing new to 10.11.

That said, anyone who is distributing Fiery drivers should probably be using smart groups to verify the Fiery Features (FF) Printer Dialog Extension (PDE) version if they're upgrading across major OS X versions (e.g. 10.9 -> 10.10) in place. This is since EFI can't be bothered to make a single FF PDE that works across all versions of OS X. For example, the "FD47" revision (version taken from the name of the dmg downloaded from EFI's site) Fiery driver for the Ricoh C3503 with E-22C 1.0 Fiery supports 10.6-10.10. When installed, the PDE that placed (EF246444 (FF).plugin) on the computer could be (as sourced from the pkg):

• 10.0 - 10.6: PluginX64, CFBundleShortVersionString 3.6.011.0
• 10.7 - 10.9: PluginX64_sandbx_dynppd, CFBundleShortVersionString 3.61.009.0
• 10.10+: PluginX64_yosemite, CFBundleShortVersionString 3.72.010.0

But note the PDE is still named "EF246444 (FF).plugin".

If you upgrade OS X across one of the boundaries defined above, you may need to (and probably should) reinstall the driver (yes, the exact same pkg you installed before the OS upgrade) lest you run into an issue like this:

(thanks to @swy for the screenshot).

EFI's pkgs run a close second to Creative Cloud Packager packages for madness level. Don't forget to check out whether your EFI Fiery pkg includes the unpopular "Fiery Printer Driver Installer.app" (my Ricoh drivers blessedly don't include it for some reason). Your EFI Fiery pkg might not work out of the box or may pop up interesting dialogs, prompts, and applications.

Hey @foigus, thanks for the extra notes. I had only deployed the drivers previously on newly built machines with Yosemite so it wasn't really an issue at that point to uninstall since there was nothing to uninstall. I also never saw the notes regarding uninstalling the drivers in previous release notes. I noticed the same thing as you did regarding the extension when dealing with these drivers on Yosemite (we were testing some issues with SMB vs LPD; short of it is that SMB caused a 30 second delay in the print dialog in Yosemite which has improved to 5 second delay with the El Capitan drivers).

@foigus @swy And any other EFI customers....I had meeting with their technical engineers. They were quite receptive and I've provided them some feedback to make things a bit more enterprise friendly. I've also pointed them to your comment regarding the Fiery Features Print Dialog Extension.

To recap what I shared with them:

Packaging Commandments: https://www.afp548.com/2010/06/03/the-commandments-of-packaging-in-os-x/ One immediate improvement that can have an immediate impact for enterprise customers: -Make documentation/whitepapers available on how to deploy and uninstall drivers in an enterprise environment so that admins do not have to come up with their own solutions and dig deep into the EFI driver installer package and tear it apart. Specifically the uninstall documentation was greatly appreciated. Topics discussed for improvements for deploying drivers in an enterprise environment: -Enterprise friendly way to deploy install drivers without the Install Wizard appearing using the command line -Add the uninstall of old EFI drivers when installing new EFI drivers. Since admins are being asked to uninstall the drivers before installing new drivers, may as well force it. Although, in doing this take into account that some people may want to remove the drivers, but not necessarily the print queues. Not sure if that's possible or not, but I'll leave that task up to you to determine the best way to handle that. -Make the installation of the Fiery Driver Updater optional as most enterprise environments have to test drivers before deploying. -Look into using getopts as opposed to multiple nested if statements. Here is one of many articles you can find online about it: http://wiki.bash-hackers.org/howto/getopts_tutorial

It'd be nice if they provided a deployable version (without that annoying GUI prompt) that would save us having to deconstruct the package and hack their installer script (btw thanks to @dwandro92 for this thread: https://jamfnation.jamfsoftware.com/discussion.html?id=14783 )

@foigus Just a minor update: I took a look at the Fiery Features (FF) Printer Dialog Extension (PDE) version. But in our case there are only two versions and they both have the same version. So even that isn't consistent across all Fiery drivers. May not effect you, but figured I'd mention it in case someone else tries to follow that technique. FWIW Our Fiery is an F200 for the Canon C700.

@benshawuk So in speaking to the developers, the reason they added that GUI was because admins were asking for it. As you may imagine, not everyone has the same skill set and not every environment is the same. So in situations where the end user has to install on their own, that GUI comes in handy. Or in places where techs are manually installing things. This is what it was like for me in Higher Ed so I can empathize with the request. Unfortunately, it complicate things for admins who like to deploy things silently and in the background. Fortunately, it's possible to break apart their installer. Hopefully the feedback I gave them will allow them to improve upon this process so they can appease the various environments they support.

We've been silently installing the latest version that works with our model Fierys at my site, "ic415_v20_PS_macOSX10_v47_R." We loaded the "Fiery Printer Driver.pkg" straight out of their DMG into JSS. We have been deploying it without any modifications as part of an imaging configuration, or if we need to install it (and map the printer) to someone's existing computer silently via Casper Remote.

Placing the Uninstaller app in the target drive is trivial. I will experiment with the command line trigger for the uninstaller you posted to see if it works with our version of the software. It'll come in handy when our lease is up (in a couple of years), and we need to upgrade to a new version.

@bpavlov Thanks for that. It's great that you've got a dialogue going with the developers.
I can understand the advantages you described. I just think it'd be best to have both options, or at least some instructions/documentation on how to silently deploy, that's officially supported rather than gleaned from a forum like this one and having to essentially hack the installer, as that's a common requirement in enterprise environments.
I must admit I hadn't seen your post above, and I see you've already fed that request back to them, which is great.

I have written an AutoPkg recipe for revision "FD50" Fiery drivers. While researching the drivers, I encountered a few things:

• Revision FD50 drivers now have an postinstall (installation) script that recognizes a command line installation
• Revision FD50 drivers seem to have consistent postinstall scripts across all printer/RIP models
• Revision FD50 drivers will abort installation of the Fiery Driver Updater if it doesn't exist

My goal is to remove the Fiery Driver Updater and then repack the package so a command line installation is silent and doesn't include the driver updater. I wrote the recipes here. The workflow is as follows:

• Navigate to EFI's download page and find your driver. You should pick a driver that specifically supports OS X 10.11, since this appears to be one of calling cards of a revision FD50 driver.
• Start the driver download and then obtain the direct URL of the downloaded file. In Safari you can right-click on the file in the download window to obtain the URL. The URL will roughly resemble this (this one is for a Ricoh Pro 901 with E41 v1.0 Fiery):

https://d1m2uyedaojrqy.cloudfront.net/FSO/ricoh/RIC_E41_E81/Mac128/lang_c_notes/v1.0/Ricoh_E41_v1_0R_EFIGSD_FD50_v1.dmg

• Note the name of the disk image (in this case "Ricoh_E41_v1_0R_EFIGSD_FD50_v1") and confirm that it is indeed named for a "FD50" revision driver
• Add my AutoPkg repo and then create a uniquely-named override for the download recipe, using the name of your disk image

  autopkg repo-add foigus-recipes 
  autopkg make-override GenericFieryFD50.pkg -n Ricoh_E41_v1_0_SC_FD50_v1.pkg

• Edit the override, setting DOWNLOAD_URL to the URL discovered when downloading your driver and the NAME and PACKAGE_ID as appropriate. I used a NAME of the disk image name plus "_No_Update", and a PACKAGE_ID of com.efi.<disk-image-name>.pkg but replacing the underscores with hyphens since the PkgCreator processor doesn't like underscores. My override for a Ricoh Pro 901 with E41 v1.0 Fiery is below:

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
  <dict>
      <key>Identifier</key>
      <string>local.pkg.Ricoh_E41_v1_0_SC_FD50_v1</string>
      <key>Input</key>
      <dict>
              <key>DOWNLOAD_URL</key>
              <string>https://d1m2uyedaojrqy.cloudfront.net/FSO/ricoh/RIC_E41_E81/Mac128/lang_c_notes/v1.0/Ricoh_E41_v1_0R_EFIGSD_FD50_v1.dmg</string>
              <key>NAME</key>
              <string>Ricoh_E41_v1_0R_EFIGSD_FD50_v1_No_Update</string>
              <key>PACKAGE_ID</key>
              <string>com.efi.Ricoh-E41-v1-0-SC-FD50-v1.pkg</string>
      </dict>
      <key>ParentRecipe</key>
      <string>com.github.foigus.pkg.GenericFieryFD50</string>
  </dict>
  </plist>

• Run the (override) recipe

  $ autopkg run Ricoh_E41_v1_0_SC_FD50_v1.pkg.recipe
  Processing Ricoh_E41_v1_0_SC_FD50_v1.pkg.recipe...
  The following packages were built:
  Identifier                             Version  Pkg Path                                                                                                                
  ----------                             -------  --------                                                                                                                
  com.efi.Ricoh-E41-v1-0-SC-FD50-v1.pkg  1.50     /Users/admin/Library/AutoPkg/Cache/local.pkg.Ricoh_E41_v1_0_SC_FD50_v1/Ricoh_E41_v1_0R_EFIGSD_FD50_v1_No_Update.pkg

The package that's output still acts like the original Fiery package, but if run from the command line should install silently and not install the Fiery Driver Updater (including the Fiery Driver Updater LaunchAgent). This recipe doesn't attempt to make the Fiery package any less weird (it's still a big postinstall script that goes at least two layers deep calling "installer"), but hopefully this should provide a common repackaging route.

Note I also picked a package version number of "1.50" since this is repacking the revision "FD50" drivers.

Mentioning @bentoms because I'd like his feedback as well.

I realize this is an older thread, but I wanted to update it with how I am handling updating my Fiery drivers after doing OS upgrades.

Utilizing @foigus AutoPkg recipe, I have AutoPKGr pulling the latest Xerox drivers into the JSS for me. I created a package with the Fiery Uninstaller and a postinstall script that calls the uninstaller per the EFI instructions above:

#!/bin/bash

# name: postinstall
# date: 26 May 2016
# purpose: postinstall script for uninstalling Fiery drivers before
# installing new ones. Based around info at the following URLs:
#
# https://jamfnation.jamfsoftware.com/discussion.html?id=17834#respond
#
# http://fieryforums.efi.com/attachment.php?attachmentid=1342&d=1447370372
###########################################################################

# set some variables
currUser=`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 + "
");'`

FSU=`/private/tmp/Fiery Software Uninstaller.app/Contents/MacOS/Fiery Software Uninstaller -s ${currUser} -rmAll`

There is one policy that has this Fiery Uninstall package, along with the updated Xerox drivers (2 packages for two different models), and the Python script to re-add the mapped printers after installing the new drivers.

I found through testing that when the Fiery Uninstaller runs, it removes any printers that were using the drivers. So you have to re-add the printers. Rather than try to capture the printers from the system, I chose to make a call back to the JSS via the API to get the mapped printers for the machine. Using the list of printers, I cycle through to see if any of them match my Fiery printers (hard coded in the Python script). The Python script then calls policies in the JSS by ID # to re-install the printers. I utilize scripts in my JSS to add printers, using lpadmin calls to do so.

In my limited testing, this works perfectly. I am releasing to a larger test group next week.

The Python script can be found on my GitHub here: Re-Add Fiery Printers, and it is below:

#!/usr/bin/env python
'''
Date: 17 Jun 2016
Author: Steve Wood (swood@integer.com)
Purpose: Use the JSS API to re-add Fiery printers after updating the Fiery drivers

Be certain to change the API user name and password, along with the JSS URL.

Also, change the policy ID #s for the printer add scripts.

This is run as an After script to removing the Fiery drivers and then adding the new ones.
You need to have JSS Policies to add the printers back without re-installing the drivers during the policy run.

Just add more "elif" statements for the printers you have.
'''

import urllib
import subprocess
import os.path
import xml.etree.ElementTree as ET

# add your api user and password, and change the jss address
jssAPIuser = 'apiuser'
jssAPIpass = 'apipass'
jssURL = 'https://' + jssAPIuser + ':' + jssAPIpass + 
    '@your.jss.com:8443'

name = list()

# determine the path to the JAMF binary
def jamf_check():
    if os.path.exists('/usr/sbin/jamf'):
        jamfbin = '/usr/sbin/jamf'
    elif os.path.exists('/usr/local/bin/jamf'):
        jamfbin = '/usr/local/bin/jamf'
    return jamfbin


serial = subprocess.Popen("system_profiler SPHardwareDataType |grep -v tray | awk '/Serial/ {print $4}'", shell=True, stdout=subprocess.PIPE).communicate()[0].strip()
jamfbinary = jamf_check()
url = jssURL + '/JSSResource/computers/serialnumber/' + serial + '/subset/Hardware'
uh = urllib.urlopen(url)
data = uh.read()
tree = ET.fromstring(data)
# use XPath syntax to locate the printers mapped to the computer
for printer in tree.findall("./hardware/mapped_printers/printer"):
    #load the names into a list for later use
    name.append(printer.find('name').text)
# iterate through the list of printer names and call the appropriate jamf policy to add the printer
for item in name:
    if item == "PrinterName1":
        # run the associated policy to install the printer
        addCopyThat = subprocess.call(jamfbinary + " policy -id #", shell=True)
    elif item == "PrinterName2":
        # run the associated policy to install the printer
        addCopyThat = subprocess.call(jamfbinary + " policy -id #", shell=True)

There probably is a cleaner way to cycle through the printers, but this is how I chose to do it. And I wrote this in Python because the XML parsing tools are easier to use, and it was a way to continue learning Python.

If anyone has any questions, please fire away.

This is a bit of an old bump, but I wanted to post that I've successfully used the "Generic FD50" packaging recipe with the FD51 drivers - the package layout is exactly the same. The resultant packages install as expected both with a user logged in and at the login window. Thanks again foigus for writing those!

I published a blog post about the latest state of the Fiery AutoPkg recipes.

https://foigus.wordpress.com/2017/04/07/trial-by-fiery/

Bumping this because current EFI drivers are still having issues with Mojave. Your users will experience slow printing. It works, but it can take 30-60seconds just to pull up print windows and get through the options, and hit print.