|
The Kermit Project |
Now hosted by
Panix.com
New York City USA •
kermit@kermitproject.org
| ||||||||
|
Before reading this short document, please look over the Unix C-Kermit Installation Instructions page, especially Section 5.
The resulting binary is named "wermit" (so as to preserve any "kermit" program that might exist in the same directory) and after successful testing should be renamed to "kermit" and put in a directory that is (a) in the PATH of all the users who need to use it, and (b) not likely to be wiped out when installing an OS upgrade. Typical choices might be /usr/local/bin, /opt/local/bin, /opt/kermit/, or /opt/kermit/bin. Of course this poses a problem because different sites, different distributions of the same OS, etc, will want to put programs such as Kermit in different places, so one install package for a particular platform (such as an RPM for Linux) will never please everybody.
The binary must be given execute permission ("chmod +x"), of course, and if it is to be used for dialing out, it will need to have the same owner and group and permissions (possibly including setuid and/or setgid) as the "cu" program (if there is one!) If the install package is to take care of all this, then obviously it must run as root. See the Installation Instructions, especially sections 10 and 11, for details and more thorough discussion of serial-port device and lockfile access and management. On single-user desktop platforms like Mac OS X, it is normally OK to build C-Kermit with the -DNOUUCP option, to skip all the lockfile business, but the (perhaps simulated) serial ports must still be configured to allow access.
When the install package builds from source code, it is important to check all the dependencies. Are the C compiler, linker, header files, and libraries installed? Are the TCP/IP sockets library and headers installed? Are the curses (or ncurses) library and headers installed?
To build a secure version of C-Kermit – that is, one with OpenSSL or Kerberos or other form of secure authentication and strong encryption for use over the Internet – it will always be necessary to build from source code because US law forbids public distribution of prebuilt binaries that do strong encryption.
When the install package builds from source code, it is important to check all the dependencies. Are the C compiler, linker, header files, and libraries installed? Are the TCP/IP sockets library and headers installed? Are the curses (or ncurses) library and headers installed? When building a secure version, is the OpenSSL and/or Kerberos libraries and headers installed, and where are they? It is often necessary to specify the location on the make command line, since (with the exception of OS's that include these libraries in a standard place) there is no standard location for them.
For version 8.0, the "man page" was done in HTML. Since there is no tool (that I know of) for converting HTML to nroff, I did it by hand. Somebody else might want to convert it to Info (TexInfo?) for Linux, and who knows what other format we're using for documentation in Linux these days. It strikes me that HTML might be a good choice, since HTML interpreters are practically universal now, even for text sessions (Lynx), and this way you get links for free, and a wide choice of tools to access them.
Anyway, the C-Kermit man page is presently available as:
ckuker.nr Traditional nroff man page source. ckututor.html HTML. ckututor.txt Plain ASCII text (dumped from the HTML). ckututor.pdf Adobe PDF format (by PDF-O-Matic).
The remaining files are not necessary for C-Kermit's operation; they are just documentation and samples. All of this (and much more besides) can be found at the Kermit website, and the information on the website is probably more current too. Should you wish to install these files on your own computer, however, feel free to do so.
The best course is to just leave out the C-Kermit initialization file (distributed as ckermit.ini but normally named .kermrc), or put it in an examples directory, and let C-Kermit start up "bare" by default. Users can create their own ~/.kermrc if they wish.
Alternatively, a single site-wide initialization file can be used, but for this Kermit has to be built specially to know where to look for it (-DCK_SYSINI=path). Such a file should always end by chaining to the user's C-Kermit initialization file:
take ~/.kermrc
You can also customize C-Kermit for local use without the need of an initialization file by defining system-wide environment variables, as described in (Section 5 of the C-Kermit installation instructions.
Text HTML Description ckcbwr.txt ckcbwr.html General C-Kermit hints and tips ckubwr.txt ckubwr.html Unix-specific C-Kermit hints and tips ckuins.txt ckuins.html Unix installation instructions ckcplm.txt ckcplm.html C-Kermit program logic manual ckccfg.txt ckccfg.html C-Kermit configuration options
The current text files are dumped from the HTML ones. If you put these text (.txt) files in any of the directories listed below, C-Kermit will find them and refer to them in its HELP text.
/usr/local/doc/kermit/ /usr/share/lib/kermit/ /usr/share/doc/kermit/ /usr/local/lib/kermit/ /usr/local/share/kermit/ /usr/local/share/doc/kermit/ /usr/local/share/lib/kermit/ /usr/doc/kermit/ /opt/kermit/ /doc/kermit/ /usr/local/doc/ /usr/share/lib/ /usr/share/doc/ /usr/local/lib/ /usr/local/share/ /usr/local/share/doc/ /usr/local/share/lib/ /usr/doc/ /opt/ /doc/
Obviously other combinations are possible, as long as they include the binary and man page.
What directories to use? It depends on which files you want to keep and the conventions used by your OS, file system, or site. A minimal installation might put the Kermit binary in /usr/local/bin and the man page in /usr/man/man1.
At the other extreme, what if you want to install everything? Most Unix platforms don't have a natural location for storing plain-text information files. Where to put them? One scheme (used on Solaris) might be:
/opt/kermit (Root of Kermit tree) /opt/kermit/bin/ (Binary and init file) /opt/kermit/src/ (Source code) /opt/kermit/doc/ (Text and info files)
The advantage of this scheme is that it provides a nice grouping for an application and its files. And it's extensible too: you could add an html subdirectory, an examples subdirectory (for scripts), etc. The disadvantage is that the /opt/kermit/bin/ directory must be added to the PATH, but that can be fudged with symlinks from /opt/local/bin/. But in either case, the installer must take some action beyond just putting the Kermit binary in a directory that is already in everybody's PATH. Anyway, the C-Kermit makefile 'install' target lets you set up this structure or most any other kind you want: CLICK HERE for details and examples.
What about security? You can't build a secure version of C-Kermit (or any other program that embodies strong encryption) and package it for general distribution without considering USA export law. We (the Kermit Project) do not distribute secure binaries or packages, only source code, for this reason: any binaries or packages that we distribute are not built with encryption code. What you or your company does is up to you, but be aware of the issues and rules.
make install # Accept defaults. make "INFODIR=/usr/share/lib/kermit" install # Override INFODIR default.
You can also build and install in one step, e.g.:
make linux install
If you don't have write access to any of the destination directories, obviously "make install" fails. In most cases, a real installation also requires you to chown / chgrp the Kermit binary for the UUCP lockfile and/or tty devices, and perhaps also to chmod +s the corresponding permission fields, but these things are best done by a human (for details see the detailed installation instructions).
If you use the 'install' target to install C-Kermit, it creates an UNINSTALL script that can be used to uninstall it.
kermit 1649/tcp # Internet Kermit Service
This socket is for the Internet Kermit Service specified in RFCs 2839 and 2840.