SUMMARY: Printers install incorrectly with the iPrint 5.74 client to OS X 10.9.x workstations from an iPrint Manager on Netware 6.5sp8 with the iPrint .8f patch. Their URI is set to file:///dev/null , which makes them appear to operate correctly but no jobs ever reach the printer.
LONGER VERSION:
This may be a function of Netware. I have a server running Netware 6.5 sp8 with the iPrint 8f patch and workstations with latest OS X iprint client (5.74). OS X is at 10.9.1. When I install a printer from this server, jobs submitted appear to print correctly but never actually come out of the printer. The iPrint Management web interface shows that no new jobs have been submitted to the printer.
A packet trace shows no traffic from the workstation to the printer.
Looking deeper, I see that the OS X iPrint client does NOT list the printer as an iPrint printer in its GUI interface. However, OS X DOES show a printer of the same name as existing. During installation, the iPrint client does give a popup indicating that the printer was installed correctly. When iPrint's trace.txt is examined, the installation of the printer is logged, but not the submission of print jobs to it. The errors.txt file indicates that at least one printer has the URI file:///dev/null but the name of the printer is not indicated.
When the OS X CUPS interface is examined directly, I find that the printer that was just installed via iPrint does indeed have its URI set to file:///dev/null .
Machines with OS X 10.8 and below print correctly and are set to the proper ipp URI instead of file:///dev/null. Printers installed from an OES manager are fine even on OS X 10.9. Also, printers that do have the URI problem get otherwise correct information during installation -- they receive correct name, location, and driver.
The release notes for the 8f iPrint patch for Netware explicitly mention 10.8 compatibility but not 10.9. I see elsewhere that the 8f patch may have been created in response to an Apache hog created by OS X 10.9, so that release is within the calculations of the Dev team (and was already released when the 8f patch appeared). However, it does appear that there is a 10.9-related bug even in the 5.74 client.
Has anyone else seen this behavior? Is anyone aware of a work-around?
If anyone is interested in investigating, a can provide lots of logs.
I have also submitted a bug on this issue via the regular bug reporting page.
LONGER VERSION:
This may be a function of Netware. I have a server running Netware 6.5 sp8 with the iPrint 8f patch and workstations with latest OS X iprint client (5.74). OS X is at 10.9.1. When I install a printer from this server, jobs submitted appear to print correctly but never actually come out of the printer. The iPrint Management web interface shows that no new jobs have been submitted to the printer.
A packet trace shows no traffic from the workstation to the printer.
Looking deeper, I see that the OS X iPrint client does NOT list the printer as an iPrint printer in its GUI interface. However, OS X DOES show a printer of the same name as existing. During installation, the iPrint client does give a popup indicating that the printer was installed correctly. When iPrint's trace.txt is examined, the installation of the printer is logged, but not the submission of print jobs to it. The errors.txt file indicates that at least one printer has the URI file:///dev/null but the name of the printer is not indicated.
When the OS X CUPS interface is examined directly, I find that the printer that was just installed via iPrint does indeed have its URI set to file:///dev/null .
Machines with OS X 10.8 and below print correctly and are set to the proper ipp URI instead of file:///dev/null. Printers installed from an OES manager are fine even on OS X 10.9. Also, printers that do have the URI problem get otherwise correct information during installation -- they receive correct name, location, and driver.
The release notes for the 8f iPrint patch for Netware explicitly mention 10.8 compatibility but not 10.9. I see elsewhere that the 8f patch may have been created in response to an Apache hog created by OS X 10.9, so that release is within the calculations of the Dev team (and was already released when the 8f patch appeared). However, it does appear that there is a 10.9-related bug even in the 5.74 client.
Has anyone else seen this behavior? Is anyone aware of a work-around?
If anyone is interested in investigating, a can provide lots of logs.
I have also submitted a bug on this issue via the regular bug reporting page.