Hello!

Because GG stops providing peering and new Usenet discussions won't
appear on GG, I thought about hosting rslight.

What are the resources needed to run it for an entire hierarchy, like
de.* with discussions ranging in the past, maybe years?

What about the built-in nntp server?
Does it do the peering or do I need to run a separate INN/Diablo?

--
kind regards
Marco

On Sun, 17 Dec 2023 20:29:42 +0100, Marco Moock wrote:

> Hello!
>
> Because GG stops providing peering and new Usenet discussions won't
> appear on GG, I thought about hosting rslight.
>
> What are the resources needed to run it for an entire hierarchy, like
> de.* with discussions ranging in the past, maybe years?
>
> What about the built-in nntp server?
> Does it do the peering or do I need to run a separate INN/Diablo?

Hi Marco,

Currently, for www.novabbs.com, there are 2,296,739 messages, and the
spool space used is 31G. Not too bad. Messages are in sqlite3 databases
(one per group), so no need to deal with millions of files.

I run and test on Debian Stable. Currently bookworm. The INSTALL file for
rslight shows what packages are needed, and Syber Shock, who also runs
rslight installs is a great source of finding out what I forget to put in
the INSTALL file, or instructions, etc. :)

The built in nntp server is actually the server that the website uses as
it's source for articles. The nntp server regularly polls an upstream
server (such as news.i2pn.org, or news.eternal-september.org, or whatever
you want to sync with). It (the local nntp server) sends local posts and
pulls remote posts via that upstream server.

Think of the built in nntp server as in place of something like leafnode.
No other nntp server is required, it is built in to rslight.

You can also connect your newsreader to the built in nntp server if you
wish. I do that here and it is how I will send this post.

The number of groups you choose to serve is up to you, but realize that
the more groups, the more resources required and the slower things can
get. NovaBBS seems to do fine with 4G of RAM and one CPU.

You can pull articles from your upstream server as far back as you wish,
you need to configure this in your overrides.conf . You choose how many
articles to go back when first connecting. Not dates, but articles (by
number).

If you choose to do this, you will have many more questions. Feel free to
ask as you go and we will try our best to help. Good luck!

On Sun, 17 Dec 2023 20:29:42 +0100
Marco Moock <mm+usenet-es@dorfdsl.de> wrote:

> Hello!
>
> Because GG stops providing peering and new Usenet discussions won't
> appear on GG, I thought about hosting rslight.

Someone got the memo. It's about time but better late than never.
> What are the resources needed to run it for an entire hierarchy, like
> de.* with discussions ranging in the past, maybe years?

If you snarf down all past history in some hierarchies, you can archive
them and just provide public access to a limited past date. You don't
have to make everything publicly available, and can just open up the
whole treasure trove for other sysops who want to run peers and
preserve the data. Almost no non-sysop users are going to preserve any
data, so making the whole trove available for them to waste bandwidth
and compute time is pointless.
> What about the built-in nntp server?
> Does it do the peering or do I need to run a separate INN/Diablo?

I have a few thoughts not directly related to rslight but to the
mechanics of dealing with so many sqlite databases or text files, and
with potential future spam and nut jobbery.

1. Set up your servers with a compression-based filesystem like ZFS or
BTRFS with snapshots and check-summing. This will be a big help in
conserving storage space since all stored data will be automatically
compressed.

2. Run a mirror peer on a totally separate machine as a backup, or at
least run a scheduled rsync mirror. If you don't, Wishidundat's law will
probably bite. When you do backup your data, you never need it. When
you don't, you needed it, and wishudundat.

3. Blacklist free email providers for signup, or at least require
applicants to write an explanation of why they are not a spammer or bot
before approving an account. I think proving ownership of a TLD by a
robots.txt comment or DNS TXT token is a good way to vet users. It also
provides you a get "don't blame me" card if some numskull does something
illegal with their account. Nobody can say you made it easy for idiots
to sign up.

That's my two cents to stave off storage and troll headaches. YMMV.