home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: vmsnet.networks.tcp-ip.ucx
- Path: sparky!uunet!decwrl!pa.dec.com!nntpd2.cxo.dec.com!nntpd.lkg.dec.com!MyTH
- From: MyTH@ucx.lkg.dec.com (M. T. Hollinger)
- Subject: Re: Proxy setup for UCX LPD
- Message-ID: <1992Oct9.041642.5489@nntpd.lkg.dec.com>
- Sender: usenet@nntpd.lkg.dec.com (USENET News System)
- Organization: Digital Equipment Corporation, Littleton, MA
- References: <6387@m1.cs.man.ac.uk>
- Date: Fri, 9 Oct 1992 04:16:42 GMT
- Lines: 24
-
- In the referenced article, mzagsaa@v4.cgu.mcc.ac.uk (Tony Arnold) writes:
- >I've configured a local printer using UCX$LPRSETUP and entered
- >into /etc/printcap of a Unix machine and then tried doing an lpr. I get
- >an error message saying User arnold not authorised to print on this
- >host, followed by a system message saying network object not known.
-
- The quickest way to avoid proxy problems is to simply turn off LPD proxy
- checking (by disabling the APPLICATION_PROXY flag on the LPD service).
- That should get you up and running. If you then want to re-enable proxy
- checking, note that the remote username specified in a proxy must match
- the local username (except for case). This is necessary because unlike
- the RSH protocol, the LPD protocol does not include a mechanism for
- specifying a username on the target machine.
-
- I consider this restriction (matching usernames) unfortunate and am
- looking for ways to eliminate it. In an update to the LPD facility now
- available from the Customer Support Centers (which, incidentally, also
- contains a number of bug fixes), I have added a second proxy check: if
- no proxy is found where the local username matches the remote one, LPD
- will now look for a proxy into the UCX_LPD account. This way, you at
- least don't have to create dummy VMS accounts to match all the remote
- usernames, and wildcard proxies into UCX_LPD will work.
-
- - MyTH
-