Has anyone seen El Capitan in their print environment and does the current Pharos Packages work with it?
We have gotten a few requests for it, as out current packages do not seem to work on 10.11. Our students were running the beta for a month and now that the GM was released, I am sure more will.
jorge a. najera-ordonez indicated to me if Pharos is installed prior to the OS X upgrade, it works fine. Installing from scratch afterward results in it not working unless the popups.app is manually clicked on. His suspicion is that it dealt with the difference between universal launch agents and user specific launch agents. I'm sure Pharos is looking into it, but waiting for Apple to lock stuff in. Things have changed between beta and official release in the past.
With the release of the GM 1 preview the other day we've began our initial testing. What we can say at this point is that the installer package we currently use fails completely with El Capitan. The Pharos Mac Popup client installer also fails. When running the Pharos installer you receive the following notice:
If you click "Install anyway" you get the following:
The error that shows up in the Console is:
System Policy: deny file-write-create /usr/share/cups/mime/pharos.convs
So a bit more research is needed find a solution that works with El Capitan's new security model.
Have a great day,
We are getting the error when trying to install the Mac Popup client in the 10.11 GM release (build 15A282b). Popup clients and queues installed before upgrading to the 10.11 GM continue to function normally.
Progress! Might have found a possible workaround/solution in getting the Popup installer to work with El Capitan.
Of course if the Popup client was already installed before the system was upgraded to 10.11 everything continues to function normally as El Capitan's new System Integrity Protection (SIP) doesn't remove existing binaries from the folders it protects.
Digging in a bit further on the Pharos Popup client installer it places three files into the /usr directory. These are:
Removing only the pharos.convs file and rebuilding the installer allows the Pharos Popup client to successfully install on the 10.11 GM release. SIP doesn't appear to have issues with installers placing files into /usr/libexec/, but has an issue with /usr/share.
Tried building a custom Popup installer that placed the pharos.convs file into /usr/local/share/cups/mime and it successfully installed without issues. Configured a printer queue to use the Popup client and sent a test job to the print server. The submitted print job appears in the Pharos queue, and prints out as expected when released.
The question to ask is does the popup client and/or CUPS actually see/use the pharos.convs file if its relocated to the /usr/local/share/cups/mime directory. From a cursory testing standpoint this appears to work.
Obviously a much more thorough testing needs to be done, but if this works its an easy fix to the El Capitan compatibility issue.
El Capitan is supposed to remove unknown files from protected locations - after you upgrade OS X, you should no longer see the pharos.convs file. Luckily this file is not essential for most users, and /usr/libexec/cups appears to be exempt from SIP protection (/usr/libexec in general is still protected). I suspect this is because a number of print drivers install their own backends in this location.
pharos.convs is only used to prevent a specific problem with certain drivers - some filters would try to contact the device when processing Supply Levels jobs, and hold up the print process. Since Popup printers do not reference the physical printer, the Supply Levels jobs are useless anyway. pharos.convs inserts an additional filter to abort those jobs as soon as possible (only for Popup queues). The popup backend also detects and cancels these jobs, but we found that with a handful of drivers this was not enough to prevent the problem.
Unfortunately, it does not look like CUPS will look in any location other than /usr/share/cups/mime without modifying /etc/cups/cups-files.conf. The problem with changing that file is that it might interfere with Apple's future CUPS upgrades. I am looking for alternative solutions for the problem above. If I can't find one, we may have to put up with the problem on a default install, and provide a workaround for affected users.
I was able to install with SIP disabled (which is not optimal, as each install would require manual touch), then reenable SIP and still print successfully.
Presumably (haven't tested this yet) installed as part of an image (read Fat Golden Master) should work as well, but reimaging a machine to get the Pharos software would be more time consuming, so that isn't an option at all, really.
Confirmations/refutations always welcome.
While using the pre-release version, I would get a warning trying to install the old Popup package, and then a failure message if I continued.
After upgrading just a few days ago to the 10.11.1 beta from the store, the old Popup started installing without a hitch, even placing pharos.convs under /usr/share/cups/mime. I thought this could have been a mistake; perhaps the upgrade accidentally disabled SIP and failed to enable it again.
Last night I finished downloading the final release, set up a fresh install and I still get the same result. I have since found an entry for pharos.convs listed in /System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths. I'm assuming that someone requested that this specific file be exempted, and Apple listened.
Can anyone else confirm or deny that the original Popup client installs correctly under the official El Capitan release?
I did inform my organization's Apple Technical Rep. of a few problem installers, Pharos being one of them. (Pharos, LANDesk, Mozy Pro,..)
I won't take credit though.
I did an automated install on the just released 10.11, and the popup appears to work appropriately (I printed one B/W test page and it displayed the price).
Additional testing will have to wait until later...
We are in the process of testing El Capitan and had no problems with the popups loading correctly or with any existing installations. The only issue we had was a weird behavior with Google Chrome; the printer defaults to A4 as the paper size. After some digging we found an issue with the script we were running to automate the install. The problem was not related to Pharos and as it turns out also occurred with Yosemite, so it wasn't OS specific either.
Just for completeness, the following is from the Pharos Popup 9.0.6 release notes.
Note for users of OS X 10.11 (El Capitan):
Thanks Chris! Once I updated the workstation to the newest version of El Capitan it worked!
Retrieving data ...