C-Kermit Packaging Guidelines for Unix

As of: C-Kermit 9.0
This page last updated: Tue Jun 28 08:25:42 2011

Before reading this short document, please look over the Unix C-Kermit Installation Instructions page, especially Section 5. Also note that C-Kermit 9.0 is in pre-release testing; CLICK HERE to see it.

The C-Kermit Binary

Lots of C-Kermit binaries are available prebuilt, mainly for the benefit of platforms like Solaris that don't necessarily come with C compilers. However, when making a C-Kermit install package, it's usually better to build a fresh binary on the target platform, because prebuilt binaries are increasingly non-portable between machines because of library mismatches. A Linux Kermit binary is created with "make linux"; a Mac OS X binary is created with "make macosx", etc.

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.

The C-Kermit Man Page

The man page for C-Kermit 8.0 is entirely new and different from previous versions. C-Kermit 6.0 and 7.0 came with a ckuker.cpp file to be run through CPP to produce ckuker.nr, an nroff source file customized by the preprocessor for various platforms (HP-UX, Solaris, etc).

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.

License

The COPYING.TXT file (plain text). The license is also displayed by C-Kermit's LICENSE command.

Initialization File

A big deal was made over the C-Kermit initialization file when C-Kermit 6.0 came out in 1997. This was mainly to highlight and illustrate the capabilities and extensibility of C-Kermit that people usually were not aware of. However, most of the services and macros defined in the distributed initialization file were little used, and the main effect of the initialization file was to make Kermit slower to start (618 lines!).

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 Files

Many of the former *.txt files have been converted to HTML and placed on the Kermit website:

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/

So what really needs to go into a C-Kermit install package?

Here are some suggestions for package contents:

1. The C-Kermit binary, the nroff-format man page, and the license.
2. Same as (1), plus source code and makefile.
3. Same as (2), plus text files.
4. Same as (3), plus html files.

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.

The C-Kermit makefile 'install' target

The C-Kermit makefile includes an install target to do approximately the same thing an install package would do, thus obviating the necessity to create 100 different install packages, one for each OS or platform, which seems like an awful waste of time and effort over an application that is structurally quite simple (all that really needs to be present is the C-Kermit binary and maybe the man page). The makefile defines default directories for the C-Kermit binary, the man page, the source code, and so on, and you can override these defaults on the 'make' command line:

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.

Internet Kermit Service

Finally... a small matter. "kermit" is the name for TCP service (socket) number 1649, just as "telnet" is the name for service 23, "ftp" is the name for service 21, and so on. If a "kermit" entry does not appear in your /etc/services file, please add one:

kermit     1649/tcp     # Internet Kermit Service

This socket is for the Internet Kermit Service specified in RFCs 2839 and 2840.

---

C-Kermit Packaging Guidelines / The Kermit Project / Columbia University / kermit@columbia.edu / 2003-2010