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 cdromgoto RedHat/RPMSrpm -ivh ncurses-devel*.rpmor to have the exact name ls ncurse* and load asrpm -ivh filenamethen leave the cdrom and unmount it.     * In AIX you might have to go back and install any or all of:bos.adt.basebos.adt.includebos.adt.libbos.adt.libmbos.adt.utils