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.bitnetbzs@BU-CS.BU.EDU (Barry Shein) (07/15/88)
>Pardon my ignorance, but I'm confused about running uucp over TCP links. > >My question is why? Very simple, to accomodate application layer software written for UUCP in the least invasive way without having to rewrite it all including, as you guessed, store and forward pieces that can travel over both TCP/UUCP links and vanilla UUCP/serial links without modification. The emphasis is on "without having to rewrite...", the approach works quite well, especially for the last few hops around a LAN after it arrives (often over a serial line) at the campus, or the first few hops going out, as the case may be. -Barry Shein, Boston University
kerr@oodis01.ARPA (Grant Kerr) (07/16/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? 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...(?) One reason is that uucp over tcp adds fault tolerance over just plain uucp. You can setup your L.sys to try a network tcp connection first and if that fails due to network problems then it (uucp) can also try other means namely a dialup modem. If you are using smtp only and the network is down then the mail waits. -- Grant Kerr Control Data Corporation INTERNET: kerr@oodis01.arpa UUCP: ames!lll-tis!oodis01!kerr
steve@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
rbj@NAV.ICST.NBS.GOV (Root Boy Jim) (07/19/88)
? From: bzs%bu-cs.bu.edu@bu-it.bu.edu (Barry Shein) ? >Pardon my ignorance, but I'm confused about running uucp over TCP links. ? > ? >My question is why? ? Very simple, to accomodate application layer software written for UUCP ? in the least invasive way without having to rewrite it all including, ? as you guessed, store and forward pieces that can travel over both ? TCP/UUCP links and vanilla UUCP/serial links without modification. ? The emphasis is on "without having to rewrite...", the approach works ? quite well, especially for the last few hops around a LAN after it ? arrives (often over a serial line) at the campus, or the first few ? hops going out, as the case may be. I would have to agree with Barry here. The `news' system works with UUCP, not with TCP/IP. I have been living with ARPANET mailing lists and am restricted to a subset of the newsgroups, which may be a blessing. ? -Barry Shein, Boston University (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement Careful with that VAX Eugene!
he@idt.unit.no (Haavard Eidnes IDT) (07/20/88)
Jim Cotrell on TCP-IP Jul 20th: > I would have to agree with Barry here. The `news' system works with UUCP, > not with TCP/IP. I thought that NNTP (NetNews Transport Protocol, created at Berkeley), was exactly `news' over TCP/IP. (Or is NNTP only applicable in a situation where you have common administration of the machines involved?) You have to re-install more software than if you just introduced TCP/IP at the UUCP level, though. Haavard Eidnes, Division of Computer Systems and Telematics Norwegian Institute of Technology
mra@srchtec.searchtech.com (Michael Almond) (01/26/91)
We are in the process of setuping our site to connect with PSINet over a SL/IP connection. Does anyone know how to do UUCP exchanges using TCP/IP? I would assume it is possible using telnet or rlogin maybe. Thanks. -- Michael R. Almond (Georgia Tech Alumnus) mra@srchtec.uucp (registered) search technology, inc. mra%srchtec@salestech.com 4725 peachtree corners cir., suite 200 emory!stiatl!srchtec!mra norcross, georgia 30092 (404) 441-1457 (office)
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