Hiya DM....
Seems as if there is an issue with the new version.
If I send sbbsecho a %-ALL it process it fine and sends back a list of each sub removed.
I then send it a %+ALL and I get back: No Changes made plus, it changes the permission of the areas.bbs to root:root and just a read access plus this is what the log says...
02-27-17 02:10:00 Importing /home/pi/sbbs/sportnet/secure/58b3d0aa.pkt (Type 2+, 0.3KB) from 24:100/1 to 24:24/1
02-27-17 02:10:00 Bill McGarrity (24:100/1) To: AREAFIX (24:24/1)
02-27-17 02:10:00 Areafix Request received from 24:100/1
02-27-17 02:10:00 ERROR 2 (No such file or directory) line 1077 opening
02-27-17 02:10:00 ERROR 2 (No such file or directory) line 1077 opening
02-27-17 02:10:00 ERROR 2 (No such file or directory) line 1077 opening
Digital Man wrote to Bill McGarrity on 02-27-17 00:01 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Mon Feb 27 2017 02:24 am
Hiya DM....
Seems as if there is an issue with the new version.
There were no recent changes in relation to the problems you reported below.
If I send sbbsecho a %-ALL it process it fine and sends back a list of each sub removed.
I then send it a %+ALL and I get back: No Changes made plus, it changes the permission of the areas.bbs to root:root and just a read access plus this is what the log says...
That sounds like you're running SBBSecho as "root". Are you?
02-27-17 02:10:00 Importing /home/pi/sbbs/sportnet/secure/58b3d0aa.pkt (Type 2+, 0.3KB) from 24:100/1 to 24:24/1
02-27-17 02:10:00 Bill McGarrity (24:100/1) To: AREAFIX (24:24/1)
02-27-17 02:10:00 Areafix Request received from 24:100/1
02-27-17 02:10:00 ERROR 2 (No such file or directory) line 1077 opening
Is that an imcomplete error message or is the listpath (after the "opening" verb) actually blank?
02-27-17 02:10:00 ERROR 2 (No such file or directory) line 1077 opening
02-27-17 02:10:00 ERROR 2 (No such file or directory) line 1077 opening
These looks like incomplete log lines or you have smoething wrong with
the "echolist:" sections in your sbbsecho.ini file?
Digital Man wrote to Bill McGarrity on 02-27-17 00:01 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Mon Feb 27 2017 02:24 am
Hiya DM....
Seems as if there is an issue with the new version.
There were no recent changes in relation to the problems you reported below.
If I send sbbsecho a %-ALL it process it fine and sends back a list of each sub removed.
I then send it a %+ALL and I get back: No Changes made plus, it changes the permission of the areas.bbs to root:root and just a read access plus this is what the log says...
That sounds like you're running SBBSecho as "root". Are you?
Nope...
02-27-17 02:10:00 Importing /home/pi/sbbs/sportnet/secure/58b3d0aa.pkt (Type 2+, 0.3KB) from 24:100/1 to 24:24/1
02-27-17 02:10:00 Bill McGarrity (24:100/1) To: AREAFIX (24:24/1)
02-27-17 02:10:00 Areafix Request received from 24:100/1
02-27-17 02:10:00 ERROR 2 (No such file or directory) line 1077 opening
Is that an imcomplete error message or is the listpath (after the "opening" verb) actually blank?
That's exactly the line as it showed in the log. When I run sbbsecho I create an error.log just in case there are issues such as this. This is the output.
02-27-17 02:10:00 ERROR 2 (No such file or directory) line 1077 opening
02-27-17 02:10:00 ERROR 2 (No such file or directory) line 1077 opening
These looks like incomplete log lines or you have smoething wrong with the "echolist:" sections in your sbbsecho.ini file?
I just shortened the log being there are 97 subs and there were 97 Error messages then the end.
I just deleted the additional echolist from sbbsecho.ini and sent an %+all areafix and it changed the areas.bbs back to root:root again.
Here is the inmail.sh (also set as pi:pi) I run when for incoming mail...
Digital Man wrote to Bill McGarrity on 02-27-17 15:25 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Mon Feb 27 2017 11:26 am
Digital Man wrote to Bill McGarrity on 02-27-17 00:01 <=-
Is that an imcomplete error message or is the listpath (after the "opening" verb) actually blank?
That's exactly the line as it showed in the log. When I run sbbsecho I create an error.log just in case there are issues such as this. This is the output.
02-27-17 02:10:00 ERROR 2 (No such file or directory) line 1077 opening
02-27-17 02:10:00 ERROR 2 (No such file or directory) line 1077 opening
These looks like incomplete log lines or you have smoething wrong with the "echolist:" sections in your sbbsecho.ini file?
I just shortened the log being there are 97 subs and there were 97 Error messages then the end.
I just deleted the additional echolist from sbbsecho.ini and sent an %+all areafix and it changed the areas.bbs back to root:root again.
Here is the inmail.sh (also set as pi:pi) I run when for incoming mail...
It doesn't matter what the owner of inmail.sh is, it matters who the current user is when that script is run. It sounds like you're running inmail.sh as root, at least sometimes.
Digital Man wrote to Bill McGarrity on 02-27-17 15:25 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Mon Feb 27 2017 11:26 am
Digital Man wrote to Bill McGarrity on 02-27-17 00:01 <=-
Is that an imcomplete error message or is the listpath (after the "opening" verb) actually blank?
That's exactly the line as it showed in the log. When I run sbbsecho I create an error.log just in case there are issues such as this. This is the output.
02-27-17 02:10:00 ERROR 2 (No such file or directory) line 1077 opening
02-27-17 02:10:00 ERROR 2 (No such file or directory) line 1077 opening
These looks like incomplete log lines or you have smoething wrong with the "echolist:" sections in your sbbsecho.ini file?
I just shortened the log being there are 97 subs and there were 97 Error messages then the end.
I just deleted the additional echolist from sbbsecho.ini and sent an %+all areafix and it changed the areas.bbs back to root:root again.
Here is the inmail.sh (also set as pi:pi) I run when for incoming mail...
It doesn't matter what the owner of inmail.sh is, it matters who the current user is when that script is run. It sounds like you're running inmail.sh as root, at least sometimes.
OK... I understand that but if that was the case, why when I send it a %-ALL it removes the node # properly but doesn't change the ownership of the areas.bbs? It only happens when the %+ALL is the trigger.
I've sent it
%LIST, %UNLINKED, %QUERY AND %RESCAN <SUB>
All those commands I am assuming have to access the areas.bbs file yet none of then changed the owner of the areas.bbs file. It remained pi:pi
In answer to your question on the other post, I did a whoami and it came back as: pi
The bash script doesn't use sudo.
????
Digital Man wrote to Bill McGarrity on 02-27-17 23:09 <=-
OK... I understand that but if that was the case, why when I send it a %-ALL it removes the node # properly but doesn't change the ownership of the areas.bbs? It only happens when the %+ALL is the trigger.
Weird. It's the same function in sbbsecho.c which handles all area file changes (alter_areas).
I've sent it
%LIST, %UNLINKED, %QUERY AND %RESCAN <SUB>
None of those make changes to the area file.
All those commands I am assuming have to access the areas.bbs file yet none of then changed the owner of the areas.bbs file. It remained pi:pi
When alter_areas() modifies the area file (e.g. areas.bbs), it first creates a new temporary file and if everything is successful, it
removes the original area file and renames the temporary file to your
area file filename. The default permissions will be 0600 and the
default owner will be the user that ran SBBSecho.
Digital Man wrote to Bill McGarrity on 02-27-17 23:09 <=-
OK... I understand that but if that was the case, why when I send it a %-ALL it removes the node # properly but doesn't change the ownership of the areas.bbs? It only happens when the %+ALL is the trigger.
Weird. It's the same function in sbbsecho.c which handles all area file changes (alter_areas).
I've sent it
%LIST, %UNLINKED, %QUERY AND %RESCAN <SUB>
None of those make changes to the area file.
In the beginning I also ran %-ALL and it did make the changes and still had the same permissions.
All those commands I am assuming have to access the areas.bbs file yet none of then changed the owner of the areas.bbs file. It remained pi:pi
When alter_areas() modifies the area file (e.g. areas.bbs), it first creates a new temporary file and if everything is successful, it removes the original area file and renames the temporary file to your area file filename. The default permissions will be 0600 and the default owner will be the user that ran SBBSecho.
What's the name of the new temp file
and I'm assuming it's created in ../temp/sbbsecho?
It seems the owner:group that temp file belongs to
root:root when either %-ALL or %+ALL makes the changes. I'm not running ./sbbsecho as root yet either changes the owner.
If I just do a -<sub> or a +<sub>, the areas.bbs stays pi:pi.
Can I do a chown on that temp file where
it will remain pi:pi?
Or should I just do a rm -R sbbs and start over again?
Digital Man wrote to Bill McGarrity on 03-01-17 00:52 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Wed Mar 01 2017 12:03 am
Digital Man wrote to Bill McGarrity on 02-27-17 23:09 <=-
OK... I understand that but if that was the case, why when I send it a %-ALL it removes the node # properly but doesn't change the ownership of the areas.bbs? It only happens when the %+ALL is the trigger.
Weird. It's the same function in sbbsecho.c which handles all area file changes (alter_areas).
I've sent it
%LIST, %UNLINKED, %QUERY AND %RESCAN <SUB>
None of those make changes to the area file.
In the beginning I also ran %-ALL and it did make the changes and still had the same permissions.
All those commands I am assuming have to access the areas.bbs file yet none of then changed the owner of the areas.bbs file. It remained pi:pi
When alter_areas() modifies the area file (e.g. areas.bbs), it first creates a new temporary file and if everything is successful, it removes the original area file and renames the temporary file to your area file filename. The default permissions will be 0600 and the default owner will be the user that ran SBBSecho.
What's the name of the new temp file
The temp filename generated using tempnam(data_dir, "AREAS") - type
"man tempnam" to get more details about how that function works.
and I'm assuming it's created in ../temp/sbbsecho?
No, in the same directory as your area file (the data_dir, by default).
It seems the owner:group that temp file belongs to
root:root when either %-ALL or %+ALL makes the changes. I'm not running ./sbbsecho as root yet either changes the owner.
I have no explanation for that. It sounds to me like you're running SBBSecho as root and you just don't realize it. Perhaps someone else
has a clue on how to determine how that could happen.
If I just do a -<sub> or a +<sub>, the areas.bbs stays pi:pi.
I don't have an explanation for that either. The exact same code in sbbsecho is used to modify the area file whether you're adding/remove
one or all areas.
Can I do a chown on that temp file where
it will remain pi:pi?
No, it's created on the fly.
Or should I just do a rm -R sbbs and start over again?
I think it would be best to find out how you're running SBBSecho as the user root and fix that.
It seems the owner:group that temp file belongs to
root:root when either %-ALL or %+ALL makes the changes. I'm not running ./sbbsecho as root yet either changes the owner.
I have no explanation for that. It sounds to me like you're running SBBSecho as root and you just don't realize it. Perhaps someone else has a clue on how to determine how that could happen.
I am staring ./sbbsecho in a folder owned by pi in group pi unless I did something when I installed the entire sbbs package from the cvs.
Or should I just do a rm -R sbbs and start over again?
I think it would be best to find out how you're running SBBSecho as the user root and fix that.
As much as I appreciate all your help, and knowledge (I am sucking this up like a sponge), I've decided to rm the entire package and start over. All the bash scripts I use I have chown'd to pi:pi and am making sure NOTHING from root starts ./sbbsecho
Digital Man wrote to Bill McGarrity on 03-01-17 13:57 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Wed Mar 01 2017 04:14 pm
It seems the owner:group that temp file belongs to
root:root when either %-ALL or %+ALL makes the changes. I'm not running ./sbbsecho as root yet either changes the owner.
I have no explanation for that. It sounds to me like you're running SBBSecho as root and you just don't realize it. Perhaps someone else has a clue on how to determine how that could happen.
I am staring ./sbbsecho in a folder owned by pi in group pi unless I did something when I installed the entire sbbs package from the cvs.
That's irrelevant. Who owns the "folder" you are are in when start a process does not dictate who the current user is when the process is executed.
Or should I just do a rm -R sbbs and start over again?
I think it would be best to find out how you're running SBBSecho as the user root and fix that.
As much as I appreciate all your help, and knowledge (I am sucking this up like a sponge), I've decided to rm the entire package and start over. All the bash scripts I use I have chown'd to pi:pi and am making sure NOTHING from root starts ./sbbsecho
I'm not sure what you mean by "nothing from root". It matters not who *owns* a script or a program (executeable binary file). If you run something "as root" (the current user is root or use sudo or similar methods), then the process will run as root.
Digital Man wrote to Bill McGarrity on 03-01-17 13:57 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Wed Mar 01 2017 04:14 pm
It seems the owner:group that temp file belongs to
root:root when either %-ALL or %+ALL makes the changes. I'm not running ./sbbsecho as root yet either changes the owner.
I have no explanation for that. It sounds to me like you're running SBBSecho as root and you just don't realize it. Perhaps someone else has a clue on how to determine how that could happen.
I am staring ./sbbsecho in a folder owned by pi in group pi unless I did something when I installed the entire sbbs package from the cvs.
That's irrelevant. Who owns the "folder" you are are in when start a process does not dictate who the current user is when the process is executed.
OK... not a problem,
Or should I just do a rm -R sbbs and start over again?
I think it would be best to find out how you're running SBBSecho as the user root and fix that.
As much as I appreciate all your help, and knowledge (I am sucking this up like a sponge), I've decided to rm the entire package and start over. All the bash scripts I use I have chown'd to pi:pi and am making sure NOTHING from root starts ./sbbsecho
I'm not sure what you mean by "nothing from root". It matters not who *owns* a script or a program (executeable binary file). If you run something "as root" (the current user is root or use sudo or similar methods), then the process will run as root.
I completely deleted the sbbs folder and reinstalled. The "inmail.sh" does not have any sudo commands in it at all. the line I run to toss the mail is:
./sbbsecho -lesr > /home/pi/sbbs/events/inerror.log
Now, everything was configured and sent it an areafix request first using %+ALL as I didn't want to screw up the areas.bbs file but most of all to see if it changed the ownership and group of the file. It didn't, it remained as pi pi so at least that part is straightened out. (Thank God)
As much as I appreciate all your help, and knowledge (I am sucking
this up like a sponge), I've decided to rm the entire package and
start over. All the bash scripts I use I have chown'd to pi:pi and
am making sure NOTHING from root starts ./sbbsecho
I'm not sure what you mean by "nothing from root". It matters not
who *owns* a script or a program (executeable binary file). If
you run something "as root" (the current user is root or use sudo
or similar methods), then the process will run as root.
I completely deleted the sbbs folder and reinstalled. The "inmail.sh" does not have any sudo commands in it at all. the line I run to toss
the mail is:
./sbbsecho -lesr > /home/pi/sbbs/events/inerror.log
Digital Man wrote to Bill McGarrity <=-
I have no explanation for that. It sounds to me like you're running SBBSecho as root and you just don't realize it. Perhaps someone else
has a clue on how to determine how that could happen.
I think it would be best to find out how you're running SBBSecho as the user root and fix that.
Digital Man wrote to Bill McGarrity on 03-01-17 16:15 <=-
As much as I appreciate all your help, and knowledge (I am sucking this up like a sponge), I've decided to rm the entire package and start over. All the bash scripts I use I have chown'd to pi:pi and am making sure NOTHING from root starts ./sbbsecho
I'm not sure what you mean by "nothing from root". It matters not who *owns* a script or a program (executeable binary file). If you run something "as root" (the current user is root or use sudo or similar methods), then the process will run as root.
I completely deleted the sbbs folder and reinstalled. The "inmail.sh" does not have any sudo commands in it at all. the line I run to toss the mail is:
./sbbsecho -lesr > /home/pi/sbbs/events/inerror.log
And what *user* is executing that line? If it's executed from a script (e.g. inmail.sh), is it possible that more than one user is executing
that script? Is it possible that you have SBBSecho executing as root
for *outbound* mail (e.g. a different script potentially run as a different user)?
Now, everything was configured and sent it an areafix request first using %+ALL as I didn't want to screw up the areas.bbs file but most of all to see if it changed the ownership and group of the file. It didn't, it remained as pi pi so at least that part is straightened out. (Thank God)
I don't think it's straightened out. I wouldn't be surprised if you
find your areas.bbs file owned by root again as you never identifed the cause (and fixed it).
Accession wrote to Bill McGarrity on 03-01-17 19:17 <=-
I'm not sure what you mean by "nothing from root". It matters not
who *owns* a script or a program (executeable binary file). If
you run something "as root" (the current user is root or use sudo
or similar methods), then the process will run as root.
I completely deleted the sbbs folder and reinstalled. The "inmail.sh" does not have any sudo commands in it at all. the line I run to toss
the mail is:
./sbbsecho -lesr > /home/pi/sbbs/events/inerror.log
What he's trying to say here is, you could have had all your stuff
owned by "pi" in the first place. However, if at one time you decided
to run your script (inmail.sh) outside of Synchronet's timed events to test it, and was logged in as root or accidentally used sudo (ie: sudo ./inmail.sh) then it would run as root, and screw up the file ownership
on files that sbbsecho created.
It may have only happened once by a manual intervention. No matter what the files ownership is currently. If it was ever ran accidentally with sudo or as the root user, it will cause problems forever until you also manually intervene and fix everything that one accident did.
I told you permissions were a bitch. :)
Vk3jed wrote to Digital Man on 03-02-17 07:43 <=-
Digital Man wrote to Bill McGarrity <=-
I have no explanation for that. It sounds to me like you're running SBBSecho as root and you just don't realize it. Perhaps someone else
has a clue on how to determine how that could happen.
That would suggest sbbsecho is being run from outside Synchronet, for example a cron job or looping script owned by root. If Synchronet is setup properly, it should drop privileges and run as a normal user,
once it had bound the ports it needs, like most *NIX daemons these
days. If sbbsecho is called from such a process, it will be running as the normal user, not root, and all should be fine.
I do have sbbsecho run from a cron job at some stage here, but that
cron job is owned by my Synchronet user, so no ownership/permissions hassles. Sure, running it from Synchronet's scheduler is probably an
even better solution, but old habits die hard. :D
I think it would be best to find out how you're running SBBSecho as the user root and fix that.
That would be the proper fix.
Bill McGarrity wrote to Digital Man <=-
I completely deleted the sbbs folder and reinstalled. The "inmail.sh" does not have any sudo commands in it at all. the line I run to toss
the mail is:
./sbbsecho -lesr > /home/pi/sbbs/events/inerror.log
Now, everything was configured and sent it an areafix request first
using %+ALL as I didn't want to screw up the areas.bbs file but most of all to see if it changed the ownership and group of the file. It
didn't, it remained as pi pi so at least that part is straightened out. (Thank God)
Digital Man wrote to Bill McGarrity <=-
And what *user* is executing that line? If it's executed from a script (e.g. inmail.sh), is it possible that more than one user is executing
that script? Is it possible that you have SBBSecho executing as root
for *outbound* mail (e.g. a different script potentially run as a different user)?
Accession wrote to Bill McGarrity <=-
I told you permissions were a bitch. :)
Now, everything was configured and sent it an areafix request first using %+ALL as I didn't want to screw up the areas.bbs file but most of all to see if it changed the ownership and group of the file. It didn't, it remained as pi pi so at least that part is straightened out. (Thank God)
I don't think it's straightened out. I wouldn't be surprised if you find your areas.bbs file owned by root again as you never identifed the cause (and fixed it).
The only thing I can possibly think of is I may have started sbbs as a root to take care of ports below 1024 and that may have affected %jfidoout.now.
This morning when I removed the sbbs folder using rm -R. I then rebooted and started the installation over from scratch and that's where we are now as in it's working. The inerror.log I create when ./sbbsecho is run is as follows after sending it a %+ALL: (it's 97 subs so I removed most of them from the log pasted here.)
What is Error 2 further down in the log?
Linking area (Yoga) for 24:100/1 in /home/pi/sbbs/data/areas.bbs
ERROR 2 (No such file or directory) line 1082 opening
ERROR 2 (No such file or directory) line 1316 opening
I am running sbbsecho standalone. The bbs portion is not running. I think I have since found the issue by doing a total removal of sbbs and rebooting and recompiling a fresh version. The possibility was very early when I tried to run sbbs using the ports lower than 1024 which required sudo. Therefore the %jfidoout.now may have been the culprit.
Digital Man wrote to Bill McGarrity on 03-01-17 22:45 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Wed Mar 01 2017 10:55 pm
Now, everything was configured and sent it an areafix request first using %+ALL as I didn't want to screw up the areas.bbs file but most of all to see if it changed the ownership and group of the file. It didn't, it remained as pi pi so at least that part is straightened out. (Thank God)
I don't think it's straightened out. I wouldn't be surprised if you find your areas.bbs file owned by root again as you never identifed the cause (and fixed it).
The only thing I can possibly think of is I may have started sbbs as a root to take care of ports below 1024 and that may have affected %jfidoout.now.
The owner of fidoout.now doesn't matter, but if you run sbbs as root
and sbbs runs SBBSecho, then SBBSecho is then running as root.
This morning when I removed the sbbs folder using rm -R. I then rebooted and started the installation over from scratch and that's where we are now as in it's working. The inerror.log I create when ./sbbsecho is run is as follows after sending it a %+ALL: (it's 97 subs so I removed most of them from the log pasted here.)
What is Error 2 further down in the log?
Error 2 means "file not found".
Linking area (Yoga) for 24:100/1 in /home/pi/sbbs/data/areas.bbs
ERROR 2 (No such file or directory) line 1082 opening
ERROR 2 (No such file or directory) line 1316 opening
Is there actually nothing following the "opening" word in this log
output or was that just a copy/paste error?
Digital Man wrote to Bill McGarrity on 03-01-17 22:47 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Vk3jed on Thu Mar 02 2017 12:27 am
I am running sbbsecho standalone. The bbs portion is not running. I think I have since found the issue by doing a total removal of sbbs and rebooting and recompiling a fresh version. The possibility was very early when I tried to run sbbs using the ports lower than 1024 which required sudo. Therefore the %jfidoout.now may have been the culprit.
Sorry, that just doesn't make any sense.
You mentioned inmail.sh, but what what runs SBBSecho for exporting? Is
it possible you have binkd (or something else) running as root and that something else is configured to run SBBSecho?
Bill McGarrity wrote to Vk3jed <=-
I am running sbbsecho standalone. The bbs portion is not running. I think I have since found the issue by doing a total removal of sbbs and rebooting and recompiling a fresh version. The possibility was very
early when I tried to run sbbs using the ports lower than 1024 which required sudo. Therefore the %jfidoout.now may have been the culprit.
Either way, it's operating properly right now...
Vk3jed wrote to Bill McGarrity on 03-03-17 06:24 <=-
Bill McGarrity wrote to Vk3jed <=-
I am running sbbsecho standalone. The bbs portion is not running. I think I have since found the issue by doing a total removal of sbbs and rebooting and recompiling a fresh version. The possibility was very
That alone will not fix the issue. Obviously, if it truly is fixed, something else has changed too.
early when I tried to run sbbs using the ports lower than 1024 which required sudo. Therefore the %jfidoout.now may have been the culprit.
Possibly some confusion making you think you needed to use sudo to run sbbsecho as well?
Either way, it's operating properly right now...
*touch wood* :)
I told you permissions were a bitch. :)
Nah, permissions are fine, but they will bite you on the ass if you're
not paying attention to what you're doing! :D General rule of thumb
is to always ensure you're running Synchronet related software as the
same user.
This morning when I removed the sbbs folder using rm -R. I then rebooted and started the installation over from scratch and that's where we are now as in it's working. The inerror.log I create when ./sbbsecho is run is as follows after sending it a %+ALL: (it's 97 subs so I removed most of them from the log pasted here.)
What is Error 2 further down in the log?
Error 2 means "file not found".
Linking area (Yoga) for 24:100/1 in /home/pi/sbbs/data/areas.bbs
ERROR 2 (No such file or directory) line 1082 opening
ERROR 2 (No such file or directory) line 1316 opening
Is there actually nothing following the "opening" word in this log output or was that just a copy/paste error?
There is nothing after the word "opening"... blank. No typo.
Digital Man wrote to Bill McGarrity on 03-01-17 22:47 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Vk3jed on Thu Mar 02 2017 12:27 am
I am running sbbsecho standalone. The bbs portion is not running. I think I have since found the issue by doing a total removal of sbbs and rebooting and recompiling a fresh version. The possibility was very early when I tried to run sbbs using the ports lower than 1024 which required sudo. Therefore the %jfidoout.now may have been the culprit.
Sorry, that just doesn't make any sense.
You mentioned inmail.sh, but what what runs SBBSecho for exporting? Is it possible you have binkd (or something else) running as root and that something else is configured to run SBBSecho?
Nothing. binkd runs as pi. binkd uses it's EXEC option to call 'inmail.sh'. There are three cron jobs, where all are calling for ./smbutil. Right now everything is working perfectly which I think the deletion, rebooting and reinstallation took care of. When it comes to binkd and sbbs, from now on I'll stay as far away from 'root' as possible.
As stated in the previous message, the only other issue I see the Error 2. Should I add the sportnet.na as an aditional echolist again? Could it be looking for that?
Bill McGarrity wrote to Vk3jed <=-
Nope. As I said, after I was using sbbsecho I was thinking about
running the bbs as well and I needed to run sudo to take advantage of ports below 1024. That is where I am almost positive the issues began.
Either way, it's operating properly right now...
*touch wood* :)
Yup...
Accession wrote to Vk3jed <=-
Nah, permissions are fine, but they will bite you on the ass if you're
not paying attention to what you're doing! :D General rule of thumb
The whole "bite you in the ass" part is what makes them a bitch to deal with on multi-user systems. I've dealt with it in the past, and have
long since alleviated that issue.
is to always ensure you're running Synchronet related software as the
same user.
I would probably say that more of a general rule of thumb for
everything linux and server related. :)
The whole "bite you in the ass" part is what makes them a bitch to
deal with on multi-user systems. I've dealt with it in the past, and
have long since alleviated that issue.
Yeah, follow a few simple rules and you're generally fine though.
Yes, indeed. I was just being Synchronet specific, but the same rule applies for any other Linux software.
Digital Man wrote to Bill McGarrity on 03-03-17 00:30 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Thu Mar 02 2017 03:18 pm
Digital Man wrote to Bill McGarrity on 03-01-17 22:47 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Vk3jed on Thu Mar 02 2017 12:27 am
I am running sbbsecho standalone. The bbs portion is not running. I think I have since found the issue by doing a total removal of sbbs and rebooting and recompiling a fresh version. The possibility was very early when I tried to run sbbs using the ports lower than 1024 which required sudo. Therefore the %jfidoout.now may have been the culprit.
Sorry, that just doesn't make any sense.
You mentioned inmail.sh, but what what runs SBBSecho for exporting? Is it possible you have binkd (or something else) running as root and that something else is configured to run SBBSecho?
Nothing. binkd runs as pi. binkd uses it's EXEC option to call 'inmail.sh'. There are three cron jobs, where all are calling for ./smbutil. Right now everything is working perfectly which I think the deletion, rebooting and reinstallation took care of. When it comes to binkd and sbbs, from now on I'll stay as far away from 'root' as possible.
Is there an 'outmail.sh'? If so, what's calling it?
As stated in the previous message, the only other issue I see the Error 2. Should I add the sportnet.na as an aditional echolist again? Could it be looking for that?
I suppose, but that would be weird. I'm curious what your sbbsecho.ini file looks like right now.
thenIs there an 'outmail.sh'? If so, what's calling it?
Nope. inmail.sh is called, runs and tosses the incoming, creates pkt's
bundles them and creates the necessary clo files that binkd uses. I can only assume it creates it's own fidoout.now file.
Nicholas Boel wrote to Vk3jed <=-
Except for the rare occasions you find something not working as
expected, do everything in your power to try to resolve it whether it
be searching via Google or whatever. Then when it probably should have been your first try, your final measure taken is to check the
permission to find out either you typo'd or accidentally touched the
file with another user and/or root at some point. Then you bang your
head on your desk because you spent the last hour trying to figure out something that should have taken about 30 seconds.
Even after 10+ years of using Linux, it can happen. And the longer
you've "known better" the worse it is on yourself when realizing what
you did. At least by now I've finally gotten myself into the habit that
if something odd like that happens, to check permissions FIRST, then go from there if it is not the case. Took awhile, though. lol
If that hasn't happened to you, then you can consider yourself pretty lucky in that regard. As you said, you're generally fine, but sometimes when it does bite you in the ass, it bites harder than expected, and becomes more embarrassing over time. :)
If that hasn't happened to you, then you can consider yourself
pretty lucky in that regard. As you said, you're generally fine,
but sometimes when it does bite you in the ass, it bites harder
than expected, and becomes more embarrassing over time. :)
Oh it has, but I'm now well into the 20+ years of using Linux
category, where checking permissions is one of the first things done,
when things go screwy. All those bites on the ass have left scars! :D
Nicholas Boel wrote to Bill McGarrity on 03-03-17 16:13 <=-
On 3/3/2017 12:46 PM, Bill McGarrity -> Digital Man wrote:
Is there an 'outmail.sh'? If so, what's calling it?
Nope. inmail.sh is called, runs and tosses the incoming, creates pkt's
then
bundles them and creates the necessary clo files that binkd uses. I can only assume it creates it's own fidoout.now file.
Keep in mind, since you're not running the sbbs daemon, fidoout.now (as well as fidoin.now) means absolutely nothing. These semaphores are not created or acted upon unless the sbbs daemon is running.
So when you assume it creates it's own fidoout.now file, you're just running sbbsecho directly instead (most likely in your inmail.sh
script).
Keep in mind, since you're not running the sbbs daemon,
fidoout.now (as well as fidoin.now) means absolutely nothing.
These semaphores are not created or acted upon unless the sbbs
daemon is running.
Agreed but as I said, being the incoming packets are tossed and there
are downlinks, sbbsecho does create all the necessary files where, in
my opinion, as of now there is zero need for a fidoout semaphore. I
ahve scripted a mailout.sh but as of now I really don't think I need
it. The nightly binkd log files after they are created I run sbbsecho -linf and that's the only place.
The inmail.sh script just runs sbbsecho to toss incoming (-lesr).
There is no use of it to send it to downlinks but in hindsight right now... I just asked a question to Rob about a stuck netmail where it
was tossed and sitting in the ..sbbs/netmail folder as a .MSG. Tonight when the nightly's ran, smbutil posted them in the sub it did run
sbbsecho -linf as I said and it didn't convert the .MSG. It marked it
as already sent.
Exporting Outbound NetMail from /home/pi/sbbs/data/mail to /home/pi/sbbs/netmail/*.msg ...
Packing Outbound NetMail from /home/pi/sbbs/netmail/*.msg ...
NetMail msg 1.msg from Eric Renfro (24:110/1) to Bill McGarrity (24:100/1): already sent
I've already sent a msg to Rob over this so I'll wait on him. :)
Accession wrote to Bill McGarrity on 03-04-17 06:36 <=-
On Sat Mar 04 2017 01:37:00, Bill McGarrity wrote to Nicholas Boel:
Agreed but as I said, being the incoming packets are tossed and there
are downlinks, sbbsecho does create all the necessary files where, in
my opinion, as of now there is zero need for a fidoout semaphore. I
ahve scripted a mailout.sh but as of now I really don't think I need
it. The nightly binkd log files after they are created I run sbbsecho -linf and that's the only place.
You should probably have some kind of mailout.sh otherwise tossed bundles/packets will sit there until sbbsecho is told to run (-linf).
You could even include another sbbsecho call to run the outbound
process right in your mailin.sh if you wish. That way everything will
be done in one shot.
The inmail.sh script just runs sbbsecho to toss incoming (-lesr).
There is no use of it to send it to downlinks but in hindsight right now... I just asked a question to Rob about a stuck netmail where it
was tossed and sitting in the ..sbbs/netmail folder as a .MSG. Tonight when the nightly's ran, smbutil posted them in the sub it did run
sbbsecho -linf as I said and it didn't convert the .MSG. It marked it
as already sent.
Why is netmail being posted to a sub? Or are you referring to the
actual netmail area?
Exporting Outbound NetMail from /home/pi/sbbs/data/mail to /home/pi/sbbs/netmail/*.msg ...
Packing Outbound NetMail from /home/pi/sbbs/netmail/*.msg ...
NetMail msg 1.msg from Eric Renfro (24:110/1) to Bill McGarrity (24:100/1): already sent
Is your hub 24:110/1? If so, the mail is already in the proper place,
and falls under that netmail that you would need to read on your hub
that can not (currently) be forwarded somewhere else.
If not, do you have a direct netmail link setup and carrying all routed netmail to your other system? Or are you currently routing everything
from everyone to your hub for 24:ALL?
I've already sent a msg to Rob over this so I'll wait on him. :)
Ok. Good luck!
Accession wrote to Vk3jed <=-
Oh it has, but I'm now well into the 20+ years of using Linux
category, where checking permissions is one of the first things done,
when things go screwy. All those bites on the ass have left scars! :D
Hah! Well said. Scars always make you remember how it originally
happened. :)
Digital Man wrote to Bill McGarrity on 03-03-17 00:30 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Thu Mar 02 2017 03:18 pm
Digital Man wrote to Bill McGarrity on 03-01-17 22:47 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Vk3jed on Thu Mar 02 2017 12:27 am
I am running sbbsecho standalone. The bbs portion is not running. I think I have since found the issue by doing a total removal of sbbs and rebooting and recompiling a fresh version. The possibility was very early when I tried to run sbbs using the ports lower than 1024 which required sudo. Therefore the %jfidoout.now may have been the culprit.
Sorry, that just doesn't make any sense.
You mentioned inmail.sh, but what what runs SBBSecho for exporting? Is it possible you have binkd (or something else) running as root and that something else is configured to run SBBSecho?
Nothing. binkd runs as pi. binkd uses it's EXEC option to call 'inmail.sh'. There are three cron jobs, where all are calling for ./smbutil. Right now everything is working perfectly which I think the deletion, rebooting and reinstallation took care of. When it comes to binkd and sbbs, from now on I'll stay as far away from 'root' as possible.
Is there an 'outmail.sh'? If so, what's calling it?
Nope. inmail.sh is called, runs and tosses the incoming, creates pkt's then bundles them and creates the necessary clo files that binkd uses. I can only assume it creates it's own fidoout.now file.
As stated in the previous message, the only other issue I see the Error 2. Should I add the sportnet.na as an aditional echolist again? Could it be looking for that?
I suppose, but that would be weird. I'm curious what your sbbsecho.ini file looks like right now.
Here ya go...
The only spot I can see there be any issue is the "temp file" as the full path isn't used but within echocfg, there is no was of changing it.
Naturally I can do it manually if you'd like.
The nightly log postings I do have sbbsecho -linf after smbutil posts then in the general sub.
Digital Man wrote to Bill McGarrity on 03-05-17 17:54 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Fri Mar 03 2017 01:46 pm
Digital Man wrote to Bill McGarrity on 03-03-17 00:30 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Thu Mar 02 2017 03:18 pm
Digital Man wrote to Bill McGarrity on 03-01-17 22:47 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Vk3jed on Thu Mar 02 2017 12:27 am
I am running sbbsecho standalone. The bbs portion is not running. I think I have since found the issue by doing a total removal of sbbs and rebooting and recompiling a fresh version. The possibility was very early when I tried to run sbbs using the ports lower than 1024 which required sudo. Therefore the %jfidoout.now may have been the culprit.
Sorry, that just doesn't make any sense.
You mentioned inmail.sh, but what what runs SBBSecho for exporting? Is it possible you have binkd (or something else) running as root and that something else is configured to run SBBSecho?
Nothing. binkd runs as pi. binkd uses it's EXEC option to call 'inmail.sh'. There are three cron jobs, where all are calling for ./smbutil. Right now everything is working perfectly which I think the deletion, rebooting and reinstallation took care of. When it comes to binkd and sbbs, from now on I'll stay as far away from 'root' as possible.
Is there an 'outmail.sh'? If so, what's calling it?
Nope. inmail.sh is called, runs and tosses the incoming, creates pkt's then bundles them and creates the necessary clo files that binkd uses. I can only assume it creates it's own fidoout.now file.
As stated in the previous message, the only other issue I see the Error 2. Should I add the sportnet.na as an aditional echolist again? Could it be looking for that?
I suppose, but that would be weird. I'm curious what your sbbsecho.ini file looks like right now.
Here ya go...
The only spot I can see there be any issue is the "temp file" as the full path isn't used but within echocfg, there is no was of changing it.
You mean TempDirectory?
Naturally I can do it manually if you'd like.
Do what?
So you pasted your sbbsecho.ini, but there were no echolist's defined.
Is that correct?
Digital Man wrote to Bill McGarrity on 03-05-17 17:57 <=-
@VIA: VERT
@MSGID: <58BCC1F8.33835.syncprog@vert.synchro.net>
@REPLY: <58BB4C90.14807.syncprog@tequilamockingbirdonline.net>
@TZ: 41e0
Re: sbbsecho 3.29
By: Bill McGarrity to Accession on Sat Mar 04 2017 05:57 pm
The nightly log postings I do have sbbsecho -linf after smbutil posts then in the general sub.
What user runs the 'nightly log postings'?
Digital Man wrote to Bill McGarrity on 03-05-17 17:54 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Fri Mar 03 2017 01:46 pm
Digital Man wrote to Bill McGarrity on 03-03-17 00:30 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Thu Mar 02 2017 03:18 pm
Digital Man wrote to Bill McGarrity on 03-01-17 22:47 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Vk3jed on Thu Mar 02 2017 12:27 am
I am running sbbsecho standalone. The bbs portion is not running. I think I have since found the issue by doing a total removal of sbbs and rebooting and recompiling a fresh version. The possibility was very early when I tried to run sbbs using the ports lower than 1024 which required sudo. Therefore the %jfidoout.now may have been the culprit.
Sorry, that just doesn't make any sense.
You mentioned inmail.sh, but what what runs SBBSecho for exporting? Is it possible you have binkd (or something else) running as root and that something else is configured to run SBBSecho?
Nothing. binkd runs as pi. binkd uses it's EXEC option to call 'inmail.sh'. There are three cron jobs, where all are calling for ./smbutil. Right now everything is working perfectly which I think the deletion, rebooting and reinstallation took care of. When it comes to binkd and sbbs, from now on I'll stay as far away from 'root' as possible.
Is there an 'outmail.sh'? If so, what's calling it?
Nope. inmail.sh is called, runs and tosses the incoming, creates pkt's then bundles them and creates the necessary clo files that binkd uses. I can only assume it creates it's own fidoout.now file.
As stated in the previous message, the only other issue I see the Error 2. Should I add the sportnet.na as an aditional echolist again? Could it be looking for that?
I suppose, but that would be weird. I'm curious what your sbbsecho.ini file looks like right now.
Here ya go...
The only spot I can see there be any issue is the "temp file" as the full path isn't used but within echocfg, there is no was of changing it.
You mean TempDirectory?
Yes, but I ahve since edited the sbbsecho.ini manually and put in the complete path of:
/home/pi/sbbs/temp/sbbsecho
Naturally I can do it manually if you'd like.
Do what?
Edited the ini file as I did above..
So you pasted your sbbsecho.ini, but there were no echolist's defined. Is that correct?
Yes, at first being I was using the areas.bbs as the avenue to allow downlinks add/subtract. I have since added it as follows:
[echolist:/home/pi/sbbs/data/sportnet.na]
Hub = 24:24/1
Pwd =
Fwd = false
Keys = SPOR
The Error 2 still appears without a clue what doesn't exist when I send it an areafix with %+all in the body.
Digital Man wrote to Bill McGarrity on 03-06-17 10:05 <=-
You mean TempDirectory?
Yes, but I ahve since edited the sbbsecho.ini manually and put in the complete path of:
/home/pi/sbbs/temp/sbbsecho
Naturally I can do it manually if you'd like.
Do what?
Edited the ini file as I did above..
Ah, I see. I'll add that option to echocfg.
So you pasted your sbbsecho.ini, but there were no echolist's defined. Is that correct?
Yes, at first being I was using the areas.bbs as the avenue to allow downlinks add/subtract. I have since added it as follows:
[echolist:/home/pi/sbbs/data/sportnet.na]
Hub = 24:24/1
Pwd =
Fwd = false
Keys = SPOR
The Error 2 still appears without a clue what doesn't exist when I send it an areafix with %+all in the body.
I'll look further and see if I can find a potential cause.
Is there actually nothing following the "opening" word in this log output or was that just a copy/paste error?
There is nothing after the word "opening"... blank. No typo.
Digital Man wrote to Bill McGarrity on 03-05-17 17:57 <=-
@VIA: VERT
@MSGID: <58BCC1F8.33835.syncprog@vert.synchro.net>
@REPLY: <58BB4C90.14807.syncprog@tequilamockingbirdonline.net>
@TZ: 41e0
Re: sbbsecho 3.29
By: Bill McGarrity to Accession on Sat Mar 04 2017 05:57 pm
The nightly log postings I do have sbbsecho -linf after smbutil posts then in the general sub.
What user runs the 'nightly log postings'?
User: pi
Group: pi
-rwxrwx--- 1 pi pi 821 Mar 2 00:06 binkdsts.sh
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Sun Mar 05 2017 11:58 pm
Digital Man wrote to Bill McGarrity on 03-05-17 17:54 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Fri Mar 03 2017 01:46 pm
Digital Man wrote to Bill McGarrity on 03-03-17 00:30 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Thu Mar 02 2017 03:18 pm
Digital Man wrote to Bill McGarrity on 03-01-17 22:47 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Vk3jed on Thu Mar 02 2017 12:27 am
I am running sbbsecho standalone. The bbs portion is not running. I think I have since found the issue by doing a total removal of sbbs and rebooting and recompiling a fresh version. The possibility was very early when I tried to run sbbs using the ports lower than 1024 which required sudo. Therefore the %jfidoout.now may have been the culprit.
Sorry, that just doesn't make any sense.
You mentioned inmail.sh, but what what runs SBBSecho for exporting? Is it possible you have binkd (or something else) running as root and that something else is configured to run SBBSecho?
Nothing. binkd runs as pi. binkd uses it's EXEC option to call 'inmail.sh'. There are three cron jobs, where all are calling for ./smbutil. Right now everything is working perfectly which I think the deletion, rebooting and reinstallation took care of. When it comes to binkd and sbbs, from now on I'll stay as far away from 'root' as possible.
Is there an 'outmail.sh'? If so, what's calling it?
Nope. inmail.sh is called, runs and tosses the incoming, creates pkt's then bundles them and creates the necessary clo files that binkd uses. I can only assume it creates it's own fidoout.now file.
As stated in the previous message, the only other issue I see the Error 2. Should I add the sportnet.na as an aditional echolist again? Could it be looking for that?
I suppose, but that would be weird. I'm curious what your sbbsecho.ini file looks like right now.
Here ya go...
The only spot I can see there be any issue is the "temp file" as the full path isn't used but within echocfg, there is no was of changing it.
You mean TempDirectory?
Yes, but I ahve since edited the sbbsecho.ini manually and put in the complete path of:
/home/pi/sbbs/temp/sbbsecho
Naturally I can do it manually if you'd like.
Do what?
Edited the ini file as I did above..
Ah, I see. I'll add that option to echocfg.
Digital Man wrote to Bill McGarrity on 03-06-17 12:56 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Mon Mar 06 2017 12:02 am
Digital Man wrote to Bill McGarrity on 03-05-17 17:57 <=-
@VIA: VERT
@MSGID: <58BCC1F8.33835.syncprog@vert.synchro.net>
@REPLY: <58BB4C90.14807.syncprog@tequilamockingbirdonline.net>
@TZ: 41e0
Re: sbbsecho 3.29
By: Bill McGarrity to Accession on Sat Mar 04 2017 05:57 pm
The nightly log postings I do have sbbsecho -linf after smbutil posts then in the general sub.
What user runs the 'nightly log postings'?
User: pi
Group: pi
-rwxrwx--- 1 pi pi 821 Mar 2 00:06 binkdsts.sh
The ownership of a file does not tell you who it runs as.
Most cron jobs, for example, run as the user 'root'. It doesn't matter
who "owns" the script or program the job is running. For more details, read: http://superuser.com/questions/170866/how-to-run-a-cron-job-as-a-specifi c-user
Digital Man wrote to Bill McGarrity on 03-06-17 12:57 <=-
Naturally I can do it manually if you'd like.
Do what?
Edited the ini file as I did above..
Ah, I see. I'll add that option to echocfg.
This option should be in echocfg now.
Digital Man wrote to Bill McGarrity on 03-06-17 12:51 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Thu Mar 02 2017 03:11 pm
Is there actually nothing following the "opening" word in this log output or was that just a copy/paste error?
There is nothing after the word "opening"... blank. No typo.
That is very strange. I've added a line of debug log output to
sbbsecho.c. The line should look something like this (right after "SBBSecho 3.00-such and such invoked with options: blah"):
x packers, x linked-nodes, x echolists configuerd
Please update to this revision and let me know what this debug line
says for the conditions when you have 1 or 0 echolists configured in
your ctrl/sbbsecho.ini and then also if you're still seeing the "ERROR
2 ... opening" in your log when performing specific areafix requests.
Thanks,
When I created the crontab I was logged in as user pi.
(pi@raspberrypi:) I typed 'crontab -e' which I thought created the job under user 'pi'. In /etc/crontab, there is no listings of any of the events I scheduled. There are events marked with 'root' as the user
but none of the ones I setup. Also, in cron.d, that folder is empty. I
am not seeing any problems with that issue any longer. The txt files being created belong to pi:pi and are being imported properly by
smbutil into the sub.
mark lewis wrote to Bill McGarrity on 03-06-17 21:27 <=-
On 2017 Mar 06 17:07:00, you wrote to Digital Man:
When I created the crontab I was logged in as user pi.
(pi@raspberrypi:) I typed 'crontab -e' which I thought created the job under user 'pi'. In /etc/crontab, there is no listings of any of the events I scheduled. There are events marked with 'root' as the user
but none of the ones I setup. Also, in cron.d, that folder is empty. I
am not seeing any problems with that issue any longer. The txt files being created belong to pi:pi and are being imported properly by
smbutil into the sub.
take a peek in /var/spool/cron/crontabs as root or using sudo...
eg: sudo mc
mc == midnight commander... a norton commander clone... really helps getting around file systems you're not familiar with ;)
sudo aptitude install mc
Digital Man wrote to Bill McGarrity on 03-06-17 12:51 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Thu Mar 02 2017 03:11 pm
Is there actually nothing following the "opening" word in this log output or was that just a copy/paste error?
There is nothing after the word "opening"... blank. No typo.
That is very strange. I've added a line of debug log output to sbbsecho.c. The line should look something like this (right after "SBBSecho 3.00-such and such invoked with options: blah"):
x packers, x linked-nodes, x echolists configuerd
Please update to this revision and let me know what this debug line says for the conditions when you have 1 or 0 echolists configured in your ctrl/sbbsecho.ini and then also if you're still seeing the "ERROR 2 ... opening" in your log when performing specific areafix requests.
I'll update this evening and get you the info as requested...
Thanks,
Thank you!
OK... updated...
Here is the first one WITH the added Additional Echolist:
03-06-17 18:19:22 SBBSecho 3.00-Linux r3.32 Mar 6 2017 GCC 4.9.2 invoked with options:
03-06-17 18:19:22 7 packers, 42 linked-nodes, 1 echolists configured
There were NO Error 2's at all...
Here is the entry when I removed the Additional Echolist Entry
Loading configuration files from /home/pi/sbbs/ctrl/
SBBSecho 3.00-Linux r3.32 Mar 6 2017 GCC 4.9.2 invoked with options: -lesr
7 packers, 42 linked-nodes, 1 echolists configured
^^^^^^^^^^^^^^^^^^^^^^??
It showed it linked ALL 97 areas but there was an Error 2 at the end of the Linking area:
ERROR 2 (No such file or directory) line 1316 opening
Created NetMail (2.msg) from SBBSecho (24:24/1) to Bill McGarrity (24:100/1), attr: 0181, subject: Area Change Request
Deleting /home/pi/sbbs/data/areas.bbs (from line 1380)
I then re-entered the Aditional Echolist in echocfg..
Loading configuration files from /home/pi/sbbs/ctrl/
SBBSecho 3.00-Linux r3.32 Mar 6 2017 GCC 4.9.2 invoked with options: -lesr
7 packers, 42 linked-nodes, 2 echolists configured <<<<<<<<????
Reading /home/pi/sbbs/data/areas.bbs
Read 97 areas from /home/pi/sbbs/data/areas.bbs
There was an error.
ERROR 2 (No such file or directory) line 1316 opening
I opened sbbsecho.ini and found the following:
[echolist:]
Hub = 24:24/1
Pwd =
Fwd = false
Keys = SPOR
As you can see when I removed the Additional echolist it never removed it from sbbsecho.ini totally.
IMHO, seems as if echocfg is leaving a ghost even when you remove an echolist using echocfg.
Hope this helps...
IMHO, seems as if echocfg is leaving a ghost even when you remove an echolist using echocfg.
Digital Man wrote to Bill McGarrity on 03-06-17 22:31 <=-
Re: sbbsecho 3.29
By: Bill McGarrity to Digital Man on Mon Mar 06 2017 06:54 pm
Digital Man wrote to Bill McGarrity on 03-06-17 12:51 <=-
Loading configuration files from /home/pi/sbbs/ctrl/
SBBSecho 3.00-Linux r3.32 Mar 6 2017 GCC 4.9.2 invoked with options: -lesr
7 packers, 42 linked-nodes, 2 echolists configured <<<<<<<<????
Reading /home/pi/sbbs/data/areas.bbs
Read 97 areas from /home/pi/sbbs/data/areas.bbs
There was an error.
ERROR 2 (No such file or directory) line 1316 opening
I opened sbbsecho.ini and found the following:
[echolist:]
Hub = 24:24/1
Pwd =
Fwd = false
Keys = SPOR
As you can see when I removed the Additional echolist it never removed it from sbbsecho.ini totally.
Right, and that's what I expected to see when I requested a copy of
your sbbecho.ini file before. So, good, that'll be an easy bug to fix.
IMHO, seems as if echocfg is leaving a ghost even when you remove an echolist using echocfg.
Hope this helps...
Yes, thank you.
Digital Man wrote to Bill McGarrity on 03-06-17 22:36 <=-
Re: sbbsecho 3.29
By: Digital Man to Bill McGarrity on Mon Mar 06 2017 10:31 pm
IMHO, seems as if echocfg is leaving a ghost even when you remove an echolist using echocfg.
Exactly what steps are you using to "remove an echolist using echocfg"?
I tried to reproduce your problem and have not. When I delete an
echolist (using the DEL key from the "Additional EchoLists" menu), it's not re-added to the sbbsecho.ini file upon saving/exiting; it's gone completely.
When I created the crontab I was logged in as user pi.
(pi@raspberrypi:) I typed 'crontab -e' which I thought created the
job under user 'pi'. In /etc/crontab, there is no listings of any
of the events I scheduled. There are events marked with 'root' as
the user but none of the ones I setup. Also, in cron.d, that folder
is empty. I am not seeing any problems with that issue any longer.
The txt files being created belong to pi:pi and are being imported
properly by smbutil into the sub.
take a peek in /var/spool/cron/crontabs as root or using sudo...
OK... I did and this is what's in that folder...
-rw------- 1 pi crontab 1265 Mar 6 17:39 pi
eg: sudo mc
mc == midnight commander... a norton commander clone... really helps
getting around file systems you're not familiar with ;)
sudo aptitude install mc
Don't you mean apt-get?
eg: sudo mc
mc == midnight commander... a norton commander clone... really helps getting around file systems you're not familiar with ;)
sudo aptitude install mc
Don't you mean apt-get?
eg: sudo mc
mc == midnight commander... a norton commander clone... really helps getting around file systems you're not familiar with ;)
sudo aptitude install mc
Don't you mean apt-get?
No, Aptitude is a console based version of the GUI that folks
normally use to download packages. It's a nice menu driven application, rather than the command line version of apt-get.
Agreed but as I said, being the incoming packets are tossed and
there are downlinks, sbbsecho does create all the necessary files
where, in my opinion, as of now there is zero need for a fidoout
semaphore. I ahve scripted a mailout.sh but as of now I really
don't think I need it. The nightly binkd log files after they
are created I run sbbsecho -linf and that's the only place.
You should probably have some kind of mailout.sh otherwise tossed
bundles/packets will sit there until sbbsecho is told to run
(-linf). You could even include another sbbsecho call to run the
outbound process right in your mailin.sh if you wish. That way
everything will be done in one shot.
All but one sub is pass-through therefore sbbsecho, upon incoming
mail, will toss it and create BSO style packets to each downlink with
the proper .*LO files that binkd can use.
Direct links are setup in echocfg for ALL linked nodes. All echo areas come into 24:24/1 and then are distributed to downlinks as explained above. The decision to route through 24:24/1 is up to the sender. I
always thought IF there was a direct link established then routed
netmail was possible. I'm not sure if I need to run ./sbbs in the background (as pi <wink>) running just 'services' for it to accomplish
the routing process.
Accession wrote to Bill McGarrity on 03-11-17 23:09 <=-
On Sat Mar 04 2017 17:57:00, Bill McGarrity wrote to Accession:
Agreed but as I said, being the incoming packets are tossed and
there are downlinks, sbbsecho does create all the necessary files
where, in my opinion, as of now there is zero need for a fidoout
semaphore. I ahve scripted a mailout.sh but as of now I really
don't think I need it. The nightly binkd log files after they
are created I run sbbsecho -linf and that's the only place.
You should probably have some kind of mailout.sh otherwise tossed
bundles/packets will sit there until sbbsecho is told to run
(-linf). You could even include another sbbsecho call to run the
outbound process right in your mailin.sh if you wish. That way
everything will be done in one shot.
All but one sub is pass-through therefore sbbsecho, upon incoming
mail, will toss it and create BSO style packets to each downlink with
the proper .*LO files that binkd can use.
You were referring to netmail being sent off immediately, were you not?
I don't believe netmail can be set as pass-through. Do you only want netmail sent out once per day (including any areafix replies)?
Direct links are setup in echocfg for ALL linked nodes. All echo areas come into 24:24/1 and then are distributed to downlinks as explained above. The decision to route through 24:24/1 is up to the sender. I
always thought IF there was a direct link established then routed
netmail was possible. I'm not sure if I need to run ./sbbs in the background (as pi <wink>) running just 'services' for it to accomplish
the routing process.
Sounds like you've already got this figured out. I suppose I had
already assumed you were routing 24:ALL to a specific address already.
| Sysop: | Ragnarok |
|---|---|
| Location: | Dock Sud, Bs As, Argentina |
| Users: | 136 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 06:16:49 |
| Calls: | 15,171 |
| Calls today: | 4 |
| Files: | 19,857 |
| D/L today: |
7 files (164K bytes) |
| Messages: | 1,691,352 |