GNU Finger is a utility program designed to allow users of Unix hosts on the Internet network to get information about each other. It is a direct replacement for the Berkeley 4.3 finger code, although it produces different looking output and is designed to run on a wide variety of systems.
Originally, each host on the Internet network consisted of a single, reasonably powerful computer, capable of handling many users at the same time. Typically, a site (physical location of computer users) would have only one or two computers, even if they had 20 or more people who used them. If a user at site A wanted to know about users logged on at site B, a simple program could be invoked to query the host at site B about the users which were logged on.
With the onset of more-power-per-person computing, the mainframe has been set aside. A modern computing facility usually consists of one user per host, and many hosts per site. This makes it a trial to find out about logged on users at another site, since you must query each host to find out about the single user who is logged on. If the site had 20 hosts, you would have to invoke a finger program 20 times just to find out who was logged on!
GNU Finger is a simple and effective way around this problem. For sites with many hosts, a single host may be designated as the finger server host. This host collects information about who is logged on to other hosts at that site. If a user at site A wants to know about users logged on at site B, only the server host need be queried, instead of each host at that site. This is very convenient.
GNU Finger is a direct replacement for existing finger programs. Since the finger protocol (rules for communication) is very simple, GNU Finger follows that protocol in responding to simple requests. But GNU Finger also implements another protocol which allows two finger programs to exchange information in a predetermined way, which allows faster and wider bandwidth communication.
Finger delivers information about users in varying formats, depending on
how it is invoked. finger invoked without any options performs a
site wide finger request, no matter which machine it has been
invoked from. Switch arguments exist for getting the "long" form of
finger information and for getting information only about the local
machine.
If a user on host A wants to know about a user on host B, finger must make a network connection to host B. If host B is running a finger program, that program is asked to relay information about the user in question through the connection back to host A, where finger can display it.
GNU Finger also runs a server daemon process on the server host, whose job is to keep track of which users are logged in to local machines.
An optional and currently unsupported feature is passing of graphic images. This is built on the new protocol. A user at site A (e.g. MIT) may see the picture of a user at site B (e.g. UCSB), by typing a finger request. The conversion of graphic data from one format to another is done through GNU Finger; no site need know where or how such images are stored on any other site to be able to display those images. You should ask your system administrator to find out whether he has chose to include this functionality on your network.
The basic argument to Finger is a user@host pair. The user portion is the name of the user about whom you would like information. The host is a machine that the user has an account on. When invoked in this manner, GNU Finger displays the list of hosts that this user is currently logged in on, or, if the user is not logged in, the last time and location that he or she was. host may be expressed as any valid Internet address (i.e. dot-notation, host.domain, etc).
If host is non-existent, the local host is assumed. If user is blank or unspecified, it is assumed that you want information about all users.
The content and format of the output of GNU finger depends on
what is being fingered:
finger will display the full name,
home directory, shell, mail forwarding, and `.plan' and/or
`.project' file. This is what the output will look like:
The following is output, in the order listed, when asking for long information (`-l' or `--info') about a particular user:bash$ finger --info bson@gnu.ai.mit.edu[apple-gunkies.gnu.ai.mit.edu]Jan Brittenson (bson)Home: /home/fsf/bsonShell: /usr/local/bin/bashMail forwarded to bson@ai.mit.edu.No mail.User Real Name What Idle TTY Host Console Locationbson Jan Brittenson fgrep *p0 apple-gu (nutrimat.gnu.ai.)bson Jan Brittenson 1:57 *sb nutrimatPlan:To hack GNU Finger
Here is an explanation of what each column contains in the short example:bash$ finger bson@gnu.ai.mit.edu[apple-gunkies.gnu.ai.mit.edu]User Real Name What Idle TTY Host Console Locationbson Jan Brittenson fgrep *p0 apple-gu (nutrimat.gnu.ai.)bson Jan Brittenson 1:57 *sb nutrimat
User
Real Name
What
Idle
TTY
Host
Console Location
The last line is the console. The following might be listed by the command `finger .local@mole.gnu.ai.mit.edu':brendan Brendan Kehoe 5:09 *p8 mole (lisa.cygnus.com)info InfoMaster 12:12 *p4 mole (hal)law Jeffrey A. Law 3:52 *p7 mole (128.110.4.17:0.0)rms Richard Stallman sendmai 1:34 *p1 mole (unix:0.0)rms Richard Stallman 6 days *co mole
[mole.gnu.ai.mit.edu]User Real Name What Idle TTY Host Console Locationbrendan Brendan Kehoe 5:18 *p8 mole (lisa.cygnus.com)info InfoMaster 12:22 *p4 mole (hal)law Jeffrey A. Law 4:01 *p7 mole (128.110.4.17:0.0)rms Richard Stallman sendmai 1:44 *p1 mole (unix:0.0)rms Richard Stallman 23:08 *p0 mole (unix:0.0)rms Richard Stallman 1 day, *p2 mole (unix:0.0)rms Richard Stallman 6 days *co mole
% finger --info postmaster@gnu.ai.mit.edu
postmaster is an alias for the following:
Roland McGrath <roland>,
<tower@prep.ai.mit.edu>,
Noah Friedman <friedman>,
Michael I Bushnell <mib>
% finger .site@gnu.ai.mit.edu This is the FSF GNU Project. For more information, please contact "postmaster". For information about guest accounts, please contact "request".
There are a number of command line options that you can give to GNU Finger:
finger as
distributed from Berkeley has this option.
You can give GNU Finger one of several "special" user names. These user names all begin with a period (`.') and instruct the receiving finger daemon to do something that only a GNU Finger daemon can do. Currently, the "special" names are:
finger command
without specifying the user name.
GNU Finger is the collective name for a set of programs:
finger server. Returns the output from
the server. finger connects to in.fingerd on the host
specified in the command line. This is the only program you need to know
anything about if you're a regular user. You should refer to this
program as the finger client to avoid possible confusion.
in.cfingerd on the clients specified in the
`fingerdir/clients' file, to obtain finger data. This client data
is saved in the file `fingerdir/userdata'. fingerd should
run on the host specified in the `fingerdir/serverhost' file.
fingerd should be started at boot time.
finger connections through inetd. Should be
attached to the `finger' service via `/etc/inetd.conf'.
in.fingerd behaves somewhat differently depending on what host it
runs on: on the server host it reads the `fingerdir/userdata'
database, on all other hosts it forwards all requests (unless
`.local' is the target) to in.fingerd on the host specified
in `fingerdir/serverhost'.
in.fingerd reads the `fingerdir/userdata' database, various
system files, and makes SMTP connections to the host specified in the
`fingerdir/mailhost' file.
fingerd by
sampling the status on the client and forwarding it to fingerd.
It should be configured to respond to the `cfinger' service
specified in the `clients' configuration file, or port 2003 if
nothing else is specified.
When the GNU Finger server receives a request for information about a user it looks to see if the user has a `.fingerrc' file in the home directory. If such a file exists, and is executable, then this file is executed, and the normal finger output is passed to it as input. Its output becomes what is returned for the request. Thus, it can be used to:
finger by ignoring its input. Below
is a sample script which could be put in `~price-info/.fingerrc'.
#! /bin/sh # # This sample script replaces the output of GNU Finger # echo Hack-O-Matic Consulting Services, Inc. " " `date` cat <<ETX Hi, thanks for asking us about prices on our newly introduced support services for Free Software. Below is a list of new services; for a list of our previous services, please send mail to this address and someone will contact you. Please don't forget to tell us how to reach you. ETX cat ~/info/new-stuff
#! /bin/sh # # This sample filter replaces the "Project:" tag with # "Working on:" # sed -e 's/^Project:$/Working on:/g'Then when `finger -l bson@gnu.ai.mit.edu' is run, the output could look something like:
Jan Brittenson (bson)
Home: /home/fsf/bson
Shell: /usr/local/bin/bash
No mail.
Jan Brittenson (bson) is not presently logged in.
Last seen at wombat.gnu.ai.mit.edu on Tue Sep 1 15:08:12 1992
No plan.
Working on:
1. Hacking GNU Finger
2. Making friends
Various special targets can be added as executable files in the directory `fingerdir/targets'. Each file name in this directory starts with a letter describing when to execute it, followed by a hyphen and the target name. The three letters are:
For instance, the special-target file `x-.help' is run for either `finger .help' or `finger -l .help', whereas the special- target file `l-prices' is run only for `finger -l prices'.
The special-target file is run as super-user, and is given no input. By convention, all GNU Finger sites should support at least:
When invoked, the GNU Finger client looks to see if a `--port' option was specified on the command line. If so, then this becomes the port number or service used. Otherwise, the client looks to see what name it was started under, removes any leading directory path, and any trailing suffixes. A suffix is the part of a filename that follows a dot, including the dot itself. This is the service name used. For instance, if GNU Finger is installed as `/usr/local/bin/finger.new', then the service `finger' is used. If it's installed as `/usr/local/bin/gfinger', then the service `gfinger' is used. This behavior can be changed by the system administrator during installation.
One question that often arises when installing networking software which adds new functionality is whether it can be considered sufficiently secure. The most significant new function in GNU Finger with regard to security is the ability for a user to have a `.fingerrc' in the home directory. The following are the precautions take by GNU Finger:
You are strongly encouraged to submit a bug report to bug-gnu-utils@gnu.ai.mit.edu if you have problems with this beta release of GNU Finger. Here are some things that are generally helpful to mention, when relevant:
If you're having problems compiling or installing GNU Finger, then the following is particularly helpful to mention:
configure.
make and make version
(particularly if you're using GNU Make).
Please feel free to include any patches, as well.
Here are the steps that you will need to take in order to install GNU Finger.
csh on an old version of System V, you might need to type
`sh ./configure' instead to prevent csh from trying to
execute configure itself.
The configure shell script attempts to guess correct values for
various system-dependent variables used during compilation, and
creates the Makefile(s) (one in each subdirectory of the source
directory). In some packages it creates a C header file containing
system-dependent definitions. It also creates a file `config.status'
that you can run in the future to recreate the current configuration.
Running configure takes a minute or two. While it is running, it
prints some messages that tell what it is doing. If you don't want to
see the messages, run configure with its standard output redirected
to `/dev/null'; for example, `./configure >/dev/null'.
To compile the package in a different directory from the one containing
the source code, you must use a version of make that supports the VPATH
variable, such as GNU make. `cd' to the directory where you want
the object files and executables to go and run configure.
configure automatically checks for the source code in the
directory that configure is in and in `..'. If for some
reason configure is not in the source code directory that you are
configuring, then it will report that it can't find the source code. In
that case, run configure with the option `--srcdir=DIR',
where DIR is the directory that contains the source code.
You can tell `configure' to figure out the configuration for your
system, and record it in `config.status', without actually
configuring the package (creating `Makefile' and perhaps a
configuration header file). To do this, give configure the
`--no-create' option. Later, you can run ./config.status to
actually configure the package for a particular host. This option is
useful mainly in `Makefile' rules for updating `config.status'
and `Makefile'. You can also give `config.status' the
`--recheck' option, which makes it re-run configure with the
same arguments you used before. This is useful if you change
configure.
`configure' ignores any other arguments that you give it.
If you want to install the GNU Finger configuration files somewhere
other than `/usr/local/etc/fingerdir', then you should edit the
files `./config.h' and `include/fingerpaths.h' now. You need
to specify the alternate locations of where the configuration files will
be kept. If you want to include the unsupported code for mugshots, then
you should now also choose one of the face formats, as well as edit
`lib/Makefile.in', `lib/site/Makefile.in', and
`src/Makefile.in' to compile and link in the files necessary.
If your system requires unusual options for compilation or linking that
configure doesn't know about, you can give configure
initial values for some variables by setting them in the environment.
In Bourne-compatible shells, you can do that on the command line like
this:
CC='gcc -traditional' DEFS=-D_POSIX_SOURCE ./configureThe `make' variables that you might want to override with environment variables when running
configure are:
(For these variables, any value given in the environment overrides the
value that `configure' would choose:)
CC
INSTALL
DEFS
LIBS
finger, in.fingerd, and in.cfingerd, as
well as fingerd on the server. If you want to, you can override
the `make' variables CFLAGS and LDFLAGS like this:
make CFLAGS=-O2 LDFLAGS=-s
in.cfingerd (port 2003) and
in.fingerd (port 79). If port 2003 is already used by something
else, then read the section on Configuration Files for details on how to
specify a port other than 2003 in the
`/usr/local/etc/fingerdir/clients' file. A good name for the
service is `cfinger'.
in.cfingerd and in.fingerd.
in.fingerd needs to be run with UID root. Consult your
system documentation for details on how to do this. in.cfingerd
should be run with UID root on System V derivatives.
fingerd. You should arrange to have
fingerd started every time the server host is rebooted. For exact
details on how to do this, please refer to the server host's system
documentation.
finger --face bfox@aurel.cns.caltech.edu
Now you're all set! You might like to read through the section on Configuration Files.
This section describes the format of the GNU Finger configuration files.
The `/usr/local/etc/fingerdir/clients' file contains a list of
clients that the GNU Finger server fingerd is supposed to poll.
You can edit this file and then send the finger server a SIGHUP
to tell it that the configuration has changed. Each line in the file
should be either the name of a host or a comment. The name can be
preceded by @port, to tell the finger server to poll the
particular host by using a port other than 2003. A comment is any line
that starts with a hash sign (#). Below is a sample `clients' file:
# This file contains all GNU Finger clients on the gnu.ai.mit.edu # network. Apple-gunkies is the GNU Finger server (see ``serverhost''). apple-gunkies.gnu.ai.mit.edu # Albert is the mail exchanger (see ``mailhost''). albert.gnu.ai.mit.edu # Spiff is a Sony, so port 2003 is already used for `mbanks'. # Use port 2010 instead. @2010 spiff.gnu.ai.mit.edu churchy.gnu.ai.mit.edu mole.gnu.ai.mit.edu geech.gnu.ai.mit.edu wookumz.gnu.ai.mit.edu nutrimat.gnu.ai.mit.edu kropotkin.gnu.ai.mit.edu goldman.gnu.ai.mit.edu hal.gnu.ai.mit.edu wombat.gnu.ai.mit.edu
Although this sample `clients' file contains the fully qualified
domain names of the hosts, it's usually enough to specify only the host
name portion. Explicit IP addresses can be used too, but this is a
practise strongly discouraged. Notice that the server is also in the
clients file and has a in.cfingerd; this is necessary in order
for the server to correctly poll itself.
The `/usr/local/etc/fingerdir/serverhost' file holds the name of
the GNU Finger server host; this is as the name implies, the host that
the GNU Finger server fingerd runs on. Lines starting with a hash
sign (#) are treated as comments. Below is a sample `serverhost'
file:
# A-g does all the finger stuff apple-gunkies.gnu.ai.mit.edu
The `/usr/local/etc/fingerdir/mailhost' file holds the name of the mail exchanger host for the network. This host should know how to talk SMTP; this file should never hold the name of a host that can't. It's contacted to obtain mail forwarding information and to expand mailing lists if a `.forward' file can't be found in the user's home directory. GNU Finger always looks and reports on user `.forward' files regardless of whether `mailhost' exists or not. Any lines in this file that start with a hash sign (#) are treated as comments.
The `/usr/local/etc/fingerdir/forwardhost' file holds the name of the host to forward finger requests to when the current finger server can't find a matching user name or mail alias. No forwarding takes place if this file doesn't exist. Any lines that start with a hash sign (#) are treated as comments. This is a sample output of what it can look like when a request is forwarded:
% finger -l nosuchuser@gnu.ai.mit.edu [No user nosuchuser@apple-gunkies.gnu.ai.mit.edu, forwarding request to life.ai.mit.edu] Login name: nosuchuser In real life: ???
The `/usr/local/etc/fingerdir/ttylocs' file holds explanations for the hosts or terminal lines that users have logged in from or through. Each client host has its own copy of this file. Each line consists of a host name followed by a description. The name and description are separated by one or more blanks or TABs.
spiff.gnu.ai.mit.edu NE43 Hall susie.gnu.ai.mit.edu NE43 Sony 427 x8568 spike.gnu.ai.mit.edu NE43 Sony 427 x8568 apple-gunkies.gnu.ai.mit.edu NE43 427 sugar-bombs.gnu.ai.mit.edu Elsewhere pogo.gnu.ai.mit.edu NE43 447 albert.gnu.ai.mit.edu Noisy Machine Room 128.52.46.42 The salt mines churchy.gnu.ai.mit.edu NE43 426 mole.gnu.ai.mit.edu NE43 430 geech.gnu.ai.mit.edu NE43 426 wookumz.gnu.ai.mit.edu NE43 427 calvin.gnu.ai.mit.edu NE43 gnu.gnu.ai.mit.edu NE43 kropotkin.gnu.ai.mit.edu Total anarchy
If you are interested in customizing GNU Finger's output, then the `lib/site' directory is the right place to start. If you would like to add new code for displaying faces, or have a particularly interesting "long" information output format, I would be glad to include it as unsupported code in the next release of GNU Finger. (I will direct correspondence regarding your code to you.) You can find other contributed code in `lib/site', most notably different user info formats and code to handle different bit map file formats. The only file supported in `lib/site' is `userinfo.c'.
The following definitions in `config.h' control the behavior of GNU Finger:
SUPPORT_FINGERRC
CHECK_OWNER_FINGERRC
CHECK_RDONLY_FINGERRC
FINGERRC_SHELL
DEFAULT_POLL_INTERVAL
fingerd with the `--interval' option.
BASENAME_IS_SERVICE
INFO_IS_DEFAULT
finger options user@host
Finger obtains information about user on the remote system host. It can also be used to obtain information about mailing lists and special site-specific services.
Options can be one or more of:
This document was generated on 7 November 1998 using the texi2html translator version 1.52.