| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 23 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 54:42:53 |
| Calls: | 583 |
| Files: | 1,139 |
| D/L today: |
179 files (27,921K bytes) |
| Messages: | 111,801 |
I am configuring and testing a Rocksolid Light peer to pull and archive
91 Usenet newsgroups, not counting the rocksolid groups.
The goal is to suck the same list of newsgroups from several remote
peers without making any attempt to push new articles to those peers
that are wide open. Push should only happen with the I2PN2 server. When
I can ensure reliably against pushing to selected remotes I want to add several more sections for more remotes.
Three identical sections in the menu.conf file appear like so:
After running the cron several times I began observing the log files and
file generation in <spool> directory and population of articles to the
spool visible via both web portal and newsreader software.
I am concerned about several things:
1. I do not want the rslight install to attempt to push articles to the
wide open peers. I want to ensure this does not happen at all.
2. I can't tell if this is happening under the hood. How might I check?
3. I only want articles forwarded to peers for which a non-null, remote username and password exist in the <section>.inc.php file. For instance,
I would like to add an open server that allows unauthenticated posting,
yet I want to ensure that this server will NOT try to forward to that
remote. Even though posting is possible, I want only to pull, never to
push.
4. The newsreader software (Sylpheed) shows three identical listings of
each newsgroup in the group list. How may I resolve this to show only
one copy of the group?
I thought about setting up a shield or transit peer, but I would like to
see if it is possible to make do with just one Rocksolid install for
this job.
Advice on forming a reliable method to check and verify these issues
will be very helpful.
On Mon, 14 Oct 2024 6:45:28 +0000, Byrl Raze Buckbriar wrote:
I am configuring and testing a Rocksolid Light peer to pull and archive<snip>
91 Usenet newsgroups, not counting the rocksolid groups.
The goal is to suck the same list of newsgroups from several remote
peers without making any attempt to push new articles to those peers
that are wide open. Push should only happen with the I2PN2 server. When
I can ensure reliably against pushing to selected remotes I want to add
several more sections for more remotes.
Three identical sections in the menu.conf file appear like so:
After running the cron several times I began observing the log files and
file generation in <spool> directory and population of articles to the
spool visible via both web portal and newsreader software.
I am concerned about several things:
1. I do not want the rslight install to attempt to push articles to the
wide open peers. I want to ensure this does not happen at all.
In the config file (rslight.inc.php) you can disable posting by setting: 'readonly' => '1',
For each section, you can have it's own config file:
rocksolid.inc.php
section2.inc.php
etc.
In this config file you can set all the settings from rocksolid.inc.php
and either change them or let them remain. See example.inc.php in
config_dir.
***BUT*** Having the same group names in multiple sections can cause
issues. It is still possible that rslight will try to send via one of
the other sections, as it searches sections when you post, then moves
message to 'outgoing' dir in that section ($spooldir/outgoing). I will
look at the code today to see how to avoid this.
It should not try to send if readonly is set, but the group in multiple sections will defeat this. It should be reasonably simple to fix in the
code.
I am configuring and testing a Rocksolid Light peer to pull and archive
91 Usenet newsgroups, not counting the rocksolid groups.
4. The newsreader software (Sylpheed) shows three identical listings of
each newsgroup in the group list. How may I resolve this to show only
one copy of the group?
On Mon, 14 Oct 2024 6:45:28 +0000, Byrl Raze Buckbriar wrote:
I am configuring and testing a Rocksolid Light peer to pull and archive
91 Usenet newsgroups, not counting the rocksolid groups.
4. The newsreader software (Sylpheed) shows three identical listings of
each newsgroup in the group list. How may I resolve this to show only
one copy of the group?
This identical listing issue should be fixed now. The fix is in cron.php
and has been pushed to devel (to gitlab).
On Mon, 14 Oct 2024 6:45:28 +0000, Byrl Raze Buckbriar wrote:
=20
I am configuring and testing a Rocksolid Light peer to pull and archive=20
91 Usenet newsgroups, not counting the rocksolid groups.
4. The newsreader software (Sylpheed) shows three identical listings of each newsgroup in the group list. How may I resolve this to show only=20
one copy of the group?
This identical listing issue should be fixed now. The fix is in cron.php
and has been pushed to devel (to gitlab).
On Mon, 14 Oct 2024 9:17:39 +0000, Retro Guy wrote:nd
=20
On Mon, 14 Oct 2024 6:45:28 +0000, Byrl Raze Buckbriar wrote:
I am configuring and testing a Rocksolid Light peer to pull and archive<snip>
91 Usenet newsgroups, not counting the rocksolid groups.
The goal is to suck the same list of newsgroups from several remote
peers without making any attempt to push new articles to those peers
that are wide open. Push should only happen with the I2PN2 server. When
I can ensure reliably against pushing to selected remotes I want to add
several more sections for more remotes.
Three identical sections in the menu.conf file appear like so:
After running the cron several times I began observing the log files a=
file generation in <spool> directory and population of articles to the
spool visible via both web portal and newsreader software.
I am concerned about several things:
1. I do not want the rslight install to attempt to push articles to the
wide open peers. I want to ensure this does not happen at all.
In the config file (rslight.inc.php) you can disable posting by setting: 'readonly' =3D> '1',
For each section, you can have it's own config file:
rocksolid.inc.php
section2.inc.php
etc.
In this config file you can set all the settings from rocksolid.inc.php
and either change them or let them remain. See example.inc.php in config_dir.
***BUT*** Having the same group names in multiple sections can cause issues. It is still possible that rslight will try to send via one of
the other sections, as it searches sections when you post, then moves message to 'outgoing' dir in that section ($spooldir/outgoing). I will
look at the code today to see how to avoid this.
It should not try to send if readonly is set, but the group in multiple sections will defeat this. It should be reasonably simple to fix in the code.=20
Ok, I see the first issue here.
=20
When rslight receives a request for a group, it checks to find the
section for the group. This is done to handle moving groups from one
section to another by admin, without breaking links. So, if you move 'rocksolid.nodes' from 'rocksolid' to 'otherstuff' and a browser
requests it in 'rocksolid', rslight will automatically redirect them to 'otherstuff'.
=20
This causes an issue when the group is in multiple sections.
=20
So a question. Is the purpose of having the group in multiple sections
simply to pull from multiple servers? If that is the case, set the extra sections in menu.conf to:
=20
extrasection:0:1 instead of extrasection:1:1
=20
This will remove it from the menu on the site, and remove it from
rslight searching what section includes a group for display.
=20
Will this work for this one particular issue? I'm going to look into the duplicate listing of groups now and try to duplicate that.
On Mon, 14 Oct 2024 10:38:42 +0000, Retro Guy wrote:
=20
On Mon, 14 Oct 2024 6:45:28 +0000, Byrl Raze Buckbriar wrote:
I am configuring and testing a Rocksolid Light peer to pull and archive
91 Usenet newsgroups, not counting the rocksolid groups.
4. The newsreader software (Sylpheed) shows three identical listings of
each newsgroup in the group list. How may I resolve this to show only
one copy of the group?
This identical listing issue should be fixed now. The fix is in cron.php and has been pushed to devel (to gitlab).=20
This seems fine now in Sylpheed (or should be any newsreader).
=20
I now have checking in TWO places to make sure to NOT send if 'readonly'
is '1' for a section. Once when you try to post, and another time if for
some reason it gets past that, it will check again when trying to
actually feed it to the remote server.
=20
This is logged in debug.log. I am still cleaning up reply codes so the newsreader has a useful reply for it's logs (and debugging). So far I
have been unable to feed an article to a remote site if the section is readonly.
=20
If there are several sections with the same group, only a NON-readonly section will allow it to be sent to remote. If there is no NON-readonly section containing the group, posting will fail.
On Mon, 14 Oct 2024 12:19:53 +0000
Retro Guy <retroguy@novabbs.com> wrote:
On Mon, 14 Oct 2024 10:38:42 +0000, Retro Guy wrote:
On Mon, 14 Oct 2024 6:45:28 +0000, Byrl Raze Buckbriar wrote:
I am configuring and testing a Rocksolid Light peer to pull and archive >>>> 91 Usenet newsgroups, not counting the rocksolid groups.
4. The newsreader software (Sylpheed) shows three identical listings of >>>> each newsgroup in the group list. How may I resolve this to show only
one copy of the group?
This identical listing issue should be fixed now. The fix is in cron.php >>> and has been pushed to devel (to gitlab).
This seems fine now in Sylpheed (or should be any newsreader).
I now have checking in TWO places to make sure to NOT send if 'readonly'
is '1' for a section. Once when you try to post, and another time if for
some reason it gets past that, it will check again when trying to
actually feed it to the remote server.
This is logged in debug.log. I am still cleaning up reply codes so the
newsreader has a useful reply for it's logs (and debugging). So far I
have been unable to feed an article to a remote site if the section is
readonly.
If there are several sections with the same group, only a NON-readonly
section will allow it to be sent to remote. If there is no NON-readonly
section containing the group, posting will fail.
That sounds right. I plan to check it out this evening. It looks like you merged 'devel' branch. Does that mean the changes are all in 'master' now?
On Mon, 14 Oct 2024 19:54:28 +0000, Byrl Raze Buckbriar wrote:
On Mon, 14 Oct 2024 12:19:53 +0000
Retro Guy <retroguy@novabbs.com> wrote:
On Mon, 14 Oct 2024 10:38:42 +0000, Retro Guy wrote:
On Mon, 14 Oct 2024 6:45:28 +0000, Byrl Raze Buckbriar wrote:
I am configuring and testing a Rocksolid Light peer to pull and archive >>>>> 91 Usenet newsgroups, not counting the rocksolid groups.
4. The newsreader software (Sylpheed) shows three identical listings of >>>>> each newsgroup in the group list. How may I resolve this to show only >>>>> one copy of the group?
This identical listing issue should be fixed now. The fix is in cron.php >>>> and has been pushed to devel (to gitlab).
This seems fine now in Sylpheed (or should be any newsreader).
I now have checking in TWO places to make sure to NOT send if 'readonly' >>> is '1' for a section. Once when you try to post, and another time if for >>> some reason it gets past that, it will check again when trying to
actually feed it to the remote server.
This is logged in debug.log. I am still cleaning up reply codes so the
newsreader has a useful reply for it's logs (and debugging). So far I
have been unable to feed an article to a remote site if the section is
readonly.
If there are several sections with the same group, only a NON-readonly
section will allow it to be sent to remote. If there is no NON-readonly
section containing the group, posting will fail.
That sounds right. I plan to check it out this evening. It looks like
you merged 'devel' branch. Does that mean the changes are all in
'master' now?
No, they are still in devel, which is pushed to gitlab. I'm still
working
on making sure it doesn't try to push articles to remote when it should
not. It's a bit confusing mixing 'readonly', don't display in header, remote_server = '', etc. I'm trying to be careful to check the right
things
and not break something. I'm concerned that 'readonly' is not the
appropriate thing to check, it's specifically whether to push to remote
or
not. I'll need some more time to work on that part.
But the duplicate listings should be fixed in devel at this time.
On Mon, 14 Oct 2024 22:24:52 +0000, Retro Guy wrote:
On Mon, 14 Oct 2024 19:54:28 +0000, Byrl Raze Buckbriar wrote:
On Mon, 14 Oct 2024 12:19:53 +0000
Retro Guy <retroguy@novabbs.com> wrote:
On Mon, 14 Oct 2024 10:38:42 +0000, Retro Guy wrote:
On Mon, 14 Oct 2024 6:45:28 +0000, Byrl Raze Buckbriar wrote:
I am configuring and testing a Rocksolid Light peer to pull and archive >>>>>> 91 Usenet newsgroups, not counting the rocksolid groups.
4. The newsreader software (Sylpheed) shows three identical listings of >>>>>> each newsgroup in the group list. How may I resolve this to show only >>>>>> one copy of the group?
This identical listing issue should be fixed now. The fix is in cron.php >>>>> and has been pushed to devel (to gitlab).
This seems fine now in Sylpheed (or should be any newsreader).
I now have checking in TWO places to make sure to NOT send if 'readonly' >>>> is '1' for a section. Once when you try to post, and another time if for >>>> some reason it gets past that, it will check again when trying to
actually feed it to the remote server.
This is logged in debug.log. I am still cleaning up reply codes so the >>>> newsreader has a useful reply for it's logs (and debugging). So far I
have been unable to feed an article to a remote site if the section is >>>> readonly.
If there are several sections with the same group, only a NON-readonly >>>> section will allow it to be sent to remote. If there is no NON-readonly >>>> section containing the group, posting will fail.
That sounds right. I plan to check it out this evening. It looks like
you merged 'devel' branch. Does that mean the changes are all in
'master' now?
No, they are still in devel, which is pushed to gitlab. I'm still
working
on making sure it doesn't try to push articles to remote when it should
not. It's a bit confusing mixing 'readonly', don't display in header,
remote_server = '', etc. I'm trying to be careful to check the right
things
and not break something. I'm concerned that 'readonly' is not the
appropriate thing to check, it's specifically whether to push to remote
or
not. I'll need some more time to work on that part.
But the duplicate listings should be fixed in devel at this time.
Ok, I think I have it and I'm testing today on a test site.
Disabling "remote push" will be handled in overrides.inc.php:
// Disable pushing articles to remote server for these sections
// (replace 'testsection...' with your choice of sections)
'disable_remote_push' => array("testsectionone", "testsectiontwo"),
This should make it simple to toggle on or off, and not send stuff by
mistake because an admin forgets to toggle something like 'readonly',
etc. Plus, you may not want the section to be readonly.
Two things will disable pushing to remote:
1. Section found in overrides.inc.php (as above)
2. 'remote_server' => '',
This code is in send.php, so at the last point (where pushing actually happens as spoolnews.php does not send articles).
For now, I'm leaving the articles that might possibly appear in <spooldir>/<section>/outgoing (articles to be pushed) in that dir so we
can see what's happening. There probably WILL be articles there, but
that's fine. We just don't want them sent (once sent, they disappear
from that dir). Blocking a push is logged to debug.log.
The dir is pruned after a few days old articles. I'll remove them
immediately in a future release.
I hope to push this later today, unless I find a big issue. I'll post
back here to let you know.