Hi all,

Seeing how long it takes, and also how difficult it could be, for new
users to get a working whole installation of a news server with usual
setup, wouldn't a ready-to-use package be useful to provide in
distributions?

For instance, a package which already has enabled:
- Cleanfeed (or PyClean)
- top1000 stats
- NoCeM keys
- active newsfeeds entry for NoCeM and ninpaths
- keys related to control.ctl
- whole active and newsgroups file from ftp.isc.org
- innreport with pictures and HTML archives
- nnrpd/TLS ready with auto-renewal of certificates via certbot
- ...

The example is for INN but other news servers of course could have a
similar packaging.

I believe it is easier to de-activate the features a news admin does not
want than having to install everything.

Just a thought to share.
Of course the remarks of package maintainers would be greatly
appreciated :-)

--
Julien ÉLIE

« Le bonheur, c'est de continuer à désirer ce que l'on possède. »
(Saint-Augustin)

Hi,

Julien ÉLIE a tapoté le 06/01/2022 10:03:
> The example is for INN but other news servers of course could have a
> similar packaging.

I agree and I would propose a "simplepeer.conf" for simple peering which
are copied and pasted (often with errors) into incoming.conf, newsfeeds
and innfeed.conf.
The old config files would be kept for compatibility with the actual
configuration or for complex feeds (not exactly the same for news-in and
news-out, special feeds ...). A news error will be useful is someone
configure the "simplepeer.conf" file and one of the old config-files ;)

--
Stéphane

On 2022-01-06, Julien ÉLIE <iulius@nom-de-mon-site.com.invalid> wrote:

> Seeing how long it takes, and also how difficult it could be, for new
> users to get a working whole installation of a news server with usual
> setup, wouldn't a ready-to-use package be useful to provide in
> distributions?

Not everone needs such an inflated package. I for instance only need a
plain INN installation since I don't peer via stream feeds or similar
things but via suck or consorts.

Feel free to develop/build packages for cleanfeed and default/sample
peer entries! If you also supply them via suitable repositories
everyone could use them.

> [...]

Best regards,
Henning
--
How many bits would a BitBlit blit if a BitBlit could blit bits?
-- macanespie@waves.pas.ti.com in <1993Nov16.130625.1@waves.pas.ti.com>

On 1/6/22 2:03 AM, Julien ÉLIE wrote:
> Hi all,

Hi,

> Seeing how long it takes, and also how difficult it could be, for new
> users to get a working whole installation of a news server with usual
> setup, wouldn't a ready-to-use package be useful to provide in
> distributions?

I'm somewhat against this.

> I believe it is easier to de-activate the features a news admin does not
> want than having to install everything.

I'm definitely against having features enabled by default. Look at the
security posture of server products over the last three decades related
to having everything enabled by default. Or more precisely the /lack/
/of/ /security/.

> Just a thought to share.
>
> Of course the remarks of package maintainers would be greatly
> appreciated :-)

I believe that new news administrators need to learn some things about
news servers; NNTP, Usenet, etc. as part of their news administration
journey.

I feel that providing an install-able package is tantamount to script
kiddies.

I would be *MUCH* /more/ _interested_ in a good tutorial that lists the
high level description of what needs to be done and includes how to do
it with various packages. Guide people through the learning process as
they follow best practices along the way.

I believe that some minimal barrier to entry is a good thing.

I believe that a run this one command / these few commands will actually
do a disservice to the Usenet community.

--
Grant. . . .
unix || die

For your reference, records indicate that
Grant Taylor <gtaylor@tnetconsulting.net> wrote:

> I would be *MUCH* /more/ _interested_ in a good tutorial that lists the
> high level description of what needs to be done and includes how to do
> it with various packages. Guide people through the learning process as
> they follow best practices along the way.

This. Places like GitHub are littered with “agile” projects where someone
sat down and wrote some code to scratch their particular itch, and then
left it to rot for years. A good HOW-TO will likely be easier to
maintain, and even *more* important if someone has to troubleshoot any
problems with any ready-to-use installer that somebody else codes up.

--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

Le 06/01/2022 à 21:52, Grant Taylor a écrit :

> I'm definitely against having features enabled by default.

well.. my self use openSUSE, not Linux From Scratch. Same idea :-)

> I believe that new news administrators need to learn some things about
> news servers; NNTP, Usenet, etc. as part of their news administration
> journey.

it's a way to not have new admins... not anybody can spend weeks on a
simple INN server

> I would be *MUCH* /more/ _interested_ in a good tutorial that lists the
> high level description of what needs to be done and includes how to do
> it with various packages. Guide people through the learning process as
> they follow best practices along the way.
>

as previous Linux Documentation Project coordinator, I know how
difficult it is to maintain such page. I try to do it myself

http://www.dodin.org/wiki/pmwiki.php?n=Doc.ConfigurerINN-2021

but do not dare to say it's a model, far from it

It's true than *documentation* is essential but often not the real
interest of developers. So why so many man pages are awful :-(

anyway, most important server applications (apache, for example) are
bundled with decent defaults

jdd
(new dodin.fr.nf inn server for fr.*)

On 1/7/22 11:23 AM, jdanield wrote:
> well.. my self use openSUSE, not Linux From Scratch. Same idea :-)

Not quite.

There's a difference in taking the time to install and configure a
distribution vs running from a live CD.

Not to mention installing and configuring the requisite packages for the
task at hand.

> it's a way to not have new admins...

I disagree.

It's a way to not have script kiddies that have no clue what they are doing.

It's a way to have new admins that ask intelligent questions and learn
as they do things.

> not anybody can spend weeks on a simple INN server

It should not take weeks for anybody to install and configure a simple
INN server, or any server for that matter.

I would expect that it's less than a days worth of work, possibly spread
over a few days if you need to ask questions.

> It's true than *documentation* is essential but often not the real
> interest of developers. So why so many man pages are awful :-(

Who said that /developers/ needed to create the documentation?

I'm not a developer and I've contributed to many different forms of
documentation.

> anyway, most important server applications (apache, for example) are
> bundled with decent defaults

Decent defaults is one thing. What's more is that defaults are limited
to what's in scope for the package in question.

The last time I looked at installing Apache (which I still run), it did
not include PHP by default. I had to /add/ PHP. Neither of which
included an MTA to get email from a web form off the box. I had to
/add/ the MTA.

Apache's defaults don't include a turn-key / default configuration that
is ready to use name based virtual hosting for multiple sites. The
closest that distros have come is a skeleton that you add your per-site
configurations into (and possibly enable).

People need to have an idea of what they want to do and how to go about
doing that.

--
Grant. . . .
unix || die

Le 07/01/2022 à 21:06, Grant Taylor a écrit :
> On 1/7/22 11:23 AM, jdanield wrote:

>> not anybody can spend weeks on a simple INN server
>
> It should not take weeks for anybody to install and configure a simple
> INN server, or any server for that matter.

it is; I began on dec 13 and the config is yet bullet proof

you begin to read a doc that ask you to read an other and so on...

I'm used to RTFM but this was pretty hard

> Who said that /developers/ needed to create the documentation?
>
> I'm not a developer and I've contributed to many different forms of
> documentation.

as a LDP man, I know what it is and that it's often much more difficult
to have people write doc than code - I'm not a developer myself, but a
teacher/doc maker.

> The last time I looked at installing Apache (which I still run), it did
> not include PHP by default.

neither anybody ask inn to include perl or python...

apart if one want to make a docker or similar app, but this is probably
an other nest of worms :-(

I had to /add/ PHP.

in openSUSE one have just to tick php in yast (or mod_php for Apache.
Nothing more

Neither of which
> included an MTA to get email from a web form off the box. I had to
> /add/ the MTA.

postfix works from the beginning in openSUSE, I think it's even
installed by default for admin communication

> Apache's defaults don't include a turn-key / default configuration that
> is ready to use name based virtual hosting for multiple sites.

sure but there is *one* example file to copy and edit. remember me how
many config files are in INN, even simply to get a peer?

> People need to have an idea of what they want to do and how to go about
> doing that.

driving a car is more dangerous than installing an usenet server and us
license is pretty easy to have :-)

most every newbie can have a phpbb forum, but not a nntp one, why?

who did KISS?

jdd

Le 07/01/2022 à 22:02, jdanield a écrit :

> it is; I began on dec 13 and the config is yet bullet proof

is *not* yet bullet proof, of course. Sorry, tired :-(

jdd

Bonsoir Jean-Daniel,

> sure but there is *one* example file to copy and edit. remember me how
> many config files are in INN, even simply to get a peer?

In fact, only two are really needed:
- incoming.conf to configure which incoming connections should be
considered as peers (and not readers) and therefore allowed to feed you
articles;
- newsfeeds to configure the list of newsgroups you send to each peer,
and you call "innfeed -y".

The default newsfeeds sample file mentions it:

## Add "-y" as an option to innfeed to use the name of each feed as the
## name of the host to feed articles to; without "-y" an innfeed.conf
## file is needed.

# innfeed funnel master.
#innfeed!\
# :!*\
# :Tc,Wnm*:@bindir@/innfeed

If the news admin wants to complicate his life, it's up to him :-)

--
Julien ÉLIE

« Boire du café empêche de dormir. Par contre, dormir empêche de boire
du café. » (Philippe Geluck)

On 1/7/22 2:02 PM, jdanield wrote:
> it is; I began on dec 13 and the config is yet bullet proof

There is a BIG difference between working and bullet proof.

I maintain that it should not take weeks to get to working.

It can take years to get to bullet proof. Even then, bullets change and
you are no longer bullet proof.

> you begin to read a doc that ask you to read an other and so on...
>
> I'm used to RTFM but this was pretty hard

What was hard?

I suspect the act of reading the manual wasn't hard.

There may have been concepts that were foreign or didn't make sense. If
that's the case, please ask for clarification.

I firmly believe in teaching people how to fish for themselves. If you
have questions, I want to provide answers if I can. If I can't provide
answers, I will try to point you someone / somewhere that you can find them.

> neither anybody ask inn to include perl or python...

I'm fairly sure that INN itself doesn't /require/ Perl, much less
Python. Though many admins /want/ one or both for various reasons.

> apart if one want to make a docker or similar app, but this is probably
> an other nest of worms :-(

Indeed.

>   I had to /add/ PHP.

;-)

> in openSUSE one have just to tick php in yast (or mod_php for Apache.
> Nothing more

The point being that you had to do something in addition to the system
default.

> postfix works from the beginning  in openSUSE, I think it's even
> installed by default for admin communication

As a 20+ year postmaster I have some questions about how it's
configured. But that's another topic for another day.

> sure but there is *one* example file to copy and edit. remember me how
> many config files are in INN, even simply to get a peer?

That's not quite a fair comparison. INN inherently uses multiple files.
So comparing it to something that uses fewer / one file is a
non-starter to me.

> driving a car is more dangerous than installing an usenet server and us
> license is pretty easy to have :-)

It depends what you consider to be dangerous; the ability to hurt / kill
people or damage / destroy property vs ability to be a source of spam /
attacks / other undesirable traffic....

> most every newbie can have a phpbb forum, but not a nntp one, why?

I never implied, much less said, that anyone couldn't have something. I
did say that they should learn about it as they are setting it up.

> who did KISS?

Microsoft did when they tried to make it (too) simple for the admin when
they installed everything and the kitchen sink as part of Back Office in
the '90s.

I maintain that educating people so they can intelligently choose what
components they want and making it fairly easy for them to install and
configure them is the way to go.

--
Grant. . . .
unix || die

On 2022-01-07, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> I disagree.
>
> It's a way to not have script kiddies that have no clue what they are doing.

Wait, script kiddies still want to setup news servers? Maybe your imagination
is just a bit more active than mine :)

> The last time I looked at installing Apache (which I still run), it did
> not include PHP by default. I had to /add/ PHP. Neither of which
> included an MTA to get email from a web form off the box. I had to
> /add/ the MTA.

Nobody runs their own webservers or their own MTAs anymore. These days on the
mail side, projects like Mail-in-a-box are become increasingly popular.
There's tons of projects online like shared hosting that are utilized because
running your own webserver is hard.

> People need to have an idea of what they want to do and how to go about
> doing that.

All 10 of the people that still use Usenet *do* know what they're doing :)

In all seriousness, I'm new to Usenet (and not young by any means). I'm a
professional software developer and spend *a lot* of time working with
networking in my day job. I don't think INN's configuration is
particularly easy to work through. Disambiguating a few things had me
open up `socat` and log NNTP traffic to see what was happening. I also
spent time reading through the RFCs. This is a lot of effort to read
what amounts to at most 20 unique messages in a day. It's fun for me
because I poke at networks and servers all the time.

I'm all for simplifying the configuration for INN, whether it's in a
default install or whether it's through a special package or docker
container or something. I think there's a lot of interest these days
among nerds (and non-nerds!) in distributed free protocols like Usenet
and easing the configuration process would go a long way to improving
usability. My $0.02 as a noob to Usenet.

On 1/7/22 9:33 PM, meff wrote:
> Nobody runs their own webservers or their own MTAs anymore.

I do.

I thought of three other people who do in less than 30 seconds.

I'm sure that I could think of more if I tried.

> These days on the mail side, projects like Mail-in-a-box are become
> increasingly popular. There's tons of projects online like shared
> hosting that are utilized because running your own webserver is hard.

IMHO running your own /web/ server is fairly easy. Presuming you can
get a globally routed IP.

IMHO running your own mail server is relatively easy. Running your own
mail server /well/ takes work. Running your own mail server with
contemporary standards and keeping up with the big players, that takes a
lot of work and approaches hard. But it's certainly possible to do so.
I've helped multiple people achieve the well category and well on their
way to contemporary standards.

IMHO running your own news server is somewhere between web and email
level of difficulty.

> All 10 of the people that still use Usenet *do* know what they're
> doing :)

I see at least two orders of magnitudes different posters (not counting
Google Groups) that participate in Usenet.

> In all seriousness, I'm new to Usenet (and not young by any means). I'm
> a professional software developer and spend *a lot* of time working
> with networking in my day job. I don't think INN's configuration is
> particularly easy to work through.

I wouldn't say that INN is /easy/. But I wouldn't say that INN was hard
either. Especially if you have someone that is willing to answer
questions and help you find your way. A tutor / mentor if you will.

> Disambiguating a few things had me open up `socat` and log NNTP
> traffic to see what was happening.

I tip my hat to you. Many would have given up long before that.

I think that people should not /need/ to use `socat` or a network
sniffer to set up a news server. But knowing how and actually doing
that is a bonus.

> I also spent time reading through the RFCs.

I consider reading (or at least skimming) RFCs to be a standard part of
anybody that is in computers, particularly (non-proprietary) server
services.

Again, this should not be /needed/ to run INN.

> This is a lot of effort to read what amounts to at most 20 unique
> messages in a day. It's fun for me because I poke at networks and
> servers all the time.

Between mailing lists and Usenet, I see anywhere between 100 and 500
messages a day. Many are skimmed or ignored as they are part of a
thread that I'm not interested in. I routinely interact with 50-150
messages a day.

> I'm all for simplifying the configuration for INN, whether it's in a
> default install or whether it's through a special package or docker
> container or something. I think there's a lot of interest these days
> among nerds (and non-nerds!) in distributed free protocols like Usenet
> and easing the configuration process would go a long way to improving
> usability. My $0.02 as a noob to Usenet.

Hum.... You cause me to ponder things. I'll start a new thread as I
think this is a good forking point.

--
Grant. . . .
unix || die

Le 07/01/2022 à 22:33, Julien ÉLIE a écrit :

> In fact, only two are really needed:
> - incoming.conf to configure which incoming connections should be
> considered as peers (and not readers) and therefore allowed to feed you
> articles;
> - newsfeeds to configure the list of newsgroups you send to each peer,
> and you call "innfeed -y".

where add the "-y"? or run this only once?

> ## Add "-y" as an option to innfeed to use the name of each feed as the
> ## name of the host to feed articles to; without "-y" an innfeed.conf
> ## file is needed.
>
> # innfeed funnel master.
> #innfeed!\
> # :!*\
> # :Tc,Wnm*:@bindir@/innfeed
>
>
>
>
> If the news admin wants to complicate his life, it's up to him :-)
>

example:

https://news.aioe.org/documentation/how-to-setup-a-feed-with-aioeorg/

how may one know who to trust?

thanks
jdd

Le 07/01/2022 à 23:18, Grant Taylor a écrit :
> On 1/7/22 2:02 PM, jdanield wrote:

> What was hard?
>
> I suspect the act of reading the manual wasn't hard.

INN manual is pretty long (I read it several times), it ask to read many
man page (around one for each of the files in ~news), the faq... and the
language used is full of words with special meaning that need to be checked.

It also contain instructions how to compile INN from source I don't need

this is sort of recursive task. After some calls, I have a too short
return stack :-(

> I firmly believe in teaching people how to fish for themselves.

sure, but if this involve learning to make a fish pole, a nylon thread,
a hook, most fisher will never get a fish

If you
> have questions, I want to provide answers if I can.

I'm sure you would. In fact I had to do, but being french I did it on a
french group :-). Thanks

> I'm fairly sure that INN itself doesn't /require/ Perl, much less
> Python. Though many admins /want/ one or both for various reasons.

Cleanfeed or pyfeed do and they are nearly mandatory if you want a peer

> The point being that you had to do something in addition to the system
> default.

I beg there may be a language problem here. I'm sure Juline never wes
thinking of including perl or python with INN (but this could be a
require in the rpm/deb)

>
>> postfix works from the beginning  in openSUSE, I think it's even
>> installed by default for admin communication
>
> As a 20+ year postmaster I have some questions about how it's
> configured. But that's another topic for another day.

sure - just an example.

I use to document all my work

http://www.dodin.org/wiki/pmwiki.php?n=Doc.Server-2021

but being only me, this doc is full of errors, lack of content...

As already said I was some years ago the tldp coordinator (my page)

https://wiki.tldp.org/jdd

and author of some howto's. But maintaining the LDP failed mainly
because nowadays everybody have his own forum (as phpbb). The *excess*
of documentation is not INN only, it's common. Some time ago Linux
documentation was not enough, now there is too much (unreliable) one.

But this is the world in which we live, we have to cope with it.

Julien is a very good fellow and do his max to help, often with success.
I'm sure he do the better to help.

>
>> sure but there is *one* example file to copy and edit. remember me how
>> many config files are in INN, even simply to get a peer?
>
> That's not quite a fair comparison. INN inherently uses multiple files.
> So comparing it to something that uses fewer / one file is a
> non-starter to me.

why should it? others don't. many apps have an unique local.conf that
hold all what is usually necessary to change.

May be it could be a workaround for the ready to use: have some config
files, sourced by the usual scripts, with example for every usage. I
mean a peering.conf.example file, a standalone.conf.example file...

just a guess, no idea if applicable

> I maintain that educating people so they can intelligently choose what
> components they want and making it fairly easy for them to install and
> configure them is the way to go.
>

sure, good doc is very desirable, but IMHO anything making things easier
also.

thanks
jdd

On 2022-01-08, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 1/7/22 9:33 PM, meff wrote:
>> Nobody runs their own webservers or their own MTAs anymore.
>
> I do.
>
> I thought of three other people who do in less than 30 seconds.

I just wanted to mention that a lot of my exact numbers ("10 people")
were chosen out of hyperbole. I agree with you that there are folks
running their MTAs successfully (and running news servers, though I'm
not an authority here so I won't make much of a claim to this.) Thanks
for engaging in good faith and not getting hung up on my
silly cheekiness.

> Hum.... You cause me to ponder things. I'll start a new thread as I
> think this is a good forking point.

Thanks. I'll respond as I can tomorrow as it's getting a bit late for
me. I'm looking forward to reading the responses as well.

On Fri, 7 Jan 2022 15:18:06 -0700,
Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 1/7/22 2:02 PM, jdanield wrote:
> > it is; I began on dec 13 and the config is [not] yet bullet
> > proof

> > I'm used to RTFM but this was pretty hard

> There may have been concepts that were foreign or didn't make
> sense. If that's the case, please ask for clarification.
>
> I firmly believe in teaching people how to fish for themselves.
> If you have questions, I want to provide answers if I can. If
> I can't provide answers, I will try to point you someone /
> somewhere that you can find them.

I've seen you (Grant) do just that in a number of settings over
quite a number of years and have always respected and appreciated
seeing your patient and clear help. Thanks for your numerous
contributions!

I've been a Linux hobbyist for over 20 years. For the first ~15
of them, I ran my own server. I came to it with a very good
understanding of DOS, a smattering of Pascal coding experience,
and a small bit of experience from CLI accounts in UNIX and DEC.
So not a complete newb, but with nearly no knowledge of setting up
distributions.

I played in Red Hat for a few months, and ended up with Slackware
(maybe v 9 or so). Setting up my own server was moderately hard,
in that it took a lot of reading and study. Some of it was very
hard for me to get a grasp of (e.g., dealing with errors when
trying to make executables from packages, configuring sendmail) in
part because the approaches seemed to be so different from thing
to thing. But I persevered. The Nemeth books were fantastically
helpful (and fun to read, too).

Eventually I could build my own kernel, set up my own news spool
(leafnode), and have my own mail agents (sendmail). The work of
configuring applictions was sporadic enough that I generally had
to refer back to various instructions when it needed doing, but by
then I never considered it "hard" per se. I enjoyed setting up
things like ntp, as well as fine tuning the logging (and rotation)
and all the devices on my home LAN. Plus setting up my own
domain. I eventually gave it up because work became very heavy
plus keeping the system updated and properly patched became more
of a chore than a pleasure.

Today I keep a couple of shell accounts so I can continue the UNIX
(or BSD) experience. When I retire in a year or two, I may go
back to my own server (if I find myself looking for something to
do).

I share all that to give you a sense of my perspective. I'd agree
with what Grant said about www service being relatively easy to
set up (depending on complexity, the content can be hard) and with
a robust mail server being hard. I've not actually ever set up
INN, but based on the reading I've done and my sense of the
overall landscape it doesn't seem likely to be overly hard. A lot
of it is just patience with the docs, repeated goes at it, and
asking for help when stuck.

Not sure if any of that's helpful, but there you have it.

--
Ted Heise <theise@panix.com> West Lafayette, IN, USA

jdanield <jdd@dodin.org> writes:

> INN manual is pretty long (I read it several times), it ask to read many
> man page (around one for each of the files in ~news), the faq... and the
> language used is full of words with special meaning that need to be
> checked.

One of the difficulties with INN is that it has evolved over the years
into being more of a Usenet-related toolkit than a program that does one
thing. There are about four ways to do just about anything that you want
to do in INN, from outgoing feeds to overview data structures to
approaches for newsgroup list management.

In a lot of ways this is a feature, and much of that feature space is
actively used by someone, but there is probably a lot of room for defining
a "happy path" approach that will work well for most people and that is
opinionated about all the decisions you need to make along the way. That
could be done entirely through documentation, but there are probably code
and packaging approaches that could make it easier.

Reading all the INN manual pages is a bit much, and will lead you off into
rabbit holes that you almost certainly do not need to care about, like
UUCP support, XBATCH, or tinyleaf.

--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Please post questions rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.

On 1/8/22 1:41 AM, meff wrote:
> Thanks for engaging in good faith and not getting hung up on my
> silly cheekiness.

You're welcome.

Thank you for what I consider to be constructive conversation.

> Thanks. I'll respond as I can tomorrow as it's getting a bit late
> for me. I'm looking forward to reading the responses as well.

I see 15 or more replies to my new thread. The few that I skimmed when
I realized I didn't have time to give them the attention they deserved
looked to be constructive and positive.

--
Grant. . . .
unix || die

On 1/8/22 1:28 AM, jdanield wrote:
> INN manual is pretty long (I read it several times), it ask to read many
> man page (around one for each of the files in ~news), the faq... and the
> language used is full of words with special meaning that need to be
> checked.

Agreed.

I wonder how much of the learning INN could be attributed to learning
Usenet as a user, learning Usenet as a news master, and learning various
software packages all lumped together in one snowball. Wherein it's
difficult to make any decisions because there is more to learn that
effect those decisions.

> It also contain instructions how to compile INN from source I don't need

Fair enough.

That seems to be a /documentation/ issue for INN.

> this is sort of recursive task. After some calls, I have a too short
> return stack  :-(

Agreed.

> sure, but if this involve learning to make a fish pole, a nylon thread,
> a hook, most fisher will never get a fish

I sort of agree. Though I think it should be possible to say:

1) Buy a pole, some string, a hook, and some bait.
2) Tie one end of the string on the hook.
3) Tie the other end of the string on the pole.
4) Go to where there are known to be fish.
5) Put some bait on the hook.
6) Put the baited hook in the water.
7) Wait ...

> I'm sure you would. In fact I had to do, but being french I did it on a
> french group :-). Thanks

:-)

> Cleanfeed or pyfeed do and they are nearly mandatory if you want a peer

/nearly/ is the operative word. I would be willing to peer with a new
news master without cleanfeed or pyfeed in order to help get them started.

I would ask that they /eventually/ install something like them.

I would also keep an eye on things and respond to complaints.

> I beg there may be a language problem here. I'm sure Juline never wes
> thinking of including perl or python with INN (but this could be a
> require in the rpm/deb)

I don't know what the language barrier would be. If you see something,
please shine a light on it.

I admit that distribution defaults / assumptions add complication on top
of base INN (et al.) software.

> sure - just an example.
>
> I use to document all my work
>
> http://www.dodin.org/wiki/pmwiki.php?n=Doc.Server-2021
>
> but being only me, this doc is full of errors, lack of content...
>
> As already said I was some years ago the tldp coordinator (my page)
>
> https://wiki.tldp.org/jdd

I'll check those out.

> and author of some howto's. But maintaining the LDP failed mainly
> because nowadays everybody have his own forum (as phpbb). The *excess*
> of documentation is not INN only, it's common. Some time ago Linux
> documentation was not enough, now there is too much (unreliable) one.

I get what you're saying.

Sadly too many of the various posts are "do this" without any "why" to
them. There's also a heavy hint of "my way is the best" / "others do it
wrong".

> But this is the world in which we live, we have to cope with it.

Ya.

> Julien is a very good fellow and do his max to help, often with success.
> I'm sure he do the better to help.

Yep.

> why should it? others don't. many apps have an unique local.conf that
> hold all what is usually necessary to change.

If you're focusing on documentation / guidance on how to do something,
the number of files and which file to do it in doesn't matter much.
Especially if there is clear documentation that states "this thing is
configured in this file" and "that thing is configured in that file" and
finally "other thing is configured in other file".

In some, if not many, ways, having the different files simplifies
things. Take a look at PAM in how you can have different sub-systems
use it's own config file vs a more complex configuration line mixed in
with a bunch of other unrelated configuration lines.

> May be it could be a workaround for the ready to use: have some config
> files, sourced by the usual scripts, with example for every usage. I
> mean a peering.conf.example file, a standalone.conf.example file...

I thought that the man pages for the various configuration files
included examples. Admittedly they may be divided up in different parts
of the config file.

One thing that came to mind is something akin to what I remember for
xfree86 configuration. An interactive utility that asks you some
questions and builds suggested configuration files based on answers to
your questions.

> just a guess, no idea if applicable

I think that it's worth discussing.

> sure, good doc is very desirable, but IMHO anything making things easier
> also.

I feel like 18 different people saying here's a Docker container,
install it and turn it on, when each and every single one of them do
slightly different things and only 2 are close to what any given person
wants.

The following comes to mind.

Link - xkcd: Standards
- https://xkcd.com/927/

--
Grant. . . .
unix || die

According to Grant Taylor <gtaylor@tnetconsulting.net>:
>I wouldn't say that INN is /easy/. But I wouldn't say that INN was hard
>either. Especially if you have someone that is willing to answer
>questions and help you find your way. A tutor / mentor if you will.

I've found that the problem is that, perhaps counterintuitively, the
instructions say too much. There are lots of options that in practice
don't matter any more, or are unlikely to do so. It'd be a lot easier
if it said to use this news spool, that overview, and those ways to
set up nntp connections and stick everything else in the equivalent
of an historical appendix.

R's,
John
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 1/8/22 7:59 AM, Ted Heise wrote:
> I've seen you (Grant) do just that in a number of settings over quite
> a number of years and have always respected and appreciated seeing
> your patient and clear help. Thanks for your numerous contributions!

Thank you Ted.

My only response is to humbly say "you are welcome".

> I've been a Linux hobbyist for over 20 years. For the first ~15 of
> them, I ran my own server. I came to it with a very good understanding
> of DOS, a smattering of Pascal coding experience, and a small bit of
> experience from CLI accounts in UNIX and DEC. So not a complete newb,
> but with nearly no knowledge of setting up distributions.

I suspect that 20 years ago Linux distributions as a group were fairly
young and immature searching to find themselves. There were a LOT of
things in flux. Some things shined. Some other things flopped.

> I played in Red Hat for a few months, and ended up with Slackware
> (maybe v 9 or so). Setting up my own server was moderately hard,
> in that it took a lot of reading and study. Some of it was very
> hard for me to get a grasp of (e.g., dealing with errors when trying
> to make executables from packages, configuring sendmail) in part
> because the approaches seemed to be so different from thing to thing.

Ya. Consistency between large packages is definitely wasn't a thing
then. I'll argue that it's still not a thing now.

> But I persevered.

Nicely done!

> The Nemeth books were fantastically helpful (and fun to read, too).

Would you pleas share more than just the author's name? I've become
somewhat of a Unix / Linux / Networking bibliophile and would like to
check them out.

> Eventually I could build my own kernel, set up my own news spool
> (leafnode), and have my own mail agents (sendmail). The work of
> configuring applictions was sporadic enough that I generally had to
> refer back to various instructions when it needed doing, but by then I
> never considered it "hard" per se.

I still reference notes for myself / refer back to (backups of) existing
configuration files / documentation when I set up new systems.

One big difference now vs when I was starting is that I understand what
various concepts are and what I want them to do. As such, it becomes
more of a reference for syntax or proper configuration option as opposed
to learning what a given path is, what alternative configuration paths
are, and why I might pick the former over the latter.

> I enjoyed setting up things like ntp, as well as fine tuning
> the logging (and rotation) and all the devices on my home LAN.
> Plus setting up my own domain. I eventually gave it up because work
> became very heavy plus keeping the system updated and properly patched
> became more of a chore than a pleasure.

I understand and respect that.

> Today I keep a couple of shell accounts so I can continue the UNIX
> (or BSD) experience. When I retire in a year or two, I may go back
> to my own server (if I find myself looking for something to do).

Feel free to reach out if there is anything I can do to help.

> I share all that to give you a sense of my perspective. I'd agree
> with what Grant said about www service being relatively easy to set up
> (depending on complexity, the content can be hard) and with a robust
> mail server being hard. I've not actually ever set up INN, but based
> on the reading I've done and my sense of the overall landscape it
> doesn't seem likely to be overly hard. A lot of it is just patience
> with the docs, repeated goes at it, and asking for help when stuck.

I think that's a very apt description.

> Not sure if any of that's helpful, but there you have it.

I think it is a well articulated opinion. I also like the fact that it
agrees with me. :-D But agreement aside, it is still well articulated.

--
Grant. . . .
unix || die

On 1/8/22 4:34 PM, John Levine wrote:
> I've found that the problem is that, perhaps counterintuitively,
> the instructions say too much. There are lots of options that in
> practice don't matter any more, or are unlikely to do so. It'd be
> a lot easier if it said to use this news spool, that overview, and
> those ways to set up nntp connections and stick everything else in
> the equivalent of an historical appendix.

I can agree with and support this concept.

As for configuration files, I wonder how many different files people
need to change and how significant those changes are.

I suspect for (unencrypted) NNTP connections, there are a small number
of files that need to be modified at server installation & turn up time,
and then a small number of files that need to be modified when adding /
changing / removing a peer.

--
Grant. . . .
unix || die

On Sat, 8 Jan 2022 16:35:28 -0700,
Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 1/8/22 7:59 AM, Ted Heise wrote:

[regarding setup of servers]

> > The Nemeth books were fantastically helpful (and fun to read,
> > too).
>
> Would you pleas share more than just the author's name? I've
> become somewhat of a Unix / Linux / Networking bibliophile and
> would like to check them out.

Absolutely. There have been a number of editions and flavors over
the years. In general they remind me of The Joy of Cooking: lots
of great explanation of how things work *in general* combined with
high quality specific recipes for how one might implement each
type of program in various settings.

The common theme across all books is that each uses several actual
UNIX (or UNIX-like) systems as the basis for the overviews and
recipes. Those book versions that served me best reflect in large
part systems that were in relatively common use at the time.

The one I started with was...

Unix System Administration Handbook, Third Edition (2001)
by Evi Nemeth, Garth Snyder, Scott Seebass, and Trent R. Hein

ISBN-13: 978-0130206015
ISBN-10: 0130206016

https://www.amazon.com/UNIX-System-Administration-Handbook-3rd/dp/0130206016/ref=pd_lpo_2?pd_rd_i=0130206016&psc=1

It describes admin work for these systems:

Solaris 2.7
HP-UX 11.00
Red Hat Linux 6.2
FreeBSD 3.4

The (only slightly) more recent book I used was...

Linux Administration Handbook, 1st Edition (2002)
by Evi Nemeth, Garth Snyder, Trent R. Hein

ISBN-13: 978-0536107527
ISBN-10: 0536107521

https://www.amazon.com/Linux-Administration-Handbook-Evi-Nemeth/dp/0130084662

It describes admin work for these systems:

Red Hat Linux 7.2
SuSE Linux 7.3
Debian GNU/Linux 3.0

Although I ended up going with Slackware (after a short time
dabbling in Red Hat), the books were still supremely helpful.
The overviews of principles and processes generally applied across
most other systems/distributions and at the very least helped me
understand what I needed to be looking for and trying to
accomplish in the system I was using.

On top of that, they were fun to read. The authors somehow kept
the material interesting, in part due to a lighthearted (and oft
amusing) writing style. I get the feeling a lot of that was Evi
Nemeth's personality coming through. I never knew her, but she
was eventualy lost at sea when out on an extended sailing trip.
Sounds like she was quite an interesting character.

Even though these books are quite dated, I have to think they
would be useful to anyone just starting out now.

> > Eventually I could build my own kernel, set up my own news
> > spool (leafnode), and have my own mail agents (sendmail).
> > The work of configuring applictions was sporadic enough that I
> > generally had to refer back to various instructions when it
> > needed doing, but by then I never considered it "hard" per se.
>
> I still reference notes for myself / refer back to (backups of)
> existing configuration files / documentation when I set up new
> systems.
>
> One big difference now vs when I was starting is that I
> understand what various concepts are and what I want them to
> do. As such, it becomes more of a reference for syntax or
> proper configuration option as opposed to learning what a given
> path is, what alternative configuration paths are, and why I
> might pick the former over the latter.

Absolutely agree. The UNIX handbook was by far my most marked up
version, in part because I used it first. I bought the Linux
handbook the next year, in part because I thought it might be more
helpful (it wasn't to a first approximation) and in part because I
just have a great love of books. Both are crammed full of short
printouts of various config files (all heavily annotated).

I also kept a notebook of things I had done. I didn't admin on
enough of a regular basis to just know what to do most time when
upkeep was in order, but the notes and logs were tremendously
helpful in (re)finding my way.

> > Today I keep a couple of shell accounts so I can continue the
> > UNIX (or BSD) experience. When I retire in a year or two, I
> > may go back to my own server (if I find myself looking for
> > something to do).
>
> Feel free to reach out if there is anything I can do to help.

Oh that's awfully kind of you. I will keep it in mind!

> > Not sure if any of that's helpful, but there you have it.
>
> I think it is a well articulated opinion. I also like the fact
> that it agrees with me. :-D But agreement aside, it is still
> well articulated.

LOL on the "like it because it agrees with me," but thanks for the
kind words.

I'll just add in a couple of other comments here...

I found Russ's post on identification and authentication in
enterprise systems (Message-ID: <874k6ekmrv.fsf@hope.eyrie.org>)
to be incredibly interesting and relatively informative. It is
entirely consistent with what I've been seeing happen at my
employer (a larger multi-national medical device company), and
gives me a nice sense of what's happening under the hood.

From another post in the other thread, I completely agree with
your preference for text over video for tutorials. Unless there
are techniques that rely on physical manipulation, I much prefer
text to video.

Finally, I still hang around on Usenet because I've run into some
of the most interesting people in the world here. Most are pretty
articulate, and usually share common interests. One of the
strengths of Usenet: great narrowing of topics to help draw in
those with common interests. I've always had keen interest in how
things work, and also a great love of computers and systems.

It's similar to my sustained interest in the HP 200LX (my travel
computer in the late 90s/early 2000s). Though I now longer use
(or even have) it, I still hang out on the listserv because of so
many likeminded folks (and friends).

Sorry this got so long.

--
Ted Heise <theise@panix.com> West Lafayette, IN, USA

On 1/9/22 7:33 AM, Ted Heise wrote:
> Absolutely.

Thank you. :-)

> There have been a number of editions and flavors over the years.

Ya. I'm finding that. I've got a physical copy of Practical Unix &
Internet Security, 3rd edition, which I'm reading and finding some
various comments like "we enumerated some of these in the 1st edition
and even more in the 2nd edition, but we are not doing so in the 3rd
edition as the number exploded exponentially, see the 1st and / or 2nd
edition". So I have electronic copies if the 1st & 2nd editions.
Thankfully The Unix CD Bookshelf includes electronic copies thereof and
I have original CDs from O'Reilly for all three versions of The Unix CD
Bookshelf. :-D

Aside: I'm collecting O'Reilly CD Bookshelf books w/ CDs if you have
any that you want to sell.

> In general they remind me of The Joy of Cooking: lots of great
> explanation of how things work *in general* combined with high quality
> specific recipes for how one might implement each type of program in
> various settings.

Nice.

I like that the PUIS3 book includes little comments about terminology /
nomenclature, e.g. "router"s used to be called "gateway"s. Hence a
"default gateway" should not be called "default router".

> The common theme across all books is that each uses several actual UNIX
> (or UNIX-like) systems as the basis for the overviews and recipes.

I consider that to be mostly a good thing, but can have some down sides.
Mostly the down side is for new people who don't have enough
foundation to separate the different platforms. Once you are
comfortable doing that, the wide view turns into a good thing.

> Those book versions that served me best reflect in large part systems
> that were in relatively common use at the time.

I think that's normal.

> The one I started with was...
>
> Unix System Administration Handbook, Third Edition (2001)
> by Evi Nemeth, Garth Snyder, Scott Seebass, and Trent R. Hein
>
> ISBN-13: 978-0130206015
> ISBN-10: 0130206016

I don't (knowingly) own a copy of it. I'll check it out.

As in it's not in my database. So either I've not entered it, or I
don't own it. I suspect the latter is more likely.

> It describes admin work for these systems:
>
> Solaris 2.7
> HP-UX 11.00
> Red Hat Linux 6.2
> FreeBSD 3.4

Solaris 2.7, that's older than anything I've worked on. Likewise for
the others. But that's to be expected.

> The (only slightly) more recent book I used was...
>
> Linux Administration Handbook, 1st Edition (2002)
> by Evi Nemeth, Garth Snyder, Trent R. Hein
>
> ISBN-13: 978-0536107527
> ISBN-10: 0536107521

I don't have the 1st edition, but I do have the 2nd edition of the Linux
Network Administrator's Guide. I believe there are electronic
counterparts on The Linux Documentation Project's web site.

> It describes admin work for these systems:
>
> Red Hat Linux 7.2
> SuSE Linux 7.3
> Debian GNU/Linux 3.0
>
> Although I ended up going with Slackware (after a short time dabbling
> in Red Hat), the books were still supremely helpful. The overviews
> of principles and processes generally applied across most other
> systems/distributions and at the very least helped me understand what
> I needed to be looking for and trying to accomplish in the system I
> was using.

Yep.

I've found that once you have enough of a foundation knowledge, you can
start to differentiate the things that are OS / distribution specific
and extract more agnostic things and apply them across distributions
(other Linuxes) if not OSs (other Unixes).

> On top of that, they were fun to read. The authors somehow kept the
> material interesting, in part due to a lighthearted (and oft amusing)
> writing style. I get the feeling a lot of that was Evi Nemeth's
> personality coming through. I never knew her, but she was eventualy
> lost at sea when out on an extended sailing trip. Sounds like she
> was quite an interesting character.

:-)

> Even though these books are quite dated, I have to think they would
> be useful to anyone just starting out now.

I've read many of the Slackware Series from MIS ~> M&T and found the
foundational material to still apply. Though it's quite obvious that
the material is from more than two decades ago. This is mostly evident
in things the book references as new up and coming hotness is now old
hand and possibly being outmoded itself.

But the historic reference helps provide context for newer / current things.

> Absolutely agree. The UNIX handbook was by far my most marked up
> version, in part because I used it first. I bought the Linux handbook
> the next year, in part because I thought it might be more helpful
> (it wasn't to a first approximation) and in part because I just have
> a great love of books. Both are crammed full of short printouts of
> various config files (all heavily annotated).

ACK

I personally dislike marking in books. But to each their own.

My (current) solution is to send myself an email which usually contains
the following sections:

- Notes - general things to remember.
- Follow Up - things I want to circle back to and research more.
- Glossary - terms that I want to add to my ever growing database.
- Books - cited books / papers / articles that I want to find and read.

I usually have something like the following as bullet points under each
section:

- handle to identify the <thing> in qustion
- short statement about why this is listed
- page number (in context of the email for the book / chapter)

For example, the following is a follow up from PUIS3 - Chapter 10:

Follow Up:
• “The RS-232 standard was developed to allow individuals to use
remote computer systems over dialup telephone lines with remote
terminals.” (Page 243) - substantiate this

So I end up with electronic notes that I can easily search and I avoid
marking up books.

> I also kept a notebook of things I had done.

I've been keeping text (<bla>.notes) files for a few years now. I've
recently started keeping a more typical journal in electronic form.
Thus searching is trivial.

> I didn't admin on enough of a regular basis to just know what to
> do most time when upkeep was in order, but the notes and logs were
> tremendously helpful in (re)finding my way.

I absolutely agree.

I've also found that such -- what I call -- crib notes can often times
easily be the start of actual documentation. This usually evolves as:

1) Save output of command history for <bla>. Often edited to omit
superfluous commands like ls and pwd.
2) Add comments various places to serve as a reminder / description of
what's being done.
3) Iterate on #1 & #2 a few times while reproducing ~> refining the
overall task.
4) Clean up some comments and make them more generic (less mental notes
and more meaningful to others) in preparation for sharing with friends &
colleagues who know how to read my chicken scratches.
5) Clean up #4 with the intention to turn into a blog article for
sharing to a larger audience.

> Oh that's awfully kind of you. I will keep it in mind!

:-)

I've had two primary email addresses over the last 20 years. I
purposefully do not obfuscate (beyond (at) / (dot)) so that people can
reach out to me and ask questions or offer corrections.

I've been exchanging email with someone for the better part of three
years after they reached out to me to ask about Sendmail after seeing a
comment like the one above years ago.

> LOL on the "like it because it agrees with me,"

;-)

> but thanks for the kind words.

You're welcome.

> I'll just add in a couple of other comments here...
>
> I found Russ's post on identification and authentication in enterprise
> systems (Message-ID: <874k6ekmrv.fsf@hope.eyrie.org>) to be incredibly
> interesting and relatively informative. It is entirely consistent with
> what I've been seeing happen at my employer (a larger multi-national
> medical device company), and gives me a nice sense of what's happening
> under the hood.

Yep.

Authentication and authorization are complex topics. Russ is distilling
it down quite well.

> From another post in the other thread, I completely agree with your
> preference for text over video for tutorials. Unless there are
> techniques that rely on physical manipulation, I much prefer text
> to video.

I *REALLY* appreciate that text is searchable.

> Finally, I still hang around on Usenet because I've run into some
> of the most interesting people in the world here. Most are pretty
> articulate, and usually share common interests. One of the strengths
> of Usenet: great narrowing of topics to help draw in those with
> common interests. I've always had keen interest in how things work,
> and also a great love of computers and systems.