mparker@chip.UUCP (M. D. Parker) (06/29/88)
In bits of the BSD documentation, there is a mention of the TCP/IP UUCP server deamon (i.e. /etc/uucpd). My question is if you are the sending party, how do you tell the system to use the UUCP protocol? I find nothing in this in connection with the L.sys file, in fact, I have really found nothing at all. Can anybody enlighten me on /etc/uucpd and its operation, invokation, etc.? Thanks....
gww@marduk.uucp (Gary Winiger) (06/30/88)
In article <175@chip.UUCP> mparker@chip.UUCP (M. D. Parker) writes: >In bits of the BSD documentation, there is a mention of the TCP/IP UUCP server >deamon (i.e. /etc/uucpd). My question is if you are the sending party, how >do you tell the system to use the UUCP protocol? I find nothing in this >in connection with the L.sys file, in fact, I have really found nothing at >all. Page 2 of L.sys(5) in the 4.3BSD documentation documents a ``caller'' field value of TCP. That will cause the sender's 4.3BSD UUCP system to open a TCP connetion to the receiver's uucpd. The receiver, of course, needs to have configured access to uucpd. I don't happen to have a 4.3 system on hand configured that way to tell you what the inetd.conf line has to look like, but I recall it all being in the source directories for uucp. (If it isn't already configured.) Gary..
ntm1569@dsacg3.UUCP (Jeff Roth) (06/30/88)
From article <10036@marduk.uucp>, by gww@marduk.uucp (Gary Winiger): [responding to mparker@chip.UUCP's question on the TCP/IP UUCP service] > Page 2 of L.sys(5) in the 4.3BSD documentation documents a ``caller'' > field value of TCP. That will cause the sender's 4.3BSD UUCP system to > open a TCP connetion to the receiver's uucpd. The receiver, of course, > needs to have configured access to uucpd. I don't happen to have a 4.3 > system on hand configured that way to tell you what the inetd.conf line > has to look like, but I recall it all being in the source directories > for uucp. (If it isn't already configured.) from our /etc/inetd.conf: uucpd stream tcp nowait uucp /etc/uucpd uucpd from our /etc/services: uucp 540/tcp uucpd # uucp daemon from our /usr/lib/uucp/L.sys: dsacg1 Any TCP uucp dsacg1 ogin:--ogin:--ogin: Udsacg3 ssword: PASSWORD -- Jeff Roth (osu-cis!dsacg1!jroth) 614-238-9421 (Autovon 850-9421) From the Internet: jroth%dsacg1.uucp@daitc.arpa US Defense Logistics Agency Systems Automation I speak for myself Center, DSAC-TMP, Box 1605, Columbus, OH 43216
hack@bellboy.UUCP (Greg Hackney) (07/01/88)
In article <175@chip.UUCP> mparker@chip.UUCP (M. D. Parker) writes: >In bits of the BSD documentation, there is a mention of the TCP/IP UUCP server >deamon (i.e. /etc/uucpd). My question is if you are the sending party, how >do you tell the system to use the UUCP protocol? I find nothing in this >in connection with the L.sys file, in fact, I have really found nothing at >all. >Can anybody enlighten me on /etc/uucpd and its operation, invokation, etc.? On my Pyramid, it is set up like this in the L.sys file: sitename Any TCP uucp sitename in:--in: nuucp password: hispassword The site I send to is a Unisys system that doesn't have the /etc/uucpd daemon, but does have telnet, so I use: sitename Any TCP telnet sitename in:--in: nuucp password: hispassword -- Greg
pst@comdesign.uucp (Paul Traina) (07/15/88)
Pardon my ignorance, but I'm confused about running uucp over TCP links.
My question is why? The ftp/smtp/bsmtp interface seems much better for
handling files & mail, and for those who run it, the rsh interface seems
better than uux. So, I ignorantly ask, why do some folk run uucp over TCP?
There must be some sort of intelligent reason it was added...(?)
My only guess would be for folks running TCP terminal servers hooked into
dial-in/dial-out modems .. the remote site dials into the modem, goes via
tcp to the host, and runs uucp as if the modem was direct-connected to
the host.
Since I don't run 4.3 myself (Sun, where are you? Get real.) I don't have
the benefit of a 4.3 doc set to explain why I want TCP/UUCP.
--
work: home:
comdesign!pst@pyramid.com pst@ai.ai.mit.edu
{uunet|pyramid}!comdesign!pst ...!ucbvax!ucsbcsl!nessus!pst
pst@sbitp.bitnetsteve@edm.UUCP (Stephen Samuel) (07/19/88)
From article <387@comdesign.UUCP>, by pst@comdesign.uucp (Paul Traina): > Pardon my ignorance, but I'm confused about running uucp over TCP links. > > My question is why? The ftp/smtp/bsmtp interface seems much better for > handling files & mail, and for those who run it, the rsh interface seems > better than uux. So, I ignorantly ask, why do some folk run uucp over TCP? Simple: Why do people use fortran on a MIPS?? Because it still works, and people are used to it. For a lot of things, it's much easier to add TCP support under UUCICO than it is to rewrite everything else that is used to the UUCP interface program set. It's a lot easier being able to go from a serial line connection to an ethernet connection by changing one line in L.sys (or Systems) than it is to teach everybody how to use the "new and improved" stuff Besides -- UUCP is kinka fire-and-forget. Who cares what protocol it uses as long as it works. rsh/ftp/rcp require a supporting UID on the remote system, and that's not necessarily easy to arrange. They also need a bit more babysitting than FAF UUCP. -- ------------- Stephen Samuel Disclaimer: You betcha! {ihnp4,ubc-vision,mnetor,vax135}!alberta!edm!steve BITNET: USERZXCV@UOFAMTS -- ------------- Stephen Samuel Disclaimer: You betcha! {ihnp4,ubc-vision,mnetor,vax135}!alberta!edm!steve BITNET: USERZXCV@UOFAMTS
mark@cbnews.ATT.COM (Mark Horton) (07/20/88)
In article <387@comdesign.UUCP> pst@comdesign.uucp (Paul Traina) writes: >Pardon my ignorance, but I'm confused about running uucp over TCP links. > >My question is why? UUCP, for all its faults, does offer some features that are not in the standard TCP/IP protocol suite. One feature is queueing. The ftp/rcp/rsh stuff is interactive (although SMTP is queued.) If the remote machine is down, ftp/rcp/rsh aren't going to do you any good. The uucp or uux commands allow you to just queue the transfer and let it go over later when everything is up. Another is sending files to somebody else. If user a on machine x wants to send file m to user b on machine y, with UUCP a can type uuto m y!b and sometime later b will be notified by mail that a gift has arrived. By contrast, with TCP/IP you use either FTP or rcp to transfer the file. FTP requires that you log into the remote system, normally with a password. Some systems set up an "anonymous" login, but that's designed for retrieving a file from an archive, not for sending a file to somebody that asked for it. rcp is even more restrictive; it won't work unless you have a login on the remote machine with blanket no-password authorization. In both cases, the file shows up owned by the remote user for whom the local user has the password, not the destination user. Another issue is email. Some users, for various reasons including upward compatibility and lowest common denominator, really want to send their email via a bang path a!b!c!d. SMTP doesn't do this without a fair amount of munging into and out of 822 format. By using UUCP/TCP/IP you have a quick and dirty way to give users what they expect. Mark
pst@comdesign.uucp (Paul Traina) (07/21/88)
In article <387@comdesign.UUCP> pst@comdesign.uucp (Paul Traina) writes: >Pardon my ignorance, but I'm confused about running uucp over TCP links. > >My question is why? Thanks to everyone who came up with reasons for running UUCP over TCP. The reasons generally fell into 5 categories: (1) To retain compatibility with existing software (designed for uucp) (2) To allow the queuing of transfers (FTP/rcp/et al don't do this) (3) FTP/rcp act differently with regards to the ownership of files at the remote end. (4) New works better with uucp links [this I question, I find NNTP performance appears superior at this time] (5) Connecting to modems off of remote TCP/IP terminal servers [does this *really* work? I tried it using a 4.3bsd VAX and it never worked] There were other reasons, some quite application specific. Thanks to all of you for helping to fill the gap in my education. -- Paul Traina - {uunet|pyramid}!comdesign!pst - comdesign!pst@pyramid.com To believe that what is true for you in your private heart is true for all men, that is genius.
zeeff@b-tech.UUCP (Jon Zeeff) (07/25/88)
In article <398@comdesign.UUCP> pst@comdesign.uucp (Paul Traina) writes: > >Thanks to everyone who came up with reasons for running UUCP over TCP. > >(5) Connecting to modems off of remote TCP/IP terminal servers [does this > *really* work? I tried it using a 4.3bsd VAX and it never worked] As long as you use the 'f' protocol and rlogin, this seems to work fine. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
pst@comdesign.uucp (Paul Traina) (07/26/88)
From article <4644@b-tech.UUCP>, by zeeff@b-tech.UUCP (Jon Zeeff):
- In article <398@comdesign.UUCP> pst@comdesign.uucp (Paul Traina) writes:
->Thanks to everyone who came up with reasons for running UUCP over TCP.
->
->(5) Connecting to modems off of remote TCP/IP terminal servers [does this
-> *really* work? I tried it using a 4.3bsd VAX and it never worked]
-
- As long as you use the 'f' protocol and rlogin, this seems to work fine.
The f-protocol is (relatively) worthless on dialup lines as it was designed
to work over error free links. Also, most old SystemV (and 4.1 < bsd)
systems don't support 'f'.
What do you mean rlogin? All terminal server's I've seen use the telnet
protocol over TCP as opposed to rlogin.
--
Paul Traina - {uunet|pyramid}!comdesign!pst - comdesign!pst@pyramid.com
To believe that what is true for you in your private heart is true for all
men, that is genius.zeeff@b-tech.UUCP (Jon Zeeff) (07/27/88)
In article <413@comdesign.UUCP> pst@comdesign.uucp (Paul Traina) writes: > >The f-protocol is (relatively) worthless on dialup lines as it was designed >to work over error free links. Also, most old SystemV (and 4.1 < bsd) I've been running a comp.* news feed over dial-up lines with 'f' for several months without problems. With clean lines and small blocks, I'd call it relatively valuable. It should also work well with an error-free modem (like a Trailblazer). > >What do you mean rlogin? All terminal server's I've seen use the telnet >protocol over TCP as opposed to rlogin. The annex boxes have rlogin. Now if they only had the -8 option. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
dyer@spdcc.COM (Steve Dyer) (07/28/88)
In article <4648@b-tech.UUCP> zeeff@b-tech.UUCP (Jon Zeeff) writes: > >The annex boxes have rlogin. Now if they only had the -8 option. When the other end of my leased line was moved from a TTY port into a 4.3 host to an annex box, I was sure that my UUCP traffic was doomed, and in fact, I started asking on the net about 8-bit paths. Well, it turns out that UUCP over rlogin into an annex box works just fine. -- Steve Dyer dyer@harvard.harvard.edu dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyer
zeeff@b-tech.UUCP (Jon Zeeff) (07/28/88)
In article <1532@spdcc.COM> dyer@spdcc.COM (Steve Dyer) writes: >it turns out that UUCP over rlogin into an annex box works just fine. I tried it and it didn't work with the 'g' protocol. Are there configuration options on the annex or different versions of the software? -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
emv@mailrus.cc.umich.edu (Edward Vielmetti) (07/29/88)
In article <4651@b-tech.UUCP> zeeff@b-tech.UUCP (Jon Zeeff) writes: >In article <1532@spdcc.COM> dyer@spdcc.COM (Steve Dyer) writes: >>it turns out that UUCP over rlogin into an annex box works just fine. > >I tried it and it didn't work with the 'g' protocol. Are there >configuration options on the annex or different versions of the software? there's configuration options on the annex - you can set it for 8 bit passthrough or for 7 bits plus a parity bit. The particular one that Jon is connecting through has 7 bits/even parity. annex boxes are a pretty scarce resource around here, but if it doesn't mess other things up we'll try out the 8 bit setting. (Jon, I'll send you mail - ok?) --Ed
lyndon@ncc.Nexus.CA (Lyndon Nerenberg) (07/29/88)
In article <4648@b-tech.UUCP> zeeff@b-tech.UUCP (Jon Zeeff) writes: >The annex boxes have rlogin. Now if they only had the -8 option. They are eight bit transparent - we xmodem binary files over them all the time... -- VE6BBM {alberta,pyramid,uunet}!ncc!lyndon lyndon@Nexus.CA
csg@pyramid.pyramid.com (Carl S. Gutekunst) (08/03/88)
In article <4648@b-tech.UUCP> zeeff@b-tech.UUCP (Jon Zeeff) writes: >I've been running a comp.* news feed over dial-up lines with 'f' for >several months without problems. That's an expensive way to run a news feed. Being 7-bit, the 'f' protocol exacts a 40% overhead penalty on binary files (like compress output). The 'g' protocol is full 8-bit, so have only the usual 8% packetizing overhead. You can use the ~news/encode filter, but that's still a 19% overhead. >It should also work well with an error-free modem (like a Trailblazer). Prior to Telebit's firmware rev 3.0, it was the *only* way to talk UUCP over a TrailBlazer. It worked well enough that we still use it for some links, if we aren't trying to pass news. <csg>
stlouis@unixg.ubc.ca (Phill St. Louis) (03/22/91)
I am trying to get UUCP to function over TCP/IP on InterActive Unix 2.2. At the start of the Dialers file is a message that says "Types that appear in the 5th field must be either built-in functions (..., TCP, ...) or ... My question is how do you use this built-in function? What I get (with uucico in x9 debugging mode) when I place TCP in the 5th column is TCP not found in Dialers file set interface UNIX getto ret -1 Call Failed: CAN'T ACCESS DEVICE exit code 101 Conversation Complete: Status FAILED My Devices file contains the following line for TCP TCP,et el - Any TCP - My Systems file contains the following line for the mirek machine: cartnet Any TCP - - in:--in: Umirek word: mnuucp1 Any assistance would be much appreciated. Phill
cpcahil@virtech.uucp (Conor P. Cahill) (03/24/91)
stlouis@unixg.ubc.ca (Phill St. Louis) writes: >I am trying to get UUCP to function over TCP/IP on InterActive Unix 2.2. Here is a posting by Bill Kennedy discussing the above subject. It should help you solve your problems. + Before I start this, many many thanks to Doug Mc Callum and Dick Dunn + at ISC for getting me straightened out on the address that nlsadmin + wants to make this work, to Bill Bunton at Tools & Techniques, Austin + for persevering as I stumble blundered through it, and to Bob Tracy + at CDC San Antonio for getting me started. + + If you have no interest in a TLI based uucp over TCP/IP, hit `n' now, + but if you ever might, save this article, it will save your hair. + + Here's the configuration and the problem. I have two machines that are + networked together using ISC TCP/IP. One of them has both printers that + used to be on a third machine connected by a direct 19.2Kbps uucp link. + My old lp scripts sort of went by the board when I no longer had a uucp + link to the system that had the printers. It became obvious to me that I + had to figure out how to get uucp to work using TLI across the network. + TFM has some information on getting RFS to work, but it's silent with + respect to uucp using TLI. A generous and TLI savvy neighbor, Bob Tracy, + was able to get things to almost work, but we kept failing in t_bind, it + couldn't allocate the address. ISC lept to the rescue by explaining how + the address had to look for the listener to fundtion but we still (by now, + Bill Bunton had agreed to help but was falling into similar potholes) + couldn't get the originator's uucico to connect with its destination. What + follows is a step-by-step recipe for something that works. If there is a + more elegant way to do it, please feel free to mark it up and re-post. If + there is any generally available documentation (cookbook please, not theory), + please tell us too. + + Begin by editing /etc/services and create a port for nls. We used + nls 256/tcp # TLI port + if that doesn't suit you, keep track of the port number because you + need it to develop the nls address. Now choose a name for the nls + "net_spec" (see NLSADMIN(1M)), we chose tcp. + + Initialize the nls net_spec with nlsadmin -i tcp, it will create a + directory, /usr/net/nls/tcp and will create some files in it that it + uses to actually start the listener. Now set up the nls service_code + nlsadmin -a 101 -c"/usr/lib/uucp/uucico -r0 -iTLI -u loginid" -y "comment" tcp + Here loginid is the name of the system who's going to be logging in, on + ssbn it's udunsel and on dunsel it's ussbn, both are no password logins + since they are local uucp over the ethernet. I used "dunsel/ssbn uucico" + for the comment, all of this ends up in /usr/net/nls/tcp/dbf, you can make + a similar entry for cu, choose another service_code, avoid 105 because + that's rfs. + + Now you have to work up your network address. We'd have _never_ figured this + out without ISC's help! This is a hex string that is composed of address + family (AF_INET), port number, IP address, and padding zeroes. Here is the + format and an example: + \x02000100c0fafa010000000000000000 mapped as + aaaappppiiiiiiiizzzzzzzzzzzzzzzz + | | | +------------------ sixteen padding zeroes + | | +-------------------------- IP address 192.250.250.1 co.fa.fa.01 + | +------------------------------ port address fm /etc/services (256) + +---------------------------------- address family, socket address + Obviously your mileage is going to vary, but it shouldn't be hard to figure + out from this example. Hang on to it, you're going to use it more than one + place... You have to tell the listener what address he's going to use + nlsadmin -l "\x02000100c0fafa010000000000000000" tcp + and that number will appear in /usr/net/nls/tcp/addr to be used when you + start nls with nlsadmin -s tcp. Look at /usr/net/nls/tcp/log to be sure + that you've gotten started, "Couldn't allocate address" means he can't + get to the address you specified, "Invalid argument" means you don't have + the right length. + + Now you need to make some entries in /usr/lib/uucp/Systems, Devices, and + Dialers. Remember that ssbn and dunsel don't have passwords on each + other, we can drop directly into uucico which is what we specified when + we added the 101 service code. + + Systems: + # ssbn's Systems line for contacting dunsel, 192.250.250.2 + dunsel Any wlknet Any \x02000100c0fafa020000000000000000 + # dunsel's Systems line for contacting ssbn, 192.250.250.1 + ssbn Any wlknet Any \x02000100c0fafa010000000000000000 + + Devices: + wlknet,eg tcp - - TLI \D nls + + Dialers: + nls "" "" NLPS:000:001:101\N\c + + If you used a service_code other than 101 in the nlsadmin -a, replace the + 101 in the Dialers entry with the code you used. Also note that the Systems + lines need the address of the system that they are "calling", choose any + convenient Devices name, I used wlknet because that's the network name in my + /etc/networks. Now you're ready to test the connection with Uutry. It + goes by too fast to watch, but it's all recorded in /tmp/systemname. You + might have to go through the usual /usr/lib/uucp/Permissions exercise to + make them actually talk to each other, but that's unrelated to nls or TCP/IP + (I _think_ :-) + + Back to the original problem I had set out to solve, my ssbn resident lp + scripts just uux the stuff over to dunsel who is physically connected to + the printers. Here's what I use to get to the dot matrix printer: + + user=$2 + options=$5 + copies=$4 + shift; shift; shift; shift; shift + files="$*" + for file in $files + do + uux - -a$user "dunsel!lp -o$options -n$copies 2>/dev/null" < $file + done + + The lp setup on dunsel contains all the stuff that worries about lines + per inch, pitch, etc. That's all passed in options, I don't try to use + more than one, so beware of quotes/apostrophes. + + You'll get some astonishing transfer rates! My lamebrained lp approach is + what I cobbled together because I don't have lpr/lpd and (you can probably + tell :-) probably wouldn't understand them if I did. Don't forget, I didn't + claim that this was elegant, just that it works... -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170