web pages. It does so using the location heuristic, which determines the
value of a given sentence based on its position and status within the
document.
PR: 15863
Submitted by: Dmitry Sivachenko <dima@Chg.RU>
Bugfix release.
IPv6 support is compiled in. I can't test to see whether it works, and
got no feedback from a request for testing on the exim-users mailing
list.
Also added hooks for SMTP AUTH and PAM support, disabled by default
for now.
honor of the occasion I have bumped the version number to 1.1.
The port now depends upon the cvsup-bin and cvsupd-bin ports rather
than on the more trouble-prone cvsup port.
The CVSup server is run with "-C 100" (max. 100 clients at a time)
and the true limit is set in the "/usr/local/etc/cvsup/cvsupd.access"
file. This is nice because you can change the limit by editing
the file; you don't have to restart the server. The cvsupd.access
file also contains a rule to limit each individual host to one
connection at a time.
The CVSup client is now run under its own unprivileged user ID
instead of root. This is a security enhancement. It makes it
impossible for a compromised master site to install files into
places outside the mirror area of the filesystem. The permissions
of various other files such as /usr/local/etc/cvsup have also been
strengthened to enhance security.
Both client and server now cd to /var/tmp to run, so that if they
decide to croak they'll be able to write the core file. :-)
The /usr/local/etc/rc.d/cvsupd.sh script now honors the "start"
and "stop" arguments.
The configure script no longer attempts to tell you the sizes of
the various collections. That's impossible to maintain. When I
have time I plan to make a web page where one can obtain that
information from an automatically-updated source. Then I will
reference the URL in the configure script.
It is possible to upgrade an existing cvsup-mirror-1.0 installation
to this new version, but it is tricky because of the change in
ownership of the mirrored files. I will post instructions to the
freebsd-hubs mailing list after I make sure I have the procedure
just right.
The trap handler returns different information after this date for
numeric error conditions. Since kern.osreldate is not a reliable
indicator of when this change occurred, we revert to checking for
the presence of a particular #define in <machine/trap.h> to decide
if the SML/NJ runtime sources need to use the newer interface.
Submitted by: Tom <tcrimi@andrew.cmu.edu> (in part)
