121 lines
4.3 KiB
Plaintext
121 lines
4.3 KiB
Plaintext
This source code is modified by Michał Krzysztof Feiler (ArchieT).
|
|
|
|
This is bsd-finger-0.17 for Linux.
|
|
|
|
This package updates bsd-finger-0.16.
|
|
|
|
If you're reading this off a CD, go right away and check the net
|
|
archives for later versions and security fixes. As of this writing the
|
|
home site for NetKit is
|
|
ftp://ftp.uk.linux.org/pub/linux/Networking/netkit
|
|
|
|
Contents:
|
|
finger Program for printing user information
|
|
fingerd Daemon for remote finger access
|
|
|
|
Requires:
|
|
Working compiler, libc, and kernel.
|
|
|
|
Security:
|
|
bsd-finger-0.17 contains no new security fixes.
|
|
|
|
bsd-finger-0.16 fixes some possible denial of service attacks
|
|
against fingerd.
|
|
|
|
bsd-finger-0.10 fixed a denial of service situation where
|
|
users' .plan or .project files are named pipes.
|
|
|
|
The NetKit-0.09 and earlier versions of this code fixed a
|
|
number of now well-known security problems. Please don't use
|
|
older versions.
|
|
|
|
Note:
|
|
If you are using the finger daemon from this package with a
|
|
custom finger client, rather than the finger client in this
|
|
package, you will need to update your client to send carriage
|
|
returns (CR, or '\r' in C) before line feeds (LF, or '\n' in
|
|
C) if the finger client's standard output is a socket.
|
|
|
|
This is because as of bsd-finger-0.15, finger probes this
|
|
condition and sends CRs itself instead of expecting fingerd
|
|
to make an extra copy of all the data through a pipe just to
|
|
add CRs in.
|
|
|
|
Ignoring this circumstance and always sending LF instead of
|
|
CR/LF will in most cases work, but is not RFC-compliant.
|
|
|
|
Installation:
|
|
Do "./configure --help" and decide what options you want. The
|
|
defaults should be suitable for most Linux systems. Then run
|
|
the configure script.
|
|
|
|
Do "make" to compile.
|
|
Then (as root) do "make install".
|
|
|
|
Save a backup copy of any mission-critical program in case the
|
|
new one doesn't work, and so forth. We warned you.
|
|
|
|
If you get gcc warnings from files in /usr/include, they are
|
|
due to problems in your libc, not netkit. (You may only see
|
|
them when compiling netkit because netkit turns on a lot of
|
|
compiler warnings.)
|
|
|
|
DEC CC:
|
|
The DEC compiler for the Alpha is now freely available. This
|
|
is a much better compiler with gcc, that is, it generates much
|
|
better code. If you have the DEC compiler, you can explicitly
|
|
use the DEC compiler instead of gcc by configuring like this:
|
|
|
|
./configure --with-c-compiler=ccc
|
|
|
|
It is known to generate spurious warnings on some files. Also,
|
|
some headers from some versions of glibc confuse it; that may
|
|
prevent netkit from working. Other problems should be reported
|
|
as bugs.
|
|
|
|
Bugs:
|
|
Please make sure the header files in /usr/include match the
|
|
libc version installed in /lib and /usr/lib. If you have weird
|
|
problems this is the most likely culprit.
|
|
|
|
Also, before reporting a bug, be sure you're working with the
|
|
latest version.
|
|
|
|
If something doesn't compile for you, fix it and send diffs.
|
|
If you can't, send the compiler's error output.
|
|
|
|
If it compiles but doesn't work, send as complete a bug report as
|
|
you can. Patches and fixes are welcome, as long as you describe
|
|
adequately what they're supposed to fix. Please, one patch per
|
|
distinct fix. Please do NOT send the whole archive back or
|
|
reindent the source.
|
|
|
|
Be sure to send all correspondence in e-mail to the netkit address.
|
|
Postings to netnews or mailing lists will not be seen due to the
|
|
enormous volume. Also, anything that doesn't get filed in the bug
|
|
database is quite likely to end up forgotten.
|
|
|
|
Please don't report known bugs (see the BUGS file(s)) unless you
|
|
are including fixes. :-)
|
|
|
|
Mail should be sent to: netbug@ftp.uk.linux.org
|
|
|
|
|
|
Early in April 2000, a hacker broke into the machine that was hosting
|
|
the netkit bug database for me and trashed it. Unfortunately, it seems
|
|
backups hadn't gotten done for a while, so three months of mail (since
|
|
mid-January) was lost. So, if you sent something and didn't hear back,
|
|
or you sent something, heard back, but the changes failed to appear in
|
|
this release (unlikely but possible) - please resend.
|
|
|
|
Please see http://www.hcs.harvard.edu/~dholland/computers/netkit.html
|
|
if you are curious why it was so long between the 0.10 and 0.16 releases.
|
|
|
|
Future plans for netkit maintenance are still up in the air, but in the
|
|
meantime new releases will still appear from time to time. I don't have
|
|
a whole lot of cycles to spare to work on netkit, so things are likely
|
|
to continue to be fairly slow.
|
|
|
|
David A. Holland
|
|
23 July 2000
|