Re: cups (sharing network printer)
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.
Reply to: