info-kermit@ucbvax.ARPA (06/27/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Info-Kermit Digest Wed, 26 Jun 1985 Volume 2 : Number 38
C-Kermit Issue:
C-Kermit 4C for Amdahl UTS 2.4
C-Kermit 4C for Fortune 16:32
Fixes to C-kermit for the Valid Scaldstar System
C-Kermit on Whitechapel MG-1 with Genix 1.3
Unix-Like Systems Supported by C-Kermit
Transporting C-Kermit to Eurosys-16 with Os9
Dialing from C-Kermit on a 3B2?
C-Kermit 4x vs Line Locking, etc
----------------------------------------------------------------------
Date: Thu 20 Jun 85 02:23:04-PDT
From: Jean-Pierre Dumas <DUMAS@SUMEX-AIM.ARPA>
Subject: C-Kermit 4C for Amdahl UTS 2.4
We have compiled Kermit 4.2 on UTS 2.4. It works very well (with "make v7";
we use a dummy function that always return 0 for initrawq in ckutio.c )
[Ed. - Thanks for the news! I've added a comment to this effect to the
makefile.]
------------------------------
Date: Wed 26 Jun 85 04:32:52-PDT
From: Jean-Pierre Dumas <DUMAS@SUMEX-AIM.ARPA>
Subject: C-Kermit 4C for Fortune 16:32
Frank,
I insert ckuker.mak ckufio.c ckutio.c as modified for the fortune 16:32 by
Gerard Gaye.
[Ed. - The Fortune support has been fitted into KER:CKUKER.MAK, KER:CKUTIO.C,
and KER:CKUTIO.C. It's mostly the same as 4.1bsd.]
As we are connected through an x25 network it should be possible to safely
by-pass some packet assembly/deassembly/coding... of kermit and rely on the
x25 pad to do the work...anybody working on that ???
[Ed. - The Kermit protocol is not layered well enough to do things like this.]
Jean-Pierre Dumas
------------------------------
Date: Thu, 20 Jun 85 17:32:51 pdt
From: psivax!woof (Hal Schloss)
To: ttidca!randvax!sy.fdc@cu20b.ARPA
Subject: Fixes to Ckermit for the Valid Scaldstar System
We have a VAX 11/750 running BSD 4.2 that we talk to with Intel MDS's and
VALID Scaldstars. We use the VAX to develop code that we download to the
MDS's and to provide remote services for the Scaldstars. In the course of
getting these to work I had to make changes to existing kermits to allow
communication to C-kermit on the VAX.
For the VALID systems I had to change all references to the variable cc in
the file ckucmd.c. These were changed to ccx, the problem is that cc is
an internal variable for the VALID's assembler which blows up in an ugly
fashion if you declare a second time. I also had to replace a reference
to FREAD in ckutio.c as the VALID does not have this in it's include files.
I hope this works, it seems to so far. To compile for the VALID include
the changes listed in diff -c format below (using patch?) and make bsd.
[Ed. - diffs omitted.]
By the way, I have implemented a remote line printer server for the VALID on
our vax, but I have to run kermit at 300 baud as the VALID has problems
above that speed. I don't know why though.
Hal Schloss
(from the Software Lounge at) Pacesetter Systems Inc.
{trwrb|allegra|burdvax|cbosgd|hplabs|ihnp4|sdcsvax|aero|uscvax|ucla-cs|
bmcg|sdccsu3|csun|orstcs|akgua|randvax}!sdcrdcf!psivax!woof
or {ttdica|quad1|scgvaxd|nrcvax|bellcore|logico}!psivax!woof
ARPA: ttidca!psivax!woof@rand-unix.arpa
[Ed. - This can be handled by adding an entry like this to the makefile:
#Valid Scaldstar
valid:
make wermit "CFLAGS= -DBSD4 -Dcc=ccx -DFREAD=1"
I've added this to KER:CKUKER.MAK. At some later time, perhaps some
of the commonly-objected to variables, like "cc" and "data" can be
renamed.]
------------------------------
Date: Fri, 21 Jun 85 18:33:06 BST
From: Ljwu@ucl-cs.arpa
Subject: C-Kermit on Whitechapel MG-1 with Genix 1.3
I have managed to compile and run C-Kermit 4C(050) on a Whitechapel MG-1
workstation (See Byte magazine from first quarter '85). This machine is
basically a Unix engine running Genix-1.3 which is essentially a bsd 4.1
system. Only hitches were:
1) single call to getppid in ckufio.c was hardwired to 0 due to
lack of this system call in Genix.
[Ed. - Sounds a lot like the Fortune support mentioned above.]
2) wart compiles fine but refuses to process ckcpro.w stating
that one of the defined dynamic states is undefined. Older
version of wart from c-kermit 4.2 also gives a similar error
but a couple of states later. Lex also wouldn't process it.
I suspect that it is an obscure bug in my operating system.
I haven't had the time or energy to chase it down. Instead
I worked around the problem by using the distributed ckcpro.c.
I haven't the foggiest idea of what is wrong since wart seemed
happy on a vax running bsd 4.2 and previous versions (4.2) of
wart and ckprot.w worked fine.
Thus far, I have done only basic send/receive functions on the
Whitechapel using only text files. Everything for the present
seems to be in order. THanks for kermit!
Les J. Wu
[Ed. - I've added Les's hints to the makefile comments section.]
------------------------------
Date: Wed 26 Jun 85 17:45:38-EDT
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: Unix-Like Systems Supported by C-Kermit
To: Info-Kermit@CU20B.ARPA
The following list shows all the systems that C-Kermit has been reported to
work on (the Fortune, Valid, and Whitechapel changes announced above are
confined to the files KER:CKUKER.MAK (makefile), KER:CKUTIO.C, and
KER:CKUFIO.C). I'd appreciate hearing from anyone who has it working on any
systems not listed here, so that I can add their machines and operating
systems to the list:
Machine Operating System Machine Operating System
AT&T 3B Series Unix Sys V IBM PC/AT Xenix/286
Cadmus 68000 Unix Sys V IBM 370 Series VM/UTS 2.4
CallanUnistar300 Unix Sys V IBM 370 Series VM/UTS v5
Codata Unix V7 NCR Tower OS 1.02
DEC VAX Ultrix-32 NCR Tower Unix Sys V
DEC VAX, ... Unix 4xBSD PerkinElmer 3200 Unix V7
DEC PDP-11 Unix 2xBSD Pyramid 90x Unix 4xBSD
DEC PDP-11, ... Unix V7 Masscomp RTU 2.2
DEC Pro-3xx Venix V1 Motorola 4 Phase Unix Sys V
DEC Pro-3xx Venix V2 Plexus P60 Unix Sys V
Fortune 16:32 For:Pro1.7 SUN Unix 4xBSD
HP-9836 S/200 HP-UX 200B TRS-80 Model 16 Xenix
HP-9000 S/500 HP-UX 3.25 Valid Scaldstar Unix 4xBSD
IBM PC/XT PC/IX Whitechapel MG-1 Genix 1.3
Also, if anyone can claim that the current version does NOT work on any of
these systems, I'd also like to find out about that. Thanks! - Frank
------------------------------
Date: Fri, 14 Jun 85 13:20:15 -0300
From: mcvax!hut!kla@seismo.ARPA (Kimmo Laaksonen, Helsinki U of Technology)
Subject: Transporting C-Kermit to Eurosys-16 with Os9
Hi,
I'm forwarding the following mail (excerpt of) for your info:
Date: 14 Jun 1985 1006
From: SAHKOL.TAKALA
To: LK.LAAKSONEN
We are planning to transfer CKERMIT into a system called EUROSYS-16. The
operating system is OS9/68000. The C-compiler we have running is done by
Microware. The version of CKERMIT we have got is 4.2(030).
Petri Alhola, Lauri Aarnio
Robcon OY
Hankasuontie 9
P. O. Box 9
SF - 00391 HELSINKI
Finland
Juha Takala
Helsinki University of Technology
Power Systems Engineerin Laboratory
Otakaari 5
SF - 02150 ESPOO
Finland
Electronic mail can be routed to the implementors through me.
Kimmo Laaksonen, mcvax!hut!kla@seismo.arpa.
[Ed. - Bob Larson, BLARSON%ECLD@USC-ECLA, is coordinating an effort to bring
up C-Kermit under Os9 on a variety of systems. Maybe these two groups can
make contact, especially since Bob has access to the up-to-date C-Kermit
sources.]
------------------------------
Date: Wed, 26 Jun 85 11:50:42 EDT
From: Dr. Joseph M. Leonard <jmleonar@crdc>
To: info-kermit@cu20b
Subject: Dialing from C-Kermit on a 3B2?
This, hopefully, will be an easy one. I have C-Kermit going on our 3B2, but
cannot get the dialer feature to work. The "set modem racal" seems to work
(with the addition of an extra \r), but the "instant" that dialer tries to
do its stuff, DTR is dropped by the 3B2. What I need is anybody who has
set up the /etc/inittab file to do this. OR, if somebody using SysV.2.2 has
used racal modems to dial out, please let me know what I've missed...
Joe Leonard
<jmleonar@crdc.arpa>
[Ed. - Has anyone done this? If not, a new dialer module is expected soon
that might help in this area.]
------------------------------
Date: Tue, 28 May 85 11:53:40 pdt
From: hpl-opus!poulton%hplabs.csnet@csnet-relay.arpa (Ken Poulton)
Subject: C-Kermit 4x vs Line Locking, etc
Questions:
1) How does kermit do uucp line locking on 4.2 systems that
(I understand) generally have /usr/spool/uucp owned by uucp
and protected as 755 ? Our system manager suggests that
we should make kermit setuid uucp; is this commonly done?
2) Some of my uses of Kermit (a spooled print server, for instance)
require that one script do the login, the next does a transfer,
more transfers occur if they are queued, and then a script
logs out. Obviously, there needs to be a way to leave the
line locked and open *between* Kermit invocations.
I have addressed this with an eXIT command, (like berkeley mail)
which exits the program without unlocking the line or dropping DTR.
To make this work, I changed look4lk to swallow an existing lock
file if the user is the owner. (This, however, provides no
protection if kermit is setuid! This may require some id inside
the lock file.)
[Ed. - This is probably a good idea, provided Kermit not setuid'd. If I were
a Unix system manager, I'd think twice about making a program as big and
complex as C-Kermit setuid'd anyway.]
To alleviate the problem of users leaving the line locked,
I print a warning message and create a script in the user's home
dir ("UNLOCKtty04") which can delete the lock and drop the line.
To avoid confusion, I have disabled the 'exit' command.
[Ed. - Well... Not to rehash all the old arguments, but there's simply NO GOOD
WAY to handle this situation over the entire family of Unixes. Unix stupidly
lets anyone assign an appropriately protected tty, regardless of whether
someone else may also have it assigned. Reasonable multiuser operating systems
allow access to devices like terminals and tape drives to one job or process at
a time, since there's no practical way that serial devices such as these can be
shared. Many operating systems even have a tough time letting users share disk
files! Anyway, because Unix blithely grants a tty device to as many users who
ask for it, the whole business of "line locking" came about. Whoever it was
that invented uucp decided for the rest of us how lines should be locked: by
writing a file into a particular directory like /usr/spool/uucp or /etc/locks.
This requires that the user's process must have write access to that directory.
This is accomplished by (a) protecting the directory so that the public can
write into it (which opens the door to potential security problems); (b)
protecting the directory so that members of certain groups can write into it
(which requires the system manager to keep track of who's in what group); (c)
setting the process's user id to a privileged id or one that has owner access
to the lock directory (more security loopholes). All of these approaches
require some action of the system manager in order to install a program that
wants to create locks, meaning that such a program is not user installable,
at least not unless condition (a) already prevails. If one wants to find out
who is currently using a device, option (c) is not viable, since the user's
name will not appear as the creator of the lock file.
Assuming that all this can be set up, there still remain ___ major problems
with line locking:
1. Programs will always appear that do not honor the locking conventions,
defeating the entire purpose of the locking mechanism by simply ignoring it.
2. Programs that do honor the locking convention will occasionally leave lock
files behind (because the process was killed, the system crashed, or the
program itself crashed), preventing other users from using the device even when
it is free.
The trade-off, then, is whether it is better to err on the side of security
or on the side of letting users get their work done. C-Kermit, in its present
form, makes various compromises. If read or write access to the lock
directory is denied, the program issues a warning but allows the user to
proceed. If a lock file exists for the specified device, the user is not
allowed to proceed, but is given an "ls -l" listing of the lock file to show
the file's creator and creation time. Since C-Kermit does not allow access to
a locked line, it is very careful to get rid of lock files whenever it exits,
whether because a command-line invocation was completed, an "exit" command was
given, or an interrupt or quit signal was raised.
If users are given the ability to exit Kermit without releasing the line or
closing the lock file, many lock files will be left behind. This is especially
likely because the intention of this feature is to facilitate running Kermit
from unattended scripts.]
The other problem is that on Bell systems,
we have no job control (sigh). This means that we can't
put a long transfer into the background after it starts.
The eXIT command allows you to be using Kermit CONNECT
for doing work, eXIT and do a transfer in the background,
and re-CONNECT when the transfer is done.
Perhaps Kermit should support background transfers directly...
[Ed. - I can see that the proposed eXIT command has its uses, but it really
supposes a friendly environment where everyone knows everyone else and can
chase them down when they leave a lock file behind. But what happens when you
have Unix running on some huge timesharing system like a VAX 8600 or an IBM
3081 with 5000 users, and they're all leaving lock files behind, perhaps even
on purpose (maybe they're premed students...)?]
------------------------------
End of Info-Kermit Digest
*************************
-------