On Mon 09 May 2016 at 20:01:28 -0500, David Wright wrote: > On Mon 09 May 2016 at 23:22:44 (+0100), Brian wrote: > > On Mon 09 May 2016 at 23:45:18 +0200, deloptes wrote: > > > Pol Hallen wrote: > > > >> Unless I am misunderstanding the question, > > > > I need to print using 192.168.1.10 (server) not directly by network > > > > printer > > > > In /etc/cups/client.conf > > > > > > set the ServerName > > > > > > ServerName 192.168.1.10 > > > > > > try lpstat -a > > > > > > $ lpstat -a > > > HP_LaserJet_5L accepting requests since Wed 04 May 2016 10:31:02 PM CEST > > > > The OP talks about *"clients"*. Would your advice stay the same if there > > was a 1000 of them? > > Your first and last comments were too terse for me to understand. I > think you might be implying here that the solution doesn't scale well.
The advice is fine as far as it goes and should work. It is a technique I use myself on a machine or two when I do not want a local cupsd or prefer not to have avahi-daemon on a print server with limited resources. Scaling is an issue and I do not know how one efficiently adopts to adding large number of clients or a change in the server's IP. The assumption is also being made that the server is online and available. Visitors on a network would have to be informed of the IP; this may be a hassle for them, particularly if they are unfamiliar with the device they are using or not comfortable with altering its settings. Visiting Big Company Boss would likely not be amused having to take a lesson in network configuration just to print. The reality is that mobile devices (laptops, phones etc) are probably more numerous than desktops. Linking them with a single infrastructure and pointing to a single server negates the advantages they have for printing. Devices using AirPrint should immediately be at home with Debian CUPS and really have no need of a client.conf. Also, if the network is down or there are network errors or the server is not available, the application may not retry and printing will be prevented. A user closing the lid on a laptop before an application has finished submitting a job is to be avoided; the job isn't going anywhere. > Can you explain the difference between the purported solution above > and your earlier "Set up the clients to discover the server. Print.", > ie how "Set up"? With a local cupsd a job can be queued and recovery from temporary issues is much easier. The local cupsd can coordinate with the OS to keep the system (and network stack) up long enough to send the job remotely. The client software can adapt to the network/location more easily (for example, when roaming). What is displayed in print dialogues of applications is what is actually online, not what may have disappeared a week ago and which you now have to re-locate. The "Set up" on a Jessie client consists of apt-get install cups The default for the installation is for print queues on a remote server to be offered by applications or displayed by 'lpstat -a'. Immediate printing capability, in other words.