I have applied a good percentage of vga-256 commits to rslight, thanks!

Unless I'm missing it, I think the commit:
* moved $ssl_dir setting to config.inc.php, which I see twice, does not revert
changes to nntp-ssl.php

Both commits seem to revert cron.php only.

I'm running the latest in a test vm, and have not pushed to github.com yet,
so no changes there atm.

--
Retro Guy

woops, absolutely correct - thanks! i forgot to add nntp-ssl.php to my git repo. just pushed it to my repo.

--
Posted on Rocksolid Light

[Bugfix for RSL user.php](https://github.com/novabbs/rocksolid-light/commit/8fd735aea70471eebbed8e337c40aefe5e75f35e)

Relevant part of the commit:

$userdata = unserialize(file_get_contents($userfile));
// critical: must check if array has data before trying to sort it (cannot sort null!)
if ($userdata)
ksort($userdata);
echo 'Configuration Saved for '.$_POST['username'];

--
Posted on Rocksolid Light

vga256 wrote:

> [Bugfix for RSL user.php](https://github.com/novabbs/rocksolid-light/commit/8fd735aea70471eebbed8e337c40aefe5e75f35e)

> Relevant part of the commit:

> $userdata = unserialize(file_get_contents($userfile));
> // critical: must check if array has data before trying to sort it (cannot sort null!)
> if ($userdata)
> ksort($userdata);
> echo 'Configuration Saved for '.$_POST['username'];

Thank you for this. I'll apply on my end.

--
Retro Guy

Cheers!

Tiny bugfix for newsportal.php - some typos in the use of PDOException:

https://github.com/vga-256/tomo-rslight/commit/4ee94a35cc74f705a95cad54aa0dd2d5840e0bf9

--
Posted on Rocksolid Light

vga256 wrote:

> Cheers!

> Tiny bugfix for newsportal.php - some typos in the use of PDOException:

Thanks again!

I "may" have copy/pasted those lines when creating those functions, lol :)

--
Retro Guy

Not really a bug, just something worth considering - currently there is no limit on username length, which gets kinda goofy when the usernames are stored in the filesystem as filenames.

https://github.com/novabbs/rocksolid-light/commit/354f100fffe6f0699132b7e047043c5872b8c07f

I hardcoded a limit of 30 characters, but this could easily be added as a config option.

--
Posted on Rocksolid Light

vga256 wrote:

> Not really a bug, just something worth considering - currently there is no limit on username length, which gets kinda goofy when the usernames are stored in the filesystem as filenames.

> https://github.com/novabbs/rocksolid-light/commit/354f100fffe6f0699132b7e047043c5872b8c07f

> I hardcoded a limit of 30 characters, but this could easily be added as a config option.

Good call. I will apply that here also.

NOTE: I plan in the future to move the users and userconfig dirs to a dir in /var in the future. It looks like newer Debians and maybe other linuxes may be moving toward disallowing writing in /etc by the web server in the future. Already 'touch' does not work from the log in script (function) in /etc. It does in var (I know because I do that on i2pn2.org).

It's a good idea anyway as /etc really shouldn't contain such things.

This will add a fourth rslight dir, and a new variable to contain it's location. I'll try to be very careful when I do this, and post here the changes. It won't be very soon, but eventually.

--
Retro Guy

> NOTE: I plan in the future to move the users and userconfig dirs to a dir in /var in the future. It looks like newer Debians and maybe other linuxes may be moving toward disallowing writing in /etc by the web server in the future. Already 'touch' does not work from the log in script (function) in /etc. It does in var (I know because I do that on i2pn2.org).

> It's a good idea anyway as /etc really shouldn't contain such things.

> This will add a fourth rslight dir, and a new variable to contain it's location. I'll try to be very careful when I do this, and post here the changes. It won't be very soon, but eventually.

Ha ha - we must be on the same wavelength, because I started moving scripts out of /etc last week :D

FWIW - I am now halfway to a working, granular, very simple RBAC-style permissions system. The admin can create roles (groups), which have permissions that can be added/removed at will. I wanted to continue with RSL's flatfile database approach, but doing a relational database this way was pretty gnarly. I resorted to sqlite3 against my desires, and it seems to be working fine. The back end is all built, and now I'm just building out the admin.php page so permissions/roles can be set and changed.

--
Posted on Rocksolid Light

On Fri, 14 Jul 2023 16:54:11 +0000
retro.guy@rocksolidbbs.com (Retro Guy) wrote:

> vga256 wrote:
>
> > Not really a bug, just something worth considering - currently
> > there is no limit on username length, which gets kinda goofy when
> > the usernames are stored in the filesystem as filenames.
>
> > https://github.com/novabbs/rocksolid-light/commit/354f100fffe6f0699132b7e047043c5872b8c07f
> >
>
> > I hardcoded a limit of 30 characters, but this could easily be
> > added as a config option.
>
> Good call. I will apply that here also.
>
> NOTE: I plan in the future to move the users and userconfig dirs to a
> dir in /var in the future. It looks like newer Debians and maybe
> other linuxes may be moving toward disallowing writing in /etc by the
> web server in the future. Already 'touch' does not work from the log
> in script (function) in /etc. It does in var (I know because I do
> that on i2pn2.org).
>
> It's a good idea anyway as /etc really shouldn't contain such things.
>
> This will add a fourth rslight dir, and a new variable to contain
> it's location. I'll try to be very careful when I do this, and post
> here the changes. It won't be very soon, but eventually.

Please ensure the installer can still choose custom path for install
directories. This is a vital feature for running on some system
configurations.

--

SugarBug | https://sybershock.com

Syber Shock wrote:

> On Fri, 14 Jul 2023 16:54:11 +0000
> retro.guy@rocksolidbbs.com (Retro Guy) wrote:

>> This will add a fourth rslight dir, and a new variable to contain
>> it's location. I'll try to be very careful when I do this, and post
>> here the changes. It won't be very soon, but eventually.

> Please ensure the installer can still choose custom path for install
> directories. This is a vital feature for running on some system
> configurations.

That's the plan. There may be an added dir, but they will all be
configurable at install.

--
Retro Guy

Retro Guy wrote:

> Syber Shock wrote:

>> On Fri, 14 Jul 2023 16:54:11 +0000
>> retro.guy@rocksolidbbs.com (Retro Guy) wrote:

>>> This will add a fourth rslight dir, and a new variable to contain
>>> it's location. I'll try to be very careful when I do this, and post
>>> here the changes. It won't be very soon, but eventually.

>> Please ensure the installer can still choose custom path for install
>> directories. This is a vital feature for running on some system
>> configurations.

> That's the plan. There may be an added dir, but they will all be
> configurable at install.

Hi Syber Shock. You also previously mentioned that your specfic setup
requires the use of different directories.

Since most of my experience is just with the plain shell and command line,
I'm not familiar working with hosting control panels. I'm guessing that
is what you are using. Please correct me if I'm wrong.

Anyway, my thought is that web stuff goes in /var/www
Spool in /var/spool
Config in /etc

Then I plan to take scripts and user data out of /etc (it never belonged there)
and move it to var. So maybe /var/rslight/bin /var/rslight/users ?

Thoughts anyone?

--
Retro Guy

On Sat, 15 Jul 2023 17:06:13 +0000
retro.guy@rocksolidbbs.com (Retro Guy) wrote:

> Retro Guy wrote:
>
> > Syber Shock wrote:
>
> >> On Fri, 14 Jul 2023 16:54:11 +0000
> >> retro.guy@rocksolidbbs.com (Retro Guy) wrote:
>
> >>> This will add a fourth rslight dir, and a new variable to contain
> >>> it's location. I'll try to be very careful when I do this, and
> >>> post here the changes. It won't be very soon, but eventually.
>
> >> Please ensure the installer can still choose custom path for
> >> install directories. This is a vital feature for running on some
> >> system configurations.
>
> > That's the plan. There may be an added dir, but they will all be
> > configurable at install.
>
> Hi Syber Shock. You also previously mentioned that your specfic setup
> requires the use of different directories.
>
> Since most of my experience is just with the plain shell and command
> line, I'm not familiar working with hosting control panels. I'm
> guessing that is what you are using. Please correct me if I'm wrong.
>
> Anyway, my thought is that web stuff goes in /var/www
> Spool in /var/spool
> Config in /etc
>
> Then I plan to take scripts and user data out of /etc (it never
> belonged there) and move it to var. So maybe /var/rslight/bin
> /var/rslight/users ?
>
> Thoughts anyone?
>

I would suggest a single directory under /var/ with subdirectories for
'config' and 'spool' and all rslight data and config dirs. I've always
preferred all files related to an application to be in one directory
rather than the Linux idea of kinds or classes of files irrespective of
the parent application. IMHO that's why we have symlinks. If one
application needs to be aware of the files of another, a directory
symlink could be in the common or file class location pointing to the
actual application folder.

In some panels the web root is under the user account for a domain so
it would look like this:

/home/$USER/web/domain.name/www/public_html

Then all the web files are owned by that user instead of www-data.
Otherwise a hole in the security would possibly allow www-data to
traverse to other domain web files. This is also useful for honeypot
tripwires as many fake users and their directories can be set up with
inotify watchers to lockout IPs and send alerts if any of their folders
or files are accessed.

In my case the web server can only access public_html. Neither the
server nor any of its spawn processes can access 'www'. Configuring it
to access the files that go in /var and /etc required some study and
config file foo.

--

SugarBug | https://sybershock.com

Syber Shock wrote:

> On Sat, 15 Jul 2023 17:06:13 +0000
> retro.guy@rocksolidbbs.com (Retro Guy) wrote:

>> Retro Guy wrote:
>>
>> > Syber Shock wrote:
>>
>> >> On Fri, 14 Jul 2023 16:54:11 +0000
>> >> retro.guy@rocksolidbbs.com (Retro Guy) wrote:
>>
>> >>> This will add a fourth rslight dir, and a new variable to contain
>> >>> it's location. I'll try to be very careful when I do this, and
>> >>> post here the changes. It won't be very soon, but eventually.
>>
>> >> Please ensure the installer can still choose custom path for
>> >> install directories. This is a vital feature for running on some
>> >> system configurations.
>>
>> > That's the plan. There may be an added dir, but they will all be
>> > configurable at install.
>>
>> Hi Syber Shock. You also previously mentioned that your specfic setup
>> requires the use of different directories.
>>
>> Since most of my experience is just with the plain shell and command
>> line, I'm not familiar working with hosting control panels. I'm
>> guessing that is what you are using. Please correct me if I'm wrong.
>>
>> Anyway, my thought is that web stuff goes in /var/www
>> Spool in /var/spool
>> Config in /etc
>>
>> Then I plan to take scripts and user data out of /etc (it never
>> belonged there) and move it to var. So maybe /var/rslight/bin
>> /var/rslight/users ?
>>
>> Thoughts anyone?
>>

> I would suggest a single directory under /var/ with subdirectories for
> 'config' and 'spool' and all rslight data and config dirs. I've always
> preferred all files related to an application to be in one directory
> rather than the Linux idea of kinds or classes of files irrespective of
> the parent application.

I think I agree with you here, as far as how I should default the install.
Everything in /var. This is how some other packages do it, and I see why.

I personally prefer the separation '/var/www' '/etc', etc. so I can do that
during install simply enough. Just that default be '/var'.

I do plan at some point in the future to make a Debian package, and that
can match Debian's dictates on directories. It should all work fine.

> IMHO that's why we have symlinks. If one
> application needs to be aware of the files of another, a directory
> symlink could be in the common or file class location pointing to the
> actual application folder.

I do find that some of my Linux installs do not allow some features to
write to '/etc/rslight/...' even when symlinked to '/var/something'. If I
move it to '/var/something', it works. I foundd this when writing and
implementing my rslight -> wordpress userbase syncing script.

--
Retro Guy

On Sun, 16 Jul 2023 15:10:12 +0000
retro.guy@rocksolidbbs.com (Retro Guy) wrote:

> > IMHO that's why we have symlinks. If one
> > application needs to be aware of the files of another, a directory
> > symlink could be in the common or file class location pointing to
> > the actual application folder.
>
> I do find that some of my Linux installs do not allow some features
> to write to '/etc/rslight/...' even when symlinked to
> '/var/something'. If I move it to '/var/something', it works. I
> foundd this when writing and implementing my rslight -> wordpress
> userbase syncing script.

The symlink issue illustrates one of the reasons I dislike the concept
of distros. I wish the Linux 'community' would just focus all their
effort on one universal solution that works the same across the board.
Of course this is wishful thinking.

All the many distros and versions of everything increase grunt work an
order of magnitude for everyone who tries to use the platform. There
are endless nags and snags to sort out. So most free software is not
really free, if you value your time.

--
SugarBug | https://sybershock.com

tiny update to rslight:

line 143 of spoolnews.php has an absolute path/filename for /etc/rslight/banned_names.conf

renamed this to:

$banned_names = file($user_ban_file, FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);

afterwards, i added the $user_ban_file variable to config.inc.php

--
Posted on Rocksolid Light

vga256 wrote:

> tiny update to rslight:

> line 143 of spoolnews.php has an absolute path/filename for /etc/rslight/banned_names.conf

Good catch. I used to do this often before deciding to make rslight available (it was just for one site for me). I thought I caught all the hard-coded paths by now, but I guess not, lol :)

> renamed this to:

> $banned_names = file($user_ban_file, FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);

> afterwards, i added the $user_ban_file variable to config.inc.php

I'll check this out.

Thanks!

--
Retro Guy

New commit to novabbs/rocksolid-light

Fix possible fatal article number error in remote_groupfile.

https://github.com/novabbs/rocksolid-light/commit/1b8f31fe34ac40c1a1d6bc0e012ca11a1963cffb7

Where <groupname>:<artnum> and 'artnum' is flawed in some way, spoolnews,php would crash. This commit checks that 'artnum' is_numeric, and if not, assigns '1', which allows spoolnews.php to continue and then write correct 'artnum' after this run.

--
Retro Guy

Retro Guy wrote:

> New commit to novabbs/rocksolid-light

> Fix possible fatal article number error in remote_groupfile.

> https://github.com/novabbs/rocksolid-light/commit/1b8f31fe34ac40c1a1d6bc0e012ca11a1963cffb7

> Where <groupname>:<artnum> and 'artnum' is flawed in some way, spoolnews,php would crash. This commit checks that 'artnum' is_numeric, and if not, assigns '1', which allows spoolnews.php to continue and then write correct 'artnum' after this run.

Fix link (I hope):

https://github.com/novabbs/rocksolid-light/commit/1b8f31fe34ac40c1a1d6bc0e012ca11a1963cffb

--
Retro Guy

Spent the past week on a Roles & Permissions system, as well as rewriting the Authentication system. I wish I could provide commits for these, but they're so wide-ranging that they really do require my tomo fork of RSLight.

Authentication:
If anyone's interested, I've migrated user creation, password, encyption key, pkey, e-mail address and verification storage all to an sqlite db. All authentication happens via the user database, and no longer uses ~/spoolnews/username to store user info in flat files.

Roles & Permissions:
All areas of the site can be assigned Permissions which check to see if the user has been assigned a role that allows them access to the area, or to run an action. Now it's possible to create moderators that can delete messages, co-sysops who can add/delete users, users with reading but no posting permissions, etc.

If anyone's interested in these commits, they're [over here](https://bitbucket.org/svga256/tomobbs/src/master/) over the past week or so. The file structure has been changed significantly to suit my own needs (e.g. most of the project runs from a single directory, and not all over the filesystem, now), and I've created a ./database folder to store user info. Merging this into RSL would also add all new installation steps (generating a SQL db, adding default users to it, etc), so it's probably not a good candidate for RSL.

That being said, these changes add a ton of configurability to the front end. I'm going to be moving all of the user.config stuff into the user sqlite db as well, over the next week.

--
Posted on Rocksolid Light

vga256 wrote:

> Spent the past week on a Roles & Permissions system, as well as rewriting the Authentication system. I wish I could provide commits for these, but they're so wide-ranging that they really do require my tomo fork of RSLight.

> Authentication:

> Roles & Permissions:

> If anyone's interested in these commits, they're [over here](https://bitbucket.org/svga256/tomobbs/src/master/) over the past week or so. The file structure has been changed significantly to suit my own needs (e.g. most of the project runs from a single directory, and not all over the filesystem, now), and I've created a ./database folder to store user info. Merging this into RSL would also add all new installation steps (generating a SQL db, adding default users to it, etc), so it's probably not a good candidate for RSL.

The feature list sounds great! tomo BBS should be a great choice for a site with thorough moderation tools. Glad to see it!

I did try to install today, but it did not work. Just in a VM, no risk to anything here.

I notice that the chosen install dirs in debian-install.sh are not written to common/config.inc.php. I needed to modify that file manually. Then it seems that no matter what directories you've chosen, $bbsroot_dir is hardcoded to be one level above the web dir, so what you choose in install doesn't really matter.

I did stop there for now as I believe you are working on more important features/tasks, and cleaning up install can wait. Just wanted to let you know my experience.

--
Retro Guy

I did try to install today, but it did not work. Just in a VM, no risk to anything here.

> I notice that the chosen install dirs in debian-install.sh are not written to common/config.inc.php. I needed to modify that file manually. Then it seems that no matter what directories you've chosen, $bbsroot_dir is hardcoded to be one level above the web dir, so what you choose in install doesn't really matter.

> I did stop there for now as I believe you are working on more important features/tasks, and cleaning up install can wait. Just wanted to let you know my experience.

Oh yikes haha! I haven't even touched or looked at the installer yet - that is an absolute final step for me. All of the values in the configuration files are hardcoded. I have to spend a day or two rewriting the installer to handle all of the new paths I've added, as well as make them system agnostic.

For now I'm focusing on building out core functionality. I'll put up a public test server somewhere so you can take it for a spin and see it in its current, broken, but feature-rich, state :)

--
Posted on Rocksolid Light

This is more of a cosmetic change to RSL, but I'll offer the commit here anyway: if you put empty text in the 'remote_server' and 'remote_port' fields of the configuration, you end up with a goofy filename in "/spoolnews/:.txt"

it took me weeks to figure out how that weird filename was ending up there every time i ran a cron job :D

Scroll down to spoolnews.php:

https://bitbucket.org/svga256/tomobbs/commits/d04226927317d4a44a55bcf7431501bb6acec1e8

--
Posted on Rocksolid Light

vga256 wrote:

> This is more of a cosmetic change to RSL, but I'll offer the commit here anyway: if you put empty text in the 'remote_server' and 'remote_port' fields of the configuration, you end up with a goofy filename in "/spoolnews/:.txt"

> it took me weeks to figure out how that weird filename was ending up there every time i ran a cron job :D

Thank you, I have implemented this change.

I was tempted to add a default for '$CONFIG['remote_port']' in config.inc.php, but decided against it. Just require it be set in config. I am 70% convinced I won't bother with that change, lol.

--
Retro Guy

Retro Guy wrote:

> vga256 wrote:

>> This is more of a cosmetic change to RSL, but I'll offer the commit here anyway: if you put empty text in the 'remote_server' and 'remote_port' fields of the configuration, you end up with a goofy filename in "/spoolnews/:.txt"

In addition to the mod above, we can add the following to line 28 in send.php to exit the script if there is no remote_server set (we don't want to 'send' anything):

if ($CONFIG['remote_server'] == '') {
exit();
}

In spoolnews.php, the following has been commented out (at line 201 in my copy):

// Broken message on last run? Let's try again.
/*
if($article > ($detail[3])) {
$article = $detail[3];
}
*/

This code fixed an old bug, but the bug no longer exists, and it was causing rslight to try to pull ONE message back everytime it polls the server. It would see it is a duplicate and no problem, but it's a waste of bandwith, and a waste of log file space.

--
Retro Guy