This is a kernal bug in freebsd, but you can get around it by doing ALL of these steps:
The panic indicates that the system ran out of virtual memory for network buffers (specifically, mbuf clusters). You can increase the amount of VM available for mbuf clusters by adding:
to your kernel config file, where <n> is a number in the range 512-4096, depending on the number of concurrent TCP connections you need to support. I'd recommend trying 2048 - this should get rid of the panic completely. You can monitor the number of mbuf clusters allocated/in use on the system with netstat -m.
How to rebuild the kernel on FreeBSD
Once you have the kerndist or srcdist loaded, do the following as root: (See readme files on your systems as these instructions may become out of date!)
2.cp GENERIC MYKERNEL
DNews does NOT support spaces in directory names, so if you define in dnews.conf
xover_dir e:\dnews stuff\xover
Terrible things will happen, don't do it :-)
stop DNews copy active.mon (workarea)/active.dat start DNews tellnews rebuild_index
In newsfeeds.conf remove the $nntp_feeder feed and insert this instead
... site pull-feed-in.internetmci.com groups * exclude *mci.* onlyposts builtin ...
With a sucking feed it does this automatically, with a normal feed, it's not
normal to update your active file in this way. But if you want to, and if your
feeding site has given you news reader access. Then:
1) Get news reader access to the machine you get your feed from
2) In dnews.conf add
nntp_feeder upstream.site.name suck_disable true
3) Then to synchronize news groups you do this:
In general you have to decide if it's
Typ Posts Queued Rejects Reque Dup Post/s Tot/s K/s File Del Feed Typ = B = Builtin, P = Posting, M = SMTP, L = Live, S = Streaming Posts = number successfully sent Queued = Number that couldn't be sent right away
Rejects = Number the other end didn't want for some reason
Reque = Number that the other end does want but not now (e.g. if it's
out of disk space)
Dup = Duplicate message id's (the other end already has the message)
Tot/s = Total of posts and rejects and reque and dup per second, e.g.
how many we offered the site or tried to.
K/s =Total K bytes per second sent
File =The size of the .feed file, this gives an indication of
Del = The total size of feed files deleted because they
got too big.
Feed = The name of the feed.
Check /etc/dnews.conf is owned by 'news' and do this too.
chmod 0664 /etc/dnwes.conf
alt - 1 day
rec - 3 days
cmp, ny, biz, gnu - 7 days
news - 15 days
Here is a sample expire.conf to handle the above:
remember 3 upto 1000% groups * default 1 keep 1 purge 30 maxitems 5000 minitems 0 upto 1000% groups alt.* default 1 keep 1 purge 30 maxitems 5000 minitems 0 upto 1000% groups rec.* default 3 keep 1 purge 30 maxitems 5000 minitems 0 upto 1000% groups comp.*,ny.*,biz.*,gnu.* default 7 keep 1 purge 30 maxitems 5000 minitems 0 upto 1000% groups news.* default 15 keep 1 purge 30 maxitems 5000 minitems 0
However, it is much better to use the new pile based rules, and NEVER mix the two types, e.g.
pile 1 days 1 use 20% days 1 groups *
pile 2 days 3 use 30% groups rec.*
pile 3 days 7 use 40% groups cmp.*,ny.*,biz.*,gnu.*
pile 4 days 15 use 5% groups news.*
Generally it's best not to specify 'days' rules which are inflexible and prevent DNews from managing the space efficiently, the 'use %' rules alone would be better.
> hi, we´ve DNews 4.5 and try to send feeds via nntp to a firewall > (borderware 5.0) . well, at the moment just many tries and no one > will finaly works . bull......... > > maby someone can help us and show us the way we have to go that > we can send our customer feed´s.
Define a port on your fire wall that links to the news server that you are
supposed to be sending news items to.
Lets assume your borderware ip name is borderware.de and your upstream news site is upstream.server
Then on borderware.de, map port 2119 to upstream.server port 119
If you do this correctly you can test it with telnet
telnet borderware.de 2119
The upstream server should respond. Now in newsfeeds.conf add a feed to it:
... site borderware.de:2119 groups * onlyposts builtin
That should do the job, I'm assuming you are sending up stream with IHAVE, if you want to send with a posting feed, add "posting' to the above newsfeeds.conf entry.
This assumes borderware is a simple tcpip mapping fire wall
control* are the logs of control news messages for creating/removing news groups.
*.upto are high water marks for sending a feed so if DNews gets restarted it can start again at about the same place in the feed file.
dbi.idx is the main index, all news items have a 20 byte entry in this file.
dblast.idx is the last entry in dbi.idx for any group.
kfile.dat is your license key
big*.tmp files are used when news items come in to avoid using memory if item is over a certain size.
diskuse.dat is a record of how much disk space DNews is using.
active.times is a list of creation dates for news groups this is used by the 'newgroups' nntp command
active.names is the list of news group names
active.add is where you put an active file when merging it with the current one.
Note: Apache doesn't support SSI with CGI scripts, this is an Apache problem, not DNewsWeb :-)
>Could someone direct me to a North American Satellite news feed. The
>only one I know of is pc-sat and they went belly up some time ago.
My report how I've set up this feed is located at:
You may also want to look into dnews's udp support dudp.htm
This can be caused by several things, first, all news clients estimate the number of new articles by subtracting the 'last' item from the last item that was read, the problem is due to cancels and expiration rules there can be gaps between these two numbers, so the total is 'less' than expected. Also since the volume of spam and cancles has increased this problem has become much more common.
With dmulti there is the possibility that new messages are not 'readable' for a short period after they arrive essentially until the files are flushed and the index for that group is re-read. This is a problem which we will address in a future version.
Lastly it is possible for there to be a straight bug in DNews where it reports the wrong figure, or items are mysteriously un-accessable, if you suspect this first try and prove it by using 'telnet' to read the problem group to establish that listgroup shows items that article nnn cannot access. Then report the problem to us as we would like to fix any such problems.
To fix it try:
This takes about 1 hour per gig and after the next expire the problem should go away, again if it doesn't please report it and send us the telnet log and matching dnews.log file so we can see what is occurring.
A non sucking news server creates new groups by actioning these special news messages, the rules for which ones to action, and which ones to email to the manager for 'consideration' are defined in your config file 'control.conf' you can change actions from 'mail' to 'doit' to 'log' to 'drop' depending on what you want it to do.
All these actions are logged to control*.* in the workarea, these files are formatted as batch files so they can be used to create the groups automatically after being reviewed.
Time problems occur in libc5 applications. They must either be recompiled or have the below fix applied.
Create the proper link by executing this command.
ln -s /usr/share/zoneinfo /usr/lib/zoneinfo
(Sorry, I'm not sure what version of Unix this answer works on :-(
On DNews 4.6k and later you can define in dnews.conf
This controls the default time zone that DNews labels outgoing messages with, remember most news clients label messages with a date so this has limited usefulness.
Site Posts Rejects Dup Total Articles/S Kbytes/s K Site = site name as found by reverse dns of number Posts = number of successful posts from that host Rejects = number rejected for any reason other than 'in history file' Dup = number rejected as they were in the history file Total = total of posts,rejects (doesn't include dup as they are not sent) Articles/S = Successful posts per second (dup isn't included) Kbytes/s = K bytes received per second while this site was connected. K = total bytes received from this site.
The file tellnews.pass is stored in the work area and this error means that Tellnews or DNews have read conflicting copies of this file. This is virtually impossible unless one or both of them cannot write to the file (as would happen if the directories defined in dnews.conf were pointing to disks that don't exist), however the DNews manager utility (that comes with versions prior to version 5) has a config screen (one of the buttons on the right hand side) that lets you specify where the workarea is, this is intended for remote management, if set incorrectly these directory settings can make the manager 'loose' tellnews.pass
On Unix the most likely problem is the directory ownership being mixed up, all the files should be owned by 'news'.
So was it Tellnews or DNews manager that gave this error about tellnews.pass, and check your directory settings in dnews.conf, then restart the computer, if the problem persists send firstname.lastname@example.org the dnews.log file after trying a Tellnews command.
Restarting DNews often fixes this problem after correcting the cause of the problem.
There is no guaranteed way to do this, the problem is even the binary posts are just text messages with binary encoded so you have to try and detect them. Here is how to do it. modify newsfeeds.conf like this, this assumes you want to allow binary messages in groups which have 'binaries' in their name.
site me groups * accept default reject body "\nContent-transfer-encoding: base64" accept newsgroups "binaires"
Here is a more extreme example that also drops html messages if you find those offensive :-)
site me groups * accept default "" reject body "begin 644" reject body "begin 755" reject body "Content-Type: application/octet-stream;" reject body "Content-Type: application/applefile;" reject body "Content-Type: image/jpeg;" accept newsgroups "binaries" reject body "Content-Type: text/html;"
The new 'rule' based filtering can do this much more acurately, faster and simpler. See this page
tellnews killitem group.name itemnumber tellnews killitem "<messageid>"
A lot of people ask how to find the item number, the answer is to use winvn or another news client which shows item numbers.
The other way to delete items is to use the message id ALL news clients will show this, look for a view options there will be one called "show all headers" or "show properties" or something like that, turn this on and your news client will show all the headers, e.g.
From: asdfasdf Subject: asfdasdf Path: asdfasd|asdfasdf|asdfasdf Message-ID: <email@example.com>
Then with the above example, to delete this message type in:
tellnews killitem "<firstname.lastname@example.org>"
The easy way to copy a set of newsgroups across is by using the sucking mechanism. Lets assume the local groups are called "tisco.*"
1) Setup the new DNews
2) Temporarily add a sucking feed, in dnews.conf and add these other settings to ensure all items are sucked.
nntp_suck2 old.news.server tisco.*
(You must increase the too_old setting so that old messages
are not rejected)
3) Optionally you may want to set in dnews.conf
This setting makes DNews use the same item numbers as the original items, however if you do this you must disable any other sucking feeds (nntp_feeder) and restart DNews (don't just do a reload) or you will cause a complete mess to occur. (the only fix if you do make this mistake is to delete the spool, so really don't do it by accident!!)
tellnews reload tellnews getgroups 2 tellnews status (wait until it has successfully fetched the list of local groups) tellnews cached "tisco.*" 1 tellnews update2 tellnews status (watch as DNews sucks the items across)
Check dnews.in for any errors.
5) Once you have all the items remove the extra sucking feed and the replicate true setting restart DNews.
Lets assume the new disk is mounted as "f:" and also lets assume it's a 4 gig disk, so we will leave 200mb to spare and use 3800 as the diskspace2 setting.
1) shutdown DNews c:> net stop dnewssvc 2) exit the DNews manager utility. 3) Add to dnews.conf diskspace2 3800 spool2 e:/spool 4) Create the directory on the disk (from DOS) c:> mkdir e:/spool 5) Start DNews c:> net start dnewssvc
#user:password:manager access(none,full):managed groups:full name:usergroups
# Example manager
# Example normal user
The number one most likely problem is in dnews.conf you could have
If you have this line, remove it and restart DNews.
Failing that solution, these lines will help with sucking:
suck_batchn 400 suck_batchsize 2000000 suck_requeue true suck_stream true
Suck_stream is the one that really helps, the others just mean that if it can't keep up at least it will share out what it does more evenly between the news groups that exist.
If that doesn't help, then the problem is almost certainly that your providers machine isn't letting DNews suck items fast enough.
One solution to this is to get an ihave feed of the worst groups, use
to find the big groups.
Lastly you could turn on pull sucking if you are sucking from more than one site
> How can I make the local groups read only? We have some local groups
> under old names and we have created some now groups under new names. We
> want the user to post to the new groups only and still keep the posts in
> the old groups for read only.
One simple option is to set the group to moderated.
tellnews newgroup old.group.name m
You should also add a line to moderators.conf so if anyone does post you will get it.
old.group.name:YOUR_EMAIL@ADDRESS gnu.*:%email@example.com *:%firstname.lastname@example.org
Alternatively you can set a group to read only using your access.conf rules, this can be a bit tricky. Here is a simple example.
*:logoff:::* *:read:::* *:post:::*,!old.group.name
Yes, Curt Cranfield has produced some similar scripts to generate web reports for DNews, here is some information on it from Curt.
Well Dnewsreport1.03 is finally ready for its official release. It provides a lot of functionality that dnewsreport0.5 had but a lot more information. For those of you who are not aware of what it does, here is a brief explanation.
Dnewsreport is a tool that provides a lot of interesting stats about your news server. For example it provides information on incoming and outgoing feeds, what groups are being read, who your largest feeder is, who your largest news acceptor is, which groups are being read - how much and how often, a break down of who and how often people are reading from your server and much much more. All of this is web based. Dnewsreport was originall written from the source that Fabien Tassin wrote for innreport. Since that time, I have tried to stay current on the development of innreport so that we can incorporate those tools and features into dnewsreport.
This release is a complete rewrite of the previous version (dnewsreport0.5). It now incorporates a configuration file which makes things much easier to configure and add new features as needed. It also makes it much more NT friendly, this was done by Eric Krichbaum. You can take a look at some of the information it produces at:
If you would like to download a copy of it, it is freely available from the following places:
Note: this software was designed to work with a full newsfeed (ihave type feed). If you wish to use it for a suck feed, it should work but your mileage may vary.
If you have any questions or would like to see new features added to dnewsreport, please let me know and I will do my best to help you out.
VPHoS - Virtuall Private Host Services Ltd.
In dnews.conf you can add username and password information onto any sucking feed, for example the main sucking feed:
nntp_feeder upstream.site.name * username password
The "*" is the list of groups to suck from that server.
In dnews.conf, stop DNews from sucking the MS groups from your main feed, and make it suck them from a second sucking feed once an hour
nntp_feeder main.sucking.site *,!microsoft.*,!local.* nntp_suck2 msnews.microsoft.com !*,microsoft.* update_at2 20 *
In newsfeeds.conf add a posting feed to send the posts back to the MS site, and stop DNews from sending the same posts to your normal upstream site, e.g.
site me groups * site main.sucking.site groups *,!microsoft.* builtin site msnews.microsoft.com groups microsoft.* builtin posting site mail.server smtp
NGroup, NRead, NXov, Nbytes, Time, NRej, Names
ngroup = the number of different groups read by that user
nread = the number of articles read
nxov = the number of xover requests
nbytes = The number of bytes sent to that user
time = the time spent connected by that user
nrej = if the user is disconnected due to an access.conf restriction
names = The name of the user
Upgrade to dnews5.3, and switch to 'pile' based expire rules.
Using dmulti or spawn_expire true will help even more if that isn't enough.
The best method is as follows, use dnews5.2 or later on both systems.
On the master use a feed entry like this
to send to the slave:
On the slave, add to dnews.conf
And in newsfeeds.conf on the slave
This is a bit tricky, the problem is DNewsWeb can only be protected by username/password by the web server, not by dnews.
So use your web server to force username/password restrictions.
Then you can add to dnewsweb.ini
Where xxxxx is the contents of the file tellnews.pass on your DNews workarea.
And install dnews/dnewsweb 4.6j
Then the username which is authenticated by the web server will be passed thru to DNews and will be matched against your users.dat access rules. See the updates.htm web page for details of the users.dat file.
If you are getting hundreds of email messages with subjects like this:
"Logged only: version"
"Logged only: newgroup"
Then you should make these changes to your control.conf file:
search/replace ":mail" ":log"
Then restart DNEWS.
This isn't actually a new feature but it has never been documented before. There is a config file you can create called "distrib.conf" in the config directory and in that file you can place rules like this:
With posts to multiple groups the highest priority rule that matches any group is applied to create the Distribution header. Note: the distribution header's only purpose is to prevent distribution of local news world wide but it also relies on other sites implementing their distribution rules correctly so it is not as effective as one might assume :-)
This topic is covered in detail on this page
Back To Top
DNews itself doesn't support the ssl protocol (mainly for legal reasons) however you can use various software (on unix sslwrap or stunnel) to link the secure port to the normal news port, then you will instantly have an encrypted news system that can be accessed from Outlook Express or Netscapes secure news browsers.
To suck news from a secure news server, you can use stunnel like this:
secnews.netscape.com:563 <--- (stunnel)127.0.0.1:5119 <--- dnews.machine
Run stunnel to link a local port, say 5119 to the upstream secure server.
stunnel -c -d 5119 -r secnews.netscape.com:563
And tell DNews to suck news from the local system on port 5119
Source for the Unix version of stunnel, and binaries for Windows, are available from http://www.stunnel.org/
To make your server respond via the secure port, and encrypt the data sent between the server and the client, using slwrap:
./sslwrap -cert /usr/local/ssl/certs/server.pem -port 119 -accept 563
SSLWRAP is available from http://www.rickk.com/sslwrap/sslwrap.tar.gz
We can now provide you with a binary of sslwrap for NT if required. Please e-mail email@example.com if you require this.
These notes are now incorporated on this page on performance.
To implement simple blocking of messages with attachments that might contain viruses do something like this.
1) Upgrade to 5.5b3 or later
2) ADd to your me feed
3) In d:\dnews\me.rul use two lines:
reject "Message contains executable programs"
accept "This message is ok"
Also, a small tip you may want to know for your Linux-based (maybe even other)
users getting news over Satellite feeds, they would be much better off using
a 2.2 kernel, as it supports large TCP windows, SACK (Selective ACKs), Scaling
TCP Windows, and lots of other great features to move data more efficiently
over a high-latency Satellite link than a 2.0.xx series kernel.