[FreeNX-kNX] how printing works

[Antoine Martin]

ChrisB wrote:
>>> It uses an ssh tunnel which redirects a port on the FreeNX server back 
> to 
>>> the workstation, so you can then connect to a port on the WS :631 or 
> :445, 
>>> via the redirected port.
>> That's the easy part... with ssh -R
> 
> Hmmmm
> 
>> But how do you tell the client applications running on the server to
>> talk to this particular cups server?
> 
> ????
> 
> You tell KDE etc. which cupsd to talk to not the client applications . . .
Sure, that's what I meant, Gnome/KDE/other.
I still don't know *how* to do that!
Is there a freedesktop.org specification on this that I have missed?
Is it via an environment variable before you launch the app? (I've tried
CUPS_SERVER - no effect).

Let's use a simple example: say I just launch "gedit" and nothing else
in an Xvnc session (no nx, no desktop, no dbus,..), how do I tell it to
use my newly started cups server?? (say: 127.0.0.1:10631)

^ This is the crucial bit that I am missing.

(I realize that it is not a freeNX question, rather a "desktop"
environment question, apologies to the list... It's just that you guys
seem to know about this stuff.)

>> In a hosted environment there may be dozens of these cups servers
>> running (one for each session)
> 
> Yup, one for each user printing through the tunnel.
> 
>> That's the bit I am missing...
>>
>> If I only deal with the somewhat easier case of nix workstations with
>> cupsd running on the client, why can't I just get the server to point
>> the apps to talk directly to that remote cups server? (via ssh -R or
>> plain tcp if on a secure LAN)
> 
> 
> It's not an easier case if you have windows workstations not running 
> cupsd, it's impossible. Given the large windows user base, it would be a 
> fatal reduction in user base to not support them.
That's not my intention! Just an example.
I would just like to avoid the complication of having an extra cups
server if it is not strictly necessary. At the very least for testing.

If the client has cups: point the server (the bit above I still don't
know how to do) directly to the tunnelled cups port. (or even direct to
a cups port if on a LAN - ignoring access rights issues for now).
If it does not (ie: Windows) then use a local cups server and point to
that. (and let it forward via smbspool/ppd)

^^ It's the "point to" part that I want to know how to do.

> Most people want to spool to a queue on a local disk, then background the 
> network transfer.
If the benefits of using a local cups server outweigh the costs, then I
would add that extra step. In a local LAN use case (even just 100Mbit)
most jobs would be sent to the cupsd on the client within seconds (and
it can deal with spooling/queueing)

> Cups deals with printer drivers, access rights etc locally.
> In the olden days it was all lp to a remote IP, but then you had to 
> manually set up printer options, trays paper size etc.
> 
> 
>> And if so... how?
>> (same question as above really)
>>
> 
> Try it !!
Duh! (I wouldn't be asking if I hadn't!)

The bit that I am missing is how you tell the applications which cups
server to talk to. (host:port or preferably a local socket)
Sorry if I didn't make it clear in my original question.

The rest of the discussion is very interesting (and will be very useful
to me), but not a show-stopper for what I am trying to achieve at the
moment.

>>>> Can anyone point me to some documentation?
>>>
>>> No ! Did you not try Google.
>> Yes.
>> I never bother dozens of people on mailing lists without spending a fair
>> amount of time doing my homework.
>> Thanks for your very detailed response though!
> 
> That was not a detailed response !!!
> 
> You are now asking cups questions, for which there is slightly too much 
> documentation !!
Yup. IMO too much is a hell of a lot better than too little!

>>> For a NIX workstation, you need to set up an ipp printer (typically) 
> in 
>>> cups on the server, pointing via the re-directed port to the 
> workstation.
>> I would like to avoid this part (as mentioned above).
> 
> Why, do you know anything easier ??
As explained above. (point to the cupsd server on the client directly,
or via a tunnel without having a cupsd running on the server)

>> If not, can this be done easily/reliably from a script? (and without
> 
> Yup.
>
>> generating a whole new cupsd.conf if possible)
> 
> Nope.
Hah.
Not too bad I guess, the config would be minimal with just:
Listen /home/user/applications_please_use_this.socket
And printers.conf would just point to the client's ipp/smbspool.


> One of the reasons for a userland cupsd is that the printing is only set 
> up after the user has successfully logged in and their session has 
> started.
> 
> If you didn't mind having all your users being printer administrators then 
> you could just use the system cupds ( which of course you also use if you 
> are NOT setting up remote printing ), because users could then set up and 
> delete their own printers ( and everyone else's, and redirect everyone 
> elses printing ) which in the real world, would not of course be 
> considered rational behavior.
Haha, that could be amusing... except for the local sysadmin.
But not very productive!

>>> For a windows WS you need an smb printer set up in cups on the server, 
> 
>>> which uses smbspool to connect via the redirected port to the print 
> share 
>>> on the workstation after the .ppd file has kicked off PS to Windows 
>>> conversion.
>> Sigh.
> 
> It ( nearly ) works. What's the problem ??
In this case you need the .ppd file, which will have to be a manual step
(as you pointed out). It's just a shame that's all.
I wished Windows could just talk ipp... (or ps or whatever)

Thanks for your time!
Antoine

> 
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ________________________________________________________________
>      Were you helped on this list with your FreeNX problem?
>     Then please write up the solution in the FreeNX Wiki/FAQ:
> 
> http://openfacts2.berlios.de/wikien/index.php/BerliosProject:FreeNX_-_FAQ
>   
>          Don't forget to check the NX Knowledge Base:
>                  http://www.nomachine.com/kb/ 
> 
> ________________________________________________________________
>        FreeNX-kNX mailing list --- FreeNX-kNX at kde.org
>       https://mail.kde.org/mailman/listinfo/freenx-knx
> ________________________________________________________________