What would you like to see changed? Ideally, what could be done without substantively changing how a program, e.g. INN, is written / config
files are parsed.
Based on some comments in other threads, I gather that some think
that running a Usenet / NNTP / INN server has a higher entry bar than
it possibly should have.
Would you please elaborate on what you think is / was difficult or a
barrier of entry for you?
What would you like to see changed? Ideally, what could be done
without substantively changing how a program, e.g. INN, is written /
config files are parsed.
So I guess we should concentrate on making doc for the nntp user that
want to help his favorite media to progress and so want to get his own
usenet server.
Would you please elaborate on what you think is / was difficult or a
barrier of entry for you?
There's a LOT of configuration options, an overwhelming amount for a
new usenet admin, especially when it's not as prevalent as it once was.
It took me long enough to decide which type of spool I wanted to keep.
Lots of terminology and so much documentation. Most of it tells you
what to do but not why you're doing it.
I stuck with traditional
spool because that's what I know. I just took most of the defaults.
Took me a while to get authentication going, I'm not sure there's a way
to generate passwords. Maybe a more easier step by step setup that
clearly but concisely explains the process.
https://www.eyrie.org/~eagle/software/inn/docs/checklist.html
We have a "Readers" section in CHECKLIST with a basic readers.conf
example and how to generate passwords :)
% htpasswd -nbd user pass
user:LIfOpbjNaEQYE
% perl -e 'print "user:".crypt("pass", "LI")."\n";'
user:LIfOpbjNaEQYE
Based on some comments in other threads, I gather that some think that running a Usenet / NNTP / INN server has a higher entry bar than it
possibly should have.
Would you please elaborate on what you think is / was difficult or a
barrier of entry for you?
Based on some comments in other threads, I gather that some think that running a Usenet / NNTP / INN server has a higher entry bar than it
possibly should have.
Would you please elaborate on what you think is / was difficult or a
barrier of entry for you?
I ask in the spirit of hoping to collectively learn from this and
streamline / simplify Usenet / NNTP / INN server installation & configuration.
What would you like to see changed? Ideally, what could be done without substantively changing how a program, e.g. INN, is written / config
files are parsed.
What would you like to see changed? Ideally, what could be done without substantively changing how a program, e.g. INN, is written / config
files are parsed.
An installation tutorial (yes, there is one in INSTALL, kind of)
Hi Nigel,
Would you please elaborate on what you think is / was difficult or a
barrier of entry for you?
There's a LOT of configuration options, an overwhelming amount for a
new usenet admin, especially when it's not as prevalent as it once was.
It took me long enough to decide which type of spool I wanted to keep.
Lots of terminology and so much documentation. Most of it tells you
what to do but not why you're doing it.
To be concrete, what should be changed in our FAQ that could help
choosing the right type of spool?
https://www.eyrie.org/~eagle/faqs/inn.html#S2.1
I stuck with traditional
spool because that's what I know. I just took most of the defaults.
And that's a good choice :-)
The defaults are normally fine.
Took me a while to get authentication going, I'm not sure there's a way
to generate passwords. Maybe a more easier step by step setup that
clearly but concisely explains the process.
To be concrete, what should be added in the quick installation checklist
that explains the things to do to have a working installation?
https://www.eyrie.org/~eagle/software/inn/docs/checklist.html
We have a "Readers" section in CHECKLIST with a basic readers.conf
example and how to generate passwords :)
% htpasswd -nbd user pass
user:LIfOpbjNaEQYE
% perl -e 'print "user:".crypt("pass", "LI")."\n";'
user:LIfOpbjNaEQYE
--
Julien ÉLIE
« Timeo Danaos et dona ferentes. » (Laocoon de Virgile)
Can Readers use a system PAssword File?
readers.conf is the part of INN that I'm probably the least happy with
apart from the build system (which I really need to get back to working
on in time for a 2.7 release). It separates authentication and authorization, which is great in theory and I approve as a security
person, but at the cost of being essentially incomprehensible to anyone
who isn't familiar with enterprise authentication concepts and why you
would separate identity mapping from access control.
That one I totally agree with.
I always end up trial and error when adding or making a change to
reader.conf becuase that never made any fucking sense to me at all.
None of it, even after reading the man page for the past 20 years or so.
A series of walkthroughs (video or otherwise) explaining how to set up INN would be a great help.
my account. However I am still running on port 119 because I never could getting SSL working. I still can't get my signed certificates to be recognized and port 563 activated. Since my server is only for me and my
Would you please elaborate on what you think is / was difficult or a
barrier of entry for you?
8--
I'm not sure even the smaller modern config (PI?) need so much storage care.
to start, I guess *real* server admins (the ones with university grade)
do not really have problems. (if it's not, speak :-))
So I guess we should concentrate on making doc for the nntp user that
want to help his favorite media to progress and so want to get his own
usenet server.
At first, may be make some sort of dictionary to make more evident the meaning of the words used in the doc
readers.conf is the part of INN that I'm probably the least happy
with.... It separates authentication and authorization, ... but at
the cost of being essentially incomprehensible to anyone who isn't
familiar with enterprise authentication concepts and why you would
separate identity mapping from access control.
I'm not sure even the smaller modern config (PI?) need so much storage care.
is the "compile" part still needed?
I know it's difficult to manage, but have a section "Configure" just
under a line with "./configure --with-perl ..." is disturbing :-(.
"If using cycbuffs (the CNFS storage method)" comes at a moment where
nobody know what cycbuffs is - nor CNFS :-(
does it mean one have to use .htaccess to manage access to the forums?
Hi Grant,
The day to day running is quite easy but getting started was a pain
in the rear. I know Russ et al. work hard on their documentation, but
it wasn't an easy set up. It took a couple of days to get everything
working and that was before I asked for peers. I'm not a Linux newbie
but it was not easy to set up.
Here's an example, I had to post here asking for help getting
external user access set up. The directions that I needed were in a
man page that I didn't even know that I needed to read.
It works now and I'm posting from my account.
However I am still running on port 119 because I never could getting
SSL working. I still can't get my signed certificates to be recognized
and port 563 activated. Since my server is only for me and my friends,
I'm not terribly worried about security, but it would be nice to get
that working.
A series of walkthroughs (video or otherwise) explaining how to set
up INN would be a great help.
On Sat, 8 Jan 2022 00:54:20 -0700
Grant Taylor <gtaylor@tnetconsulting.net> wrote:
It also took me a while to find peers. I emailed many and got a few responses. Now I know to look in news.admin.peering. Maybe a mention
there along with a possible list of willing news admins who are willing
to work with new newsmasters and help become their first peer.
to setup 3 separate files and making sure they're all right could be
somewhat daunting to a new news admin.
daunting is a bit big, but unquiet, yes.
I just read the grep manual to use
to check files.
The first peer is somewhat easier than subsequent because subsequent
brings other questions with it. Am I causing a loop? How badly did /
can / will I break things?
No. That's what the Path: header is for. You don't send stuff to
a peer that already has the peer's name in the path.
Potential loops and redundant feeds are fine. Even with the path
checking, you get some duplication if the message arrived at the two
peers by different paths, but the message-id takes care of that.
On 2022-01-09, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
The first peer is somewhat easier than subsequent because subsequent
brings other questions with it. Am I causing a loop? How badly did /
can / will I break things?
On this note, is ensuring loops don't occur a function of peering
agreements?
On 1/9/22 9:16 PM, John Levine wrote:
No. That's what the Path: header is for. You don't send stuff to a
peer that already has the peer's name in the path.
My understanding is that news servers will also ignore an incoming
article if their own ID (from the me: entry) is already in the path. So you're protected on both sides of a peering session.
Though I think that there is a timing aspect. E.g. if the second /
duplicate message arrives /after/ the Message-ID has been purged from history.
It took me long enough to decide which type of spool I wanted to keep.
Lots of terminology
Most of it tells you
what to do but not why you're doing it.
"If using cycbuffs (the CNFS storage method)" comes at a moment where
nobody know what cycbuffs is - nor CNFS :-(
Ya. Bootstrap documentation such that things are introduced / defined before they are referenced is ... difficult. It's almost always
extremely long compared to more dense documentation that assumes prior knowledge of a specific concept.
does it mean one have to use .htaccess to manage access to the forums?
I feel like "htpasswd" is a bit of a name collision. My understanding
is that INN is re-using a (presumed to be) standard utility.
Would you please elaborate on what you think is / was difficult or a
barrier of entry for you?
Can Readers use a system PAssword File?
I mostly think that man pages are a great form of reference when you
have an idea what you're looking for
but they make terrible introduction material.
However I am still running on port 119 because I never could getting
SSL working. I still can't get my signed certificates to be recognized
and port 563 activated. Since my server is only for me and my friends,
I'm not terribly worried about security, but it would be nice to get
that working.
Ya. TLS support for INN is ... let's go with a work in progress.
A series of walkthroughs (video or otherwise) explaining how to set up
INN would be a great help.
I'm personally not a fan of videos. But textual walk through, sure.
I had to post here asking for help getting external
user access set up. The directions that I needed were in a man page that I didn't even know that I needed to read.
It works now and I'm posting from
my account. However I am still running on port 119 because I never could getting SSL working. I still can't get my signed certificates to be recognized and port 563 activated.
A series of walkthroughs (video or otherwise) explaining how to set up INN would be a great help.
The main problem was to get an overview of how
the individual components interact, i.e. the flow of articles from peers
and posters into INN, from there into the storage system and then from
there back out to the peers, and what role the individual programs that
make up the INN distribution and their configuration files play. The documentation of those individual parts is absolutely exemplary, but I
missed an overview of the big picture.
In my opinion, you need two things to set up and run INN:
1. A tutorial on how to set up the server for the first time
2. An overview, perhaps even including a few diagrams, of how all the individual programss and their configuration files fit together and
interact.
I tried to do that in 2005:
<https://th-h.de/net/usenet/servers/inn/overview/> (German language)
3. recipes for certain tasks and situations,
... but that is the typical task of a FAQ, and the FAQ can be expanded
as needed for that.
https://www.eyrie.org/~eagle/software/inn/docs/checklist.html
missed this one :-(. should be linked on top of "documentation" here:
https://www.eyrie.org/~eagle/software/inn/
(no "checklist" in this page :-()
probably a typo: "work on the files in ~news/etc" should be "work on the files in ~news"
is the "compile" part still needed?
I know it's difficult to manage, but have a section "Configure" just
under a line with "./configure --with-perl ..." is disturbing :-(
"If using cycbuffs (the CNFS storage method)" comes at a moment where
nobody know what cycbuffs is - nor CNFS :-(
I stopped reading here. Good idea, but have to be completely rewritten :-(
We have a "Readers" section in CHECKLIST with a basic readers.conf
example and how to generate passwords :)
     % htpasswd -nbd user pass
     user:LIfOpbjNaEQYE
     % perl -e 'print "user:".crypt("pass", "LI")."\n";'
     user:LIfOpbjNaEQYE
does it mean one have to use .htaccess to manage access to the forums?
Bonsoir Jean-Daniel,
probably a typo: "work on the files in ~news/etc" should be "work on the
files in ~news"
No, it's really "~news/etc" as the sentence speaks about <pathetc>, as
said in the parenthesis:
"work on the files in ~news/etc (the default <pathetc> location set in inn.conf)"
is the "compile" part still needed?
It is the CHECKLIST for the INN upstream package, not the OpenSUSE
package...
     % htpasswd -nbd user pass
     user:LIfOpbjNaEQYE
does it mean one have to use .htaccess to manage access to the forums?
No, you don't need using .htaccess (that's not what is written here). I
just provided commands to Nigel who was asking how to generate passwords
for readers.conf.
The first peer is somewhat easier than subsequent because subsequent
brings other questions with it. Am I causing a loop? How badly did /
can / will I break things?
This uncertanty seems to be perfectly normal to me.
"work on the files in ~news/etc (the default <pathetc> location set in
inn.conf)"
this I don't understand. ~news/etc is not a path??
No. That's what the Path: header is for. You don't send stuff to a
peer that already has the peer's name in the path.
My understanding is that news servers will also ignore an incoming
article if their own ID (from the me: entry) is already in the path.
This should not be possible if the server is correctly configured. The
history database entry should be retained for longer than the cutoff time
on the article Date / Injection-Date, so any article that is no longer in
history should be rejected as being too old (assuming nothing is messing
with the Date / Injection-Date headers).
Jean-Daniel knows that by heart :-)
(private joke)
With this in mind, I wonder if a "First Server" / "New Newsmaster" type document might be in order. Something that provides suggestions on how[...]
to get started with your first server.
The other very big thing that I think needs to be provided is a highThere are several layers in documentation, maintained by different
level overview of Usenet, NNTP, and news servers in general.
Neither of these documents need, nor should, be an end all be all
document. Especially the "First Server" / "New Newsmaster" document
should be more of a boot strap type document.
There will be things that
may be sub-optimal from a performance point of view, but chosen because
they have a lower barrier to entry while suggesting to check things out
again at some point in the future.
I have no etc in ~news, but ~news is /etc/news, so it's pretty confusing[...]
so most of the time pathnews and pathetc are the same
to be made clear somewhere :-)
articles where my path name is already present in the Path header field.
this I don't understand. ~naws/etc is not a path??
sure but who still compile apps, apart linux from scratch?
Distributors who supply INN packages often rearrange the files and directories.
Unfortunately, this is very confusing for system administrators,
because the documentation is not updated to reflect the modified
locations of files.
Hi Grant,
It even sounds like a questionary to fill, and then the right optimized documentation appears :-)
Or a book you are the Hero, will plenty of "if x go to page n" :-)
Apart of a global schema of INN's architecture, I would still like to understand why already existing contributed documentation for "First
Server" is still not good enough, and what should be added.
8--
(Nobody answered when I asked what should be changed in these one-HTML
pages describing the installation of INN and its related packages.)
it should also be made clear what a "path" is.
once again, same word for different use... confusing.
* system path, where Linux looks for executable
* local path:
* feed path: route followed by an article (if I understand well) -
example in the article I answer:
Hi Grant,
Yes exactly, the special ME entry in newsfeeds can do that.
Anyway, all of that could be done via Cleanfeed.
If a distro is using atypical paths, then I think they need to either
update the documentation, or do something like the sym-link trick to
have their path point to the paths in the documentation so that things
seem rational.
1. A tutorial on how to set up the server for the first time
That's a tough tutorial to do!
I tried to do that in 2005:
<https://th-h.de/net/usenet/servers/inn/overview/> (German language)
Good job! Pretty detailed.
Russ, couldn't it be added in the "Contributed documentation" of your
INN's main web page?
Based on some comments in other threads, I gather that some think that running a Usenet / NNTP / INN server has a higher entry bar than it
possibly should have.
Would you please elaborate on what you think is / was difficult or a
barrier of entry for you?
I ask in the spirit of hoping to collectively learn from this and
streamline / simplify Usenet / NNTP / INN server installation & configuration.
What would you like to see changed? Ideally, what could be done
without substantively changing how a program, e.g. INN, is written /
config files are parsed.
Or someone could do a (machine-assisted, eg. by Deeple) translation to English before; it's CC-licensed (BY-NC-SA) and could be re-licensed in
any way necessary.
-thh
Hi Thomas,
2. An overview, perhaps even including a few diagrams, of how all the
individual programss and their configuration files fit together and
interact.
I tried to do that in 2005:
<https://th-h.de/net/usenet/servers/inn/overview/> (German language)
Good job! Pretty detailed.
Russ, couldn't it be added in the "Contributed documentation" of your
INN's main web page?
https://www.eyrie.org/~eagle/software/inn/docs/checklist.htmlmissed this one :-(. should be linked on top of "documentation" here:
https://www.eyrie.org/~eagle/software/inn/
(no "checklist" in this page :-()
A suggestion for Russ.
It indeed may be worth highlighting more CHECKLIST and INSTALL.
I've added some more prominent links to the checklist and install for the current stable version.
1. A tutorial on how to set up the server for the first time
It's mostly covered by INSTALL and the checklist, I think.
A couple things that stood out to me:
1. I only found out about the Checklist in this thread. I naturally
went straight for the README and INSTALL first because they were at
the top of the list of docs.
2. The "Choosing an article storage format" section seems a bit
unnecessary for most folks. There's just enough detail to know that
there's alternatives to things like "tradspool", but not enough to
know exactly what benefits are offered by something like "cnfs". The
"nerdy layperson" in me is confused at the choice, the engineer in me
wants to know just how much faster under what conditions an allocated
buffer as in cnfs is than tradspool, especially on newer filesystems
and SSDs.
3. The "Overview Storage Mechanism" section also seems a bit
overkill. The layperson in me would skim the section and pick
"tradindexed" because "traditional" sounds conservative and easy? The engineer in me again wonders under which conditions I would pick one
or the other. I went with ovsqlite because I'm familiar with the
performance and guarantees of sqlite.
4. The syntax for the different files is confusing. It's like I'm
learning a new config DSL for each thing.
5. I'm unclear as to why Perl and Python are compiled into INN for
filter usage. Is it to avoid spawning a Perl or Python subprocess when running filters? How does this work?
At a high-level I'd like a couple things:
1. An opinionated guide on setting up INN that picks sane defaults
based on today's filesystems, SSDs, and networking assumptions. Folks interested in UUCP can certainly read about integrating rmail, but
most folks setting up INN will just want NNTP support. I also don't
know how hard it is for a modern computer/VPS to handle Usenet levels
of traffic, so I'm unsure on how careful the operator needs to be when picking the article storage format or the overview storage mechanism.
2. An architectural explanation on how INN works.
3. A clearer explanation on how filters work and why you'd even need
filters.
Or a book you are the Hero, will plenty of "if x go to page n" :-)
I would STRONGLY recommend avoiding page number references.
I would hope that the first server document could be read in the amount
of time that it takes to read a long email. It shouldn't answer all the questions. But it should provide some background / context and provide pointers of where to get more detailed information.
In some ways, it's more of an introduction / overview that someone might
give in the first 5-10 minutes of a multi-hour talk, wherein they
brifely itroduce the concept and say something like "we'll talk more
about spool storage when we get back from lunch" type thing.
The first server document should leave the reader with an idea of "i
need to go read <this>, <that>, and <other thing>, but I do have an idea
how the three relate to each other and why they are important at the
1,000 foot level.
Hi Grant,
Hmm, maybe my reference was not clear enough.
I see that the name "a book you are the hero" ("Un livre dont vous êtes
le héros", in French) is the one chosen by a French editor.
They're known as gamebooks or "choose your own adventure" in your country.
So of course I wouldn't have hard-coded the page numbers. Modern
editing software know how to dynamically update number pages when doing proper references.
Good idea.
And then he takes an aspirin :-)
Personally for me not technical, but, primary, the organizational
component serves as an barrier to set up and own NNTP server. For
example, INN 2.x FAQ says nothing about how to find a peer. No peer - no useful content - no reason to set up and advertise own NNTP server.
Based on some comments in other threads, I gather that some think
that running a Usenet / NNTP / INN server has a higher entry bar than
it possibly should have.
Another thing that I think that was missing was a list of pre-req
packages or libraries, possibly listed for the most common types of
package system such as rpms or .deb packages. I moved to another server
and tried to compile but was missing perl_alloc which I had to chase
down and a few other bits. Knowing ahead of time what I need would save several iterations through ./configure
Another thing that I think that was missing was a list of pre-req
packages or libraries, possibly listed for the most common types
of package system such as rpms or .deb packages.
I moved to another server and tried to compile but was missing
perl_alloc which I had to chase down and a few other bits. Knowing
ahead of time what I need would save several iterations through
./configure
[This got stuck in my client outbound queue for some reason)
I moved to another server and tried to compile but was missing
perl_alloc which I had to chase down and a few other bits. Knowing
ahead of time what I need would save several iterations through
./configure
Compiling from source is another thing entirely.
I would expect that there is documentation about what dependencies there
are.
But IM(ns)HO the configure script /is/ the method for ensuring that dependencies are met when compiling.
Admittedly it would be nice if the configure script could ~> would make
it through all the tests and then generate a report of what's preventing
the build.
perl_alloc comes from the Perl development libraries (libperl-dev).
I've just had a look at the logs of Debian builds:
And Fedora builds:
Is it the list you would like to appear in CHECKLIST and INSTALL?
I'll add libcanlock-dev and libsqlite3-dev for INN 2.7.0 (for Cancel
Lock support and the news ovsqlite overview method).
It is libcanlock-devel and sqlite3-devel for Fedora.
Any other things you would like to add in our installation guide that
you think would have been helpful?
I would expect that the system's package manager would handle
dependencies when installing packages.
I would expect that there is documentation about what dependencies
there are.
But IM(ns)HO the configure script /is/ the method for ensuring that dependencies are met when compiling.
Admittedly it would be nice if the configure script could ~> would
make it through all the tests and then generate a report of what's
preventing the build. That way you could probably reduce the number
of runs to two. The first time to find out what is missing, and the
second time actually do the configure having fulfilled the
dependencies.
Not when you build from source, obviously.
There is no mention of perl_alloc in the root or doc directory.
Yes but saying that is cannot find perl_alloc doesn't tell me which
package I need to install. It would be better to have a list of all
libraries and possibly a package list for the major distros.
Right, but still without knowing which package something is in, that
still leaves it to end user to hunt down the missing package.
I could probably bring up a fresh VM for Ubuntu and go through the
install and see what I need, but I'll probably end up installing a
bunch of stuff I also don't need to try and find the right dependency, because they're not listed anywhere...vicious circle.
On 1/27/22 7:52 PM, Nigel Reed wrote:
Not when you build from source, obviously.
Source and packaged versions are two completely different things.
There is no mention of perl_alloc in the root or doc directory.
I think that's being worked on / rectified.
Right, but still without knowing which package something is in, that
still leaves it to end user to hunt down the missing package.
Both of these (last) comments are a symptom of the difference between
source vs packaged distribution. If you are doing things from
source, you are working in a distribution agnostic manner. As such,
there would not be any information as to what packages are called.
It is up to you to identify which package provides a given dependency
for the distribution that you're using.
There are a lot of different distributions across many different OSs. Expecting a source maintainer to know what package is used on your
specific OS / distribution is ... probably unreasonable.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 295 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 01:39:39 |
| Calls: | 6,642 |
| Calls today: | 2 |
| Files: | 12,190 |
| Messages: | 5,325,422 |