[cups] CUPS + VPN

Alex Korobkin korobkin+cups at gmail.com
Thu Oct 15 10:41:40 PDT 2015


Michael,

wrt PS: What does the adoption of this newer API entail exactly? Is there a
way to use a central print server for multiple Linux clients similar to
client.conf approach?


On Thu, Oct 15, 2015 at 8:24 AM, Michael Sweet <msweet at apple.com> wrote:

> Lisa,
>
> > On Oct 14, 2015, at 2:32 PM, Lisa Marie Maginnis <lisam at fsf.org> wrote:
> >
> > Hello,
> >
> > We are having issues with CUPS and shared printers over our VPN. The
> issue is that if a user is not on the VPN when CUPS starts, they are unable
> to see printers until they restart CUPS by hand. It crossed my mind to add
> a restart of CUPS to the scripts that run when a client connects to the
> VPN, but I wanted to ask around to see if there is a CUPS only solution to
> try first.
> >
> > Clients are configured by adding the following line to
> /etc/cups/client.conf:
> > ServerName printserver.example.com
> >
> > Is there a way to increase the polling time of the remote cups server?
> Or maybe a better way to configure CUPS clients for using a remote cups
> server that might not be there when the system first boots?
>
> The client.conf setting is checked on the startup of every program that
> uses the CUPS API (actually for every thread in every program ...)  And all
> of the standard CUPS programs and APIs will retry both the address lookup
> and connection to the server.
>
> So theoretically an application that is started before the VPN is up
> *might* not be able to print, but generally speaking that should never
> happen unless the program is written explicitly to not retry such issues.
>
> So without more information it is difficult to help you here - what
> software isn't working? Where are the printers not showing up?
>
> ........
>
> PS: The ServerName directive in client.conf is officially deprecated for
> all platforms and explicitly not supported on OS X - sandboxing, AppArmor,
> SELinux, etc. can all interfere with an application's ability to access
> remote servers, so its continued use is not recommended.  Other CUPS APIs
> (cupsEnumDests in particular) can be used by applications to get a dynamic
> view of available shared printers (from multiple servers); adoption of the
> newer (4 years old now) APIs has been slow, however... :/
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
> _______________________________________________
> cups mailing list
> cups at cups.org
> https://www.cups.org/mailman/listinfo/cups
>



-- 
-Alex



More information about the cups mailing list