Raising this to track the discussion on samba-technical regarding cupsaddsmb removal from upstream CUPS and proposed inclusion in Samba.... On Wed, Jan 09, 2019 at 01:57:42AM +0100, David Disseldorp via samba-technical wrote: > Hi All, > > I was recently directed to look at some upstream CUPS changes which > impact Samba's printer server functionality: cupsaddsmb has been dropped > via > https://github.com/apple/cups/commit/f1def5b85f51120f5dc1eb21e1f38860ef41be9c > > Given that it's only just gone in, I wouldn't expect it to reach distros > for some time, but I think it's worth discussing how/whether we should > react. > AFAICT cupsaddsmb walks the cupsGetDests2() printer list and performs > PPD file creation, driver upload (using smbclient) and registration > (via rpcclient adddriver). > IIRC, this functionality is similar to what's performed by Window's > native Add Printer Wizard. If cupsaddsmb is heavily used in Samba Print > Server deployments, then perhaps we should look at merging it into the > Samba codebase (it's Apache 2.0 licensed). > Any thoughts? Here's the reasoning from the issue tracker: ------------------------------------------------ https://github.com/apple/cups/issues/5449 @frazhome Judging from the number of emails we get about cupsaddsmb not working or problems with Samba, I don't think that everything is working as well for people in general. Since neither CUPS nor macOS comes bundled with Samba, the right place for this kind of program is in cups-filters (which is used on all Linux distributions) or in Samba (which covers all Linux/UNIX platforms). Also, Windows 10 has built-in support for IPP Everywhere printing now - those clients can print directly and more reliably without Samba. ------------------------------------------------ Looks like we should pick this up and merge into Samba. Jeremy.
There was also a follow-up change via: https://github.com/apple/cups/commit/6648f8c125a435c68d392013d68afb627a0e4a4e
I've taken a closer look at the cupsAdminCreateWindowsPPD() and cupsAdminExportSamba() functionality in cupsaddsmb. Attempting to briefly summarise what it's capable of: 1) generate PPD metadata for the Samba exported printer based on the CUPS PPD for the existing printer - This process appears to require intricate knowledge of the PPD format + JCL entries are stripped and replaced + some CUPS printer attributes are appended in a "OpenGroup: CUPS/CUPS Options" section of the new PPD - One thing I don't understand is why the existing CUPS PPD can't be used here. Perhaps this is to cater to both Windows and CUPS postscript dlls? 2) place generated PPD and postscript driver dlls in the driver download area (Samba's print$ share) - CUPS 32-bit, Windows 2K, Adobe Windows 9X and Windows+CUPS 64-bit postscript drivers can be placed 3) perform DCE/RPC calls to register the printer driver and associate it with the printer share. If I understand correctly, the functionality in (2) and (3) can also be performed via the Windows Print Management UI. Alternatively a simple smbclient / rpcclient wrapper shell script could be provided. The functionality for (1) is less easily replaced. If it's really needed (i.e. we can't just use the cupsGetPPD3() data), then I think my preference would be to add cupsAdminCreateWindowsPPD() back to upstream CUPS and call it via a simple standalone binary. It's then up to the user to provide the generated PPD during subsequent driver upload.
(In reply to David Disseldorp from comment #2) > I've taken a closer look at the cupsAdminCreateWindowsPPD() and > cupsAdminExportSamba() functionality in cupsaddsmb. > Attempting to briefly summarise what it's capable of: > 1) generate PPD metadata for the Samba exported printer based on the > CUPS PPD for the existing printer > - This process appears to require intricate knowledge of the PPD > format > + JCL entries are stripped and replaced > + some CUPS printer attributes are appended in a > "OpenGroup: CUPS/CUPS Options" section of the new PPD > - One thing I don't understand is why the existing CUPS PPD can't be > used here. Perhaps this is to cater to both Windows and CUPS > postscript dlls? I'm also curious how this all interacts with signed user-mode drivers - is the PPD also covered by any signature? What kind of support to we currently have for signed drivers? @Andreas: IIRC, you've looked into driver signing in the past. It'd be great if you could comment.