Re: Recommended way to manually add an undiscovered IPP printer in CUPS 3.x
Michael Sweet <[email protected]> Sat, 1 Aug 2026 19:03:31 -0400
| Newsgroups | dev.linux.lists.printing-architecture |
|---|---|
| Message-ID | <[email protected]> |
Till, > On Aug 1, 2026, at 5:21=E2=80=AFPM, Till Kamppeter = <[email protected]> wrote: >=20 > On 8/1/26 22:41, Michael Sweet wrote: >> Till, >>> On Aug 1, 2026, at 3:50=E2=80=AFPM, Till Kamppeter = <[email protected]> wrote: >>> ... >>> But how to proceed under CUPS 3.x? >> CUPS 3.x uses PAPPL 2.x which has different operations and attribute = names (as part of standardization in the PWG) but otherwise works = similarly. >> The Create-Printer operation accepts the "smi55357-device-uri (uri)" = and "smi55357-driver (keyword)" operation attributes to provide the = device URI and model/driver name, and cupslocald (from the cups-local = project) supports the following driver names: >> - 'everywhere': IPP Everywhere/AirPrint/Mopria/Wi-Fi Direct printer >> - 'pcl': Generic B&W PCL printer >> - 'pcl_duplex': Generic B&W PCL printer with 2-sided printing support >> - 'ps': Generic B&W PostScript printer >> - 'ps_duplex': Generic B&W PostScript printer with 2-sided printing = support >> - 'ps_color': Generic Color PostScript printer >> - 'ps_color_duplex': Generic Color PostScript printer with 2-sided = printing support >> The PCL and PostScript drivers are extremely limited and are just = there to support legacy Samba printing basic support for local = (typically enterprise) laser printers. >=20 > So when I send a Create-Printer request to a CUPS 3.x daemon (both = local and sharing) an entry in a profile (~/.cups/profiles/ or = /etc/cups/profiles/*, latter only for sharing server) is created? *No*. Profiles are ONLY for the local server, and they are manually created by = the user/admin. Profiles in /etc/cups/profiles (or similar "world" = directories apply to all users while profiles under $HOME apply to that = user. There is one cupslocald running per logged-in user on a system. The goal is that cupslocald will only list those printers/servers that = it can connect to, and will periodically update the list of available = printers as conditions change (switching networks, printers/servers = coming and going, etc.) >>> If I have only the local server, it is stateless, it only uses = temporary queues. >> It is not stateless. It just doesn't have permanent queues and = doesn't share local queues with other systems. >>> How do I, in case of not using mDNS/DNS-SD, tell my = discoveries/manual IP selections to the local server so that it sticks = with them? Or am I REQUIRED to use mDNS/DNS-SD when I have a system with = only the local server of CUPS 3.x as print environment? >> We have been talking about this ("printer profiles") for a very long = time: >> https://github.com/OpenPrinting/cups-local/issues/2 >=20 > OK, so they also work with the local server. They *only* work with the local server. The sharing server does NOT use = profiles at all. > So this means that our printer setup tool which Abdelrahman is working = on creates entries in the profile when manually adding print = destinations, either if mDNS/DNS-SD is not used or when the printer is = outside the local network (VLAN or so)? No, he should focus on adding printers to the sharing server. Profiles = are not intended as things that are created/edited with special tools, = they are simple text files that replace DNS-SD discovery of IPP = printers/servers. > OK, so we need to settle on a format for this file so that Abdelrahman = can implement that. The proposed format is in the issue. >>> Or do I have to use the sharing server when I just want to print = locally but not use mDNS/DNS-SD? Does the sharing server has a config = file for holding such printers? >> The sharing server is more of a traditional "all queues are = permanent" service and saves the queue state/configuration across runs. >>=20 >=20 > Does the sharing server not get its queues the same way as the local = one, both by discovering printers via mDNS/DNS-SD AND including = destinations by entries in the profile (which can be system-wide now)? = And it adds rules for how to share these printers also in the profile? No, the sharing server is more akin to a regular printer application - = yes, printers get discovered via standard means (DNS-SD, SNMP, USB, = etc.) and you add the queues (discovered or manual entry) that you want = to share. Profiles are NOT used to configure the sharing server, = although you might use a profile on a client system to point cupslocald = at a sharing server. ________________________ Michael Sweet