Re: Recommended way to manually add an undiscovered IPP printer in CUPS 3.x

On 8/2/26 11:18, AbdElRahman Khalifa wrote:
> Thank you for the explanations. I think I now understand the
> separation between printer profiles, the local server, and the sharing
> server.
> 
> My current understanding is the following:
> 
> 1. cupsEnumDests() should be the source of truth for the destinations
> displayed on the main Printers page.
> It can return automatically discovered IPP destinations, remote CUPS
> queues, Printer Application destinations, and eventually destinations
> supplied through profiles.
> Therefore, a destination must still be displayed even when I cannot
> find a corresponding local DNS-SD advertisement.
> 

Yes, especially as there can be destinations due to entries in the profile, 
either because DNS-SD is off or destination outside the local network are 
defined. You do not need to parse the profile or investigate any reasons, if you 
are using cupsEnumDests() the right thing will happen and you will see the 
correct list of available destinations. And as print dialogs are also supposed 
to use cupsEnumDests(), you see exactly the printers which you see in the print 
dialogs.

> 2. DNS-SD should be an enrichment and grouping source, rather than the
> authoritative destination list.
> I currently use Avahi to obtain information such as the service
> instance, hostname, port, resource path, TXT UUID, and the
> relationship between _ipp._tcp and _ipps._tcp advertisements.
> I will correlate this information with the destinations returned by
> cupsEnumDests() and use it for physical-device grouping. Where
> possible.
> 

Yes, DNS-SD checking by your software is only to get extra info, like for 
grouping. The authoritative list of available destinations comes from 
cupsEnumDests().

> 3,. COSMIC Printers should not create or edit printer profile files.
> 

Generally, under Linux configuration info is stored in text files and GUI tools 
to do configuration save the settings in that text files. So the GUI tools are 
frontends to easily "edit" these files and the user sees the realm of 
controlling the settings by GUI, as this is much more intuitive.

So principally one can make a GUI for managing a profile for the local server of 
CUPS.

For correctly configured Linux distros this should not be that necessary, as for 
end users at home or in small offices (SOHO setting), where we do not have a 
system administrator, DNS-SD should always be turned on, and so all print 
destinations get automatically available, without need to edit the profile. An 
end-user distro coming with DNS-SD off is not a good end-user distro.

In enterprise settings with a lot of machines and networks there are always 
system administrators who have no problems to hand-edit config files. And to 
manage the vast amount of network resources (also printers) they decide on how 
to do so, and when turning DNS-SD off or sub-dividing the local network into 
many smaller ones, they enter the needed references to printers and 
printer-providing external sub-nets, and also filters in the CUPS profiles of 
the desktop machines, so that cupsEnumDests() called by a user's print dialog or 
printer setup tool shows exactly the needed printers.

> 4. Profiles belong to the local-server/libcups discovery mechanism.
> When libcups supports them, profile-defined destinations should appear
> naturally through cupsEnumDests().

Yes, exactly this.

> Queues owned by the sharing server are a separate concept.
> I should query the sharing server using its IPP System Service
> operations, such as Get-Printers, when I specifically need to list or
> administer the queues owned by that server. I should not infer that
> every destination returned by cupsEnumDests() is a configured
> sharing-server queue.
>

A sharing server is a Printer Application and so it is like an IPP network 
printer. A Printer Application is not necessarily an application providing the 
driver for a non-driverless legacy printer, but a Printer Application is any 
kind of software implementation of a driverless IPP printer. Even ipp-usb is a 
Printer Application. On the sharing server there are print queues defined. These 
print queues are IPP print destinations for clients, and they pass on the jobs 
to other IPP print destinations. They are highly configurable, for example to 
allow only certain clients to see/use the print queue, to do page accounting, to 
restrict the use to certain users, to require authentication, ... and the 
network where the print queues are visible to clients and where the destination 
printer is do not need to be actually the same.

In most SOHO settings you do not need a sharing server as network printers are 
sharing themselves to your whole local network. Also Printer Applications to 
provide the driver for a legacy printer can be set to share the printer to the 
local network instead of only the local machine. The same is valid even for ipp-usb.

cupsEnumDests() is showing any IPP print destination, regardless of whether it 
is a network printer, a destination from a sharing server, an IPP-over-USB 
printer, a legacy printer set up with a Printer Application.

With IPP System Service you handle any IPP server. Get-Printers gives you all 
IPP destinations which this server provides. Works on a sharing server (shows 
the queues created on it), on a network multi-function printer (shows the print 
destination and depending on the device also the fax out destination), ... IPP 
System Service can especially also help you to group the print destinations 
correctly, especially if DNS-SD is turned off.

> 5. A normal driverless destination returned by cupsEnumDests() is
> already usable and does not require an Add operation.

Yes, that's it. The printer setup tool should provide buttons for opening the 
web admin interface and for default option settings (GUI for lpoptions).

> A queue on the
> sharing server should only be created if the user explicitly requests
> server-side sharing, relaying, accounting, access control, or similar
> policies, for example, when the user opens the Add Printer dialog and
> selects that printer.
> 

Yes, you use the sharing server by installing it and creating queues on it if 
you have special needs, which are not served by the network printers themselves.

You can have for example a sharing server in your local network which has a 
queue set up pointing to a printer in a VLAN, which your local network's DNS-SD 
does not see, but your DNS-SD sees your sharing server and so the printer gets 
available for everybody.

Or you can enforce page accounting by configuring the printer (via its web 
interface, do not forget to password-protect the web interface) to only accept 
jobs from the machine running your sharing server. On your sharing server create 
a queue pointing to your printer and having page accounting. Now users see only 
the queues of your sharing server and not the printer itself, forcing their jobs 
through the page accounting.

With DNS-SD in your local network turned off, you have to point to your sharing 
server in your profile, as you would also do for a regular network printer.

> 6. For an undiscovered driverless printer entered manually via IP
> address or hostname, printer setup tool should probe it using
> Get-Printer-Attributes and then create a queue for it on the sharing
> server.

Here the sharing server is not necessarily needed. To just overcome the fact 
that DNS-SD is not available or the printer is in a separate local network the 
sharing server is often overkill and adding the printer's URI to the profile 
does the trick already.

    Till