ckuins.txt

KERMIT工具 这在办公室下载不了,很多人都没有载不到.

C-Kermit 8.0 Unix Installation Instructions

   [ [1]Contents ] [ [2]C-Kermit ] [ [3]Kermit Home ]

   Frank da Cruz
   The Kermit Project
   Columbia University

      As of C-Kermit version: 8.0.211, 10 April 2004
      This file last updated: Tue Apr 13 10:14:33 2004 (New York City
   time)

   IF YOU ARE READING A PLAIN-TEXT version of this document, note that
   this file is a plain-text dump of a Web page. You can visit the
   original (and possibly more up-to-date) Web page here:

[4]http://www.columbia.edu/kermit/ckuins.html
  __________________________________________________________________________

CONTENTS

     [5]OVERVIEW

    1. [6]INTERNET QUICK START
    2. [7]INSTALLING FROM PACKAGES
    3. [8]INSTALLING PREBUILT BINARIES
    4. [9]BUILDING FROM SOURCE CODE
    5. [10]INSTALLING THE KERMIT FILES
    6. [11]INSTALLING UNIX C-KERMIT FROM DOS-FORMAT DISKETTES
    7. [12]CHECKING THE RESULTS
    8. [13]REDUCING THE SIZE OF THE EXECUTABLE PROGRAM IMAGE
    9. [14]UNIX VERSIONS
   10. [15]DIALING OUT AND COORDINATING WITH UUCP
   11. [16]RUNNING UNIX C-KERMIT SETUID OR SETGID
   12. [17]CONFIGURING UNIX WORKSTATIONS
   13. [18]BIZARRE BEHAVIOR AT RUNTIME
   14. [19]CRASHES AND CORE DUMPS
   15. [20]SYSLOGGING
   16. [21]BUILDING SECURE VERSIONS OF C-KERMIT 8.0
   17. [22]INSTALLING C-KERMIT AS AN SSH SERVER SUBSYSTEM
  __________________________________________________________________________

OVERVIEW

   [ [23]Top ] [ [24]Contents ] [ [25]Next ]

     WARNING: This document contains notes that have been accumulating
     since the early 1980s. Many of the products and Unix versions
     mentioned here have not been heard of in a long while, but that
     does not necessarily mean they are not still running in some
     obscure nook. 

   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 [26]Configurations
   Options document. For troubleshooting after installation, see the
   [27]General Hints and Tips and [28]Unix-Specific Hints and Tips
   documents. 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 [29]C-Kermit Program Logic Manual

   You may install C-Kermit:

     * From an "[30]install package", if one is available.
     * As a [31]prebuilt binary, if available, plus accompanying text
       files.
     * By building from [32]source code.
  __________________________________________________________________________

1. INTERNET QUICK START

   [ [33]Top ] [ [34]Contents ] [ [35]Next ] [ [36]Previous ]

   If your Unix computer is on the Internet and it has a C compiler,
   here's how to download, build, and install C-Kermit directly from the
   "tarballs" or Zip archives:

    1. Make a fresh directory and cd to it.
    2. Download the C-Kermit source code:
       [37]ftp://kermit.columbia.edu/kermit/archives/cku211.tar.Z
       (compress format) or
       [38]ftp://kermit.columbia.edu/kermit/archives/cku211.tar.gz
       (gunzip format).
    3. Uncompress the compressed tar file with "uncompress" or "gunzip",
       according to which type of compressed file you downloaded. (If you
       don't understand this, you could download a (much larger)
       uncompressed tar archive directly:
       [39]ftp://kermit.columbia.edu/kermit/archives/cku211.tar
    4. Now type "tar xvf cku211.tar" to unpack the individual files from
       the tar archive.
    5. Type "rm cku211.tar" to get rid of the tar archive, which is no
       longer needed.
    6. Read the comments at the top of the makefile to find out which
       target to use and then type the appropriate "make" command, such
       as "make linux", "make solaris8", etc.
    7. This produces a binary in your current directory called "wermit".
       Start it by typing "./wermit" and [40]try it out to make sure it
       works. Then read [41]Section 5 for how to install it, or simply
       copy the wermit binary to the desired public directory, rename it
       to kermit, and give it the needed permissions (and, if it is going
       to be used to dial out, give it the same group and owner and
       permissions as the cu, tip, or minicom program).

   For secure installations, see [42]Sections 5 and [43]16.
  __________________________________________________________________________

2. INSTALLING FROM PACKAGES

   [ [44]Top ] [ [45]Contents ] [ [46]Next ] [ [47]Previous ]

   Various Unix varieties -- Linux, Solaris, AIX, 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 [48]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 regarding
       security and privilege.

   Item (b) is discussed at length in [49]Sections 10 and [50]11 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 [51]Section 10) are
   usually protected against "world". Therefore, the install procedure
   must either run as root in order to give the Kermit binary the
   required permissions, group, and/or owner, or else the dialout devices
   and associated directories must be open for group or world reading and
   writing. 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 the method, if any, for regulating
   access to the dialout devices:

    a. Check the permissions of the lockfile directory and the dialout
       devices. If they do not allow group or world 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 a message that
       the install procedure can be run only by root and then quit.

   It should go without saying, of course, that any binaries that are to
   be included in an install package should be built fresh on the exact
   platform (e.g. Red Hat 8.0 on Intel) for which the package is
   targeted; prebuilt binaries ([52]next section) from other sites are
   likely to have library mismatches. [53]CLICK HERE for more about
   building C-Kermit install packages.

   The Kermit Project does not have the resources or the expertise to
   make install packages for every platform. Most install packages,
   therefore, are contributed by others, and they do not necessarily
   follow the guidelines given above. Pay attention to what they do.

   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 if you want to use Kermit to dial out. Read [54]Section
   10 for details.
  __________________________________________________________________________

3. INSTALLING PREBUILT BINARIES

   [ [55]Top ] [ [56]Contents ] [ [57]Next ] [ [58]Previous ]

   Hundreds of prebuilt C-Kermit binaries are available on the CDROM in
   the BINARY tree [NOTE: The C-Kermit CDROM is still for version 7.0],
   and at our ftp site in the [59]kermit/bin area (with names starting
   with "ck"), also accessible on the [60]C-Kermit website. To install a
   prebuilt binary:

    a. Rename the binary to "wermit".
    b. Make sure it works; some tests are suggested in [61]Section 7.
    c. Follow steps (b) through (e) in [62]Section 4.
    d. Install related files as described in [63]Section 5.

   But first... Please heed the following cautions:

    a. If you pick the wrong binary, 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 [64]Section 4.0).
    c. Don't expect a binary built on or for version n of your OS to work
       on version n - x (where x > 0). However, it is usually safe to run
       a binary built on (or for) an older OS release on a newer one.

   Therefore, it is better to build your own binary from source code
   ([65]next section) if you can. But since it is increasingly for Unix
   systems (not to mention VMS and other OS's) to be delivered without C
   compilers, it is often impractical. In such cases, try the most
   appropriate prebuilt binary or binaries, and if none of them work,
   [66]contact us and we'll see what we can do to help.
  __________________________________________________________________________

4. BUILDING FROM SOURCE CODE

   [ [67]Top ] [ [68]Contents ] [ [69]Next ] [ [70]Previous ]

   Also see: [71]Section 8 and [72]Section 9.

   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 or contributions
   from users of each platform.

   The [73]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 [74]Plan 9 and [75]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 ([76]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. Ditto on
       platforms like AIX and Solaris that don't come with C compilers,
       and then later have gcc installed, but are still missing crucial
       libraries, like libm (math).

   Plus:

     * For TCP/IP networking support, the sockets library and related
       header files must be installed.
     * The math library for floating-point arithmetic support (can be
       deselected by adding -DNOFLOAT to CFLAGS and removing -lm from
       LIBS).
     * Many and varied security libraries for building a secure version
       (Kerberos, SSL/TLS, SRP, Zlib,...) These are required only if you
       select a secure target.
     * 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 [77]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.

     * In AIX you might have to go back and install any or all of:

bos.adt.base
bos.adt.include
bos.adt.lib
bos.adt.libm
bos.adt.utils