summaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
Diffstat (limited to 'README')
-rw-r--r--README118
1 files changed, 118 insertions, 0 deletions
diff --git a/README b/README
new file mode 100644
index 0000000..9bbe6ab
--- /dev/null
+++ b/README
@@ -0,0 +1,118 @@
+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