ckuins.txt

C-Kermit源码。是使用串口/Modem和网络通讯的程序

C-KERMIT 7.0 INSTALLATION INSTRUCTIONS FOR UNIX

  As of C-Kermit version:  7.0.196
  This file last updated:  Sat Jan  1 13:32:48 2000

  Author: Frank da Cruz, Columbia University

  Copyright (C) 1985, 2000,
    Trustees of Columbia University in the City of New York.
    All rights reserved.  See the C-Kermit COPYING.TXT file or the
    copyright text in the ckcmai.c module for disclaimer and permissions.


DOCUMENTATION

  Frank da Cruz and Christine M. Gianone, "Using C-Kermit", Second Edition,
  1997, Digital Press / Butterworth-Heinemann, Woburn, MA, ISBN 1-55558-164-1
  US single-copy price: $44.95; quantity discounts available.  Available in
  computer bookstores or directly from Columbia University:

    The Kermit Project
    Columbia University
    612 West 115th Street
    New York NY  10025-7799  USA
    Telephone: [phone]
    Email: [e-mail]
    Web: http://www.columbia.edu/kermit/

  The CKERMIT2.TXT file contains supplementary info for C-Kermit 7.0 to be
  used until the 3rd edition of the manual is ready.


CONTENTS

 1. OVERVIEW
 2. INSTALLING FROM PACKAGES
 3. INSTALLING PREBUILT BINARIES
 4. BUILDING FROM SOURCE CODE
    4.0. Special Considerations for C-Kermit 7.0
    4.1. The UNIX Makefile
    4.2. The C-Kermit Initialization File
    4.3. The 2.x BSD Makefile
    4.4. The Plan 9 Makefile
    4.5. Makefile Failures
 5. INSTALLING THE KERMIT FILES
 6. INSTALLING UNIX C-KERMIT FROM DOS-FORMAT DISKETTES
 7. CHECKING THE RESULTS
 8. REDUCING THE SIZE OF THE EXECUTABLE PROGRAM IMAGE
 9. UNIX VERSIONS
    9.1. Standards
    9.1.1. POSIX
    9.1.2. ANSI C
    9.1.3. Other Standards
    9.2. Library Issues
    9.3. UNIX File System Peculiarities
    9.4. Hardware Flow Control
    9.5. Terminal Speeds
    9.6. Millisecond Sleeps
    9.7. Nondestructive Input Buffer Peeking
    9.8. Other System-Dependent Features
    9.9. Terminal Interruption
10. DIALING OUT AND COORDINATING WITH UUCP
11. RUNNING UNIX C-KERMIT SETUID OR SETGID
12. CONFIGURING UNIX WORKSTATIONS
13. BIZARRE BEHAVIOR AT RUNTIME
14. CRASHES AND CORE DUMPS
15. SYSLOGGING
16. SECURITY OPTIONS


1. OVERVIEW

This file contains UNIX-specific information.  A lot of it.  Unlike most
other packages, C-Kermit tries very hard to be portable to every UNIX variety
(and every release of each one) known to exist, including many that are quite
old, as well as to other platforms like VMS, AOS/VS, VOS, OS-9, the BeBox,
the Amiga, etc.

Since C-Kermit gets so deeply into the file system, i/o system, and other
areas that differ radically from one UNIX platform to the next, this means
that a lot can go wrong when you try to install C-Kermit on (for example) a
new release of a particular variety of UNIX, in which certain things might
have changed that C-Kermit depended upon.

This file concentrates on installation.  For a description of general
configuration options for C-Kermit, please read the file ckccfg.txt.  For
troubleshooting after installation, see the files ckcbwr.txt and ckubwr.txt.
The latter, in particular, contains lots of information on lots of specific
UNIX platforms.  If you want to work on the source code, see the C-Kermit
Program Logic Manual, ckcplm.txt.

You may install C-Kermit:

 . From an "install package", if one is available.
 . As a prebuilt binary, if available, plus accompanying text files.
 . By building from source code.


2. INSTALLING FROM PACKAGES

Various UNIX varieties -- Red Hat Linux, Solaris, etc -- now incorporate the
idea of "install packages", and many users expect to find all new applications
in this format.  A selection of install packages might be available for any
given release of C-Kermit, but there is a tradeoff between convenience and
safety.  UNIX presents several notable problems to the builder of install
packages:

 a. Since C-Kermit is portable to many non-UNIX platforms (VMS, VOS, AOS/VS,
    etc), some of the files in the C-Kermit distribution do not fit into the
    UNIX application model.  In particular, C-Kermit includes some plain
    text files (described in Section 5) and UNIX has no standard place to
    put such files.  Typical UNIX package managers do not allow for them.
    Where should they go, and how will the user know where to find them?

 b. Installation of any program that will be used to make modem calls requires
    some important decisions from the installer regarded security and
    privilege.

Item (b) is discussed at length in Section 10 of this document, but the
package-related aspects are also given here.  The basic problem is that UNIX
dialout devices and the UUCP "lock files" that regulate contention for them
(described in Section 10) are protected against "world".  Therefore, the
install procedure must either run as root in order to give the Kermit binary
the required permissions, or else it must open up the permissions on the
devices and lockfile directory.  Otherwise, the Kermit program just installed
WILL NOT WORK for dialing out.

Thus, a well-crafted installation procedure should present the options and
allow the installer to choose:

 a. Check the permissions of the lockfile directory and the dialout devices.
    If they do not allow unprivileged R/W access, then:

 b. "Your UUCP lockfile directory and/or dialout devices require privilege
    to access.  You must either change their permissions or install Kermit
    with privileges."

 c. "If you wish to install Kermit with privileges, it will be given the
    same owner, group, and permissions as the cu program so it can use the
    dialout devices."

 d. If they choose (c) but the user is not root, give message that the
    install procedure can be run only by root and then quit.

The Kermit Project does not necessarily have the resources or the expertise
to make install packages for any (and certainly not all) UNIX (and other)
platforms.  Most install packages, therefore, are contributed by others, and
they do not necessarily follow the guidelines given above.

If you are an end user who has obtained a C-Kermit install package for a
particular platform, you should be aware that some additional steps might
needed.  Read Section 10 for details.


3. INSTALLING PREBUILT BINARIES

Hundreds of prebuilt C-Kermit binaries are available on the CDROM in the
BINARY tree, and at our ftp site in the kermit/binaries area (with names
starting with "ck").  To install a prebuilt binary:

 a. Rename the binary to "wermit".

 b. Follow steps (b) through (e) in Section 4.

But first...  Please heed the following cautions:

 a. If you pick the wrong one, it won't work (or worse).

 b. Even when you pick the appropriate binary, it still might not work due
    to shared-library mismatches, etc. (see Section 4.0).

 c. Don't expect a binary built on or for version "n" of your OS to work
    on version "m" (where m < n).  However, it is usually safe to run a
    binary built on (or for) an older OS release on a newer one.


4. BUILDING FROM SOURCE CODE

C-Kermit is designed to be built and used on as many platforms as possible:
UNIX and non-UNIX, old and new (and ancient), ANSI C and K&R.  The UNIX
version does not use or depend on any external tools for building except the
"make" utility, the C compiler, and the linker.  It does not use any automated
configuration tools such as configure, autoconf, automake, libtool, etc.
Everything in C-Kermit has been built by hand based on direct experience or
reports from users.

The C-Kermit makefile contains the rules for building the program for each of
the hundreds of different kinds of UNIX systems that C-Kermit attempts to
support.  It covers all UNIX variations since about 1980 -- pretty much
everything after UNIX V6.  Separate makefiles are used for Plan 9 and 2.x BSD.

Prerequisites:

 . The C compiler, linker, and make program must be installed.
 . The C libraries and header files must be installed (*).
 . The C-Kermit source code and makefile in your current directory.
 . The C-Kermit text files (Section 5) in your current directory.

(*) This is becoming problematic in this new age of "selective installs"
    e.g. of Linux packages.  C-Kermit builds will often fail because replying
    "no" to some obscure Linux installation option will result in missing
    libraries or header files.

Plus:

 . For TCP/IP networking support, the sockets library and related header
   files must be installed.

 . For the curses-based fullscreen file-ransfer display, the curses or
   ncurses header file(s) and library, and probably also the termcap and/or
   termlib library.  Note that the names and locations of these files and
   libraries are likely to change capriciously with every new release of your
   UNIX product.  If you discover that the C-Kermit build procedure fails
   because your curses and/or termxxx headers or libraries are not named or
   located as expected, please let us know.  In the meantime, work around by
   installing symlinks.

 . IMPORTANT: Modern Linux distributions might give you the choice during
   installation of whether to install the "ncurses development package"
   (perhaps called "ncurses-devel").  If you did not install it, you won't
   be able to build C-Kermit with curses support included.  In this case,
   either go back and install ncurses, or else choose (or create) a
   non-curses makefile target for your platform.  To install the ncurses
   developers tools in Red Hat Linux, do:

     mount redhat cdrom
     goto RedHat/RPMS
     rpm -ivh ncurses-devel*.rpm
     or to have the exact name ls ncurse* and load as
     rpm -ivh filename
     then leave the cdrom and unmount it.

Directions:

The makefile might need to be renamed from ckuker.mak to makefile.

 a. Type "make xxx" where xxx is the name of the makefile target most
    appropriate to your platform, e.g. "make linux", "make aix43", etc.  Read
    the comments at the top of the makefile for a complete list of available
    targets (it's a long list).

 b. Test the resulting 'wermit' file (see Section 7 for suggestions).
    If it's OK, proceed; otherwise notify us.

 c. Rename the 'wermit' file to 'kermit', copy it to the desired binary
    directory (such as /usr/local/bin or /opt/something), and if it is to be
    used for dialing out, give it the same owner, group, and permissions as
    the 'cu' program (IMPORTANT: read Sections 10 and 11 for details).

 d. Install the man page, ckuker.nr, with your local man pages.

 e. Install the accompanying text files (see Section 5).

Steps (c) through (e) can be accomplished using the 'install' target in the
makefile.  Directories are specified by the following variables:

 Name        Default
  BINDIR      /usr/local/bin
  MANDIR      /usr/man/manl
  MANEXT      l (that's letter "l" for "local", not digit 1)
  INFODIR     /usr/local/doc/kermit

To use the defaults, just type "make install".  You can override any of the
defaults on the 'make' command line, e.g.:

  make "INFODIR=/usr/share/lib/kermit" install

The 'install' target does not attempt to set Kermit's owner, group, and
permissions to allow dialing out.  This requires privileges and open eyes.
Please read Sections 10 and 11 below, make the necessary decisions, and then
implement them by hand as described in those sections.


4.0. Special Considerations for C-Kermit 7.0

(Also see ckccfg.txt Section 8.)

Lots of new features have been added, requiring access to new symbols, APIs,
libraries, etc, and this will no doubt cause problems in compiling, linking,
or execution on platforms where 6.0 and earlier built without incident.  This
section contains all we know as of the date of this file.

The first category concerns the new Kermit Service Daemon (IKSD; see separate
iksd.txt file for details):