I can't figure this one out. This posting bug has been around for a long time, and it doesn't seem to happen on your server - only mine.

When I write a new post, the first post is always rejected. There is no NNTP error registered, yet post.php responds with "The Newsserver rejected the message:" (with no actual error afterwards).

I've checked articles-overview.dat, and the message is definitely being added to the sql database. But for some reason the NNTP server itself is failing somewhere along the way.

If I re-send the exact same message, I get the same error.

If I re-send the same message, but change ONE letter in the subject area (or add a space randomly somewhere in it), the message is accepted and posted.

Any ideas?

--
Posted on Rocksolid Light

vga256 wrote:

> I can't figure this one out. This posting bug has been around for a long time, and it doesn't seem to happen on your server - only mine.

> When I write a new post, the first post is always rejected. There is no NNTP error registered, yet post.php responds with "The Newsserver rejected the message:" (with no actual error afterwards).

Did it do this from the very first install, or only after modifications?

You may want to look in post.php and log the response from the news server here ($message):

// Article sent without errors, or duplicate?
if ((substr($message,0,3)=="240") ||
(substr($message,0,7)=="441 435")) {
echo '<h1 class="np_post_headline"><'.$text_post["message_posted"].'></h1>';
echo '<p>'.$text_post["message_posted2"].'</p>';
if(isset($CONFIG['auto_return']) && ($CONFIG['auto_return'] == true)) {
echo '<meta http-equiv="refresh" content="0;url='.$file_thread.'?group='.urlencode($returngroup[0]).'"';
}
if($CONFIG['rate_limit'] == true) {
$postsremaining = check_rate_limit($name,1);
echo 'You have '.$postsremaining.' posts remaining of '.$CONFIG['rate_limit'].' posts per hour.<br />';
if($postsremaining < 1) {
$wait = check_rate_limit($name,0,1);
echo 'Please wait '.round($wait).' minutes before posting again.<br />';
}
}
// echo '<p><a href="'.$file_thread.'?group='.urlencode($returngroup[0]).'">'.$text_post["button_back"].'</a> '.$text_post["button_back2"].' '.group_display_name($returngroup[0]).'</p>';
if(isset($_REQUEST['returngroup']) && $_REQUEST['returngroup'] !== '') {
echo '<p><a href="'.$file_thread.'?group='.$_REQUEST['returngroup'].'">Your post will appear in '.group_display_name($_REQUEST['returngroup']).'</a></p>';
}
if(isset($_SESSION['return_page'])) {
echo '<p><a href="'.$_SESSION['return_page'].'">Back to Previous Page</a></p>';
} else {
echo '<p><a href="'.$file_thread.'?group='.$_REQUEST['returngroup'].'">Back</a></p>';
}
} else {
// article not accepted by the newsserver
$type="retry";
$error=$text_post["error_newsserver"]."<br><pre>$message</pre>";
}

> I've checked articles-overview.dat, and the message is definitely being added to the sql database. But for some reason the NNTP server itself is failing somewhere along the way.

Does the article appear normally (as if posted properly)?

> If I re-send the exact same message, I get the same error.

> If I re-send the same message, but change ONE letter in the subject area (or add a space randomly somewhere in it), the message is accepted and posted.

This one is most likely due to the message-id. Since it is created based on headers and body, an exact duplicate will fail as a 'Duplicate' message. Changing any one thing will generate a different message-id.

--
Retro Guy

Retro Guy wrote:

> Did it do this from the very first install, or only after modifications?

I wish I remembered - I think I've been politely tolerating it for a month, but it might have been from a recent change.

> You may want to look in post.php and log the response from the news server here ($message):

I should have included this in my earlier post. Yes, I logged $message and all server responses from beginning to end in the posting process, in various files. Whenever the post fails, echoing $message is completely empty - nothing.
If I use print_r($message), I get a "1". That's it - it just stores a 1. So I imagine the server response is getting filled with a "true" earlier as $ns produces output in newsportal.php, instead of actual 2xx,3xx,4xx nntp responses? Just thinking out loud.

> Does the article appear normally (as if posted properly)?

No, it never appears at all in the front end - just as stored data in the overview db.

> This one is most likely due to the message-id. Since it is created based on headers and body, an exact duplicate will fail as a 'Duplicate' message. Changing any one thing will generate a different message-id.

Ah haaa... I didn't realize that. At least that's one part of the mystery solved.

Thanks for the help. I'm going to debug some more today and pin this down. It's been a real pain.

--
Posted on Rocksolid Light

It has taken two days, but I think I've pinned down where the problem is originating from. I just don't know what the underlying cause is yet.

rslight-lib.php:

foreach($grouplist as $findgroup) {
$name = explode(':', $findgroup);
if (strcmp($name[0], $nntp_group) == 0) {
if (is_numeric($name[1]))
$local = $name[1];
else {
$ok_article = get_article_list($nntp_group);
sort($ok_article);
$local = $ok_article[key(array_slice($ok_article, -1, 1, true))];
if(!is_numeric($local))
$local = 0;
$local = $local + 1;
}
break;
}
}
if($local < 1)
$local = 1;
if($article_date > time())
$article_date = time();
$in_file=fopen($filename, 'r');
while(is_file($grouppath."/".$local)) {
$local++;
}
$out_file=fopen($grouppath."/".$local, 'w+');
$header=1;
while($buf=fgets($in_file)) {
if((trim($buf) == "") && ($header == 1)) {
$buf="Xref: ".$CONFIG['pathhost']." ".$nntp_group.":".$local;
fputs($out_file, rtrim($buf, "nr").PHP_EOL);
$xref_i=$buf;
$buf="";
$header=0;
}
fputs($out_file, rtrim($buf, "nr").PHP_EOL);
}
fputs($out_file, "n.n");
fclose($out_file);
fclose($in_file);
touch($grouppath."/".$local, $article_date);

This hunk of code is meant to increment the article number in $local. After logging the hell out of it, I realized that $local is not being incremented properly. It is only getting incremented *every other post*. E.g.
First message I post: body/name/subject/date, gets message ID of "1". -> I click submit, the article is posted correctly.
Second message I post: body/name/subject/date, SUPPOSED to get message ID of "2", but gets a "1"! -> I click submit, nothing happens. Is this a silent SQL INSERT failure because the article numbers are identical for two rows?

--
Posted on Rocksolid Light

Narrowed down to this exact loop where the $local message number is incremented:

while(is_file($grouppath."/".$local)) {
$local++;
}

--
Posted on Rocksolid Light

More info:

/spoolnews/section.group-articles.db3: 13 messages (correct and up to date)
/spoolnews/articles-overview.db3: 13 messages (correct and up to date)
/spoolnews/section.group-info.txt: 12 messages (incorrect, one behind)
/spoolnews/articles/section/group/* : 12 messages (incorrect, one behind)

So that suggests to me the article is making it into the SQL databases correctly, but *not* getting written into the article directory.

--
Posted on Rocksolid Light

I can now post successfully on the first try, but I don't like my fix:

rslight-lib.php:

.....

//DEBUG TESTING - why is this unlinked?
//unlink($grouppath."/".$local);
$article_dbh = null;
}

By commenting out the file deletion, the new article now sits in /articles/section/group/, with the correct article number as the filename. the articles directory now has the same number of articles as the sqlite db's.

By commenting this out, have I fundamentally broken something with the way RSL works? The relationship between the sqlite db and the flat file articles is frustratingly complex at times.

--
Posted on Rocksolid Light

vga256 wrote:

> I can now post successfully on the first try, but I don't like my fix:

> rslight-lib.php:

> .....

> //DEBUG TESTING - why is this unlinked?
> //unlink($grouppath."/".$local);
> $article_dbh = null;
> }

> By commenting out the file deletion, the new article now sits in /articles/section/group/, with the correct article number as the filename. the articles directory now has the same number of articles as the sqlite db's.

> By commenting this out, have I fundamentally broken something with the way RSL works? The relationship between the sqlite db and the flat file articles is frustratingly complex at times.

Sorry, my brain is only partially functional this week.

Commenting the line out shouldn't break anything, but it will result in excess disk space being used. If you are running 'article_database' == '1' in config, you save all articles to a sqlite database, else you are running tradspool and need to retain the article (don't unlink). This is in an if statement:
if($CONFIG['article_database'] == '1') {

This looks like a holdover from original tradspool only:
while(is_file($grouppath."/".$local)) {
$local++;
}
I'll have to look more into that, but it will be a day or two.

Have you made any changes that rely on that file existing and containing an article?

--
Retro Guy

Retro Guy wrote:

> Sorry, my brain is only partially functional this week.

No apologies - look after your health - this is just fun stuff I get to bash my brain against until it works :)

> Commenting the line out shouldn't break anything, but it will result in excess disk space being used. If you are running 'article_database' == '1' in config, you save all articles to a sqlite database, else you are running tradspool and need to retain the article (don't unlink). This is in an if statement:
> if($CONFIG['article_database'] == '1') {

OK that's interesting. I do have article_database = 1 in my config, suggesting that it should be database-only. But it is most definitely adding articles to the local tradspool storage anyway. In fact,

while(is_file($grouppath."/".$local)) {
$local++;
}

the above lines determine what the next article number will be, regardless of whether you're running tradspool or article_database. They count the next article number based on the tradspool article count even if you're not running tradspool. I don't know if this was intended behaviour, or a holdover from earlier versions of the script when the database didn't exist yet.

(I also have no idea why my server was seemingly fine for a month, and then I suddenly started seeing problems with this approach, but I'll leave that for now.)

> This looks like a holdover from original tradspool only:
> while(is_file($grouppath."/".$local)) {
> $local++;
> }
> I'll have to look more into that, but it will be a day or two.

Thanks - no rush.

> Have you made any changes that rely on that file existing and containing an article?

To my knowledge, no other changes to the storage/retrieval system. The only thing I've done that could be related is implementing article and group deletion, but those both use existing functions (which I borrowed from the article db import script) to pull that off. They correctly zero-out databases, and reset post numbers.

--
Posted on Rocksolid Light

vga256 wrote:

> Retro Guy wrote:

> OK that's interesting. I do have article_database = 1 in my config, suggesting that it should be database-only. But it is most definitely adding articles to the local tradspool storage anyway. In fact,

> while(is_file($grouppath."/".$local)) {
> $local++;
> }

> the above lines determine what the next article number will be, regardless of whether you're running tradspool or article_database. They count the next article number based on the tradspool article count even if you're not running tradspool. I don't know if this was intended behaviour, or a holdover from earlier versions of the script when the database didn't exist yet.

It is definitely a holdover from the original tradspool only setup. Since the $local article number is determined before this here:
$ok_article = get_article_list($nntp_group);
sort($ok_article);
$local = $ok_article[key(array_slice($ok_article, -1, 1, true))];

The 'while' loop should hopefully never happen. I should have carefully removed that in the past, but yes, there are holdover features from tradspool only.

> (I also have no idea why my server was seemingly fine for a month, and then I suddenly started seeing problems with this approach, but I'll leave that for now.)

Some minor thing must have been changed, but I can't immediately see what it might be (digging through your repo atm)

> By commenting this out, have I fundamentally broken something with the way RSL works? The relationship between the sqlite db and the flat file articles is frustratingly complex at times.

> /spoolnews/section.group-articles.db3: 13 messages (correct and up to date)
This is the actual articles in the group.

> /spoolnews/articles-overview.db3: 13 messages (correct and up to date)
This is the overview for all articles on the system.

> /spoolnews/section.group-info.txt: 12 messages (incorrect, one behind)
Created and maintained by newsportal code.

<$spooldir>/<group>-overview
Flat file containing overview for the group.

<$spooldir>/articles/<group>/$
Article storage for tradspool, but 'article_database' writes the article there for temporary use, then deletes it when finished posting it (rslight-lib.php:1155):

$this_article = file_get_contents($grouppath."/".$local);
$article_stmt->execute([$nntp_group, $local, $mid_i, $article_date, $from_i, $subject_i, trim($this_article), $this_snippet]);
unlink($grouppath."/".$local);

It's difficult to see how this file disappearing at this location can cause an auth error (or whatever the error is). This file has been deleted ever since rslight started supporting sqlite.

I'm sure you've tried, but it would be great to see a more complete error displayed.

BTW, not sure if you are aware, but if you write a semaphore file in $config_dir, all php messages will display, and you can check for the file for any other DEBUG info you want displayed. Then, you could leave some debug lines in the code, but they won't do anything without the file (so no effect on users)

Create $config_dir/DEBUG to do this.

--
Retro Guy

More thoughts:

When attempting to post, are you authenticating a username, or using the anonymous user?

Is there a difference between trying the two?

Is it possible that $spooldir.'/keys.dat' is expiring? That should really cause a login failure, but does it do so properly? As I'm sure you've found, the 'keys' in that file rotate (in cron.php, 'rotate_keys'), so that old or spoofed cookies will not work to log in. What happens if you run (just for a test) cron.php regulary for a bit?

--
Retro Guy

So after hours of testing, here where I'm at:

Here's the behaviour:

I have a completely empty group, with nothing in the article database and nothing in the tradspool/articles folder. I post the first message in the group. The articles-db3 gets INSERTed with the article, and the article is assigned a "number" of 1. **Tradspool remains empty because the article has been unlinked.** (this is important - because it leads to the bug).

Now for round two - and this is when the bug shows up. I create a second message, hit post. This time, when I post to exactly the same group, the message is rejected. This time, the new message is added to tradspool, but NOT to the articles database. This is because the sqlite query is failing silently. (More on that later).

I get exactly 50% posting reliability in a tick-tock progression: first message is rejected without a visible error from the NNTP server, and when re-submitted (with non-identical text to get past the duplicate post detector) second message is accepted.

The behaviour is perfectly consistent. When unlink($grouppath."/".$local); is commented out, I get 100% posting reliability without exception.

There are *no* PHP errors present in the process, yielded by the presence DEBUG file as you recommended. There are no *visible* errors on the client side, because all of the SQL queries (and their errors) made in rslight-lib.php are pushed to the NNTP daemon's message buffer, which I've never figured out how to monitor from the outside. That's a minor problem.

The cause:

The cause of the posting bug is that function insert_article() searches spool/articles/section/group/article#. If the tradspool folder is empty, it assigns a message "number" 1 to the first message. This is stored in $local. $local is later used as the sql query's article # when it INSERTs into the "number" column, for the articles table in the articles databases. Message 1 is added to the SQL database. Message 1 is *THEN UNLINKED* from tradspool/articles/
This is fine....

... until:

Message #2 is written and I hit post. This time, insert_article() searches tradspool/articles/article#. It's an empty folder once again, so it assigns #1 to the article number in $local. The SQL query feeds INSERT INTO the articles database with an article number of 1. The SQL database has a shitfit because we're trying to insert duplicate data, and fails silently. In fact, it fails so spectacularly that the PHP stops execution right at the sql->execute instruction:
$article_stmt->execute([$nntp_group, $local, $mid_i, $article_date, $from_i, $subject_i, trim($this_article), $this_snippet, $userid]);

The script never gets to the line where it is supposed to delete tradspool/rocksolid/somegroup/article1. The file just sits there.

Message #3 is written. This time, insert_article() searches tradspool, and sees one article in there. It assigns a 2 to $local because that's the next free article number. SQL query has no problem inserting article #2.

The cause is mixing tradspool and sql logic. They need to be separated.

So, why am I getting this behaviour and you and no one else is? I have no idea. I don't think that even matters. The article database should *never ever* depend upon the article count in /tradspool/articles to determin the next article number for the database. The article number for the database should *only* come from an SQL query to the table, which asks what next unique article number is available.

--
Posted on Rocksolid Light

I've cleaned an install (deleted everything in spool) and will try to duplicate.

I do agree completely that we should no be using the tradspool article file or number at all in sqlite systems (it's a holdover from tradspool only), so I'm looking at 'function insert_article' in rslight-lib.php to rewrite it. I can quickly see just from a brief glance that it needs work.

I will try to get that done tonight and early tomorrow, and using sqlite data for sqlite systems.

--
Retro Guy

Hopefully it can be duplicated. I'd be embarrassed if this was due to some goofup on my end with deleting a line or missing a paren months ago.

Either way, yes - the logic in that function needs some rethinking. Splitting it into two different logical branches - if (usingTradspool) and if (usingArticleDatabase), would make sense to me.

--
Posted on Rocksolid Light

Retro Guy wrote:

> I've cleaned an install (deleted everything in spool) and will try to duplicate.

I tested using this install (clean spool, no .db3's, no article files, etc.). I posted the first article to a group 'local.test' and it worked. Then I posted another article to the same group and it also worked. With this test I was unfortunately not able to duplicate the issue.

> I do agree completely that we should no be using the tradspool article file or number at all in sqlite systems (it's a holdover from tradspool only), so I'm looking at 'function insert_article' in rslight-lib.php to rewrite it. I can quickly see just from a brief glance that it needs work.

> I will try to get that done tonight and early tomorrow, and using sqlite data for sqlite systems.

I still want to rewrite this function, and will work on this as mentioned above. Mainly to fully separate tradspool and sqlite stuff.

I'll post here when I believe it's complete.

--
Retro Guy

Retro Guy wrote:

> I tested using this install (clean spool, no .db3's, no article files, etc.). I posted the first article to a group 'local.test' and it worked. Then I posted another article to the same group and it also worked. With this test I was unfortunately not able to duplicate the issue.

Damn. I guess I've made some kind of tiny change along the way that woke this up.

> I still want to rewrite this function, and will work on this as mentioned above. Mainly to fully separate tradspool and sqlite stuff.

Sounds good.

fwiw, if you want to poke around and see what additions i've been making to RSL with tomo, i have a demo site up and running at http://tomo.dialup.cafe
admin account: sysop/sysop
unprivileged user account: malik/1234

Lots of stuff unfinished and borked, but it's functional enough to give you an idea of where I'm aiming with the permissions and roles features.

--
Posted on Rocksolid Light

On Sun, 23 Jul 2023 01:38:47 +0000
vga@vga256.com (vga256) wrote:

> Retro Guy wrote:
>
> > I tested using this install (clean spool, no .db3's, no article
> > files, etc.). I posted the first article to a group 'local.test'
> > and it worked. Then I posted another article to the same group and
> > it also worked. With this test I was unfortunately not able to
> > duplicate the issue.
>
> Damn. I guess I've made some kind of tiny change along the way that
> woke this up.
>
> > I still want to rewrite this function, and will work on this as
> > mentioned above. Mainly to fully separate tradspool and sqlite
> > stuff.
>
> Sounds good.
>
> fwiw, if you want to poke around and see what additions i've been
> making to RSL with tomo, i have a demo site up and running at
> http://tomo.dialup.cafe admin account: sysop/sysop unprivileged user
> account: malik/1234
>
> Lots of stuff unfinished and borked, but it's functional enough to
> give you an idea of where I'm aiming with the permissions and roles
> features.

It looks like you are pushing the design in a good direction. A lot of
people really get worn out by backend-only configurations. Having GUI
forms lowers the bar to entry and lessens friction.

Keep coding and carry on.

SugarBug | https://sybershock.com

Syber Shock wrote:

> On Sun, 23 Jul 2023 01:38:47 +0000
> vga@vga256.com (vga256) wrote:

>> Retro Guy wrote:
>>
>> > I tested using this install (clean spool, no .db3's, no article
>> > files, etc.). I posted the first article to a group 'local.test'
>> > and it worked. Then I posted another article to the same group and
>> > it also worked. With this test I was unfortunately not able to
>> > duplicate the issue.
>>
>> Damn. I guess I've made some kind of tiny change along the way that
>> woke this up.
>>
>> > I still want to rewrite this function, and will work on this as
>> > mentioned above. Mainly to fully separate tradspool and sqlite
>> > stuff.
>>
>> Sounds good.
>>
>> fwiw, if you want to poke around and see what additions i've been
>> making to RSL with tomo, i have a demo site up and running at
>> http://tomo.dialup.cafe admin account: sysop/sysop unprivileged user
>> account: malik/1234
>>
>> Lots of stuff unfinished and borked, but it's functional enough to
>> give you an idea of where I'm aiming with the permissions and roles
>> features.

> It looks like you are pushing the design in a good direction. A lot of
> people really get worn out by backend-only configurations. Having GUI
> forms lowers the bar to entry and lessens friction.

I agree, tomoBBS is looking great so far!

If I could only do backend, I'd be happy, lol. I find frontend a chore
and backend where the fun is.

--
Retro Guy

vga256 wrote:

> Retro Guy wrote:

>> I tested using this install (clean spool, no .db3's, no article files, etc.). I posted the first article to a group 'local.test' and it worked. Then I posted another article to the same group and it also worked. With this test I was unfortunately not able to duplicate the issue.

> Damn. I guess I've made some kind of tiny change along the way that woke this up.

I think I see how it happens. It does not happen on my sites, but I think I see why it happens. Not sure it's specifically due to tradspool stuff.

Basically, any error in 'insert_article' that breaks out of the function will end up returning '441' (posting failed), even if the error was after the posting succeeded.

I have now created a commit to address this, and also separating tradspool/sqlite code in rslight-lib.php.

In 'process_post', where 'insert_article' is called, the NNTP response is now retrieved from the return value of 'insert_article'. This does not guarantee that it will always be correct if there is a failure in 'insert_article', but I've added logging (to $spooldir/log/nntp.log) to hopefully help find the problem.

I am running this now on www.rocksolidbb.com and it seems ok. Of course I did testing on a test site first.

The commit has one changed file, 'rslight-lib.php' with two changed functions, 'process_post' and 'insert_article'. It is here:

https://github.com/novabbs/rocksolid-light/commit/f00596a520555c3a0bbeb3cb180e73d0f34d21ee

Note, to see php errors from nntp.php, I run it from the command line (cd $webdir/spoolnews; php $config_dir/scripts/nntp.php). Then when I try to post, I can usually see specifically what may have failed if it's a php error. Note, if you modify rslight-lib.php, you need to restart nntp.php.

--
Retro Guy

Retro Guy wrote:

>> It looks like you are pushing the design in a good direction. A lot of
>> people really get worn out by backend-only configurations. Having GUI
>> forms lowers the bar to entry and lessens friction.

> I agree, tomoBBS is looking great so far!

> If I could only do backend, I'd be happy, lol. I find frontend a chore
> and backend where the fun is.

Glad there is some value in these changes. While I'm (selfishly) trying to make tomo its own thing, I hope that some of the front-end stuff eventually makes its way into RSL. I'm extremely lazy, and if I can do something with 3 clicks rather than dropping to the CLI, I'll do it in a nanosecond :D

That being said, because I've made some changes to the back end to support the front end (e.g. the entire User accounts system runs on sqlite now), I have limited options to offering PRs for RSL. It's really hard maintaining changes across two completely separate code branches, so I kinda gave up doing that :

I'm happy to work on both front and back end stuff, but my preference is always front-end first. I begrudgingly make back-end changes when they're necessary.

--
Posted on Rocksolid Light

Retro Guy wrote:

> I think I see how it happens. It does not happen on my sites, but I think I see why it happens. Not sure it's specifically due to tradspool stuff.
> Basically, any error in 'insert_article' that breaks out of the function will end up returning '441' (posting failed), even if the error was after the posting succeeded.

> I have now created a commit to address this, and also separating tradspool/sqlite code in rslight-lib.php.

> In 'process_post', where 'insert_article' is called, the NNTP response is now retrieved from the return value of 'insert_article'. This does not guarantee that it will always be correct if there is a failure in 'insert_article', but I've added logging (to $spooldir/log/nntp.log) to hopefully help find the problem.

> I am running this now on www.rocksolidbb.com and it seems ok. Of course I did testing on a test site first.

I've implemented the changes - thank you - the extra debugging information I get from the NNTP server is really helpful for understanding what is happening. It yielded exactly the error I described that I had suspected all along, but could only guess at its exact output:

PHP Fatal error: Uncaught PDOException: SQLSTATE[23000]: Integrity constraint violation: 19 UNIQUE constraint failed: articles.number in /Users/tomo/tomobbs/admintools/rslight-lib.php:1182

At least this can help me debug what's causing the article numbering error. I'll start digging into get_article_list() to see how it determines article numbering, and where I might be having a problem.

--
Posted on Rocksolid Light

LOL. I spoke too soon.

I *improperly* implemented your changes. If you can believe it, I mistyped:
if (!is_numeric($local))

and put in:
if (is_numeric($local))

which of course broke article numbering. With that stupid typo fixed, it all works perfectly now. Thank you again for the hard work refactoring this function.

--
Posted on Rocksolid Light

vga256 wrote:

> LOL. I spoke too soon.

> I *improperly* implemented your changes. If you can believe it, I mistyped:
> if (!is_numeric($local))

> and put in:
> if (is_numeric($local))

> which of course broke article numbering. With that stupid typo fixed, it all works perfectly now. Thank you again for the hard work refactoring this function.

YAY! I'm glad it's working!

Now I can get back to very slowly considering the best way to execute the Mail features. I believe I have the structure, now to implement piece by piece in a way that I hopefully don't need to make major changes to it.

> Glad there is some value in these changes. While I'm (selfishly) trying to make tomo its own thing, I hope that some of the front-end stuff eventually makes its way into RSL.

I do plan to implement, but not right away. I'd like to get Mail working, then consider the best way to add such features to the rslight fork. I'm not opposed to the userbase being in a sqlite db, but I do a lot of cross-auth with rslight for things like inn2, wordpress, apache2, etc. I have written scripts to allow these programs to authenticate against rslight, so I need to be careful to make sure they will still work with minor changes.

--
Retro Guy

Retro Guy wrote:

> Now I can get back to very slowly considering the best way to execute the Mail features. I believe I have the structure, now to implement piece by piece in a way that I hopefully don't need to make major changes to it.

Awesome. Site-to-site mail will be a game-changer. I'm excited about the technical side of it too, because I can learn a lot about how to properly cryptographically sign stuff, check keys against it, etc.

> I do plan to implement, but not right away. I'd like to get Mail working, then consider the best way to add such features to the rslight fork. I'm not opposed to the userbase being in a sqlite db, but I do a lot of cross-auth with rslight for things like inn2, wordpress, apache2, etc. I have written scripts to allow these programs to authenticate against rslight, so I need to be careful to make sure they will still work with minor changes.

Ah ha ha... now that makes a lot of sense. I was wondering why it was still relying upon a flatfile. I realized, a little too late after I started, that I could have added branching logic to let the user select between flat-file database calls, and sqlite database calls, for user management.

--
Posted on Rocksolid Light

vga256 wrote:

> Retro Guy wrote:

>> Now I can get back to very slowly considering the best way to execute the Mail features. I believe I have the structure, now to implement piece by piece in a way that I hopefully don't need to make major changes to it.

> Awesome. Site-to-site mail will be a game-changer. I'm excited about the technical side of it too, because I can learn a lot about how to properly cryptographically sign stuff, check keys against it, etc.

I now have rslight setup to automatically create a server key, and make it available (it can be downloaded by a link). This key (not link) will reside in the same keyring as NoCeM keys, so the plan is that all rslight gpg is done in $config_dir/.gnupg . To manually manipulate keys in this keyring, change to the user that runs rslight, then set GNUPGHOME to $config_dir/.gnupg . Now you can work with keys manually using gpg.

Right now $config_dir/.gnupg is hard coded, but we can change that if necessary.

I'll work now on generating a post to advertise this key over the network, and give instructions to either automatically install the key, or manually. This would be determined by each site's admin. The group I plan to use is rocksolid.shared.encryption. That group already exists, and is named appropriately. I'd rather not create a new group that other servers don't add for a year if there is already one that is somewhat available on a few of the popular text only servers out theere now.

Both of the above are handled automatically in cron.php, using a timer so as to send the advertisement out probably monthly.

This will all take some time, as I don't want to rush it and then rewrite it and rewrite it again :)

--
Retro Guy