• Ready-to-use installation of a news server

    From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Thu Jan 6 10:03:57 2022
    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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From yamo'@21:1/5 to All on Thu Jan 6 11:01:37 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Henning Hucke@21:1/5 to iulius@nom-de-mon-site.com.invalid on Thu Jan 6 15:23:29 2022
    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>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Thu Jan 6 13:52:15 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Doc O'Leary@21:1/5 to Grant Taylor on Fri Jan 7 17:42:15 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jdanield@21:1/5 to All on Fri Jan 7 19:23:20 2022
    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.*)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to jdanield on Fri Jan 7 13:06:35 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jdanield@21:1/5 to All on Fri Jan 7 22:02:11 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Fri Jan 7 22:33:14 2022
    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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jdanield@21:1/5 to All on Fri Jan 7 22:18:34 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to jdanield on Fri Jan 7 15:18:06 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From meff@21:1/5 to Grant Taylor on Sat Jan 8 04:33:05 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to meff on Sat Jan 8 00:50:33 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jdanield@21:1/5 to All on Sat Jan 8 09:06:25 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jdanield@21:1/5 to All on Sat Jan 8 09:28:59 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From meff@21:1/5 to Grant Taylor on Sat Jan 8 08:41:12 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ted Heise@21:1/5 to Grant Taylor on Sat Jan 8 14:59:18 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to jdanield on Sat Jan 8 09:35:23 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to meff on Sat Jan 8 16:07:02 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Levine@21:1/5 to All on Sat Jan 8 23:34:30 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to John Levine on Sat Jan 8 16:37:48 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Ted Heise on Sat Jan 8 16:35:28 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to jdanield on Sat Jan 8 16:24:51 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ted Heise@21:1/5 to Grant Taylor on Sun Jan 9 14:33:52 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Ted Heise on Sun Jan 9 11:33:34 2022
    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.

    I completely agree.

    I don't think there's anything quite like it.

    I'm thankful that Usenet exists.

    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).

    I do similar in Slackware newsgroups for similar reasons.

    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. ;-)



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ted Heise@21:1/5 to Grant Taylor on Sun Jan 9 20:29:27 2022
    On Sun, 9 Jan 2022 11:33:34 -0700,
    Grant Taylor <gtaylor@tnetconsulting.net> wrote:
    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.

    I tossed all my CDs a few years back, including v9-13 of
    Slackware. Sorry. In the time since my folks passed (and
    especially after cleaning out my mom's place), I've been a lot
    more intent on divesting material property. Unfortunately, I
    still have quite a ways to go.


    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.

    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. See next
    comment for more on this.


    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.

    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...

    https://mog.dog/files/SP2019/2017%20Nemeth%20Evi%20etal%20-%20UNIX%20and%20Linux%20System%20Administration%20Handbook%5B5thED%5D_Rell.pdf

    Ugh. That looks like it (i.e., the spaces) didn't paste at all
    well, maybe try this instead...

    tinyurl.com/47afaswh

    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.


    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).

    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.


    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.

    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.

    [snip thoughtful description of documentation practices]


    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.

    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.


    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. ;-)

    Heh. Appreciated all around.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Ted Heise on Sun Jan 9 16:54:22 2022
    On 1/9/22 1:29 PM, Ted Heise wrote:
    I tossed all my CDs a few years back, including v9-13 of Slackware.

    ACK

    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.

    Interesting.

    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).

    Perhaps I made a bad assumption based on a name collision between a book
    title and a TLDP document title.

    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...

    Oh, I've seen that book in my searches online. It's definitely a
    different book than I'm thinking of.

    I'm thinking of the O'Reilly Linux Network Administrator's Guide (ISBN: 1-56592-400-2) it's the guy riding a horse as the animal logo.

    Ugh. That looks like it (i.e., the spaces) didn't paste at all well,
    maybe try this instead...

    The first link worked for me.

    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.

    I'll consider your testimony as an endorsement for the Unix and Linux
    System Administration Handbook and consider picking up a physical copy.

    I'm enjoying sitting in my rocker reading & taking notes (on my phone).

    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.

    *nod*

    I find that many Linux distributions differ in where they place files,
    what packages contain said files, and init scripts are the biggest
    differences. Beyond that it's little things some of which have a small
    impact and others have a big impact. E.g. (my understanding is)
    Slackware not using PAM.

    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.

    I think about it more as leaving a book in the condition that I would
    like to find it, or better. I dislike reading marked up books, so I
    think that others will dislike it too.

    Aside: Many of the used book sites that I use tend to grade unmarked
    books higher than marked up books. So apparently I'm not the only one.
    None of this means much though. ...

    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.

    ... You use your books the way that you want to. ;-)

    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.

    Yep.

    Heh. Appreciated all around.

    :-)



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ted Heise@21:1/5 to Grant Taylor on Mon Jan 10 16:23:06 2022
    On Sun, 9 Jan 2022 16:54:22 -0700,
    Grant Taylor <gtaylor@tnetconsulting.net> wrote:

    I'll consider your testimony as an endorsement for the Unix and
    Linux System Administration Handbook and consider picking up a
    physical copy.

    I have nothing much more to add, other than saying I enjoyed the
    exchange.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Fri Jan 14 16:25:09 2022
    Bonjour Jean-Daniel,

    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?

    In the definition of the innfeed channel feed in newsfeeds:

    innfeed!\
    :!*\
    :Tc,Wnm*:/usr/lib/news/bin/innfeed -y

    I've put the <pathbin> path for OpenSUSE :-)

    --
    Julien ÉLIE

    « Une fois rien, c'est rien ; deux fois rien, c'est pas beaucoup, mais
    pour trois fois rien, on peut déjà acheter quelque chose, et pour pas
    cher. » (Raymond Devos)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jdanield@21:1/5 to All on Fri Jan 14 18:02:15 2022
    Le 14/01/2022 à 16:25, Julien ÉLIE a écrit :

    I've put the <pathbin> path for OpenSUSE :-)


    anyway, I add links (but not to be used in config files)

    news> ll | grep lr
    lrwxrwxrwx 1 root root 17 10 oct. 12:04 bin -> /usr/lib/news/bin lrwxrwxrwx 1 root root 13 10 oct. 12:04 logs -> /var/log/news
    lrwxrwxrwx 1 root root 15 10 oct. 12:04 spool -> /var/spool/news

    thanks
    jdd

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From JP@21:1/5 to All on Sat Jan 15 03:07:31 2022
    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.

    On 06/01/22 14:33, Julien ÉLIE wrote:
    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 :-)


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Fri Jan 14 17:03:48 2022
    On 1/14/22 2:37 PM, JP wrote:
    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.

    I have even bigger problems with Docker, et al., than I do a fully
    configured server. (See my other posts in this thread.)

    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.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From meff@21:1/5 to Grant Taylor on Sat Jan 15 00:37:38 2022
    On 2022-01-15, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
    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 work just fine with external storage. You'll need to mount
    the external storage and make sure to set permissions properly on the
    external storage but that's at its worst just as hard as setting spool
    and history permissions without a container. If you think about it,
    any container that talks to a database _is_ depending on external
    storage heh.

    The mail containers can also show prior art for storing state in a
    volume.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Grant Taylor on Fri Jan 14 16:42:13 2022
    Grant Taylor <gtaylor@tnetconsulting.net> writes:

    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.

    Uh. Well, I'm not sure what best practices guides they've been reading,
    but this is not the case for services that store things, such as any
    database server or, of course, a news server. Of *course* such containers
    rely on external persistent storage. That's the only way you can possibly
    put such software inside a container.

    If you're running the container on a full container system like
    Kubernetes, there is tons of built-in support for allocating and managing
    that storage, ensuring that it is not deleted when the container is
    replaced with a new one, etc., via, for example, PersistentVolumes. If
    you're running it in a simple standalone container system on one host,
    you'd normally bind-mount some host file systems into the container for
    that stuff.

    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.

    INN obviously isn't set up to use an external database (in theory it could
    use an external database for overview and history and some sort of object
    store for the articles, but none of that code exists), so it's more like running your own instance of PostgreSQL in a container: you will
    definitely need persistent external storage attached to the container
    unless you're only using ephemeral containers for testing or CI.

    Anyway, all the container platforms let you mount external storage. This
    isn't the problem with containers. What I would be more worried about is
    how to inject site-specific configuration, which for INN is quite complex
    and which is the actual hard part of setting up INN. 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.

    Containers are primarily useful as a software delivery mechanism when assembling that software is in some way non-trivial (lots of plugins or libraries that need to be installed or whatnot). INN is the type of
    software for which Linux distributions do this quite well and thus it's
    not obvious how a container is helping. INN doesn't need exotic versions
    of libraries that are unlikely to be present already in the distribution,
    or some complex assemblage that the distribution doesn't already have
    packaged. 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.

    --
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to meff on Fri Jan 14 16:57:36 2022
    meff <email@example.com> writes:

    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.

    Doing make install into a Docker container is easy. Adding a few things
    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).

    --
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Russ Allbery on Fri Jan 14 18:08:59 2022
    On 1/14/22 5:42 PM, Russ Allbery wrote:
    You would either need to inject all of pathetc from external storage,
    which makes me wonder what the container is really doing for you,

    Agreed.

    What's more is I feel like what (little?) the container is providing
    could be similarly provided by a tar ball or a script that executes OS /
    distro specific install commands to install the required ~> desired
    components.

    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.

    And I feel like you've now added at least one order of magnitude to the complexity while jumping the shark.

    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.

    I suspect the container is actually going to bring more baggage with it
    than it helps alleviate.

    What's more is that once things are in a container, they tend to become
    opaque blobs meaning that people will likely have /less/ visibility into
    what is happening. Sure they may see some of the config files, but
    there's more to running INN than /just/ the config files.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From meff@21:1/5 to Russ Allbery on Sat Jan 15 01:11:22 2022
    On 2022-01-15, Russ Allbery <eagle@eyrie.org> wrote:
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to meff on Fri Jan 14 17:30:52 2022
    meff <email@example.com> writes:

    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.

    That said, the really hard part is the feed configuration and some
    entirely local parameters like the site name for the Path header.
    Normally in containerized software this information is injected as
    parameters, via environment variables or whatnot, but INN is very much not
    set up to do that, so it would require code changes (and ones that aren't entirely obvious, such as how to configure feeds).

    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.

    --
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From meff@21:1/5 to Russ Allbery on Sat Jan 15 02:09:32 2022
    On 2022-01-15, Russ Allbery <eagle@eyrie.org> wrote:
    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.

    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...

    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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to meff on Sat Jan 15 11:50:11 2022
    On 1/14/22 7:09 PM, meff wrote:
    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...

    You could cheat a bit. Have all ""standard (as in from ISC) newsgroups
    in the active file and control feed via what a peer sends you. -- I
    don't like it, but I don't see any breakage either.

    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.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From meff@21:1/5 to Grant Taylor on Sat Jan 15 20:18:07 2022
    On 2022-01-15, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
    +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.

    I just said it's possible lol. Any discussion of a hypothetical
    container would be purely tangential to regular INN configuration, and
    as I said I'm not sure this form of retrofitting is desirable in any
    way. I've done it in the past when we've needed to take our own crappy
    software that depends on configuration files and retrofit them for
    containers, not necessarily that INN should have it. It's an exercise
    bound in enterprise compromise.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?8J+YiSBHb29kIEd1eSDwn5iJ?@21:1/5 to All on Sat Jan 15 20:30:00 2022
    This is a multi-part message in MIME format.
    On 06/01/2022 09:03, Julien ÉLIE wrote:
    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?

    This is a very good idea Julien. Please do it and don't listen to people
    who say it is not possible because "where there is a will there is a way".

    People have to start somewhere and your suggestion is a very good one to
    start with. Security can be enhanced AFTER something is up and running.
    That is how people started with web-servers. They first tried it on
    their desktop and when it was running, they uploaded it online and now everybody can run their own web-server without worrying about security
    issues!.

    Just do it like a good old French man and make Emmanuel Macron proud of
    you! We need more people like you here.

    Good luck and keep us posted.


    --
    "Let us read, and let us dance; these two amusements will never do any
    harm to the world."
    ― Voltaire


    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=ascii-us">
    <style>
    @import url(https://fonts.googleapis.com/css2?family=Brawler&display=swap);body{font-size:1.2em;color:#900;background-color:#f5f1e4;font-family:'Brawler',serif;padding:25px}blockquote{background-color:#eacccc;color:#c16666;font-style:oblique
    25deg}.table{display:table}.tr{display:table-row}.td{display:table-cell}
    </style>
    </head>
    <body text="#990000" bgcolor="#f5f1e4">
    <div class="moz-cite-prefix">On 06/01/2022 09:03, Julien ÉLIE wrote:<br>
    </div>
    <blockquote type="cite"
    cite="mid:sr6b9t$1ejhd$1@news.trigofacile.com">Hi all, <br>
    <br>
    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? <br>
    </blockquote>
    <p>This is a very good idea Julien. Please do it and don't listen to
    people who say it is not possible because "where there is a will
    there is a way".</p>
    <p>People have to start somewhere and your suggestion is a very good
    one to start with. Security can be enhanced AFTER something is up
    and running. That is how people started with web-servers. They
    first tried it on their desktop and when it was running, they
    uploaded it online and now everybody can run their own web-server
    without worrying about security issues!.</p>
    <p>Just do it like a good old French man and make Emmanuel Macron
    proud of you! We need more people like you here.</p>
    <p>Good luck and keep us posted.<br>
    </p>
    <p><br>
    </p>
    <pre class="moz-signature" cols="72">--
    <q>Let us read, and let us dance; these two amusements will never do any harm to the world.</q>
    ― Voltaire
    </pre>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to meff on Sat Jan 15 20:41:28 2022
    On 1/15/22 1:18 PM, meff wrote:
    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.

    Surprisingly, or not, m4 actually makes me like the idea more. ;-)

    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.

    I think there were other options for router(), I don't remember off
    hand. There were also other things besides rotuer(). I think I had
    created network() and server().

    I also has some other things that could set some defaults that could be
    used if unspecified in smaller contexts, however the smaller context
    would override the default if set in the context.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From meff@21:1/5 to Grant Taylor on Sun Jan 16 04:31:12 2022
    On 2022-01-16, Grant Taylor <gtaylor@tnetconsulting.net> wrote:
    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.

    This is very similar to what we wrote to retrofit some of our older
    PHP configs into a container, except obviously it was based around
    environment variables instead of routing terms. We went with m4
    because:

    1. M4 has no language dependencies. A lot of templating languages out
    there depend on some programming language or the other, and we wanted
    something language agnostic.

    2. M4 has very few library dependencies and comes with almost every
    Linux distro. It adds very little bloat to our containers.

    3. M4 is stable software that doesn't change. These containers host
    some of our oldest code, and so we really don't want to muck with
    things if not absolutely necessary.

    I have a soft spot for M4 but again I'm not sure how productive this
    would be lol.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Doc O'Leary@21:1/5 to Russ Allbery on Sun Jan 16 23:16:39 2022
    For your reference, records indicate that
    Russ Allbery <eagle@eyrie.org> wrote:

    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.

    In the context of databases, being “external” will be an issue for containers if there is some migration in the shared model that is
    incompatible between the software on multiple different containers. Are
    there any plans in the works to do that kind of thing for INNs persistent
    data? Regardless, I really don’t see containers as being the right
    solution here. With sane configuration defaults and reasonable OS-level package manager support, there’s no reason most people shouldn’t be able
    to have a basic INN install running with a few clicks. Everything
    significant after that is best accomplished with HOW-TOs and a few choice configuration tweaks.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Julien_=c3=89LIE?=@21:1/5 to All on Mon Mar 7 20:43:52 2022
    Hi all,

    For instance, a package which already has enabled:
    - Cleanfeed (or PyClean)

    Seems like a few distributions have already packaged Cleanfeed.

    Fedora has legacy Marco's version:
    https://src.fedoraproject.org/rpms/cleanfeed/tree/rawhide

    PLD has latest Steve's version, and even provides a cleanfeed(8) man page:
    https://git.pld-linux.org/?p=packages/cleanfeed.git;a=tree

    --
    Julien ÉLIE

    « Chaque chêne est envahi par quantité de druides qui cueillent le gui
    en travaillant dur de la serpe… » (Astérix)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)