[FreeNX-kNX] printing

James james at brutalhugs.com
Tue Jan 24 20:22:04 UTC 2006


Wow.  That's a lot to digest.  Thanks for taking the time to provide so
much detail.  I'll try to use it well. :)

Alastair Johnson wrote:
> I _think_ I covered it all in the 'cups to cups print problem' thread, but 
> it's probably somewhat disjointed. The basic config is as below, though I 
> repeated the client end with a Knoppix 4.0 dvd which has a nomachine 1.4 
> client.
> 
> Client:
> Gentoo i586
> nomachine NX Client 1.5.0-135 from emerge
> HP510 configured in CUPS, verified available to all on this and other subnets 
> without authentication (just for testing to make sure this isn't a source of 
> problems, and within firewall limitations)
> Client configured for unix-kde desktop, ssl encryption of all traffic enabled, 
> CUPS printing on port 631 enabled and HP510 selected
> 
> Server:
> FC3
> http://fedoranews.org/contributors/rick_stout/freenx/freenx-0.4.4-1.fdr.0.noarch.rpm
> http://fedoranews.org/contributors/rick_stout/freenx/nx-1.5.0-4.FC3.1.i386.rpm
> node.conf has ENABLE_KDE_CUPS="1" set
> 
> The way I understand it's supposed to work for cups is this:
> When you configure your NXClient you can select the local printer you wish the 
> session to print to. The client starts a cupsd session as the user, printing 
> to the printer(s) you selected via the main cups daemon on the client. It 
> listens on port 20000 or similar, but requires authentication using the 
> username and a password that looks random, using AuthType Digest. The port is 
> forwarded in the ssh tunnel to port 3000 or similar on the server. The client 
> makes an addprinter request to the server, detailing the printer to add, the 
> username, password and URL, and more. The server also starts a usermode cupsd 
> session listening on or around port 10000, and honors the addprinter request 
> by adding this printer to this cups session. It appears to ignore the 
> username and password however. To complete adding the printer it needs to 
> know which printer driver to use, and uses 'nxclient' on the server end to 
> show a dialog for selecting the printer driver. The server also temporarily 
> changes the kde configuration so that the print manager points to the local 
> usermode cupsd on port 10000 or wherever (it's actually the display port plus 
> 9000, so varies with the number of connected sessions). Printing should then 
> flow from server kde process to server usermode cups through the tunnel to 
> the client usermode cups to the client main cups and finally to the printer. 
> Simple eh? ;-)
> 
> I think the complexity is needed because of the need to suppost smb printing 
> as well as cups, both at the client, and possibly when the server proxies an 
> rdp or vnc connection to a Windows machine. The cups on the server may 
> connect to an smb print share on both the client, and on the proxied 
> connection. The password protection on the client cupsd is needed to stop 
> other NX users having access to your printer through the forwarded port.
> 
> Bear in mind this is not authoritative - just the result of me poking around 
> trying to find out why it  didn't work for me. Anyway I ran into a few 
> problems along the way, presented below more or less in the order I found 
> them.
> 
> The first problem is in the freenx nxnode script in function 
> cmd_node_addprinter() which handles the addprinter request from the client. 
> This has to determine the printer driver to use, so calls a script 
> confusingly called nxclient. This is NOT a client! It is meant to replicate 
> certain functions of the nomachine nxclient as used by the nxserver though, 
> such as allowing you to select a printer driver. For me this printer driver 
> selection never displayed however, so for testing I modified 
> cmd_node_addprinter() to bypass this for testing, hardwiring it to the driver 
> for my printer. Another option may be to install the nomachine client on the 
> server, since it seems the freenx nxclient script checks for the presence of 
> the nomachine client, and calls it if present. I've not tried that yet 
> though...
> 
> Next up the cups on my server seems incapable of printing. The logs suggest 
> installing esp ghostscript, which is already installed. I suspect it's either 
> a missing package or a permissions issue accessing the progs that do the 
> conversion to the printer format. Again for testing I bypassed this by 
> pointing the kde print manager direct to the forwarded port of the client's 
> cupsd. Do this in the Control center -> Peripherals -> Printers section, 
> follow the Print Manager -> Configure manager... dropdown, and pick the CUPS 
> Server option. Set the server to localhost and the port to the forwarded 
> port. This is most likely your display port (shown in the nxclient title bar, 
> usually round 1000) plus 2000. You can also set the username and password 
> here.
> 
> The username and password you need are in /var/log/nxserver.log if you set the 
> log level high enough (NX_LOG_LEVEL>4 I think) , and turn off the safe 
> logging (NX_LOG_SECURE=0) in /etc/nxserver/node.conf, since this will obscure 
> the password. Look for a line beginning:
> NX> 105 addprinter
> this will have the username and password for the session. Do I need to mention 
> this is generally a bad idea?
> 
> So far so good(?) except that the kde print manager appears unable to 
> authenticate using AuthType Digest. I've tried in from both Gentoo and 
> knoppix, and it fails every time. You can work around this by reconfiguring 
> the client userspace cupsd to use AuthType BasicDigest in 
> ~/.nx/cups/cupsd.conf _while_the_session_is_active_ then getting the cupsd to 
> reread its config by using kill -hup on it. This MUST be while the session is 
> active because the client rewrites it at the start of  every session, ad the 
> authtype appears hardcoded into the nxclient binary.
> 
> All except this last bit should be reasonably easy to fix on the server, and I 
> can't see how the authentication can be a universal problem. If it was the 
> nomachine nxclient would never be able to print. I haven't had the chance to 
> do any more than this yet. I hope this helps someone to get the printing 
> going.
> 
> Al
> 
> On Tuesday 24 January 2006 14:46, James wrote:
> > Care to provide some details on your manual intervention?  As things
> > stand now, I have no printing ability at all via FreeNX.
> >
> > Thanks.
> >
> > Alastair Johnson wrote:
> > > I believe this is _supposed_ to work seamlessly, but my experience with
> > > linux to linux printing is that it doesn't with FreeNX (see thread 'cups
> > > to cups print problem' for details). I have managed to get it going with
> > > some manual intervention, so it may work. I haven't tried the nomachine
> > > server yet though I would hope it just works.
> > >
> > > Good luck, and please post anything you find.
> > >
> > > Al
> > >
> > > On Monday 23 January 2006 09:57, David Obando wrote:
> > > > Dear all,
> > > >
> > > > I use NX to access a WinXP application server (with RDP) from a Linux
> > > > client. Is it possible to print from within the Windows applications on
> > > > my local printer?
> > > >
> > > >
> > > > Thanks and best regards,
> > > > David
> > >
> > > _______________________________________________
> > > FreeNX-kNX mailing list
> > > FreeNX-kNX at kde.org
> > > https://mail.kde.org/mailman/listinfo/freenx-knx
> >
> > _______________________________________________
> > FreeNX-kNX mailing list
> > FreeNX-kNX at kde.org
> > https://mail.kde.org/mailman/listinfo/freenx-knx
> 
> _______________________________________________
> FreeNX-kNX mailing list
> FreeNX-kNX at kde.org
> https://mail.kde.org/mailman/listinfo/freenx-knx



More information about the FreeNX-kNX mailing list