3 Replies Latest reply on Oct 15, 2015 9:11 AM by Damon Lynch

    Popup & OS X 10.11 El Capitan

    VDE Reg Georgia State University Wayfarer

      Hello everyone,


      By now several of you have probably noticed that the current version of the Popup (which is 9.0.5 at least as of this writing) does not successfully install on OS X 10.11 El Capitan.  Looking around a bit, I saw this article on Clemson University's web site:  ERROR: Paw Prints Fails to Install on Mac OS X 10.11 (El Capitan)


      As Clemson notes, the problem is with the installation of the Popup on OS X 10.11.  It appears that the software otherwise works if it is installed before upgrading to OS X 10.11.  This prompted me to do a little looking around:


      The Pharos Popup is distributed in an Apple package, and you can extract its contents to an artificial root directory to see exactly what it installs.  For example:


      # Create a package root into which we'll expand the package's payload:

      mkdir /tmp/pkg-root

      # Expand the Popup package:

      pkgutil --expand Popup.pkg /tmp/popup-expanded

      # Move the package's payload into the package root:

      mv /tmp/popup-expanded/popupclient.pkg/Payload /tmp/pkg-root/payload.pax.gz

      # Expand the payload:

      cd /tmp/pkg-root

      gunzip payload.pax.gz

      sudo pax -r -p e -f payload.pax

      sudo rm payload.pax


      Now you have the expanded contents of the package for your inspection.  Right away, it's obvious why the installation fails on OS X 10.11:  Among other things, a file called pharos.convs is written to /usr/share/cups/mime.  In OS X 10.11, System Integrity Protection prevents non-Apple software from writing to /usr, with a few exceptions (like /usr/local and /usr/libexec/cups).  It appears that nothing in /usr/share is marked as writable by any actor besides Apple software.  More information about System Integrity Protection is available online:  Apple has a PDF guide and in its Developer documentation.


      I should note that, even though /usr/libexec/cups is not listed as writable in the Apple documentation, it actually is writable.  Inspect the rootless.conf file in /System/Library/Sandbox to see for yourself:

      cat /System/Library/Sandbox/rootless.conf | grep usr


      * /usr/libexec/cups

      * /usr/local

      * /usr/share/man

      The file's syntax indicates that /usr is protected, but that /usr/libexec/cups, /usr/local, and /usr/share/man (and their contents) are not protected by SIP.  Notice that /usr/share/cups is not whitelisted.


      Therefore, whenever you try to install the Popup in OS X 10.11, the Installer reports a failure:  /usr/share/cups/mime/pharos.convs couldn't be written.  It looks like the pharos.convs file implements a CUPS command to call the abort_popup filter.  Per current CUPS documentation, it looks like the current guidance is to implement custom filters (including cupsCommand filters) in the PPD directly.  I realize that involves more work.  Inspection of the abort_popup filter reveals it's a shell script responsible for canceling jobs sent through the popup:// device URI.  Perhaps this canceling functionality would be better implemented in the backend itself instead of in a dummy filter.  I've written CUPS filters and backends that performed similar tasks in the past, but I don't have the complete picture as Pharos does.


      While we're talking about the Apple package for the Pharos Popup, I should note that the package version is set to 0 (zero) instead of 9.0.5.  Again, check this yourself by running the following command on a system that has the current Popup installed:

      pkgutil --pkg-info com.pharos.pkg.popup | grep version

      version: 0


      Not to sound too picky, but this should be fixed by Pharos in its next build of the package.  It's very easy to fix, too.  When building the package with pkgbuild, specify the package version with the --version argument.


      --Gerrit DeWitt

      Mac Engineering

      Georgia State University

        • Re: Popup & OS X 10.11 El Capitan
          Jim Gilliver Pioneer

          Hi Gerritt,


          Thanks for the pointer on the package version.  This has been corrected for the next release.


          As far as the other information on pharos.convs, this has been discussed in another thread, here: El Capitan OSX .  To recap, the abort_popup filter was a workaround for some badly-behaved third-party filters that did not honour the backend's cancellation of the job and held up the queue while they timed out (presumably on network requests).  The backend itself does cancel cupsCommand jobs, but inserting the priority 0 filter helped a subset of users.


          Could you tell me what build number of OS X you are using when you see the failed installer?  On build 15A284, pharos.convs is listed in an exclusion list for compatibility (under /System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths), and no longer seems to block the install.  A commenter in the other thread stated that 15A282b failed, but there was at least one update to the beta release that also had this change.  Unfortunately, I did not note the build number on that one, as the official release arrived shortly afterwards and testing against that was more important.


          We will be releasing an updated Popup client soon, but as far as we can see, the current client installs without issue on the final public release of El Capitan.  If there are installs of 15A284 around that don't have the compatibility entry, then I am not sure what to make of that, but we need to deal with it.  If there are people using beta versions under the impression that it's the same as the final release, then we may have to add a note to the documentation to encourage them to upgrade.





            • Re: Popup & OS X 10.11 El Capitan
              VDE Reg Georgia State University Wayfarer

              Hi Jim,


              Thank you for your quick reply.  Glad to hear you guys caught the package version error, too.


              I've had the Pharos Popup 9.0.5 installation both fail and succeed on OS X 10.11 build 15A284.  However, I believe I know why:


              On a freshly imaged system, installation fails via the command line and a similar warning is presented by the Installer.  Inspection of the paths file in Compatibility.bundle reveals no entry for /usr/share/cups/mime/pharos.convs.


              So it occurred to me that Apple probably doesn't bake-in the contents of the Compatibility bundle.  It probably gets them dynamically in the same way that it gets Gatekeeper and quarantine data (formerly XProtect).  So I forced a check-in by running:


              sudo softwareupdate --background-critical


              And, sure enough, a few minutes later, the system had updated the paths file to include an entry for pharos.convs.  Installation was successful after that.


              Under normal circumstances, any Mac left running for a few hours with Internet access should have updated its "background critical" data as long as the "install system data files and security updates" box is checked in the App Store pane of System Preferences.  (It is by default.)


              With that in mind, it might be helpful to add this to your documentation:  Customers who encounter problems installing the Popup client on El Capitan need to enable the "install system data files and security updates" option in the App Store pane of System Preferences if they disabled it.  Then, if they don't want to wait for the updates, they should force the system to check in by running softwareupdate as I did above.


              --Gerrit DeWitt

              Mac Engineering

              Georgia State University

              3 of 3 people found this helpful