ANNOUNCE: INN 1.7 available
James Brister
I'm pleased to announce the availability of the INN 1.7. That's right
1.7. 1.6 was killed in the beta stage.
This release can be found at:
ftp://ftp.isc.org/isc/inn/inn-1.7.tar.gz
This release is a bug-fix to 1.5.1sec2. This means that the features that
would have made it into 1.6 are not there, and will instead show up in the
next release, which will be 1.8 (don't ask me when, though).
Thanks to everyone on the inn-workers list for help in testing etc., and
especially to Forrest J. Cavalier III, who did the hard work of fixing the
numerous bugs introduced in the 1.5.1 series panic.
James
--
James Brister bri...@vix.com
Internet Software Consortium http://www.isc.org i...@isc.org
Andrew
James Brister <bri...@velo.pp.vix.com> wrote:
> I'm pleased to announce the availability of the INN 1.7. That's right
> 1.7. 1.6 was killed in the beta stage.
*clap*clap*clap*
Since my bigass collection of patches for 1.5.x was reasonably popular,
I've tidied up the set and ported it to 1.7.
For those who don't remember the patch cluster from before, it's a set of
11 patches, all of which coexist beautifully on our server, and which,
IMHO, make INN just about as fast as it can get (and it's quite a speed
demon).
I did not write any of these patches myself, I just got 'em to work
together and did a little portability work on them. The kudos for these
go to the guys who wrote them in the first place.
Anyway, you can find the new 1.7 version of the "Big Badass Insync INN
Patch Cluster From Hell" (okay, pushing it a little I guess) at:
http://www.insync.net/~aos/inn.html
Enjoy, and feel free to write me if you have any comments or questions.
--
Andrew O. Smith - a...@insync.net | "Reality is that which, when you stop
Sysadmin, Insync Internet Services | believing in it, doesn't go away."
BOFH, Wielder of the sacred LART | -- Philip K. Dick
Dave Barr
In article <slrn64dmsk.l...@worf.netins.net>,
Jonathan Grobe <grobe...@netins.net> wrote:
>In article <yy3oh4p...@velo.pp.vix.com>, James Brister wrote:
>>I'm pleased to announce the availability of the INN 1.7. That's right
>>1.7. 1.6 was killed in the beta stage.
>>
We were all tired of fixing the crap introduced by SNI. We bit the
bullet, backtracked to 1.5.1 and applied Forrest Cavalier's 1.5.1corr
fixes. The result is _much_ more stable than 1.5.1sec2 or 1.6b3.
The snprintf code was also not very portable, adding additional
problems.
--Dave
--
http://www.cis.ohio-state.edu/~barr/
ba...@cis.ohio-state.edu
Charles R. Dennett
Just a heads up of a problem I just ran into in converting from 1.5.1 to
1.7 on a Solaris 2.4 system.
Got the source, run subst -f to convert my old config.data file to the
new one. Ran a make. innd failed in the link stage. Said it
could not find setbuffer() in innd.c. Compared it against the 1.5.1 version
which compiled fine.
Looks line a typo correction in 1.7 was the cause. In 1.7's innd.c and
include/configdata.h and in 1.5's include/configdata.h, there is
a compiler macro called DO_HAVE_SETBUFFER. However, in 1.5's innd.c
it uses HAVE_SETBUFFER which does not exist and so the falls through
to to the #else clause of the #if defined.
Here is the code from 1.7's innd.c:
========================================================================
#if defined(DO_HAVE_SETBUFFER)
#define SETBUFFER(F, buff, size) setbuffer((F), (buff), (size))
STATIC int LogBufferSize = 4096;
#else
#define SETBUFFER(F, buff, size) setbuf((F), (buff))
STATIC int LogBufferSize = BUFSIZ;
#endif /* defined(HAVE_SETBUFFER) */
========================================================================
The 1.5 version has #if defined(HAVE_SETBUFFER) instead which
evaluates to false.
I believe setbuffer() may be in the /usr/ucblib area. The fix to this
is either to set HAVE_SETBUFFER to DONT in config.data or use
the correct library from /usr/ucblib.
Charlie Dennett
Jonathan Grobe
In article <yy3oh4p...@velo.pp.vix.com>, James Brister wrote:
>I'm pleased to announce the availability of the INN 1.7. That's right
>1.7. 1.6 was killed in the beta stage.
>
Why was 1.6 killed in the beta stage?
--
Jonathan Grobe
Forrest J. Cavalier III
In article <627oef$joq$1...@bigred.inka.de>, ol...@bigred.inka.de wrote...
>
>James Brister <bri...@velo.pp.vix.com> wrote:
>> This release is a bug-fix to 1.5.1sec2. This means that the features that
>> would have made it into 1.6 are not there, and will instead show up in the
>> next release, which will be 1.8 (don't ask me when, though).
>
>(a) in 1.7 and not in 1.6, and
>(b) in 1.6 and not in 1.7,
>to see whether it would be warranted to upgrade/not to upgrade from
>1.6b3 to 1.7.
To answer your questions directly...
(a) There are three patches in 1.7 which are not in 1.6.
Basically 1.7 is 1.5.1corr. There are a few (not many) differences,
and they are described at: "The differences between 1.5.1corr and 1.7"
http://www.mibsoftware.com/0022.htm
1.7 has some additional "prepackaged" upgrades to non INN code
(like the FAQ, etc.)
(b) There are features in 1.6 that are not in 1.7.
The features which were added to 1.6 are inventoried in my message
to inn-workers:
http://www.mibsoftware.com/userkt/inn/dev/inn-workers/vol9709/xcb.htm
(Probably the most notable is XREF slaving.)
If you need them, you can get most of them as patches to 1.5.1. (and
they will work pretty well with 1.7, since that was one of my design
goals with 1.5.1corr.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
For what it is worth, 1.8 will be based on 1.7. It will probably get
the extra 1.6 features (but not the exact code)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
My opinions on what you should do....
1. If you are running 1.6b3 + patches, and you are happy with 1.6b3,
then just make sure you know about the three patches which were added
to 1.7. http://www.mibsoftware.com/0022.htm
Keep running 1.6b3: 1.7 offers no other compelling benefits.
2. If you are trying to run 1.5.1, 1.5.1sec, 1.5.1sec2, etc, then you will
probably save yourself time and get a lot of benefit in stability by
switching to 1.7.
If you have local patches against 1.5.1, they will most likely still work in
1.7. config.data is completely compatible to 1.5.1 (well, there is that
HAVE_SETBUFFER thing which was broken in 1.5.1 and fixed in 1.7, which could
throw you a bit. See the other message in this thread.)
3. If you are running 1.4xxxx, and are happy with it, then you have probably
been ignoring all of this version multiplication. Carry on.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I'll be making all the necessary changes to the Usenet RKT to explain
all of this (in a hopefully simple way.....)
Forrest Cavalier, Mib Software, INN customization and consulting
Searchable hypertext INN docs, FAQ, RFCs, etc: 650+ pages:
http://www.mibsoftware.com/userkt/forprov.htm
Commercial support for INN: http://www.mibsoftware.com/innsup.htm
Matthias Watermann
brister schrieb am 16.10.97 in <yy3oh4p...@velo.pp.vix.com>:
> [...]
> I'm pleased to announce the availability of the INN 1.7. That's right
> 1.7. 1.6 was killed in the beta stage.
Since Mozilla wasn't able to connect I had to make a quick fix:
>------------------------------- schnipp -------------------------------------
--- rc.c.orig Tue Oct 7 17:18:05 1997
+++ rc.c Sat Oct 18 16:50:05 1997
@@ -780,7 +780,10 @@
inet_ntoa(remote->sin_addr), lbuf);
if (setsockopt(fd, ipproto, IP_OPTIONS, (char *) 0, optsize) != 0) {
syslog(LOG_ERR, "setsockopt IP_OPTIONS NULL: %m");
+/*
return -1;
+*/
+ return 0; /* wg. Mozilla! */
}
}
#endif
>------------------------------- schnapp -------------------------------------
--
Matthias
Liebe Deine Feinde, aber sei schneller als sie.
James Brister
ol...@bigred.inka.de (Olaf Titz) writes:
> James Brister <bri...@velo.pp.vix.com> wrote:
> > This release is a bug-fix to 1.5.1sec2. This means that the features that
> > would have made it into 1.6 are not there, and will instead show up in the
> > next release, which will be 1.8 (don't ask me when, though).
>
> It would be nice to have a list of features which are
> (a) in 1.7 and not in 1.6, and
> (b) in 1.6 and not in 1.7,
> to see whether it would be warranted to upgrade/not to upgrade from
> 1.6b3 to 1.7.
See the README for 1.6. Everything noted as a change from 1.5.1 is missing
from 1.7. If you're happy with 1.6 then there's no need to move up.
bill davidsen
In article <627vri$3ag$1...@news1.epix.net>,
Forrest J. Cavalier III <mib...@epix.net> wrote:
| The features which were added to 1.6 are inventoried in my message
| to inn-workers:
| http://www.mibsoftware.com/userkt/inn/dev/inn-workers/vol9709/xcb.htm
| (Probably the most notable is XREF slaving.)
The XREF slave and background renumbering are two performance
features which really address problems of some large sites. I sure
hope they get into a stable version soon, because they address major
performance problems at some sites.
--
bill davidsen <davi...@tmr.com> CTO, TMR Associates, Inc
The net serves four of the five physical senses. You can get sight, and
sound, and to a limited extent tactile feedback. No one would deny that
some portions of the net smell, but I see no signs that taste will ever
come to the net. -me
Don Lewis
In article <62g9k0$fve$1...@newssvr03-int.news.prodigy.com>,
bill davidsen <davi...@tmr.com> wrote:
>In article <627vri$3ag$1...@news1.epix.net>,
>Forrest J. Cavalier III <mib...@epix.net> wrote:
>
>| The features which were added to 1.6 are inventoried in my message
>| to inn-workers:
>| http://www.mibsoftware.com/userkt/inn/dev/inn-workers/vol9709/xcb.htm
>| (Probably the most notable is XREF slaving.)
>
>The XREF slave and background renumbering are two performance
>features which really address problems of some large sites. I sure
>hope they get into a stable version soon, because they address major
>performance problems at some sites.
I hope the active file corrupting bugs in the background renumbering
enhancement get fixed first.
--
Don "Truck" Lewis TDK Semiconductor
Internet: Don....@tsc.tdk.com 138 New Mohawk Road
Phone: +1 916 478-8284 FAX: +1 916 478-8251 Nevada City, CA 95959
Sean Donelan
Ah, the great thing about UNIX, there are so many variants to choose
from. According to the latest version of TCP_WRAPPER which this code
was copied from, Linux does something incompatible with its IP_OPTIONS
so you should read your manual for disabling source routing in the
kernel.
For systems with source routing disabled in the kernel (not just at
the router), you can turn this code off. Although being a parnoid
person, never knowing when someone else might accidently re-enable
source routing, I would still use it when ever the O/S supports it.
Appended to this note is a patch file which makes this an option in
the config.data file. It would be better to include the new fix_options
code from TCP_WRAPPER 7.6, but even then you would still need the
option to disable it for some O/Ss. More portability concerns, where
is IP_OPTIONS actually defined on all the variants of UNIX.
Linux and some really old versions of Solaris may need to turn this code
off. Remember, if you disable this code be sure to turn off source routing
in your kernel.
In article <6gH4y...@dfg.oln.ComLink.APC.org>, Matt...@OLN.ComLink.APC.org (Matthias Watermann) writes:
> ol...@bigred.inka.de wrote on 19.10.97 in article <62d400$sku$1...@bigred.inka.de>:
>> This fix doesn't fix the problem, which is that the setsockopt() call
>> fails. With the fix, you'll enable clients to circumvent hosts.nntp
>> and/or nnrpd.access by IP source routing. Better have a look at the
>> syslog entry and try to find out what goes wrong.
>
> All this connects are such of the cron-entry "rnews -U". As I
> said in another posting, =all= of the tested news-readers
> (Mosaic, Mozilla, M$IE) are causing those "IP_OPTIONS NULL" msgs
> and without thath Q&D "fix" can't read any news at all. I know,
> that my "fix" doesn't fix the problem, but I have no idea, what
> the real problem might be. I just havn't seen those log-entries
> with v1.4... and v1.5.1sec2 but only with v1.7 and since I didn't
> change anything with my OS (CND 1.0 / Linux 1.2.13) I =thought=
> (I may be wrong) that this problem is related to INN 1.7. I'd be
> happy to learn better ...
========================CUT HERE========================
*** config/config.dist.orig Tue Oct 21 07:06:44 1997
--- config/config.dist Tue Oct 21 07:03:25 1997
***************
*** 529,534 ****
--- 529,537 ----
## Some versions of Solaris should set to DONT (pre 2.4 it seems)
#### =()<SET_SOCKOPT @<SET_SOCKOPT>@>()=
SET_SOCKOPT DO
+ ## Should INN clear IP_OPTIONS on network connections. Pick DO or DONT.
+ #### =()<KILL_IP_OPTIONS @<KILL_IP_OPTIONS>@>()=
+ KILL_IP_OPTIONS DO
##
*** config/config.data.orig Tue Oct 21 07:06:44 1997
--- config/config.data Tue Oct 21 07:03:25 1997
***************
*** 529,534 ****
--- 529,537 ----
## Some versions of Solaris should set to DONT (pre 2.4 it seems)
#### =()<SET_SOCKOPT @<SET_SOCKOPT>@>()=
SET_SOCKOPT DO
+ ## Should INN clear IP_OPTIONS on network connections. Pick DO or DONT.
+ #### =()<KILL_IP_OPTIONS @<KILL_IP_OPTIONS>@>()=
+ KILL_IP_OPTIONS DO
##
*** include/configdata.h.orig Tue Oct 21 07:05:02 1997
--- include/configdata.h Tue Oct 21 07:06:24 1997
***************
*** 336,341 ****
--- 336,344 ----
/* Should Inn be calling setsockopt() on network fds. */
/* =()<#define @<SET_SOCKOPT>@_SET_SOCKOPT @<SET_SOCKOPT>@>()= */
#define DO_SET_SOCKOPT DO
+ /* Should Inn clear IP_OPTIONS on network fds. */
+ /* =()<#define @<KILL_IP_OPTIONS>@_KILL_IP_OPTIONS @<KILL_IP_OPTIONS>@>()= */
+ #define DO_KILL_IP_OPTIONS DO
/* Function that returns no value, and a pointer to it. */
*** innd/rc.c.orig Tue Oct 7 10:18:05 1997
--- innd/rc.c Tue Oct 21 07:04:04 1997
***************
*** 750,758 ****
*/
/* fix_options - get rid of IP-level socket options */
- #ifndef IP_OPTIONS
- #define IP_OPTIONS 1
- #endif
int
RCfix_options(fd, remote)
--- 750,755 ----
***************
*** 759,765 ****
int fd;
struct sockaddr_in *remote;
{
! #if IP_OPTIONS
unsigned char optbuf[BUFSIZ / 3], *cp;
char lbuf[BUFSIZ], *lp;
int optsize = sizeof(optbuf), ipproto;
--- 756,762 ----
int fd;
struct sockaddr_in *remote;
{
! #if defined(DO_KILL_IP_OPTIONS)
unsigned char optbuf[BUFSIZ / 3], *cp;
char lbuf[BUFSIZ], *lp;
int optsize = sizeof(optbuf), ipproto;
========================CUT HERE========================
--
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
Affiliation given for identification not representation
Michael Shields
In article <344CEA11...@spinne.com>,
Jeff Garzik <jeff....@spinne.com> wrote:
> 1.2.13 was stable for what it did, and many people would choose stable
> over bleeding edge.
2.0 is generally at least as stable as 1.2.
--
Shields, CrossLink.
Rick Ellis
>1.2.13 was stable for what it did, and many people would choose stable
>over bleeding edge.
Funny. We used to constantly get ext2 errors on our news spool. They
stopped when we left 1.2.13 and when to a 2.0 kernel. I guess 1.2.13
wasn't all that stable.
Jeff Garzik
Rick Ellis wrote:
> Jeff Garzik <jeff....@spinne.com> wrote:
> >1.2.13 was stable for what it did, and many people would choose stable
> >over bleeding edge.
> Funny. We used to constantly get ext2 errors on our news spool. They
> stopped when we left 1.2.13 and when to a 2.0 kernel. I guess 1.2.13
> wasn't all that stable.
We can trade conflicting examples of stability all day, for any version
of any operating system. If you're pushing hardware to its limits, I've
found that Linux will always start falling short, even the new 2.0
series.
Linux 1.2 worked great on the right hardware, and was very stable. A
1.2.13-based news server I ran had an uptime of over 100 days, and it
went down only for the upgrade to a new Slackware distribution. It kept
up with no problems (this was before the Usenet traffic explosion...).
I still think my original point about legacy support remains valid.
--
Jeff Garzik Fast and efficient news feeds
Spinne USENET News Service News tuning and consulting
http://www.spinne.com/usenet/ Cyclone, Diablo, and INN
Forrest J. Cavalier III
In article <62l1ig$20f$1...@news1.epix.net>, I wrote...
>The IP_OPTIONS code is new in 1.6/1.7. There is more info on the
>source of the code in innd/rc.c.
>
>This code can be disabled in rc.c by compiling with -DIP_OPTIONS=0,
>at which point you will get the 1.5.1 (and prior) behavior, with
>all of the risks.
Because of this thread, and lingering nagging doubts, I looked
at this code some more.
Now (and after a few man page checks) I can't see how it works at all.
I've started a thread in inn-workers about it. I'll report back. But
it sure seems defective to me.
Forrest