sscott@camdev.comm.mot.com (Steve Scott) (02/14/91)
HELP (please ;-) I have installed nntp (the Dec-15 patch level), cnews, and nn nntp is working well (good news) cnews (for the most part) is working well. I am getting articles in my database The problem is this: When I use postnews (or :post from within nn), I get the following error -- Error message begins relaynews: error writing `/usr/lib/news/history', probably the disk filled (Error 0) Your response has been saved in ~/dead.letter -- Error message ends I have checked everything I know to check (permission on /usr/lib/news/history is 666/news/news, relaynews is 6775/news/news, etc) I have discovered that this line is generated via the function prfulldisk in the source file msgs.c. But, I cannot understand from where relaynews calls it or why it is doing so Any help would be appreciated. While on a related subject: how do I set up my sys file so that only articles that have been posted will be batched up for nntpsend'ing to my nntp server? I don't want to use the F command in the sys file (at least not alone) as that simply causes all articles I receive to be spooled (their full path name, anyway ;-) and that is NOT what I want Please feel free to call with friendly advice!!! -- +------------------------------------------------------------------------------+ | Steve Scott | Internet: sscott@mot.com | | Fort Worth Research and Development Center | UUCP: csccat!camdev!sscott | | Cellular Infrastructure Group | Internal: TX14/1D | | Radio Telephone Systems Group | Voice: (817) 232-6317 | | Motorola, Inc. | Fax: (817) 232-6081 | | The opinions contained herein are STRICTLY my own | +------------------------------------------------------------------------------+
res@colnet.uucp (Rob Stampfli) (02/16/91)
In article <365@camdev.comm.mot.com?> sscott@camdev.comm.mot.com (Steve Scott) writes: >When I use postnews (or :post from within nn), I get the following error > >relaynews: error writing `/usr/lib/news/history', probably the disk filled (Error 0) My guess is you (or your system administrator) probably limits the size of the files users can write, via the ulimit shell builtin. Usually, relaynews is invoked from cron, which suffers no such limitation. However, the one time relaynews is invoked from a user's account is when that user post news. In this case, Unix passes the ulimit faithfully thru and causes the appending of the article ID to the history file to bomb out. Luckily for sV Unix, the cnews authors, in their infinite wisdom, provided a set-uid invoking function 'setnewsids', which can be easily recompiled to bump the ulimit to a reasonable value. I suggest putting the line (void) ulimit(2, 30000L); next to the umask() line. -- Rob Stampfli, 614-864-9377, res@kd8wk.uucp (osu-cis!kd8wk!res), kd8wk@n8jyv.oh
henry@zoo.toronto.edu (Henry Spencer) (02/20/91)
In article <365@camdev.comm.mot.com?> sscott@camdev.comm.mot.com (Steve Scott) writes: >cnews (for the most part) is working well. I am getting articles >in my database > >When I use postnews (or :post from within nn), I get the following error... Apart from the possibility others have already mentioned -- the %$^%#ed SysV ulimit -- the usual cause of "everything's fine except that nobody can post an article" is permission problems. A local posting is the only situation in which the setuid machinery really gets exercised. >While on a related subject: how do I set up my sys file so that only >articles that have been posted will be batched up for nntpsend'ing to >my nntp server? ... Use the L flag; see man/news.5. -- "Read the OSI protocol specifications? | Henry Spencer @ U of Toronto Zoology I can't even *lift* them!" | henry@zoo.toronto.edu utzoo!henry
fitz@wang.com (Tom Fitzgerald) (02/21/91)
> sscott@camdev.comm.mot.com (Steve Scott) writes: >> While on a related subject: how do I set up my sys file so that only >> articles that have been posted will be batched up for nntpsend'ing to >> my nntp server? ... henry@zoo.toronto.edu (Henry Spencer) writes: > Use the L flag; see man/news.5. Personally, I think the L flag should be avoided whenever possible, it's too easy to get burned by it. It works fine in the case described, but: 1) When you get a downstream feed, you won't pass on the articles posted at the downstream site until you change the L to an L2; 2) When you do this, you'll find yourself passing things posted at your server site back to the server again; 3) When your downstream feed site gets themselves a downstream feed site, you'll need to change L2 to L3, then you'll start feeding everything posted at all your server's immediate neighbors back to the server.... Anyway, using a / in the first field of the sys file entry is much better at things like this. It works whether you have more than one server, or whether the name for the server in your sys file entry is different from the name the server puts in the Path: header for itself. server1/server1.domain,server2:.../all,!local:f server2/server1.domain:.../all,!local:f --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
wolfgang@wsrcc.com (Wolfgang S. Rupprecht) (02/21/91)
>[...]the usual cause of "everything's fine except that nobody can >post an article" is permission problems. A local posting is the only >situation in which the setuid machinery really gets exercised. Yes. I just experienced this. Local posting quietly failed because relaynews didn't like the $NEWSUMASK environment variable it was passed. Grumble. If it doesn't like the recommended umask why didn't it just *ignore* the recommendation? As it is, relaynews seems to use any excuse to revoke its setuid privileges and then fail at the following lock-file manipulations. This leads to a failed posting. In this case the failed posting came from sendmail so no humans ever saw the output on stderr. I would have missed these failures entirely if I hadn't seen the disected headers/msg-bodies in /tmp. Oh, the source of the incorrect umask? Apparently .../news/bin/conf was never updated (a local build permissions problem???). Relaynews "knew" the correct umask to use since this knowledge was compiled in, but saw an incorrect version in the environment. -wolfgang -- Wolfgang Rupprecht wolfgang@wsrcc.com (or) uunet!wsrcc!wolfgang Snail Mail Address: Box 6524, Alexandria, VA 22306-0524
rickert@mp.cs.niu.edu (Neil Rickert) (02/21/91)
In article <1991Feb21.042744.26770@wsrcc.com> wolfgang@wsrcc.com (Wolfgang S. Rupprecht) writes: >Yes. I just experienced this. Local posting quietly failed because >relaynews didn't like the $NEWSUMASK environment variable it was >passed. Grumble. If it doesn't like the recommended umask why didn't This is a feature of relaynews which I like. (Please, Henry, don't change it). It purpose is to make it much harder for would-be hackers to bypass the normal routes to entering news by screwing up the environment. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
henry@zoo.toronto.edu (Henry Spencer) (02/22/91)
In article <1991Feb21.042744.26770@wsrcc.com> wolfgang@wsrcc.com (Wolfgang S. Rupprecht) writes: >relaynews didn't like the $NEWSUMASK environment variable it was >passed. Grumble. If it doesn't like the recommended umask why didn't >it just *ignore* the recommendation? As it is, relaynews seems to use >any excuse to revoke its setuid privileges and then fail ... It didn't just ignore the recommended umask because there was presumably a reason for the recommendation. However, it did renounce setuid because it couldn't accept the recommendation without opening up the possibility of security holes. The ability to override the configuration parameters with environment variables is useful for many things, but it does open up vulnerabilities if it's not done carefully. >Oh, the source of the incorrect umask? Apparently .../news/bin/conf >was never updated (a local build permissions problem???). Relaynews >"knew" the correct umask to use since this knowledge was compiled in... There are some tricky problems with updating the configuration information, since it has to be updated in more than one place. A fix for this is being thought about. -- "Read the OSI protocol specifications? | Henry Spencer @ U of Toronto Zoology I can't even *lift* them!" | henry@zoo.toronto.edu utzoo!henry