Bug 218 - The inn rpm won't work for news over UUCP
Summary: The inn rpm won't work for news over UUCP
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: inn
Version: 5.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Preston Brown
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1998-11-29 00:55 UTC by Marc MERLIN
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-03-22 14:52:30 UTC

Attachments (Terms of Use)

Description Marc MERLIN 1998-11-29 00:55:35 UTC
This is an old bug forwarded to your new bug tracking system

Yes I know, few people still do news over UUCP, but for the
few that might try, here are a couple of

1) the permission on /usr/lib/news/rnews are wrong (as per
the INN FAQ). It should be 6555 uucp.news because without
this rnews can't write in the UUCP spool areas (4555 may be
enough though)

2) magic:~# less
--- sendbatch.orig      Thu Sep 17 13:19:55
+++ sendbatch   Thu Sep 17 13:20:44
@@ -134,7 +134,7
     cat ${SITE}.work
     rm -f
     if [ ! -s ${BATCHFILE} ] ;
-       echo "${PROG}:  No articles for
+       #echo "${PROG}:  No articles for
        rm -f


sendbatch has to be run by news to queue outgoing news, but
without this patch, if there are no messages, you get an
This used to be acceptable for sites who had a newsfeed for
a bunch of users and only synced a few times a day, but when
you use uucp over tcp and run the queue every 10 minutes,
the mails quickly get annoying...

Comment 1 Preston Brown 1999-03-20 00:11:59 UTC
stole the bug

Comment 2 Preston Brown 1999-03-22 14:52:59 UTC
I have fixed the first bug (permissions problem) as of inn-2.2-5, but
I am not going to change the second one.  As you said, whether you
want the mail or not is highly variable depending on how often you do
your news synchronization.  At red hat we are more in favor of
providing verbosity and letting the user configure for brevity than
the other way around in most circumstances.  In this case, the output
could be squelched with a simple modification to the cron job or, as
you have, directly editing the shell script.  However, I don't think
it would be wise for us to change this behaviour, as some people may
have been relying on it for quite some time for their sysadmin
monitoring scripts, etc.

Note You need to log in before you can comment on or make changes to this bug.