Anyway, hopefully this is enough to see it in action. Its annoying, but I guess I get why I dont see those messages alerts.
It also didnt show the message waiting status (M)?
Node Status
ÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
1 deon posting message via telnet (P) [UQ]
Anyway, hopefully this is enough to see it in action. Its annoying, but I guess I get why I dont see those messages alerts.
No, I don't really get it. Did you add lprintf() messages to sbbsecho.c like I suggested?
But I would expect the *.last.msg file to have the message
contents (after read/display to the user) as well.
Re: imsg on incoming echomail
By: Digital Man to deon on Sun Jan 19 2025 12:34 am
Howdy,
Anyway, hopefully this is enough to see it in action. Its annoying, but I guess I get why I dont see those messages alerts.
No, I don't really get it. Did you add lprintf() messages to sbbsecho.c like I suggested?
What dont you get?
No, I didnt modify sbbsecho.
But I think I've reproduced the scenario that results in me not getting the messages, that new echomail has come in addressed to me.
When I connected and saw that idle node still logged in, I used ;spy 1 to check to see if anything was displayed. I didnt expect anything to display since the 0001.msg file was blank (and nothing was).
And the fact that no *.msg files changed, means that the message was never sent nor consumed right?
Do you have custom message reading script or
shell or something that could be deleting the message without saving it to the *.last.msg chain?
Re: imsg on incoming echomail
By: Digital Man to deon on Sun Jan 19 2025 01:07 pm
Howdy,
Do you have custom message reading script or
shell or something that could be deleting the message without saving it to the *.last.msg chain?
No I have nothing that modifies the msg files - in fact "my" access to SBBS is via the default shell (Classic?) - and its all stock standard.
Anyway, lets see if I can get the SBBSecho log to show "Error x notifying recipient".
I realize you think you have evidence to the contrary, but I'm skeptical.
I would have expected something from the logging you added right?
Re: imsg on incoming echomail
By: deon to Digital Man on Mon Jan 20 2025 03:03 pm
I would have expected something from the logging you added right?
Only if there was an echomail message successfully imported and it was addressed to you (or one of your other BBS users). I'll add some more debug-level log messages to sbbsecho so it's obvious when messages are imported and whom each was addressed to.
I would have expected something from the logging you added right?
Only if there was an echomail message successfully imported and it was addressed to you (or one of your other BBS users). I'll add some more debug-level log messages to sbbsecho so it's obvious when messages are imported and whom each was addressed to.
addressed to you (or one of your other BBS users). I'll add some more debug-level log messages to sbbsecho so it's obvious when messages are imported and whom each was addressed to.
OK, updated.
OK, got something:
2025-01-21 15:07:54 PVT_TEST: User (deon #1) doesn't have read access to sub-board
Okay, that's a good find. What are the access requirements for the message group that the echo is in and the access and reading requirements for the sub-board (in SCFG)?
Okay, that's a good find. What are the access requirements for the message group that the echo is in and the access and reading requirements for the sub-board (in SCFG)?
Re: imsg on incoming echomail
By: Digital Man to deon on Mon Jan 20 2025 08:24 pm
Howdy,
Okay, that's a good find. What are the access requirements for the message group that the echo is in and the access and reading requirements for the sub-board (in SCFG)?
From msgs.ini:
[grp:0010:PVT]
description=PrivateNet
ars=PROT != IMAP AND PROT != IMAPS
[sub:0010:PVT:TEST]
description=Test Messages
ars=
read_ars=
post_ars=
operator_ars=
moderated_ars=
area_tag=PVT_TEST
What will be common, is the ars for IMAP:
ars=PROT != IMAP AND PROT != IMAPS
But that might not be it. I did used to have "ars=PROT NOT IMAP" before (which did nothing at the time).
So at some point you're probably connecting with IMAP[S] which sets your user account protocol to IMAP[S] and then disqualifies your account from reading the "PVT" message group. Removing those access restrictions would resolve the issue. I'll look into making a service option to not change the user protocol (something you could enable for IMAP and IMAPS to prevent this situation).
So sbbsecho thinks I dont have access to the sub board now - and no, I havent made any changes, havent run scfg/echocfg nor edited any of the config files.
-rw------- 1 root root 131 Jan 21 10:08 msgs/0001.last.msg
-rw------- 1 root root 71 Jan 20 21:54 msgs/0001.last.0.msg
-rw------- 1 root root 71 Jan 20 21:51 msgs/0001.last.1.msg
-rw-r--r-- 1 deon deon 30395 Jan 20 08:18 ctrl/sbbsecho.ini
-rw-r--r-- 1 deon deon 11398 Jan 10 14:06 ctrl/sbbs.ini
-rw-r--r-- 1 root root 147354 Jan 10 14:06 ctrl/msgs.ini
Are permissions an issue here? Looks like your *.msg files are being created by 'root', and sbbsecho.ini is owned by 'deon'. I don't think sbbsecho.ini would be able to read/post these messages properly if they're owned by 'root'.
No, my sync runs as root (inside a container), and I dont have selinux enabled.
Even if it's in a container, I imagine it's probably not a good idea to run a public-facing server as root.
deon wrote to Accession <=-
Re: Re: imsg on incoming echomail
By: Accession to deon on Tue Jan 21 2025 06:58 am
Are permissions an issue here? Looks like your *.msg files are being created by 'root', and sbbsecho.ini is owned by 'deon'. I don't think sbbsecho.ini would be able to read/post these messages properly if they're owned by 'root'.
No, my sync runs as root (inside a container), and I dont have selinux enabled.
But if it was a problem, (because it dropped privileges - which I dont have that set either), then I would expect the core issue to be consistently failing trying to update those files.
But...... why? Why run as root? Makes no sense, and is likely the
cause of the issue(s).
Digital Man wrote to Gamgee <=-
Re: Re: imsg on incoming echomail
By: Gamgee to deon on Tue Jan 21 2025 09:50 pm
But...... why? Why run as root? Makes no sense, and is likely the
cause of the issue(s).
We already identified the root (the "PROT" keyword in the access requirements to his message group excluded "IMAP") and provided a work-around. root or not was not an issue.
Sysop: | fluid |
---|---|
Location: | wickliffe, ohio |
Users: | 4 |
Nodes: | 10 (0 / 10) |
Uptime: | 196:50:43 |
Calls: | 52 |
Files: | 15,838 |
Messages: | 52,769 |