Let's assume I have this setup ...

I configure the access for three peers.

Each peer has its configuration in a separate rslight.inc.php file in
its own directory.

The configuration files are all identical except for the peer hostname,
port and authentication data for each specific peer.

A wrapper script around the cron creates a symlink in
config/rslight.inc.php and points to one of the above referenced
configuration files before running config/scripts/cron.php.

At each invocation the symlink is changed to point to the next peer
config in the rotation. This way the syncronization rotates between the
three peers.

What problems might be encountered?

If the peers have different message ordering could this corrupt or
confuse the local tradspool or database message stores?

What more elegant method might work for this setup?

On Sat, 16 Dec 2023 16:47:20 -0600, Syber Shock wrote:

> Let's assume I have this setup ...
>
> I configure the access for three peers.
>
> Each peer has its configuration in a separate rslight.inc.php file in
> its own directory.
>
> The configuration files are all identical except for the peer hostname,
> port and authentication data for each specific peer.
>
> A wrapper script around the cron creates a symlink in
> config/rslight.inc.php and points to one of the above referenced
> configuration files before running config/scripts/cron.php.
>
> At each invocation the symlink is changed to point to the next peer
> config in the rotation. This way the syncronization rotates between the
> three peers.
>
> What problems might be encountered?

I have not tried this, but I believe it should work.

> If the peers have different message ordering could this corrupt or
> confuse the local tradspool or database message stores?

Each peer will be saved in $spooldir/<section>/<peername:port.txt

This file saves the article number pointers per group per peer. Each peer
will create it's own file to keep track, so they should not step on each
other.

What you will probably find is a LOT of 'Duplicate' notices in
spoolnews.log as each peer starts from where it left off per group and
pulls the overview for what comes next. It will check the overview article
by article and NOT pull articles that are duplicates, which will be
displayed in the log file.

> What more elegant method might work for this setup?

If this is something people want to do, and I certainly see why they may
wish to, we could modify the code to make it easier. Perhaps a .conf file
to set it up (points servers to .inc.php files). That shouldn't be too
terribly complicated.

On Sun, 17 Dec 2023 11:37:38 +0000
Retro Guy <retroguy@novabbs.org> wrote:

> On Sat, 16 Dec 2023 16:47:20 -0600, Syber Shock wrote:
>
> > Let's assume I have this setup ...
> >
> > I configure the access for three peers.
> >
> > Each peer has its configuration in a separate rslight.inc.php file
> > in its own directory.
> >
> > The configuration files are all identical except for the peer
> > hostname, port and authentication data for each specific peer.
> >
> > A wrapper script around the cron creates a symlink in
> > config/rslight.inc.php and points to one of the above referenced
> > configuration files before running config/scripts/cron.php.
> >
> > At each invocation the symlink is changed to point to the next peer
> > config in the rotation. This way the syncronization rotates between
> > the three peers.
> >
> > What problems might be encountered?
>
> I have not tried this, but I believe it should work.
>
> > If the peers have different message ordering could this corrupt or
> > confuse the local tradspool or database message stores?
>
> Each peer will be saved in $spooldir/<section>/<peername:port.txt
>
> This file saves the article number pointers per group per peer. Each
> peer will create it's own file to keep track, so they should not step
> on each other.
>
> What you will probably find is a LOT of 'Duplicate' notices in
> spoolnews.log as each peer starts from where it left off per group
> and pulls the overview for what comes next. It will check the
> overview article by article and NOT pull articles that are
> duplicates, which will be displayed in the log file.
>
> > What more elegant method might work for this setup?
>
> If this is something people want to do, and I certainly see why they
> may wish to, we could modify the code to make it easier. Perhaps a
> .conf file to set it up (points servers to .inc.php files). That
> shouldn't be too terribly complicated.

Even something as simple as a switch list or cycle list in the code
that pulls pointers from a config file of available peers would be
plenty good. Brainstorm ...

Something like:

==> for groups in folder rocksolid/
$ nano rocksolid.peers
:rslight peers
rslight.config.php
paganini.config.php
novabbs.config.php
hispagatos.config.php

==> for groups in folder tilde/
$ nano tilde.peers
:tildeverse peers
tilde_club.config.php
tilde_team.config.php

for groups in folder hispagatos/
$ nano hispagatos.peers
hispagatos.inc.php
hispanicat.inc.php

Or maybe even simpler, all the *.inc.php for a group could be in the
same folder as the groups.txt file, and rslight could just check for the
extension *.inc.php.

So one would get this:

==> for groups in folder rocksolid/
$ ls rocksolid/
groups.txt
rslight.config.php
paganini.config.php
novabbs.config.php

==> for groups in folder hispagatos/
ls hispagatos/
groups.txt
hispagatos.inc.php
hispanicat.inc.php

I think I like the second way better. Less ways to mess it up. If there
is a filled-out or blank *inc.php above the folder then that would mark
the folder active as the source of config for that folder.

Basically the php script could check the folders for additional
*.inc.php files then cycle through them in alphabetical order or
digital order if the filenames begin with digits. I would limit it to
the first two digits being relevant. A manifest file would keep track
of the order, by noting the last one used during the last cron.

On Sun, 17 Dec 2023 08:15:38 -0600, Syber Shock < wrote:

> On Sun, 17 Dec 2023 11:37:38 +0000 Retro Guy <retroguy@novabbs.org>
> wrote:
>
>> On Sat, 16 Dec 2023 16:47:20 -0600, Syber Shock wrote:
>>
>> > Let's assume I have this setup ...
>> >
>> > I configure the access for three peers.
>> >
>> > Each peer has its configuration in a separate rslight.inc.php file in
>> > its own directory.
>> >
>> > The configuration files are all identical except for the peer
>> > hostname, port and authentication data for each specific peer.
>> >
>> > A wrapper script around the cron creates a symlink in
>> > config/rslight.inc.php and points to one of the above referenced
>> > configuration files before running config/scripts/cron.php.
>> >
>> > At each invocation the symlink is changed to point to the next peer
>> > config in the rotation. This way the syncronization rotates between
>> > the three peers.
>> >
>> > What problems might be encountered?
>>
>> I have not tried this, but I believe it should work.
>>
>> > If the peers have different message ordering could this corrupt or
>> > confuse the local tradspool or database message stores?
>>
>> Each peer will be saved in $spooldir/<section>/<peername:port.txt
>>
>> This file saves the article number pointers per group per peer. Each
>> peer will create it's own file to keep track, so they should not step
>> on each other.
>>
>> What you will probably find is a LOT of 'Duplicate' notices in
>> spoolnews.log as each peer starts from where it left off per group and
>> pulls the overview for what comes next. It will check the overview
>> article by article and NOT pull articles that are duplicates, which
>> will be displayed in the log file.
>>
>> > What more elegant method might work for this setup?
>>
>> If this is something people want to do, and I certainly see why they
>> may wish to, we could modify the code to make it easier. Perhaps a
>> .conf file to set it up (points servers to .inc.php files). That
>> shouldn't be too terribly complicated.
>
> Even something as simple as a switch list or cycle list in the code that
> pulls pointers from a config file of available peers would be plenty
> good. Brainstorm ...
>
> Something like:
>
> ==> for groups in folder rocksolid/
> $ nano rocksolid.peers :rslight peers rslight.config.php
> paganini.config.php novabbs.config.php hispagatos.config.php
>
> ==> for groups in folder tilde/
> $ nano tilde.peers :tildeverse peers tilde_club.config.php
> tilde_team.config.php
>
> for groups in folder hispagatos/
> $ nano hispagatos.peers hispagatos.inc.php hispanicat.inc.php
>
> Or maybe even simpler, all the *.inc.php for a group could be in the
> same folder as the groups.txt file, and rslight could just check for the
> extension *.inc.php.

That's something I've considered (not multiple config files, but
moving .inc.php to <section> dir, and I agree it's a good idea.

I'll start messing with this some time next week and see what I come up
with, including multiple .inc.php per <section>.

On Sun, 17 Dec 2023 15:09:35 +0000
Retro Guy <retroguy@novabbs.org> wrote:

<snip>

> > Something like:
> >
> > ==> for groups in folder rocksolid/
> > $ nano rocksolid.peers :rslight peers rslight.config.php
> > paganini.config.php novabbs.config.php hispagatos.config.php
> >
> > ==> for groups in folder tilde/
> > $ nano tilde.peers :tildeverse peers tilde_club.config.php
> > tilde_team.config.php
> >
> > for groups in folder hispagatos/
> > $ nano hispagatos.peers hispagatos.inc.php hispanicat.inc.php
> >
> > Or maybe even simpler, all the *.inc.php for a group could be in the
> > same folder as the groups.txt file, and rslight could just check
> > for the extension *.inc.php.
>
> That's something I've considered (not multiple config files, but
> moving .inc.php to <section> dir, and I agree it's a good idea.
>
> I'll start messing with this some time next week and see what I come
> up with, including multiple .inc.php per <section>.

If you push a testing branch I'll clone to test it and give feedback.

On Sun, 17 Dec 2023 11:11:26 -0600, Syber Shock wrote:

> On Sun, 17 Dec 2023 15:09:35 +0000 Retro Guy <retroguy@novabbs.org>
> wrote:
>
> <snip>
>
>> > Something like:
>> >
>> > ==> for groups in folder rocksolid/
>> > $ nano rocksolid.peers :rslight peers rslight.config.php
>> > paganini.config.php novabbs.config.php hispagatos.config.php
>> >
>> > ==> for groups in folder tilde/
>> > $ nano tilde.peers :tildeverse peers tilde_club.config.php
>> > tilde_team.config.php
>> >
>> > for groups in folder hispagatos/
>> > $ nano hispagatos.peers hispagatos.inc.php hispanicat.inc.php
>> >
>> > Or maybe even simpler, all the *.inc.php for a group could be in the
>> > same folder as the groups.txt file, and rslight could just check for
>> > the extension *.inc.php.
>>
>> That's something I've considered (not multiple config files, but moving
>> .inc.php to <section> dir, and I agree it's a good idea.
>>
>> I'll start messing with this some time next week and see what I come up
>> with, including multiple .inc.php per <section>.
>
> If you push a testing branch I'll clone to test it and give feedback.

Sounds good, thank you! I will do that.

I have some doctor crap early in the week, but should be able to get to it
soon after that.

I like the idea, so looking forward to working on it.