I managed to get INN2 installed and working locally. The Debian/Ubuntu
package is broken and would not install so I had to troubleshoot. No joy.

How do I enable username/password authentication for all readers? What
config option in inn.conf or readers.conf or whatever will make it so:

Every reader, local or remote, must enter a username and password in
their reader software to post anything to any group, ever.

Are there already any scripted solutions for allowing people to sign up
for credentials through a web or CLI interface?

Is it possible to confine authentication data to INN without creating
unix user accounts? If so lay that out.

--

G.K.

On 7/22/22 09:00, G.K. wrote:
> I managed to get INN2 installed and working locally. The Debian/Ubuntu
> package is broken and would not install so I had to troubleshoot. No joy.
>
> How do I enable username/password authentication for all readers? What
> config option in inn.conf or readers.conf or whatever will make it so:
>
> Every reader, local or remote, must enter a username and password in
> their reader software to post anything to any group, ever.
>
> Are there already any scripted solutions for allowing people to sign up
> for credentials through a web or CLI interface?
>
> Is it possible to confine authentication data to INN without creating
> unix user accounts? If so lay that out.
>
> --
>
> G.K.

I just realized that Eternal-September has a authenticated setup in
which people sign up for credentials via email. I would like to set up
my NNTP server similarly but without a public website, or at least
restrict access to the website similarly to the NNTP server. Instead
users would use a terminal and telnet or ssh to sign up, then the
user/pass would be sent to their email.

Also do any sysops use stunnel to negotiate TLS for nnrpd? I'm
considering that and trying to figure out how exactly and if it is
better than configuring TLS paths directly in nnrpd.

If anyone from Eternal-September or elsewhere has any advice on how to
proceed it would be appreciated. Please post links to any requisite
docs, code repos, or libraries.

--

G.K.

On 7/22/22 2:18 PM, G.K. wrote:
> Also do any sysops use stunnel to negotiate TLS for nnrpd? I'm
> considering that and trying to figure out how exactly and if it is
> better than configuring TLS paths directly in nnrpd.

I've found that using direct support for something is almost always
better than using indirect support for the same thing.

I'm running nnrpd with TLS support directly on port 563.

--
Grant. . . .
unix || die

On 7/22/22 2:18 PM, G.K. wrote:
> I just realized that Eternal-September has a authenticated setup in
> which people sign up for credentials via email.

> I would like to set up my NNTP server similarly but without a public
> website, or at least restrict access to the website similarly to the
> NNTP server.

I think setting up the email portion would be trivial. People can email
newsmaster@example.com with a request for an account. But the kicker is
that they need to know to email newsmaster@example.com, knowledge that
frequently comes from a web page, something that's hard to do without a
web server.

Admittedly, such sign up would be manual and require the newsmaster to
take action. Though I suspect that's good from an anti-abuse perspective.

> Instead users would use a terminal and telnet or ssh to sign up,
> then the user/pass would be sent to their email.

I think that enabling terminal access (even if it's not full shell
access) is asking for miscreants to abuse ssh / telnet / et al.

What's more, if you aren't going to also be providing terminal access
for reading / posting, think I think you're opening up an attack surface
just for sing up. Something that seems questionable in my opinion.

--
Grant. . . .
unix || die

On 7/22/22 15:33, Grant Taylor wrote:
> On 7/22/22 2:18 PM, G.K. wrote:
>> I just realized that Eternal-September has a authenticated setup in
>> which people sign up for credentials via email.
>
>> I would like to set up my NNTP server similarly but without a public
>> website, or at least restrict access to the website similarly to the
>> NNTP server.
>
> I think setting up the email portion would be trivial.  People can email
> newsmaster@example.com with a request for an account.  But the kicker is
> that they need to know to email newsmaster@example.com, knowledge that
> frequently comes from a web page, something that's hard to do without a
> web server.
>
> Admittedly, such sign up would be manual and require the newsmaster to
> take action.  Though I suspect that's good from an anti-abuse perspective.
>
>> Instead users would use a terminal and telnet or ssh to sign up, then
>> the user/pass would be sent to their email.
>
> I think that enabling terminal access (even if it's not full shell
> access) is asking for miscreants to abuse ssh / telnet / et al.
>
> What's more, if you aren't going to also be providing terminal access
> for reading / posting, think I think you're opening up an attack surface
> just for sing up.  Something that seems questionable in my opinion.

This may be true. But first things first, having a wide open server to
which anyone can post without authenticating is also an attack surface.

How do I configure INN2 to require authentication for all readers
(including origin localhost)? I would like to get that taken care of
first so I can open up a firewall port and test it out. Figuring out my
front end for signups although important, can come later.

--

G.K.

Hi,
G.K. a écrit :
> How do I configure INN2 to require authentication for all readers
> (including origin localhost)? I would like to get that taken care of
> first so I can open up a firewall port and test it out. Figuring out my
> front end for signups although important, can come later.

The official doc is here but it not give a simple example :
<https://www.eyrie.org/~eagle/software/inn/docs-2.7/readers.conf.html>

For my server I have followed this french documentation which give a simple
example :
<https://git.alphanet.ch/gitweb/?p=inn-install;a=blob_plain;f=README.html;hb=HEAD#le-fichier-readers.conf>

--
Stéphane
Sorry for my bad English

On 7/24/22 00:51, yamo' wrote:
> Hi,
> G.K. a écrit :
>> How do I configure INN2 to require authentication for all readers
>> (including origin localhost)? I would like to get that taken care of
>> first so I can open up a firewall port and test it out. Figuring out my
>> front end for signups although important, can come later.
>
> The official doc is here but it not give a simple example :
> <https://www.eyrie.org/~eagle/software/inn/docs-2.7/readers.conf.html>
>
> For my server I have followed this french documentation which give a simple
> example :
> <https://git.alphanet.ch/gitweb/?p=inn-install;a=blob_plain;f=README.html;hb=HEAD#le-fichier-readers.conf>

Thank you. This is helpful. Would you mind if I publish my English
translation of your document once I clean it up?

--

G.K.

Hi,
G.K. a tapoté le 24/07/2022 09:25:
> On 7/24/22 00:51, yamo' wrote:
>> G.K. a écrit :
>>> How do I configure INN2 to require authentication for all readers
>>> (including origin localhost)? I would like to get that taken care of
>>> first so I can open up a firewall port and test it out. Figuring out my
>>> front end for signups although important, can come later.
>>
>> The official doc is here but it not give a simple example :
>> <https://www.eyrie.org/~eagle/software/inn/docs-2.7/readers.conf.html>
>>
>> For my server I have followed this french documentation which give a simple
>> example :
>> <https://git.alphanet.ch/gitweb/?p=inn-install;a=blob_plain;f=README.html;hb=HEAD#le-fichier-readers.conf>
>
> Thank you. This is helpful. Would you mind if I publish my English
> translation of your document once I clean it up?

This documentation is absolutely open source.
It has been done by several people.

--
Stéphane

On 7/22/22 10:00, G.K. wrote:
> I managed to get INN2 installed and working locally. The Debian/Ubuntu
> package is broken and would not install so I had to troubleshoot. No joy.
>
> How do I enable username/password authentication for all readers? What
> config option in inn.conf or readers.conf or whatever will make it so:
>
> Every reader, local or remote, must enter a username and password in
> their reader software to post anything to any group, ever.
>
> Are there already any scripted solutions for allowing people to sign up
> for credentials through a web or CLI interface?
>
> Is it possible to confine authentication data to INN without creating
> unix user accounts? If so lay that out.
>
> --
>
> G.K.
>
>
Chromium translates the page quite nicely.

On 7/22/22 10:00, G.K. wrote:
> I managed to get INN2 installed and working locally. The Debian/Ubuntu
> package is broken and would not install so I had to troubleshoot. No joy.
>
> How do I enable username/password authentication for all readers? What
> config option in inn.conf or readers.conf or whatever will make it so:
>
> Every reader, local or remote, must enter a username and password in
> their reader software to post anything to any group, ever.
>
> Are there already any scripted solutions for allowing people to sign up
> for credentials through a web or CLI interface?
>
> Is it possible to confine authentication data to INN without creating
> unix user accounts? If so lay that out.
>
> --
>
> G.K.
>
>

chromium translates the page nicely.

yamo' <yamo@beurdin.invalid> wrote:
>> Thank you. This is helpful. Would you mind if I publish my English
>> translation of your document once I clean it up?
>
> This documentation is absolutely open source.
> It has been done by several people.

Yes, it is freely usable and modifiable. If you need, I could even host
the English translation.

Hi G.K.,

> I managed to get INN2 installed and working locally. The Debian/Ubuntu
> package is broken and would not install so I had to troubleshoot. No joy.

What problems did you encounter with the Debian/Ubuntu package? Did you
open a bug report for it?

> How do I enable username/password authentication for all readers? What
> config option in inn.conf or readers.conf or whatever will make it so:
>
> Every reader, local or remote, must enter a username and password in
> their reader software to post anything to any group, ever.

Stéphane gave you links to achieve that in this thread.

Could you please tell what should be improved in the first section of
the readers.conf man page ("IN A NUTSHELL")? It should normally have
answered your question, but apparently isn't still clear enough. I
would be glad to improve it: what is missing or should be better
explained in that first section of the man page?
https://www.eyrie.org/~eagle/software/inn/docs/readers.conf.html

It also refers to the documentation of the -f flag of ckpasswd to
generate password hashes:
https://www.eyrie.org/~eagle/software/inn/docs/ckpasswd.html

--
Julien ÉLIE

« – Quelle idée de nous atteler à des balistes ! C'est un travail de
Romains ça !
– Justement, de quoi te plains-tu ? » (Astérix)

On 7/30/22 03:22, Julien ÉLIE wrote:
> Hi G.K.,
>
>> I managed to get INN2 installed and working locally. The Debian/Ubuntu
>> package is broken and would not install so I had to troubleshoot. No joy.
>
> What problems did you encounter with the Debian/Ubuntu package?  Did you
> open a bug report for it?

Not yet. See below.

>> How do I enable username/password authentication for all readers? What
>> config option in inn.conf or readers.conf or whatever will make it so:
>>
>> Every reader, local or remote, must enter a username and password in
>> their reader software to post anything to any group, ever.
>
> Stéphane gave you links to achieve that in this thread.
>
> Could you please tell what should be improved in the first section of
> the readers.conf man page ("IN A NUTSHELL")?  It should normally have
> answered your question, but apparently isn't still clear enough.

Or maybe it just needs rednecked down with color ABC blocks. ;)
  I
> would be glad to improve it: what is missing or should be better
> explained in that first section of the man page?
>   https://www.eyrie.org/~eagle/software/inn/docs/readers.conf.html

I'll have a look but not today. I must finish the grindstone list.

> It also refers to the documentation of the -f flag of ckpasswd to
> generate password hashes:
>   https://www.eyrie.org/~eagle/software/inn/docs/ckpasswd.html

I saw that part and got a bead on it. I'm leaning toward finding or
building a front end that automates all that. I'm leaning toward telnet
or ssh over a socat or s_server socket because I don't want another web
server with all its attack surface and complexity and a bunch of PHPoo
and graphical web sorcery just to negotiate a set of tokens to an email
address.

Debian does not fully install the package and exits with unintelligible
errors which I failed to copypasta and forgot about after tinkering with
other things. I would have to scrub the system and re-install from
scratch to replicate the apt errors. Maybe later, since I'm still
tinkering with configuration and making notes so I can do it again later.

Find below systemd errors and how I fixed the problem.

Here is systemd output directly after install:

$ sudo journalctl -u inn2

Jul 20 10:55:35 dev systemd[1]: Starting LSB: INN news server...
Jul 20 10:55:36 dev inn2[31091]: * Starting news server innd
Jul 20 10:55:36 dev dma[31130]: new mail from user=news uid=9
envelope_from=<news@dev>
Jul 20 10:55:36 dev dma[31130]: mail to=<root> queued as
19c07f9.56392eebd8e0
Jul 20 10:55:36 dev dma[31131]: <root> trying delivery
Jul 20 10:55:36 dev dma[31131]: <root> delivery successful
Jul 20 10:55:36 dev inn2[31091]: ...done.
Jul 20 10:55:36 dev innd[31138]: SERVER descriptors 1023
Jul 20 10:55:36 dev innd[31138]: SERVER outgoing 1010
Jul 20 10:55:36 dev systemd[1]: Started LSB: INN news server.
Jul 20 10:55:36 dev innd[31138]: dbz: bad first line in .dir history file
Jul 20 10:55:36 dev innd[31138]: dbzinit: getconf failure
Jul 20 10:55:36 dev innd[31138]: can't dbzinit /var/lib/news/history
Numerical argument out of domain
Jul 20 10:55:36 dev innd[31138]: dbzclose: not opened!
Jul 20 10:55:36 dev innd[31138]: can't dbzclose /var/lib/news/history
Numerical argument out of domain
Jul 20 10:55:36 dev innd[31138]: SERVER can't open history
/var/lib/news/history: Numerical argument out of domain
Jul 20 11:25:59 dev systemd[1]: Stopping LSB: INN news server...
Jul 20 11:26:00 dev inn2[35190]: * Stopping news server innd
Jul 20 11:26:00 dev inn2[35190]: ...done.
Jul 20 11:26:00 dev systemd[1]: inn2.service: Succeeded.
Jul 20 11:26:00 dev systemd[1]: Stopped LSB: INN news server.

First sudo apt-get install inn2, which unpacks everything then exits
with the errors. INN files are installed but do not run. Restarting the
systemd service fails. Invoking news.rc fails. I fixed the problem on
Debian this way:

$ sudo systemctl stop inn2
$ sudo -u news /usr/lib/news/bin/makehistory
$ sudo -u news /usr/lib/news/bin/makedbz
$ sudo systemctl start inn2

$ sudo journalctl -u inn2

Jul 20 17:42:31 dev systemd[1]: Starting LSB: INN news server...
Jul 20 17:42:33 dev systemd[1]: Started LSB: INN news server.
Jul 20 20:31:53 dev systemd[1]: Stopping LSB: INN news server...
Jul 20 20:31:53 dev inn2[38086]: * Stopping news server innd
Jul 20 20:31:54 dev inn2[38086]: ...done.
Jul 20 20:31:54 dev systemd[1]: inn2.service: Succeeded.
Jul 20 20:31:54 dev systemd[1]: Stopped LSB: INN news server.
Jul 20 20:32:06 dev systemd[1]: Starting LSB: INN news server...
Jul 20 20:32:06 dev inn2[38131]: * Starting news server innd
Jul 20 20:32:06 dev innd[38170]: SERVER descriptors 1023
Jul 20 20:32:06 dev innd[38170]: SERVER outgoing 1010
Jul 20 20:32:06 dev inn2[38131]: ...done.
Jul 20 20:32:06 dev systemd[1]: Started LSB: INN news server.

I would suggest a few shell commands cobbled together to check the
database, history, file permissions, etc. and other stuff that would
stop the server upon a botched install, and push it to the package
maintainer.

I will get back to you hopefully in a couple weeks when I can free up
time for this. To do a proper bug report I need to replicate on a fresh
system, then navigate the package maintainer's minefield of gotchas and
reasons we didn't even look at your bug report for the past 5 years, and
why your bug report is closed as a duplicate of this other bug report we
didn't look at for the past 5 years. ;)

BTW: Grumpy Smurf hates systemd. Nice going Debian, for welding Linux to
systemd malware and making it so only heute-teute, artsy-fartsy
city-slickers can play.

SystemD was only ever a solution in search of a problem.

--

G.K.

Hi G.K.,
> Debian does not fully install the package and exits with unintelligible
> errors which I failed to copypasta and forgot about after tinkering with
> other things.
>
> Here is systemd output directly after install:
>
> $ sudo journalctl -u inn2
>
> Jul 20 10:55:36 dev innd[31138]: dbz: bad first line in .dir history file
> Jul 20 10:55:36 dev innd[31138]: dbzinit: getconf failure
> Jul 20 10:55:36 dev innd[31138]: can't dbzinit /var/lib/news/history
> Numerical argument out of domain
> Jul 20 10:55:36 dev innd[31138]: dbzclose: not opened!
> Jul 20 10:55:36 dev innd[31138]: can't dbzclose /var/lib/news/history
> Numerical argument out of domain
> Jul 20 10:55:36 dev innd[31138]: SERVER can't open history
> /var/lib/news/history: Numerical argument out of domain

Oh, that's strange. It seems that the history file already existed.
Did you install inn before, and then inn2 without purging the installed
files by INN 1.7.2?
It would explain why the inn2 package didn't install a fresh empty
history file in the inn2 format.

> I would suggest a few shell commands cobbled together to check the
> database, history, file permissions, etc. and other stuff that would
> stop the server upon a botched install, and push it to the package
> maintainer.

There's the inncheck program for that :-)

Maybe the inn2 package should check before beginning its installation
that the history file is not in the 1.7.2 format? (or any other check
showing that there is a conflict with old files from the inn package not
purged)

.... or remove the inn package from Debian ^^

--
Julien ÉLIE

« Petite annonce : Artificier cherche femme canon. »

On 8/1/22 14:45, Julien ÉLIE wrote:
> Hi G.K.,
>> Debian does not fully install the package and exits with
>> unintelligible errors which I failed to copypasta and forgot about
>> after tinkering with other things.
>>
>> Here is systemd output directly after install:
>>
>> $ sudo journalctl -u inn2
>>
>> Jul 20 10:55:36 dev innd[31138]: dbz: bad first line in .dir history file
>> Jul 20 10:55:36 dev innd[31138]: dbzinit: getconf failure
>> Jul 20 10:55:36 dev innd[31138]: can't dbzinit /var/lib/news/history
>> Numerical argument out of domain
>> Jul 20 10:55:36 dev innd[31138]: dbzclose: not opened!
>> Jul 20 10:55:36 dev innd[31138]: can't dbzclose /var/lib/news/history
>> Numerical argument out of domain
>> Jul 20 10:55:36 dev innd[31138]: SERVER can't open history
>> /var/lib/news/history: Numerical argument out of domain
>
> Oh, that's strange.  It seems that the history file already existed.
> Did you install inn before, and then inn2 without purging the installed
> files by INN 1.7.2?

No. This is fresh install on a fresh system that for certain had no
prior installation of INN. Something in the package install scripts is
off, or doing operations out of order. I remember being 100% certain it
was something in the Debian package configuration, which was reporting
errors and failure to install the package, even though the files had
been copied to the filesystem.

> It would explain why the inn2 package didn't install a fresh empty
> history file in the inn2 format.

It might be touching the history file then the error halts installation
before it is set up right. I'll set aside an hour and a half to look
into it when I have time to install Linux on a blank box and make notes
for every step I take. It's on my todo list.

>> I would suggest a few shell commands cobbled together to check the
>> database, history, file permissions, etc. and other stuff that would
>> stop the server upon a botched install, and push it to the package
>> maintainer.
>
> There's the inncheck program for that :-)

Yeah, but guaranteed automagic resolution on package install would be nice.

> Maybe the inn2 package should check before beginning its installation
> that the history file is not in the 1.7.2 format?  (or any other check
> showing that there is a conflict with old files from the inn package not
> purged)

We could eventually push something like this to the maintainer. Rather
than asking maintainer to do it, just push some code ready to roll.

> ... or remove the inn package from Debian ^^
>

--

G.K.