home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
old
/
ckermit80
/
edit206
/
iksd.txt
< prev
next >
Wrap
Text File
|
2020-01-01
|
72KB
|
1,593 lines
IKSD - The Internet Kermit Service Daemon
IKSD SYSTEM ADMINISTRATOR'S GUIDE FOR UNIX
The Kermit Project
Columbia University
[1]http://www.columbia.edu/kermit/
As of: C-Kermit 8.0, 12 Dec 2001
This page last updated: 12 Dec 2001
The Internet Kermit Service Deamon (IKSD) is C-Kermit 7.0 or later,
started in a special way. At this writing, only the UNIX version of
C-Kermit can act as IKSD, but IKSD will also be available soon in the
Windows version, and can be added to the VMS, VOS, and other versions
if there is sufficient demand. The Internet Kermit Service is
specified in [2]RFC2839 and [3]RFC2840.
CONTENTS
1. [4]Why IKSD?
2. [5]System Configuration
3. [6]Compile-Time Configuration Options
4. [7]Runtime Configuration Options
4.1. [8]Command-Line Options
4.2. [9]System Logging
4.3. [10]The IKSD Log File
4.4. [11]IKSD Configuration File
4.5. [12]Initialization File
5. [13]Access to Services
5.1. [14]Automatic Settings
5.2. [15]Authentication
5.3. [16]The DISABLE Command
5.4. [17]Shell Access
5.5. [18]Anonymous Users
5.6. [19]Management Information
6. [20]Open Issues
6.1. [21]Connection Establishment
6.2. [22]Shell Access
6.3. [23]External and/or non-Kermit Protocols
6.4. [24]Additional Administrative Controls
6.5. [25]Known Bugs
7. [26]Monitoring
7.1. [27]Database Record Format
7.2. [28]The Display Module
7.3. [29]Database Management
8. [30]Testing
_________________________________________________________________
1. Why IKSD?
Why run an Internet Kermit Service Daemon when you are already running
an FTP server?
* Like FTP, Kermit provides a service that can be accessed from many
different platforms with a consistent set of commands, but unlike
FTP, these commands include programming constructions such as
variables, arrays, looping and selection mechanisms, and local and
remote procedure calls, thus allowing file transfer and management
operations of arbitrary complexity to be easily automated.
* Like FTP, Kermit provides both text- and binary-mode data
transfer, as well as file management capabilities. But Kermit also
offers numerous features lacking from FTP, such as:
+ [31]character-set translation;
+ [32]flexible file selection mechanisms;
+ [33]preservation of timestamps and permissions;
+ [34]automatic per-file text/binary mode switching (important
in cross-platform transfers);
+ [35]cross-platform directory-tree transfer; and:
+ a selection of file collision options including "make backup
copy of existing file and accept incoming file", "reject
incoming file", "accept incoming file only if newer than
existing file", etc.
* Unlike FTP, Kermit supports [36]atomic file movement, in which the
source file can be deleted (or renamed, or moved) when and only
when it has been transferred successfully, as part of the transfer
operation itself.
* Unlike most FTP implementations, Kermit supports [37]recovery of
interrupted transfers from the point of failure. You can even use
it to recover interrupted FTP transfers when FTP itself does not
offer this option.
* Unlike standard FTP, Kermit can transfer data through firewalls or
proxies or NATs on a single well-known port (unless the TCP port
for the connection has been explicitly filtered).
* Unlike FTP, Kermit can transfer data across a combination of
transports (e.g. dial-up to a terminal server and thence to an
Internet host).
* Authentication and data transfer can take place over [38]secure
connections (mutually authenticated and encrypted) using
established Telnet authentication and encryption options.
* Unlike traditional Kermit use over Telnet, anonymous access is
possible, and the considerable overhead of the intervening Telnet
server and pseudoterminal service is eliminated.
* Unlike the FTP daemon (ftpd), the IKSD can be monitored in real
time by the system administrator (see [39]Section 7).
A prototype IKSD is available for public access at:
[40]kermit.columbia.edu port 1649
This service is based in part on a new Telnet Kermit Option described
in a pair of Internet Drafts:
[41]ftp://ftp.ietf.org/internet-drafts/draft-altman-telnet-kermit-server-03.t
xt
[42]ftp://ftp.ietf.org/internet-drafts/draft-columbia-kermit-service-03.txt
_________________________________________________________________
2. System Configuration
WARNING: Do not attempt to install a pre-7.0 version of C-Kermit as an
IKSD. Earlier versions do not perform the necessary authentication and
security functions, and therefore will leave your system wide open to
anonymous root access. (Don't worry, the installation procedure
described here, if you follow it, and the interface to IKSD, prevent
you from starting an earlier version of C-Kermit as an IKSD, since it
lacks the needed command-line options and will halt with a usage
message if you try to use them.)
Directory organization, file system, naming conventions, and other
administrative details vary from system to system and site to site, so
specific instructions can not be given here. In general, however, the
steps are:
a. The C-Kermit executable should be copied to the directory that is
normally used for launching Internet services, and renamed to
"iksd". Normally the owner and group should be root and the
permission 0750.
The following entry should be added to the Internet services file,
normally /etc/services:
kermit 1649/tcp
b. An entry must be made in the inetd configuration file, normally
/etc/inetd.conf. See your system-specific documentation for the
name, location, and format of this file, e.g. "man inetd" and "man
inetd.conf". Typical example:
kermit stream tcp nowait root iksd -A other-iksd-options
Or, with TCP wrappers:
kermit stream tcp nowait root tcpd iksd -A other-iksd-options
Include full pathnames for tcpd and iksd if required. See
[43]Section 4 for iksd-options. NOTE: Different platforms might
require different syntax, e.g.:
kermit stream tcp nowait root /usr/sbin/iksd iksd -A other-iksd-options
c. When using TCP wrappers, make the appropriate entries in its
configuration file(s), such as /etc/hosts.allow and
/etc/hosts.deny. See the TCP wrappers documentation for further
info.
d. Make any required hard or soft links to the iksd executable.
e. If desired, create an IKSD configuration file (/etc/iksd.conf by
default).
This setup allows multiple simultaneous IKSD sessions. A fresh IKSD
process is started for each session, and disappears when IKSD exits,
automatically closing the session and the connection.
To kill a particular instance of IKSD, find its pid with "ps ax | grep
iksd" (or the equivalent command to list all processes) and then "kill
-9 pid" (as root).
To update the IKSD program, simply replace the executable in the
"launch" directory ([44](a) above).
To discontinue IKSD service quickly, delete the iksd executable, or
(to avoid unwanted console logging) replace it with (say) /bin/false.
_________________________________________________________________
3. Compile-Time Configuration Options
You can use any C-Kermit configuration as an IKSD, ranging from a
fully configured version, to a special IKSD-Only version, to any of
the various "stripped-down" versions, as described in the C-Kermit
Configuration Guide ([45]ckccfg.txt) and/or Installation Instructions
([46]ckuins.txt).
The following compile-time options are specific to or of special
relevance to the IKSD:
TNCODE - Required for IKS.
Include Telnet protocol code, even if networking code is not
included. Defined by default if TCPSOCKET defined, otherwise
must be defined explicitly.
IKS_OPTION - Required for IKS.
Include code for the new Internet Kermit Service Option.
Currently defined automatically if TNCODE is defined.
CK_LOGIN - Required for IKS.
Include user authentication code. Defined automatically for
UNIX unless NOLOGIN defined.
CK_PAM
The IKS is to be compiled to use PAM (Pluggable Authentication
Modules) to authenticate the user for interactive logins
instead of Unix password files. The default PAM service type
for IKSD is "kermit".
PAM_SERVICE_TYPE
If CK_PAM is defined and you wish to use a service type other
than "kermit" you can define PAM_SERVICE_TYPE to equal the
string you wish to use.
CK_SHADOW
If your host utilizes the shadow password system for storing
user passwords the IKS must be compiled with support for shadow
passwords. This might also require some additional libraries
added the LIBS clause, such as -lgen, for loading the
getspnam() routine.
CKSYSLOG
Include code for making syslog entries. This symbol is defined
automatically if (a) CK_LOGIN is defined; (b) UNIX is defined;
and (c) NOSYSLOG is not defined.
CKWTMP
Include code for making wtmp log entries. This symbol is
defined automatically if (a) CK_LOGIN is defined; (b) UNIX is
defined; and (c) NOWTMP is not defined.
WTMPFILE
String containing pathname of the default wtmp logfile. If not
specified, a default is supplied, currently /var/log/wtmp on
Linux and /usr/adm/wtmp elsewhere. The wtmp file can also be
specified at runtime; see [47]next section.
CK_CURSES
Need not be defined in an IKSD-only build, since curses is used
only in local mode, and the IKSD is always in remote mode, plus
the fact that curses initialization can cause spurious error
messages in IKSD since it might not have a terminal type (TERM
variable) in its environment.
NOLOCAL
This may be defined to exclude all code relating to the making
of both serial and network connections from the C-Kermit/IKSD
executable. This code is presently not needed, and is never
used, in the IKSD. Compiling it out reduces the size of the
executable and eliminates any possibility that a loophole could
be exploited to use the IKSD as a relay.
NOPUSH
This symbol may be defined to exclude all code that is used to
access local shell or system functions, such as the RUN (!)
command, the server end of the REMOTE HOST command,
file-transfer pipes and filters, etc. Note that such code is
disabled at runtime in the IKS anyway; compiling it out
completely reduces the size of the executable and the risk of
loopholes.
NOICP
Disables the interactive command parser as well as long-form
command-line options ([48]Section 4.1). In this configuration,
the IKS runs only in Kermit Server mode, and the size of the
executable is reduced dramatically. WARNING: NOICP also
inhibits extended command-line options (the ones that start
with "--"), since these share the same parsing routines as the
interactive parser.
NOSPL
Disables the script programming language (INPUT, OUTPUT, FOR,
WHILE, IF, SWITCH, macros, variables, etc) without disabling
the interactive command parser.
NOGETUSERSHELL
Add this if the link steps fails because it can't resolve
getusershell() and/or endusershell(). Normally, IKSD will
refuse a login if the user's login shell is not one of those
returned by getusershell() (normally, getusershell() simply
lists the shells listed in /etc/shells, but we can't depend on
this). Thus if your site "invalidates" user IDs by setting
their login shell to something that is not really a shell (like
/etc/nologin), but does not have a getusershell() function,
IKSD will still let such users log in unless (a) you put them
in the forbidden users file (see [49]Section 4.1), or (b) add
some code to ckufio.c to check for whatever invalid or valid
shells might apply at your site.
NOIKSD
This defines the symbols NOLOGIN, NOSYSLOG, NOWTMP,
NOPRINTFSUBST, which in turn prevent the definition of symbols
(CK_LOGIN, CKSYSLOG, etc) that cause IKSD-specific code to be
included.
CK_SYSINI
CK_DSYSINI
System-wide initialization file; see [50]Section 4.4.
IKSD
Is defined automatically if NOIKSD is not defined.
IKSDCONF
The name of the IKSD configuration file. In UNIX this is
"/etc/iksd.conf" by default; elsewhere "iksd.cfg".
In an IKSD-only build, you should omit the termcap/termlib and
(n)curses libraries, and set up the link step to make sure the IKSD is
linked with the same user authorization libraries used by your local
login program. Here is a sample for SunOS 4.1.3 at a particular site:
sunos41giks:
@echo Making C-Kermit $(CKVER) for SunOS 4.1 with gcc for IKS...
$(MAKE) wermit "CC= gcc" "CC2= gcc" \
"CFLAGS= -O -DSUNOS41 -DNDGPWNAM \
-DTNCODE -DNOLOCAL -DNOPUSH $(KFLAGS)" \
"LIBS= -L/usr/local/lib -lpwent -lcrypt"
in which:
* -DNOLOCAL excludes all code that is used to make connections.
* -DNOPUSH excludes all code that accesses local system shells and
commands.
* -DTNCODE includes Telnet protocol code even though -DNOLOCAL is
included.
At sites that use shadow passwords, you'll need to add -DCK_SHADOW to
CFLAGS and perhaps -lgen to LIBS.
Also note that the crypt() function, which is used for verifying
passwords, is normally found in libc, but on some platforms it has
been broken out into a separate library, such as -lcrypt, and in that
case must be included in the LIBS clause.
For PAM installations, here's an example /etc/pam.d/kermit file that
uses EPS password files for user authentication and the standard unix
modules for account and session management:
auth required /lib/security/pam_eps_auth.so
password required /lib/security/pam_eps_passwd.so
account required /lib/security/pam_unix_acct.so
session required /lib/security/pam_unix_session.so
Kerberos IV, Kerberos V, SRP, and TLS can also be selected at build
time if you have the appropriate libraries and header files installed
on your system. See the [51]Kermit Security Reference for further
details.
For a build that excludes all IKSD functions, it is normally
sufficient to add NOIKSD to the CFLAGS, e.g.:
make aix41 KFLAGS=-DNOIKSD
_________________________________________________________________
4. Runtime Configuration Options
The IKSD can be configured at runtime with command-line options or by
an initialization file or other auxilliary file(s), in any
combination. The SHOW IKSD command lists the IKSD-relevant parameters
and their values.
4.1. Command-Line Options
To start C-Kermit as an Internet Kermit Service Daemon, include the
'-A' command-line option. This option not only configures C-Kermit as
an IKSD, but it also ensures that you are running a version of
C-Kermit that can do this, i.e. C-Kermit 7.0 or later built with all
the necessary compile-time options ([52]Section 3). If either of these
conditions does not apply, the '-A' option will be invalid and the
Kermit program will halt immediately.
In addition to -A and the command-line options described in [53]Using
C-Kermit (2nd Edition), plus any other new ones described in the
[54]C-Kermit 7.0 Update Notes and [55]C-Kermit 8.0 Update Notes, a
selection of new long-form options apply specifically to the IKSD.
Long-form options work as follows:
a. All long-form options must begin with "--" (two hyphens) or "-+".
If the option begins with "--" it is executed before or after the
C-Kermit initializaton file, according to its internal keyword
flags. If it begins with "-+", it is executed before the init
file, regardless of the keyword flags. There is no way to force an
argument to be executed after the init file if it has the CM_PRE
bit set (see table below).
b. No spaces are allowed in the keyword.
c. If an operand contains spaces, it (or the entire option) must be
quoted according to the rules of the shell from which Kermit is
invoked.
d. Case doesn't matter in the option keyword (unlike with regular
single-letter options).
e. If an operand is required, it must be included. If no operand is
required, no operand must be included.
f. The operand follows the keyword, separated by a colon (:) or equal
sign (=). There are no spaces between the separator and the
keyword or operand.
g. Long-form option names may be abbreviated according to the same
rules as interactive keywords.
h. On/Off operands can be On, Off, Yes, No, True, False, 0, 1, or OK
(case of letters does not matter).
i. Long-form options are available only when the interactive command
parser is built-in (i.e. not NOICP).
The new long-form options are:
Option Values Default CM_PRE Effect
--anonymous on/off on yes anonymous login allowed
--bannerfile filename (none) no greeting message
-+cdfile filelist (see below) no CD message filename
-+cdmessage on/off on no CD messages on/off
-+cdmsg on/off on no synonym for cdmessage
--help (none) (n/a/) no list available --options
--helpfile filename (none) no custom text for HELP command
--initfile filename /.kermrc yes Init file for anonymous users
--nointerrupt (none) (see below) yes Disables SIGINT and SIGTSTP
--permissions octalnum 0040 yes anonymous upload permissions
--perms octalnum 0040 yes synonym for permissions
--root directory /pub/ftp yes root for anonymous users
--syslog number 3 yes level of syslogging
--timeout number 300 yes time limit for login
--userfile filename /etc/ftpusers yes forbidden local users list
--wtmplog on/off on yes wtmp logging on/off
--wtmpfile filename (see below) yes pathname of wtmp logfile
--xferlog on/off off yes use an ftpd-logfile
--xferfile filename (see below) yes pathname of ftpd-like logfile
Note: in all options that take a filename, except --cdfile, relative
filenames or filenames that start with ~ are expanded to full
pathnames.
In more detail:
--nointerrupts
Disables keyboard interrupts that are normally enabled. In
IKSD, when it is in interactive prompting state, commands can
normally be interrupted with Ctrl-C. Suspending (normally via
Ctrl-Z) is always disabled in IKSD.
--help
Lists the extended command-line options that are available in
your version of C-Kermit. If any options seem to be missing,
that is because your copy of C-Kermit was built with
compile-time options to deselect them.
--helpfile:filename
Specifies the name of a file to be displayed if the user types
HELP (not followed by a specific command or topic), in place of
the built-in top-level help text. The file need not fit on one
screen; more-prompting is used if the file is more than one
screen long if COMMAND MORE-PROMPTING is ON, as it is by
default.
--anonymous:{on,off}
Whether anonymous logins are allowed. By default they are
allowed, so this option need be included only to disallow them
(or for clarity, to emphasize that they are allowed). Anonymous
login occurs when the username "anonymous" or "ftp" is given,
with any password (as with ftpd).
--timeout:number
This sets a limit (in seconds) on the amount of time the client
has to log in once the connection is made. If successful login
does not occur within the given number of seconds, the
connection is closed. The default timeout is 300 seconds (5
minutes). A value of 0 or less indicates there is to be no
limit.
--bannerfile:filename
The name of a file containing a message to be printed after the
user logs in, in place of the normal message (Copyright notice,
"Type HELP or ? for help", "Default transfer mode is...", etc).
--permissions:octalnum
The permissions given to any file that is uploaded by an
anonymous user. 0040 is the default and recommended value. The
default permits only group-read access, and therefore prevents
anonymous users from uploading files (e.g. pirated sofware) to
be downloaded by other anonymous users. Synonym: --perms.
--initfile:filename
The initialization file to be executed for anonymous logins. By
default it is /.kermrc, where "/" is the root of the chroot'd
file system. Any filename that you specify here must be
specified in the notation of the the chroot'd file system. This
option is independent of the '-y' option (alternative init
file), which applies only to real users.
--cdmessage:{on,off,0,1,2}
For use in the Server-Side Server configuration; whenever the
client tells the server to change directory, the server sends
the contents of a "read me" file to the client's screen. This
feature is On by default, and operates only in client/server
mode when ON or 1. If set to 2 or higher, it also operates when
the CD command is given at the IKSD> prompt. Synonym: --cdmsg.
--cdfile:filename (or list)
When cdmessage is on, this is the name of the "read me" file to
be sent. Normally you would specify a relative (not absolute)
name, since the file is opened using the literal name you
specified, after changing to the new directory. Example:
--cdfile:READ.ME
You can also give a list of up to 8 filenames by (a) enclosing
each filename in braces, and (b) enclosing the entire list in
braces. Example:
--cdfile:{{./.readme}{READ.ME}{aaareadme.txt}{README}{read-this
-first}} When a list is given, it is searched from left to
right and the first file found is displayed. The default list
for UNIX is:
{{./.readme}{README.TXT}{READ.ME}}
--database:{on,off}
Whether an active-sessions database should be kept. On by
default. If "on", but --dbfile is not specified,
/var/log/iksd.db is used.
--dbfile:filename
Use this option to specify an iksd database file name. If you
include this option, it implies .
--syslog:number or {on,off}
Whether and what level of syslog entries should be made. A
level of 0 (or "off" or "false" or "no") means no syslogging. A
level of "on" (or "yes" or "true") invokes the default
syslogging level. To choose a non-default level of syslogging,
specify a number (see [56]Section 4.2).
--wtmplog:{on,off}
Whether wtmp log entries should be made. On by default. An
entry is made when the user logs in and when the session is
closed. The "tty name" field is given as "iks_xxxx", where xxxx
is the process ID (pid) of the IKSD. Thus IKSD session history
can be monitored via "last | grep iks_". Anonymous logins are
shown with a user ID of "ftp".
--wtmpfile:filename
The default wtmp log file is /var/log/wtmp in Linux, and
/usr/adm/wtmp elsewhere. In case your system's wtmp log file
does not match the default, use this option to specify the
appropriate filename.
--userfile:filename
This file contains a list of local usernames that are to be
denied access to Internet Kermit Service. The default is
/etc/ftpusers. This can be the same file that is used by
wuftpd, and the syntax is the same: one username per line;
lines starting with "#" are ignored. Use this option to specify
the name of a different forbidden-user file, or use
--userfile:/dev/null to disable this feature in case there is a
/etc/ftpusers file but you don't want to use it.
--xferlog:{on,off}
Whether a wu-ftpd-like log should be kept. Off by default. If
"on", but --xferfile is not specified, /var/log/iksd.log is
used. This log is explained in [57]Section 4.3.
--xferfile:filename
Use this option to specify an iksd log file name. If you
include this option, it implies --xferlog:on.
--database:{on,off}
Whether an active-sessions database should be kept. On by
default. If "on", but --dbfile is not specified,
/var/log/iksd.db is used.
--dbfile:filename
Use this option to specify an iksd database file name. If you
include this option, it implies --database:on.
Some of the traditional options have special significance in the IKS,
e.g.:
-x (server mode)
If this option is included on the IKSD command line, the Client
Side Server configuration is disabled, and the user will not
get a Username: or Password: prompt, and will not be able to
access the IKSD command prompt. A FINISH command sent to the
IKSD will log it out and close the connection, rather than
returning it to its prompt.
-y filename
Execute "filename" rather than the normal initialization file
for real users; this option does not apply to anonymous users.
-Y (no init file)
Do not execute an initialization file, even if a real user is
logging in.
Examples:
kermit -A
Starts the Internet Kermit Server with all defaults in effect.
iksd
Equivalent to "kermit -A". If the binary is invoked as "iksd"
(e.g. through a symlink) rather than "kermit", the -A option is
not necessary.
iksd --syslog:5
As above, but with the highest level of syslogging ([58]Section
4.2).
iksd --anonymous:off --cdfile:READ.ME
Starts the IKSD with anonymous access forbidden and changes the
name of CD message file from the default list to READ.ME.
iksd -x --anonym:no --cdf:READ.ME
As above, but forces the IKSD to operate only in Kermit server
mode, thus preventing user access to the IKSD command prompt.
Also illustrates abbreviation of long-form option keywords and
use of "no" as a synonym for "off".
Bad syntax in an extended command-line option causes immediate
termination with the message "Extended option error", and an exit
status code of 1.
Brief help about command line options may be obtained at the C-Kermit
prompt with "help options", and for extended options with "help
extended-options".
You can prototype the IKSD command line by including any desired
extended options, but omitting the -A option, and then when you get
the C-Kermit> prompt, use "show extended-options" to check the parsing
of the options you have included. Example:
$ kermit --anonymous:ok --root:/tmp --userfile:/etc/badusers
(/users/olga/) C-Kermit>show extended-options
--bannerfile=(null)
--cdfile:./.readme
--cdmessage:0
--syslog:3
--wtmplog:1
--wtmpfile=(null)
--anonymous:1
--permission:0040
--initfile:(null)
--userfile:/etc/badusers
--root:/tmp
--xferlog=0
--xferfile=(null)
--timeout:300
(/users/olga) C-Kermit>
Note that this only shows the values that were given as arguments to
the extended options, or their default values, if they have any, but
it does not show values that will be computed dynamically at runtime
in the absence of a command-line value. For example, --wtmplog:1 and
--wtmpfile:(null) mean that an appropriate default will be supplied
for the wtmp logfile name at runtime.
Also note that SHOW EXTENDED-OPTIONS does not show the IKSD-specific
options when this command given at the IKSD prompt by the user. Thus
this command is useful only as a prototyping tool. (And as noted
elsewhere, the IKSD command-line argument vector is also inaccessible
to the IKSD user via other methods such as the \&@[] array.)
4.2. System Logging
System logging in UNIX is via the standard syslog() facility ("man
syslog" and/or "man syslogd" for further info).
All IKSD entries (except debugging, see below) appear in the daemon
log, as defined in the syslog.conf file with a tag of "iksd" and the
process ID (pid) of the IKSD process, and therefore can be extracted
by grepping for "iksd".
The system logging levels are:
0 = no logging
1 = Login/out, failed login attempts, failed Kerberos (etc) authentication
2 = Dialing out (does not apply to IKSD)
3 = Making any kinds of connections (does not apply to IKSD)
4 = Creating / receiving / deleting / renaming / copying files
5 = Sending / typing / reading / transmitting files
6 = All top-level commands and all server commands sent to iksd
7 = Commands executed from macros and command files
8 = Debug
Each level includes all the levels beneath it (except 0 is not
included if the logging level is greater than 0).
The default logging level is 5, and is used if the --syslog: option is
not included on the command line, or if is given with an affirmative
keyword (yes, true, on, ok) rather than a number. If you specify a
number higher than the the maximum, it is the same as specifying the
maximum.
Syslog entries are at LOG_INFO priority, except for refused logins,
which are at LOG_NOTICE priority, and failed Telnet-level
authentication (such as Kerberos), which are at LOG_ERR priority.
Note that if C-Kermit is built with -DSYSLOGLEVEL=n (where n is a
number) on the cc command line, this turns on syslogging and hardwires
it to the given level for all users. See
[59]ftp://kermit.columbia.edu/kermit/f/ckuins.txt for further info.
WARNING
Debug level produces VOLUMINOUS amounts of information -- it is
equivalent to (in fact, it is) C-Kermit's debug log.
Furthermore, there is a good possibility it will contain
sensitive information such as clear-text passwords. Debug
records are written to the syslog DEBUG facility, as defined
(or not defined) in syslog.conf. If you use this level of
logging, make sure that the logfile defined for "daemon.debug"
is secured from the public, and that there is plenty of space
for it.
ANOTHER WARNING
In some UNIX systems, syslogging does not work once a chroot()
has occurred, which is done by iksd just as it is by ftpd for
anonymous users, to restrict them to the /pub/ftp (or other
desired) directory tree. At present, SunOS and Linux are known
to have this deficiency and there probably are many others.
THERE IS NO SYSLOGGING FOR ANONYMOUS USERS on these systems.
The only way to log the activities of anonymous users on such
systems is to specify a transfer iksd log on the command line
([60]Sections 4.1 and [61]4.3).
4.3. The Transfer Log File
The transfer log is disabled by default; it must be enabled on the
command line ([62]Section 4.1).
The transfer log has the same format as the wu-ftpd log, and so all
the same scripts can be used to process it, collect statistics, etc.
In fact, you can even have ftpd and iksd share the same log, in which
case records will be intermixed.
The Transfer log can also be used in regular user-mode C-Kermit
sessions.
The first field is fixed-length and contains spaces; subsequent fields
are variable length, contain no spaces, and are separated by one or
more spaces. The fields are:
Timestamp
This is an asctime-style timestamp, example: "Wed Sep 16
20:19:05 1998" It is always exactly 24 characters long, and the
subfields are always in fixed positions.
Elapsed time
The whole number of seconds required to transfer the file, as a
string of decimal digits, e.g. "24".
Connection
In IKSD, the IP hostname or address of the client. For
user-mode C-Kermit transfers, The name of the network host to
which C-Kermit is connected, or the name of the serial device
through which it has dialed (or has a direct connection), or
"/dev/tty" for transfers in remote mode.
Bytes transferred
The number of bytes transferred, decimal digits, e.g.
"1537904".
Filename
The full pathname of the file that was transferred, e.g.
"/pub/ftp/kermit/a/README.TXT". If the filename contains any
spaces or control characters, each such character is replaced
by an underscore ('_') character.
Mode
The letter 'b' if the file was transferred in binary mode, or
'a' if it was transferred in text (ASCII) mode.
Options
For compatibility with the wuftpd log. This field always
contains an underscore ('_') character.
Direction
The letter 'o' if the file was transferred Out, and 'i' if the
file was transferred In.
User class
The letter 'r' for real users, or 'a' for anonymous users.
User identification
The user ID of a real user, or the password given by an
anonymous user.
Server identification
The string "iks" (Internet Kermit Server), or if C-Kermit is
running in user mode, "kermit". This distinguishes a Kermit
transfer log record from a WU-FTPD record, which contains "ftp"
in this field.
Authentication class
The digit '1' if we know the user's ID on the client system,
otherwise '0'. Currently, always '0'.
Authenticated user
If the authentication class is '1', this is the user's ID on
the client system. Otherwise it is an asterisk ('*'). Currently
it is always an asterisk.
4.4. The IKSD Configuration File
The IKSD configuration file is a place to put commands that should
always be executed for every client, real or anonymous.
When C-Kermit is started as IKSD, it always begins by reading the IKSD
configuration file, if any. By default this is /etc/iksd.conf (you may
change the definition at compile time by adding
-DIKSDCONF=\"filename\" to CFLAGS). This file contains ordinary
C-Kermit commands. Normally these would be SET or DISABLE commands. In
case any commands in this file write to standard output, remember that
IKSD's standard output is the connection to the client. For more ideas
about what can go in the iksd.conf file, read the next section -- the
difference is that when you put commands in the iksd.conf file, they
apply not only to anonymous users, but to real users too. So, for
example, if you want to disable uploads for all users, you could put
DISABLE SEND in the iksd.conf file, whereas if you wanted to disable
them only for anonymous users, you would put this command in the
anonymous-user initialization file.
The IKSD configuration file is executed before the user logs in (or is
otherwise authenticated), before the C-Kermit initialization file, and
before any extended-format command line options that start with "--",
but after any that are marked CM_PRE in the table in [63]Section 4.1,
or that start with "-+". Since execution occurs before login, the
\v(user) variable is meaningless here.
4.5. The Initialization File
When a real user logs in to the IKSD, the C-Kermit initialization file
is executed in the normal manner, depending on the compile-time
configuration of the IKSD. Normally, the user's own .kermrc file is
executed, and this, in turn, executes the user's customization file,
.mykermrc. If the IKSD was built with the CK_SYSINI or CK_DSYSINI
compile-time options (described in [64]ckccfg.txt), a single, shared
system-wide initialization file is executed instead; this may, in
turn, execute a customization file out of the user's home directory.
You may override C-Kermit's automatic selection of initialization with
the regular C-Kermit -y or -Y options on the IKSD command line,
described in the C-Kermit manual.
For anonymous users, the default initialization file, if any, is
.kermrc in the chroot'd file system. This default may be overridden
with the --initfile:xxx command-line option. The system administrator
may include commands in this file to disable selected services for
anonymous users, e.g.:
disable delete ; Don't let anonymous users delete files
disable send ; Don't let anonymous users send files
Of course, any Kermit commands at all may be included: settings, macro
definitions, etc. (Also see [65]Section 5.5.)
When the sysadmin specifies the initialization file, this allows a
high degree of fine-grained control over who is allowed access to what
commands and resources, using standard C-Kermit commands, functions,
and variables. The following are particularly useful:
\v(date), \v(ndate)
The current date, in case you want to restrict access by date.
(Also read about the new date-related functions in [66]Section
1.6 of the [67]C-Kermit 7.0 Supplement.)
\v(day), \v(nday)
The day of the week, in case you want to restrict access to
certain days of the week.
\v(home)
The user's home directory.
\v(host)
The hostname of the IKS.
\v(ipaddress)
The IP address of the IKS. This and/or \v(host) may be used
when you are running an IKS on multiple hosts and want to have
different setups on each, but still have a common
initialization file.
\v(line)
The IP host name or address of the client's host.
\v(time), \v(ntime)
The current time of day, in case you wish to restrict access to
certain times of day.
\v(userid)
The ID with which the user logged in to the IKS. For anonymous
logins, this is "ftp".
So, for example, if the sysadmin wishes to prevent user "olga" from
using the IKS on Mondays, the initialization file could contain a
command like:
if equal \v(user) olga -
if equal \v(nday) 1 -
exit 1 Sorry Olga - please come back another day
Or suppose it is desirable to block access from all xyzcorp.com hosts
between 9:00am and noon:
if match \v(line) *.xyzcorp.com -
if lgt \v(time) 09:00:00 -
if llt \v(time) 12:00:00 -
exit 1 Sorry - Please come back after noon
Or suppose a certain user is to be allowed to GET files from the
server, but not SEND, PRINT, or MAIL them:
xif equal \v(user) ivan {
disable send
disable print
disable mail
disable enable
}
_________________________________________________________________
5. Access to Services
The IKSD behaves at runtime just like the regular C-Kermit program,
with any restrictions resulting from compile-time options, and with
the differences noted in this section and in [68]Section 4.
5.1. Automatic Settings
When C-Kermit is started as an Internet Kermit Service, the following
settings occur automatically:
a. Login (authentication) is required.
b. Shell access is disabled.
c. Server-side Telnet negotiation is enabled.
d. SET RELIABLE ON (see the [69]C-Kermit 7.0 Supplement).
e. FAST file-transfer settings, including "cautious" unprefixing.
f. No flow control, no parity.
Items d-f can be overridden with command-line options and/or in the
initialization file.
5.2. Authentication
The IKSD command prompt will not appear, and no commands may be given,
before the user is authenticated.
When the IKSD has been started without the '-x' command-line option,
it issues a Username: prompt. The user may type a username at the
prompt, in which case a Password: prompt is issued, and the user must
enter a password. Three login attempts are allowed, with a pause
enforced between each one. If all three fail, the connection is
closed.
The user may also authenticate from the client by sending a [ REMOTE ]
LOGIN command (again, only 3 tries are allowed), or by Telnet
Authentication negotiations. Prior to authentication, the IKSD
responds to only the following client commands:
[ REMOTE ] LOGIN
[ REMOTE ] LOGOUT
REMOTE HELP (or RHELP)
REMOTE EXIT (or REXIT)
BYE
Once authenticated, the user may not re-authenticate or change
identities.
The connection persists until it is broken in any of the following
ways:
a. Client sends BYE or REMOTE EXIT (REXIT) or [ REMOTE ] LOGOUT to
IKSD.
b. Client sends FINISH to IKSD that has been started with "-x".
c. User gives HANGUP or CLOSE command to the client.
d. User gives EXIT, QUIT, or LOGOUT command at IKSD prompt.
The connection is also closed if the user exits from the client, but
only if it was an end-to-end Telnet connection. There can be no
guarantee that exiting from a serial communication program will close
and hang up the serial connection.
5.3. The DISABLE Command
In the IKSD, the DISABLE command applies not only to client/server
functions, but also to the corresponding commands when given at the
prompt. For example, DISABLE DELETE disables not only REMOTE DELETE
commands given from the client, but also DELETE commands given at the
IKSD's command prompt, as well as implicit forms of file deletion,
such as when the target of a COPY command is an existing file.
The DISABLE ENABLE command is irreversible; once this command is
given, the ENABLE command can not be re-enabled, and therefore no
other disabled commands can be enabled either. ENABLE is DISABLEd
automatically for anonymous users, so any DISABLE commands in the
anonymous-user initialization file ([70]Section 4.4) are also
irreversible.
5.4. Shell Access
All forms of system and shell access are disabled in the IKS. Thus the
user can not execute REMOTE HOST commands from the client, nor access
the shell from the IKS command prompt via shell escapes (!), the RUN
or PUSH command, or by specifying pipes or filters in file-transfer
commands, or by pipe specifications in REMOTE commands, or in any
other way. This is true even if the executable was built without the
NOPUSH compile-time option.
5.5. Anonymous Users
Anonymous users are allowed by default, but can be denied with
--anonymous:no on the command line ([71]Section 4.1).
Anonymous users are handled in about the same way as they are by ftpd.
Their effective user ID is set to "ftp" and their file-system access
is restricted to the tree rooted at the home directory of the "ftp"
user, normally /pub/ftp, via chroot. If /pub/ftp does not exist, login
fails. In that case (or for any other desired reason), the anonymous
root directory can be changed with the --root: option, e.g.
--root:/tmp. Note that, unlike ftpd, iksd does not necessarily require
any particular binaries (such as ls) to be in the chroot'd tree. DLLs
might be another story, but so far these have not been needed, even
with dynamically linked Kermit binaries (at least in Linux and
Solaris). Should DLLs be a problem, use a statically linked Kermit
binary (if possible), or install the needed DLLs in the anonymous
root.
File access is according to user "ftp" and the directory and file
permissions of the /pub/ftp tree. If anonymous uploads are to be
allowed, then usually only specific directories (often with a name
like "incoming") are given write permission, and any files that are
created in such a directory have owner "ftp", with the group set to
the group of the directory. As noted in [72]Section 4.1, the
permission for all files created by anonymous users is 0040
(group-read only), or whatever else the sysadmin has specified in the
--permissions: command-line option.
Thus, if you already have a public ftp server, most likely everything
is set up appropriately already">up appropriately already. If
anonymous ftp is allowed (by the presence of a valid user "ftp" in
your system's password file), it will be allowed also for IKSD unless
explicitly disallowed on the IKSD command-line (or if /pub/ftp doesn't
exist and you did not supply a --root: option on the command line).
In addition to the FTP-like restrictions, certain Kermit services are
always denied to anonymous users. These include:
* PRINT (at IKSD prompt) and REMOTE PRINT (from client)
* MAIL (or SEND /MAIL) at IKSD prompt and from client.
* Creation of any logs (transaction, debug, packet, etc).
* No file may be deleted, including implicitly, e.g. by the COPY
command.
* FILE COLLISION is set to RENAME and may not be changed.
The latter three provisions mean that anonymous users can not delete,
overwrite, rename, or alter any existing files in any way, whether by
file transfer or with the DELETE or RENAME command.
Note that IKSD, like FTPD, does not allow directory creation by
anonymous users, even when file/directory permissions would otherwise
allow it. To change this, add:
enable mkdir ; Enable directory creation
to /pub/ftp/.kermrc (or whatever other initialization file you have
designated for anonymous users with --initfile). Similarly for
directory removal:
enable rmdir ; Enable directory removal
Of course directories can be removed only if (a) they are empty, and
(b) their permissions allow it.
5.6. Management Information
The command-line argument vector, normally accessible in the \&@[]
array, the top-level \%0..9 variables, or by other means, is
inaccessible to IKSD users. Thus IKSD clients can not discover the
IKSD startup path or options, the logfile pathnames or directories,
logging level, etc.
_________________________________________________________________
6. Open Issues
Several services that are normally provided by C-Kermit are not
available when it is an Internet Kermit Service Daemon.
6.1. Connection Establishment
If the user has access to the IKSD command prompt, why not allow her
to "set host" or "set line" from there to another place? Obviously
this would be a security risk if allowed for anonymous users. For
authenticated users, it should be OK, but is not currently possible
for Telnet connections since the IKSD is already a Telnet server on
the incoming connection, and is not designed to conduct two separate
Telnet sessions simultaneously. It might be possible to allow the user
to make a dialout connection, but some coding and testing would be
needed should this prove desirable.
6.2. Shell Access
Shell access is forbidden to anonymous users for obvious reasons. From
a security standpoint, it could be allowed for authenticated users,
but there remains a technical obstacle: the absence of a terminal
driver for the connection.
6.3. External and/or non-Kermit Protocols
External protocols such as Zmodem can not be expected to perform any
of the logging or security functions that are done by C-Kermit itself
within its protocol and file modules. Thus external protocols are
disabled in the IKSD. Plus the fact that such protocols are likely to
be incompatible with Telnet connections in the first place. In more
detail:
* When the user is 'anonymous' the file system is chroot'd, which
means that any external executables must exist in the chroot'd
file system. This leaves open the possibility that executables
might be replaced by a different file of the same name that has
been uploaded either on top of the existing file or just into the
same directory. If "." is in the PATH for the process anything the
user uploads with the name 'rz' or 'sz' might be executed in its
place. Therefore, the IKSD does not use any external commands of
any kind. Not 'ls', not 'cp', not 'df', not anything. To allow the
execution of external programs is a major security hole in this
setting.
* Most implementations of 'sz' and 'rz' are designed for remote use
over a terminal connection. They expect to be run underneath a
pseudoterminal (PTY). When IKSD is running there is no PTY. In
fact, when IKSD is running there is only a raw socket; the IKSD
handles all necessary Telnet protocol translations including
Telnet Network Virtual Terminal (NVT) rules regarding quoting of
Carriage Return and 0xFF depending upon the state of the BINARY
Telnet option in each direction. 'sz' and 'rz' are completely
incapable of performing these translations in either direction and
any attempt to transfer a file with them will result in a transfer
failure and the corruption of the data stream.
* IKSD supports encrypted sessions, in which case it handles the
encryption and decryption itself; an external protocol module
would not do this, and so could not be used on encrypted channels
in any case.
6.4. Additional Administrative Controls
Certain options available in wu-ftpd are not implemented in iksd:
* Ability to select IKSD logging for real vs anonymous users.
* Ability to select IKSD logging for inbound vs outbound files.
+ Currently all transfers are logged or not logged.
* Ability to allow/restrict chmod/delete/overwrite for anonymous
users.
+ Currently there is no command for changing file permissions.
+ Guests may not delete files, period.
+ FILE COLLISION is set to RENAME for guests and may not be
changed since all the other options allow existing files to
be altered.
+ There is no way to grant these capabilities to guests.
* Ability to allow directory creation by anonymous users.
+ Anonymous users may not create or remove directories.
* Ability to allow/specify CD messages on a per-directory basis.
* RFC931 authentication of remote (client) user (but wu-ftpd doesn't
either).
These or other controls can be added if there is sufficient reason or
demand.
6.5. Known Bugs
* When commands are logged in syslog, the EXIT command appears
twice.
* wtmp entries show pids in hex due to length restrictions, so
you'll need to convert them to decimal before using them with ps,
kill, etc.
_________________________________________________________________
7. Monitoring
Unless you disable it, all IKSDs keep current session information in a
shared database. The IKSD instances can be within one computer or
running on any number of different computers that share the same file
system on the same network. The database can be monitored by the
sysadmin with a simple "systat"-like display program, which shows who
is logged in, from where, and what they're doing. (The idea is easily
adapted to other servers, such as FTP.) For maximum portability and
reliability, the database is an ordinary file on disk.
The IKSD database file should reside in its own directory (to avoid
conflicts with other servers that might use the same filename
conventions), and this directory and its files should be visible to
the sysadmin without privileges (e.g. by group access) but hidden from
the public for privacy reasons if other such logs (e.g. the ftpd log,
syslog, etc) also are.
The database is a random-access file indexed by "slot number", which
is self-assigned during a quick search at startup. Once a slot is
claimed, there is no more searching; each IKSD updates its own slot in
place and does not touch the others. Slots never move.
When an IKSD instance starts, it must obtain a "slot allocation lock"
before it can claim its slot. Otherwise there could be a race
condition when another IKSD instance starts at the same time, in which
the two could wind up with the same slot.
Since exclusive access is a nonportable concept, we obtain the lock in
a crude but portable manner, without recourse to kernel locks,
interprocess communication, semaphores, memory-mapped files, or other
platform-specific mechanisms:
a. Create a temp file in the database directory called ip.pid,, where
ip is the local IP address as 8 hex digits and pid is my own
process ID (PID) in hex (no leading zeros). This is guaranteed to
be a unique name (and if by chance a file of this name already
exists, it can't possibly be valid, so it it's ok to overwrite
it).
b. Write my own ID string into the file. The ID string is ip:pid,
where ip is (again) my IP address as 8 hex digits, and pid is my
PID in decimal (not hex). (The reason for decimal here is
readability, so sysadmins can easily enter it into other tools or
commands; it has to be hex in the temp filename for compactness in
case of 14-character filename limitations.)
c. Try to open iksd.lck, which is the real lockfile. If this
succeeds, read its contents (an ip:pid string). If the ip not the
same as mine, consider the file locked. If it is the same, extract
the PID and check its validity. If it is not valid, delete the
lockfile. (Currently this step is skipped by K95 since it can't
check PIDs.)
d. At this point the iksd.lck file might or might not exist. Try to
rename the temp file to iksd.lck. This will fail if the lockfile
exists, in which case we sleep, loop, and try again, up to a
certain number of times -- say 16 tries spaced 1 second apart. If
we fail to get a lock, we let the user on anyway, in the spirit of
service over management. If the rename succeeds, on the other
hand, we have a lock.
When and if we have obtained a lock, we open the database file itself
and search the whole database (sequentially) for:
a. Free slots (In-Use flag is 0), or:
b. Stale slots(*), or:
c. Any slot with our own IP and PID (a special kind of stale slot).
(*) In-Use flag is 1 and IP address is ours, but PID is invalid.
In C-Kermit only (not K-95) we also perform some housekeeping duties
while searching (the Windows APIs include no provisions for this):
a. Whenever a stale slot is found, we free it (set its In-Use flag to
0).
b. We remove all free slots after the last in-use slot by truncating
the database file (this keeps the database file from constantly
growing as new highwater marks are reached).
Then we claim the first one of these that was found. If no slot was
claimed, we add a new slot at the end and claim it. If the database
file did not exist, we create it and claim the first slot. (In
Windows, the IKSD listener simply deletes the existing database, if
any, on initial startup.)
To claim a slot:
a. We set the In-Use flag to 1, fill in the Server PID and IP address
fields with our own PID and IP address, fill in the session-start
and update time fields, and clear the other fields.
b. Then we release the lock.
From this point, we can write freely into our slot regardless of
locks.
Notes:
a. Since all IKSDs follow the same procedure, only one can have a
lock a at a time.
b. The lockfile is readable text; it can be typed (cat'd). The
contents are the same format on every platform, regardless of byte
order or word size.
c. This scheme allows (but does not require) multiple computers that
share a common file system to have a single IKSD database, which
in turn allows the site manager to monitor all IKSDs on all
computers at once. This works if each computer has a unique IP
address (which it must if they are on the same network sharing a
common file system; nevertheless, care must be taken regarding IP
address pools, etc). It also depends on the file- sharing
mechanism (such as NFS) to propogate updates promptly and in
sequence.
d. While one IKSD is allocating its slot, nothing prevents other IKSD
instances that already have their own slots from updating them,
since that does not interfere with slot allocation.
e. The tempfile name format is UNIXish and will need modification for
file systems with restrictive names, such as FAT, 14-char UNIXes,
etc. In such cases we could (a) omit the IP address if we're not
concerned about multiple computers sharing a single database, or
(b) encode the IP address in Base 64 to make it shorter. But
probably none of this will ever come up.
f. The design accommodates 64-bit IPv6 addresses, but for now the
software uses only 32 bits.
7.1. Database Record Format
A slot is 4K (4096 octets), divided into 4 1K chunks. The first chunk
is further subdivided into shorter fields. Numeric fields are coded in
hexadecimal, right-adjusted, and left-padded with 0's. Text fields are
left-adjusted and right-padded with blanks. Date-time fields are
right-adjusted within a field of 18 with the leading blank reserved
for Y10K. Date-time format is:
yyyymmdd hh:mm:ss
where yyyymmdd are the numeric year, month, and day, and hh:mm:ss are
the hour (24-hour clock), minute, and second. Months and days are
1-based, leading 0's are supplied where needed.
The layout of each slot is as follows (fields and byte positions are
numbered from 0):
0. FLAGS (Slot/Session Flags)
Start: 0
Length: 4
Type: Bit Mask
Format: Hex digits.
Bit Values:
1: 1 = Slot in use, 0 = Slot is free.
2: 1 = Real user, 0 = Anonymous user.
4: 1 = Logged in, 0 = Not logged in.
1. AUTHTYPE (Authorization Type)
Start: 4
Length: 4
Type: Number
Format: Hex digits.
Values:
0: None 8: (reserved)
1: Kerberos IV 9: (reserved)
2: Kerberos V 10: LOKI
3: SPX 11: SSA
4: MINK 12: KEA_SJ
5: SRP 13: KEA_INTEG
6: RSA 14: DSS
7: SSL 15: NTLM
2. AUTHMODE (Authorization Type)
Start: 8
Length: 4
Type: Number
Format: Hex digits.
Values:
0: Rejected
1: Unknown
2: Other
3: User
4: Valid
3. STATE (IKSD State)
Start: 12
Length: 4
Type: Bit Mask
Format: Hex digits.
Bit Values:
1: Initializing
2: Sending a file
4: Receiving a file
8: Executing a REMOTE command
32: At command prompt
4. PID (IKSD's Process ID)
Start: 16
Length: 16
Type: Number
Format: Hex digits.
5. SERVER IP (IKSD's IP Address)
Start: 32
Length: 16
Type: IP address as a series of numeric octets in network byte order
Format: Hex digits
6. CLIENT IP (Client's IP Address)
Start: 48
Length: 16
Type: IP address as a series of numeric octets in network byte order
Format: Hex digits
7. SESSION START (Date and Time session started)
Start: 64
Length: 18
Type: Date-time
Format: Date-time string
8. LAST UPDATE (Date and Time this record was last updated)
Start: 82
Length: 18
Type: Date-time
Format: Date-time string
9. ULENGTH (Username length)
Start: 100
Length: 4
Type: Number
Format: Hex digits, right adjusted
10. DLENGTH (Length of current directory)
Start: 104
Length: 4
Type: Number
Format: Hex digits, right adjusted
11. ILENGTH (Length of state-specific information)
Start: 108
Length: 4
Type: Number
Format: Hex digits, right adjusted
12. RESERVED
Start: 112
Length: 912
Type: None
Format: Filled with blanks
13. USERNAME (Username; if anonymous "anonymous:password")
Start: 1024
Length: 1024
Type: None
Format: Text, ULENGTH sigificant chars, right-filled with blanks
14. DIRECTORY (Current directory)
Start: 2048
Length: 1024
Type: None
Format: Text, DLENGTH sigificant chars, right-filled with blanks
15. INFO (State-specific information)
Start: 3072
Length: 1024
Type: None
Format: Text, ILENGTH sigificant chars, right-filled with blanks
The state-specific information tells you whether IKSD is at its
command prompt or in server command wait, if it is sending or
receiving a file (in which case the filename is shown), it is
executing a REMOTE command (in which case the command is shown), or
how it was terminated (BYE, REMOTE EXIT, disconnect, etc)
Notes:
a. There are no control characters (CR, LF, NUL, etc) or 8-bit
characters; only ASCII graphic characters are used in the
database. Fields are left- or right-padded with Space or '0' as
indicated.
b. Since the USERNAME, DIRECTORY, and INFO fields are right-padded
with spaces, it would be laborious to isolate their actual values
by trimming spaces from the right (since we must allow for
internal spaces); hence the ULENGTH, DLENGTH, and ILENGTH fields.
c. The USERNAME, DIRECTORY, and INFO fields are 1K each since 1K is
the maximum pathname length found on common UNIX platforms (even
though many platforms have smaller maximums). Thus, for example,
the current directory string might be exactly 1K long. This is why
its length is kept outside the block. Also the division of the
record into four 1K blocks tends to make for more efficient i/o.
d. The IKSD database does not provide a permanent record or give
complete information. That's what the syslog entries and the IKSD
log are for.
7.2 The Display Module
The straightforward data definitions and formats allow a display
module to be written easily in the language of your choice, including
scripting languages such as Kermit's own. A sample display module,
iksdpy, is provided as a "Kerbang" script, providing a running display
of the active IKSD sessions from the database. In its startup mode, it
lists each session in the database, refreshing every 4 seconds.
Various keystroke commands are available for help, quitting, etc, and
to enter the detail screen for a specific session. The detail screen,
too, refreshes itself every 4 seconds. Here you have keys to return to
the main screen, to pick another session, to cycle through sessions,
and so on.
When a slot is freed, its information is left intact so you can still
see who was using it, when, and from where, and the last thing they
did before logging out. The old info persists until the slot is
removed or reclaimed, which will happen when the next new IKSD session
starts.
The iksdpy script is short, simple, and easily extensible. For
example, while watching a detail screen and you see somebody doing
something bad, you might like to have a "K" key to kill the session
(the script already knows the pid, so it need simply form a "!kill -9"
command, including the pid).
7.3. Database Management
The following command-line options let you disable/enable the database
and specify its location:
--database:{on,off}
Whether an active-sessions database should be kept. On by
default. If "on", but --dbfile is not specified,
/var/log/iksd.db is used.
--dbfile:filename
Use this option to specify an iksd database file name. If you
include this option, it implies --database:on.
In UNIX, the system startup procedure can delete the database file
before starting inetd, since nothing in it is valid; however, this is
not necessary since normal cleanup procedures will do the job too. In
Windows, the IKSD listener takes care of it.
To capture a snapshot of IKSD usage, simply copy the database file.
_________________________________________________________________
8. TESTING
In case you want to test IKSD on a port other than 1649, be aware that
IKS-aware Kermit clients (such as C-Kermit 7.0 and K95 1.1.18 and
later) will not initiate Telnet negotiations with it, since it is not
on a Telnet port (i.e. 23 or 1649). To get correct operation you'll
need to force the client to negotiate, e.g.:
telnet hostname 3000
set host hostname 3000 /telnet
[[73]Top] [[74]C-Kermit Home] [[75]7.0 Update Notes] [[76]8.0 Update
Notes] [[77]Kermit Home]
_________________________________________________________________
C-Kermit IKSD Aministration / Columbia University /
kermit@columbia.edu / 12 Dec 2001
References
1. http://www.columbia.edu/kermit/
2. ftp://ftp.isi.edu/in-notes/rfc2839.txt
3. ftp://ftp.isi.edu/in-notes/rfc2840.txt
4. http://www.columbia.edu/kermit/iksd.html#x1
5. http://www.columbia.edu/kermit/iksd.html#x2
6. http://www.columbia.edu/kermit/iksd.html#x3
7. http://www.columbia.edu/kermit/iksd.html#x4
8. http://www.columbia.edu/kermit/iksd.html#x4.1
9. http://www.columbia.edu/kermit/iksd.html#x4.2
10. http://www.columbia.edu/kermit/iksd.html#x4.3
11. http://www.columbia.edu/kermit/iksd.html#x4.4
12. http://www.columbia.edu/kermit/iksd.html#x4.5
13. http://www.columbia.edu/kermit/iksd.html#x5
14. http://www.columbia.edu/kermit/iksd.html#x5.1
15. http://www.columbia.edu/kermit/iksd.html#x5.2
16. http://www.columbia.edu/kermit/iksd.html#x5.3
17. http://www.columbia.edu/kermit/iksd.html#x5.4
18. http://www.columbia.edu/kermit/iksd.html#x5.5
19. http://www.columbia.edu/kermit/iksd.html#x5.6
20. http://www.columbia.edu/kermit/iksd.html#x6
21. http://www.columbia.edu/kermit/iksd.html#x6.1
22. http://www.columbia.edu/kermit/iksd.html#x6.2
23. http://www.columbia.edu/kermit/iksd.html#x6.3
24. http://www.columbia.edu/kermit/iksd.html#x6.4
25. http://www.columbia.edu/kermit/iksd.html#x6.5
26. http://www.columbia.edu/kermit/iksd.html#x7
27. http://www.columbia.edu/kermit/iksd.html#x7.1
28. http://www.columbia.edu/kermit/iksd.html#x7.2
29. http://www.columbia.edu/kermit/iksd.html#x7.3
30. http://www.columbia.edu/kermit/iksd.html#x8
31. http://www.columbia.edu/kermit/case14.html
32. http://www.columbia.edu/kermit/case15.html
33. http://www.columbia.edu/kermit/case18.html
34. http://www.columbia.edu/kermit/case04.html
35. http://www.columbia.edu/kermit/case05.html
36. http://www.columbia.edu/kermit/case10.html
37. http://www.columbia.edu/kermit/newsn6.html#recover
38. http://www.columbia.edu/kermit/security.html
39. http://www.columbia.edu/kermit/iksd.html#x7
40. telnet:kermit.columbia.edu:1649
41. ftp://ftp.ietf.org/internet-drafts/draft-altman-telnet-kermit-server-03.txt
42. ftp://ftp.ietf.org/internet-drafts/draft-columbia-kermit-service-03.txt
43. http://www.columbia.edu/kermit/iksd.html#x4
44. http://www.columbia.edu/kermit/iksd.html#itema
45. ftp://kermit.columbia.edu/kermit/f/ckccfg.txt
46. ftp://kermit.columbia.edu/kermit/f/ckuins.txt
47. http://www.columbia.edu/kermit/iksd.html#x4
48. http://www.columbia.edu/kermit/iksd.html#x4.1
49. http://www.columbia.edu/kermit/iksd.html#x4.1
50. http://www.columbia.edu/kermit/iksd.html#x4.4
51. http://www.columbia.edu/kermit/security80.html
52. http://www.columbia.edu/kermit/iksd.html#x3
53. http://www.columbia.edu/kermit/ck60manual.html
54. http://www.columbia.edu/kermit/ckermit70.html
55. http://www.columbia.edu/kermit/ckermit80.html
56. http://www.columbia.edu/kermit/iksd.html#x4.2
57. http://www.columbia.edu/kermit/iksd.html#x4.3
58. http://www.columbia.edu/kermit/iksd.html#x4.2
59. ftp://kermit.columbia.edu/kermit/f/ckuins.txt
60. http://www.columbia.edu/kermit/iksd.html#x4.1
61. http://www.columbia.edu/kermit/iksd.html#x4.3
62. http://www.columbia.edu/kermit/iksd.html#x4.1
63. http://www.columbia.edu/kermit/iksd.html#x4.1
64. ftp://kermit.columbia.edu/kermit/f/ckccfg.txt
65. http://www.columbia.edu/kermit/iksd.html#x5.5
66. http://www.columbia.edu/kermit/ckermit70.html#x1.6
67. http://www.columbia.edu/kermit/ckermit70.html
68. http://www.columbia.edu/kermit/iksd.html#x4
69. http://www.columbia.edu/kermit/ckermit70.html
70. http://www.columbia.edu/kermit/iksd.html#x4.4
71. http://www.columbia.edu/kermit/iksd.html#x4.1
72. http://www.columbia.edu/kermit/iksd.html#x4.1
73. http://www.columbia.edu/kermit/iksd.html#top
74. http://www.columbia.edu/kermit/ckermit.html
75. http://www.columbia.edu/kermit/ckermit70.html
76. http://www.columbia.edu/kermit/ckermit80.html
77. http://www.columbia.edu/kermit/index.html