The example is for INN but other news servers of course could have a
similar packaging.
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?
[...]
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?
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 :-)
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'm definitely against having features enabled by default.
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 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.
well.. my self use openSUSE, not Linux From Scratch. Same idea :-)
it's a way to not have new admins...
not anybody can spend weeks on a simple INN server
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
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.
Who said that /developers/ needed to create the documentation?
I'm not a developer and I've contributed to many different forms of documentation.
The last time I looked at installing Apache (which I still run), it did
not include PHP by default.
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.
People need to have an idea of what they want to do and how to go about
doing that.
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?
it is; I began on dec 13 and the config is yet bullet proof
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
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
postfix works from the beginning in openSUSE, I think it's even
installed by default for admin communication
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?
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?
I disagree.
It's a way to not have script kiddies that have no clue what they are doing.
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.
People need to have an idea of what they want to do and how to go about
doing that.
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.
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.
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".
## 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 :-)
On 1/7/22 2:02 PM, jdanield wrote:
What was hard?
I suspect the act of reading the manual wasn't hard.
I firmly believe in teaching people how to fish for themselves.
have questions, I want to provide answers if I can.
I'm fairly sure that INN itself doesn't /require/ Perl, much less
Python. Though many admins /want/ one or both for various reasons.
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.
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.
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.
Hum.... You cause me to ponder things. I'll start a new thread as I
think this is a good forking point.
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.
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.
Thanks for engaging in good faith and not getting hung up on my
silly cheekiness.
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 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.
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.
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 :-(
sure, but if this involve learning to make a fish pole, a nylon thread,
a hook, most fisher will never get a fish
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
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)
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.
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
sure, good doc is very desirable, but IMHO anything making things easier also.
On 1/8/22 7:59 AM, Ted Heise wrote:
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.
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.
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.
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
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
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.
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.
Oh that's awfully kind of you. I will keep it in mind!
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.
On 1/9/22 7:33 AM, Ted Heise wrote:
Aside: I'm collecting O'Reilly CD Bookshelf books w/ CDs if
you have any that you want to sell.
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.
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.
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).
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.
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.
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.
I completely agree.
I don't think there's anything quite like it.
I'm thankful that Usenet exists.
Sorry this got so long.
Apology returned to sender as unnecessary.
This is Usenet. Meaning that people can skip parts they are
not interested in or the message in it's entirety. ;-)
I tossed all my CDs a few years back, including v9-13 of Slackware.
I probably didn't explain that very well. They also talk about where
and how each of their selected model systems may deviate from the
others, often given specific recipes for each.
If this is the admin guide I'm thinking of, it's entirely different
from the books I've been describing (NB handbook vs. guide).
In looking for an example of the way Nemeth et al. approach the
mutilple systems, I came across an online version of a more recent
edition...
Ugh. That looks like it (i.e., the spaces) didn't paste at all well,
maybe try this instead...
The cartoons at each chapter heding are a hoot. Look also (for
example) at pages 246-247 to see how they discuss one aspect of the
various systems (in this case BSD, Debian, Ubuntu, Red Hat, and CentOS)
with a table for specific file locations in each.
Yeah, there's often a need to infer local specifics from other
systems and even guidance for the specific system. For example, in
the make process, the error messages often differ quite a lot from
what you might expect or what others might suggest. I've at times
had to make educated guess about what the issue is or even whether
it really needs to be rectified.
I used to be that way too, and then I gradually came to believe that
it was in a way honoring the book to add my own view and expertise.
Especially for technical books. Think skin horse vs. velveteen
rabbit. That said, I have a few books that are classics and I will
not write in them.
Yeah, I decided long ago that I would not obfuscate my address, nor
would I use nyms. I fogured if I can't stand behind what I post,
I shouldn't be posting it. And if I screw up? Well, that's what
apologies and amends are for. And technology (especially spamassassin)
does really well at filtering out the cruft.
Heh. Appreciated all around.
I'll consider your testimony as an endorsement for the Unix and
Linux System Administration Handbook and consider picking up a
physical copy.
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?
I've put the <pathbin> path for OpenSUSE :-)
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 :-)
Has anyone thought of making a Docker image for a decent INN
installation? That'll bring down the barrier to entry for people who are already using containers like me.
Containers inherit the same concerns plus they add new ones. Not the
least of which is persistent data across instantiations of the
container. Do you really want to blow away your spool and history when
you refresh the container?
Note: I'm going by what friends & colleagues say is best practice for containers in that they should not rely on external storage.
Containers inherit the same concerns plus they add new ones. Not the
least of which is persistent data across instantiations of the
container. Do you really want to blow away your spool and history when
you refresh the container?
Note: I'm going by what friends & colleagues say is best practice for containers in that they should not rely on external storage.
I would be a fan of a container setup. I think it would make it a lot
easier to get an INN setup going. Of course there's the question of maintenance. It's probably a lot of work as is working on/maintaining
INN, let alone separately maintaining a container.
You would either need to inject all of pathetc from external storage,
which makes me wonder what the container is really doing for you,
or you would need to have some mechanism to override individual
files via, e.g., Kubernetes ConfigMaps, and the mapping of that to
INN configuration isn't straightforward at all. Or I suppose every
user of the INN container could build their own Docker image based
on some base image with configuration injected; that's probably the
most straightforward way to do it, but that means you'd have to build
your own container and couldn't use a standard container, which is
not normally what people are after.
So I'm not sure a container is solving the hard problem with setting
up a new site, although I guess it would integrate Cleanfeed and PGP configuration and a few things like that.
meff <email@example.com> writes:
like Cleanfeed isn't a lot harder. The hard part is what the heck to put into the container as far as configuration, without making too many
decisions that the person running the container isn't going to agree with (and putting aside the question of feed configuration and other inherently site-specific things).
I think it's fine for a container to be highly opinionated. If the user
wants to go their own way, they can edit the container or work with INN
and create their own container/systemd unit/runit script etc. I'm
thinking the container could be something like "beginner mode" where the
user opts-in to all the decisions made for them.
That's fine so far as it goes, but to take a specific example, what groups should the container carry? This isn't just an opinionated decision; it really goes to the heart of why someone is running a news server. I'm betting most people don't really want a full feed including all the
regional and language hierarchies. They may just want fr.*, for instance.
If I were building a news server from scratch designed to be
containerized, I'd put that sort of configuration in a database and then provide an authenticated API to add and remove feeds. That would be nice
to have! But that's a whole project.
Hm this is a good point, but I'm guessing most folks will not be
receiving a firehose when peering. It might not be the worst to offer
all newsgroups, and then offer some way to customize the newsgroups
inside the container but...
Yeah exactly. I've retrofitted some software before to work with
environment variables, and it usually involved templates and scripts
which would read environment variables on container startup and then
generate the configs from the templates. I wonder if such an approach
would be pallatable here, but yeah this is sort of working against
the design of INN.
+10 for creativity
-100 for making things more complex when the stated task at hand is to simplify things.
-10 for diverging from an INN config to
$CustomINNisNotSoSimplePackageConfig.
I feel like adding custom complexity is antithetical to the overall
stated goal of making INN / Usenet easier.
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?
To make everyone gag a little more, we used m4 to do a lot of the
templating. I have a soft spot for m4 heh.
I've written some things that I consider to be both quite interesting in
m4. The most recent was an rwhois data management system that was
object oriented, e.g.:
router(
name(`r1a.example.net`)
ip(`192.0.2.1/24`)
ip(`198.51.100.2/24`)
ip(`203.0.113.3/24`)
)
name() was required as it identified the router.
ip() was required at least one time but could exist an indefinite number
of times. ip() also calculated the network and broadcast based on the
IP & subnet mask.
You'll sometimes see this "containers should not rely on external storage" talking point when people are talking specifically about web services and what they're worried about is someone's PHP application that uses files in /tmp as a session database or some similar kind of anti-pattern. Web services should normally use an external database, and if you're running
the container in some sort of hosting platform, there's usually some
database as a service thing you can use that will be way simpler and more reliable (if more expensive) than rolling your own.
For instance, a package which already has enabled:
- Cleanfeed (or PyClean)
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 89:05:27 |
Calls: | 6,496 |
Calls today: | 7 |
Files: | 12,100 |
Messages: | 5,277,442 |