Hello All.
There is a request to support new Synchronet config (msgs.ini).
https://github.com/golded-plus/golded-plus/issues/77
I've implemented it today and it looks working, but I wouldn't mind if someone who uses GoldEd with Synchronet test this for me.
Code can be build from Synchronet branch.
Hello All.
There is a request to support new Synchronet config (msgs.ini).
https://github.com/golded-plus/golded-plus/issues/77
I've implemented it today and it looks working, but I wouldn't mind
if someone who uses GoldEd with Synchronet test this for me.
Code can be build from Synchronet branch.
Awesome, thank you for doing that!
Code can be build from Synchronet branch.
Awesome, thank you for doing that!
Could you test that for me? I tried to use msgs.cnf and msgs.ini and it works for me. At least it reads configuraion correctly. I didn't try to read messages, because I don't have full Synchronet installation.
Re: Re: Synchronet config change
By: Vitaliy Aksyonov to Rob Swindell on Mon Mar 04 2024 07:57 am
Code can be build from Synchronet branch.
Awesome, thank you for doing that!
Could you test that for me? I tried to use msgs.cnf and msgs.ini and it works for me. At least it reads configuraion correctly. I didn't try to read messages, because I don't have full Synchronet installation.
I'll try to. :-)
Re: Re: Synchronet config change
By: Vitaliy Aksyonov to Rob Swindell on Mon Mar 04 2024 07:57 am
and itCode can be build from Synchronet branch.
Awesome, thank you for doing that!
Could you test that for me? I tried to use msgs.cnf and msgs.ini
works for me. At least it reads configuraion correctly. I didn'ttry to
read messages, because I don't have full Synchronetinstallation.
I'll try to. :-)
Not much luck so far. I forked and then cloned your github repo.
First, I tried a 'make' which after hundreds of warnings, did generate bin/gedlnx:
rswindell@git ~/golded-plus (Synchronet) $ ll bin
total 34688
-rwxrwx--- 1 rswindell rswindell 33386672 Mar 5 23:25 gedlnx
But running it (via SSH) doesn't output anything, just exits
immediately. 'gedlnx --help' same, nothing.
So then I searched for documentation. golded.org appears down.
I saw you have CMakeLists.txt, so I tried using that to build. This
time, a lot fewer errors and it output some promising binaries, but
again, running them produces no output:
rswindell@git ~/golded-plus/out/golded3 (Synchronet) $ sudo make
install [ 4%] Built target uulib [ 9%] Built target hunspell [ 34%] Built target gall [ 53%] Built target gcfg [ 60%] Built target gcui [
61%] Built target smblib [ 77%] Built target gmb3 [100%] Built target golded Install the project... -- Install configuration: "" --
Installing: /usr/local/bin/golded rswindell@git
~/golded-plus/out/golded3 (Synchronet) $ golded rswindell@git ~/golded-plus/out/golded3 (Synchronet) $
Maybe I need to create or edit a config file or something? An error message or *some* kind of output from running 'golded' could be
helpful.
BTW, make sure that Synchronet changes are actually there. I've pushed them to master just today. You may need to pull
from repo again.
But running it (via SSH) doesn't output anything, just exits immediately. 'gedlnx --help' same, nothing.
Unfortunately there is a bug which hides usage message if no config found. I've tried to fix it, but had to revert it back, because correct fix is not that simple.
So then I searched for documentation. golded.org appears down.
I saw you have CMakeLists.txt, so I tried using that to build. This time, a lot fewer errors and it output some promising binaries, but again, running them produces no output:
rswindell@git ~/golded-plus/out/golded3 (Synchronet) $ sudo make install [ 4%] Built target uulib [ 9%] Built target hunspell [ 34%] Built target gall [ 53%] Built target gcfg [ 60%] Built target gcui [ 61%] Built target smblib [ 77%] Built target gmb3 [100%] Built target golded Install the project... -- Install configuration: "" -- Installing: /usr/local/bin/golded rswindell@git ~/golded-plus/out/golded3 (Synchronet) $ golded rswindell@git ~/golded-plus/out/golded3 (Synchronet) $
Maybe I need to create or edit a config file or something? An error message or *some* kind of output from running 'golded' could be helpful.
You have to have config file. You may start from simple config file from here:
https://github.com/golded-plus/golded-plus/blob/master/cfgs/config/simple.cf g
And then uncomment this line:
;AREAFILE SBBS R:\SBBS\ ; Synchronet BBS dir
Set correct path to Synchronet directory. That shall do the trick.
BTW, make sure that Synchronet changes are actually there. I've
pushed them to master just today. You may need to pull from repo
again.
I was using the "Synchronet" branch. I'll switch to master.
But running it (via SSH) doesn't output anything, just exits
immediately. 'gedlnx --help' same, nothing.
Unfortunately there is a bug which hides usage message if no config
found. I've tried to fix it, but had to revert it back, because
correct fix is not that simple.
So then I searched for documentation. golded.org appears down.This
I saw you have CMakeLists.txt, so I tried using that to build.
time, a lot fewer errors and it output some promisingbinaries, but
again, running them produces no output:make
rswindell@git ~/golded-plus/out/golded3 (Synchronet) $ sudo
install [ 4%] Built target uulib [ 9%] Built target hunspell[ 34%]
Built target gall [ 53%] Built target gcfg [ 60%] Built targetgcui [
61%] Built target smblib [ 77%] Built target gmb3 [100%] Builttarget
golded Install the project... -- Install configuration: "" --error
Installing: /usr/local/bin/golded rswindell@git
~/golded-plus/out/golded3 (Synchronet) $ golded rswindell@git
~/golded-plus/out/golded3 (Synchronet) $
Maybe I need to create or edit a config file or something? An
message or *some* kind of output from running 'golded' couldbe
helpful.
You have to have config file. You may start from simple config file
from
here:
https://github.com/golded-plus/golded-plus/blob/master/cfgs/config/
simple.cf g
And then uncomment this line:
;AREAFILE SBBS R:\SBBS\ ; Synchronet BBS
dir
Set correct path to Synchronet directory. That shall do the trick.
Okay, where does goled need to find this simple.cfg file? I assume I
have to move or copy it somewhere that goled expects to find it.
But running it (via SSH) doesn't output anything, just exits
immediately. 'gedlnx --help' same, nothing.
@MSGID: 1:103/705 65e8cd2a
Hello Vitaliy!
Replying to a msg dated 06 Mar 24 12:54, from you to me.
I'm attempting a reply using GoldEd+ here.
One thing I noticed, the SBBS config points to the parent of the Synchronet
"control" directory rather than the ctrl directory itself (which is normally represnted by the SBBSCTRL environment variable). The control directory is not hard-coded to be "ctrl" anywhere, thought that is the default/stock configuration that most sysops keep. I would recommend that the GoldEd+ config file point to the path of the Synchronet "control" directory and not its parent directory. Or read this from the SBBSCRL env var.
-Rob
--- GoldED+/LNX 1.1.5-b20240303
# Origin: ----> Default GoldED Origin <---- (1:103/705)
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
@MSGID: 1:103/705 65e8cd2a
Finally a normal MSGID from a synchronet system! ;-)
@MSGID: 1:103/705 65e8cd2a
Finally a normal MSGID from a synchronet system! ;-)
Yeah, and it's a clearly-flawed one at that:
@MSGID: 1:103/705 65e8cd2a
Finally a normal MSGID from a synchronet system! ;-)
Yeah, and it's a clearly-flawed one at that:
time_t 1709755690 (0x65E8CD2A) ISO 2024-03-06 12:08:10.000-08:00
@MSGID: 1:103/705 65e8cd2a
Finally a normal MSGID from a synchronet system! ;-)
Yeah, and it's a clearly-flawed one at that:
It would be great if GoldED+ had an option like:
// Generate special, SBBS-style MSGIDs: "msgno.echotag@z:n/f[.p] serialno" SMSGID YES
It would be great if GoldED+ had an option like:
// Generate special, SBBS-style MSGIDs: "msgno.echotag@z:n/f[.p]
serialno" SMSGID YES
It would be a terrible idea.
I'm attempting a reply using GoldEd+ here.
One thing I noticed, the SBBS config points to the parent of the Synchronet "control" directory rather than the ctrl directory itself (which is normally represnted by the SBBSCTRL environment variable).
The control directory is not hard-coded to be "ctrl" anywhere, thought that is the default/stock configuration that most sysops keep. I would recommend that the GoldEd+ config file point to the path of the
Synchronet "control" directory and not its parent directory. Or read
this from the SBBSCRL env var.
Hi Rob,
On 06 Mar 24 17:31, Rob Swindell wrote to Wilfred van Velzen:
about: "Re: Synchronet config change":
@MSGID: 1:103/705 65e8cd2a
Finally a normal MSGID from a synchronet system! ;-)
Yeah, and it's a clearly-flawed one at that:
time_t 1709755690 (0x65E8CD2A) ISO 2024-03-06 12:08:10.000-08:00
That isn't a problem as long as it doesn't re-use it in 3 years. And it doesn't.
Hello Rob.
06 Mar 24 12:05, you wrote to me:
I'm attempting a reply using GoldEd+ here.
One thing I noticed, the SBBS config points to the parent of the Synchronet "control" directory rather than the ctrl directory itself (which is normally represnted by the SBBSCTRL environment variable). The control directory is not hard-coded to be "ctrl" anywhere, thought that is the default/stock configuration that most sysops keep. I would recommend that the GoldEd+ config file point to the path of the Synchronet "control" directory and not its parent directory. Or read this from the SBBSCRL env var.
Currently you may use three different options for Synchronet AreaFile:
1) Path to Synchronet root. And then Golded would assume that config is is ctrl directory.
2) Path to Synchronet control directory.
3) Path to msgs.ini itself.
And also GoldEd assumes that message bases located on the same level as control directory in "data/subs" directory.
I didn't invent that logic. Just added parsing ini in addition to cnf file.
I'm happy to change the way it configured. But I'm not an expert in Synchronet design. Could you please describe how it may be configured?
Maybe
would be better to parse main config file first and pull necessary directories from there?
It would be great if GoldED+ had an option like:
// Generate special, SBBS-style MSGIDs: "msgno.echotag@z:n/f[.p]
serialno" SMSGID YES
It would be a terrible idea.
Hello Rob.
06 Mar 24 12:05, you wrote to me:
I'm attempting a reply using GoldEd+ here.the
One thing I noticed, the SBBS config points to the parent of
Synchronet "control" directory rather than the ctrl directoryitself
(which is normally represnted by the SBBSCTRL environmentvariable).
The control directory is not hard-coded to be "ctrl" anywhere,thought
that is the default/stock configuration that most sysops keep.I would
recommend that the GoldEd+ config file point to the path ofthe
Synchronet "control" directory and not its parent directory.Or read
this from the SBBSCRL env var.
Currently you may use three different options for Synchronet
AreaFile:
1) Path to Synchronet root. And then Golded would assume that
config is is ctrl directory. 2) Path to Synchronet control
directory. 3) Path to msgs.ini itself.
Only methods 2 and 3 there would be valid. There's no real "Synchronet root".
And also GoldEd assumes that message bases located on the same
level as control directory in "data/subs" directory.
That would be incorrect. Each message base can actually be located anywhere (that's what 'data_dir' is used for - but it's it's blank,
then data/subs can be assumed, but the location of the 'data'
directory is also configurable in the [dir] section of main.ini).
I didn't invent that logic. Just added parsing ini in addition to
cnf file.
I'm happy to change the way it configured. But I'm not an expert in
Synchronet design. Could you please describe how it may be
configured?
SBBSCTRL (env var or other method of discovery) points to Synchronet "control" directory (which could be named/located anywhere), where you
can find main.ini which in turn defines the relative path (from the "control" directory) to the "data" directory.
Then parsing msgs.ini, each message area (sub) can have its own
"data_dir" defined (where to find the message base files themselves) -
if the data_dir isn't defined, then the "subs" sub-directory of the configured "data" directory is where the message base files are
expected to be found.
Maybe
would be better to parse main config file first and pull necessary
directories from there?
Yes, main.ini would need to be parsed as well (first).
Synchronet is open source and the most relevant source file, for reference, would be: https://gitlab.synchro.net/main/sbbs/-/blob/master/src/sbbs3/scfglib1.
c
But running it (via SSH) doesn't output anything, just exits
immediately. 'gedlnx --help' same, nothing.
This is the "no config" bug and it's more than 10 years old. Try
gedlnx -INSTALL
to create a minimal config or build your own from examples.
Hello Rob.
07 Mar 24 10:46, you wrote to me:
Hello Rob.
06 Mar 24 12:05, you wrote to me:
I'm attempting a reply using GoldEd+ here.the
One thing I noticed, the SBBS config points to the parent of
Synchronet "control" directory rather than the ctrl directoryitself
(which is normally represnted by the SBBSCTRL environmentvariable).
The control directory is not hard-coded to be "ctrl" anywhere,thought
that is the default/stock configuration that most sysops keep.I would
recommend that the GoldEd+ config file point to the path ofthe
Synchronet "control" directory and not its parent directory.Or read
this from the SBBSCRL env var.
Currently you may use three different options for Synchronet
AreaFile:
1) Path to Synchronet root. And then Golded would assume that
config is is ctrl directory. 2) Path to Synchronet control
directory. 3) Path to msgs.ini itself.
Only methods 2 and 3 there would be valid. There's no real "Synchronet root".
I'm inclining to rework it and use only method 3, but read main.ini first, then mail.ini.
And also GoldEd assumes that message bases located on the same
level as control directory in "data/subs" directory.
That would be incorrect. Each message base can actually be located anywhere (that's what 'data_dir' is used for - but it's it's blank, then data/subs can be assumed, but the location of the 'data'
directory is also configurable in the [dir] section of main.ini).
You're right. It does use data_dir if it's available in message base config. I forgot to mention that. Only if it's empty - it uses data/subs. I'll rework this too.
I didn't invent that logic. Just added parsing ini in addition to
cnf file.
I'm happy to change the way it configured. But I'm not an expert in
Synchronet design. Could you please describe how it may be
configured?
SBBSCTRL (env var or other method of discovery) points to Synchronet "control" directory (which could be named/located anywhere), where you can find main.ini which in turn defines the relative path (from the "control" directory) to the "data" directory.
Then parsing msgs.ini, each message area (sub) can have its own "data_dir" defined (where to find the message base files themselves) - if the data_dir isn't defined, then the "subs" sub-directory of the configured "data" directory is where the message base files are expected to be found.
Env var is not a good idea. Better to use path to main.ini. Am I right that all ini files shall be within control directory?
I used that file for reference when worked on this change. Thanks.
Wait for the next patch which will make it even better. BTW, I found one issue in my change which will make it fail to read message bases in windows. That will be fixed too.
But running it (via SSH) doesn't output anything, just exits
immediately. 'gedlnx --help' same, nothing.
This is the "no config" bug and it's more than 10 years old. Try
gedlnx -INSTALL
to create a minimal config or build your own from examples.
This was fixed in some builds ago, but it is back now. :(
./gedlnx -h >/dev/null helps. :)
The SBBSCTRL env var is a method of locating the main.ini file to
begin with. that's how most Synchronet utilities find it. Otherwise, you'll need store a path to it somewhere else (e.g. in a golded.cfg
file, like you do now).
I used that file for reference when worked on this change. Thanks.
Wait for the next patch which will make it even better. BTW, I
found one issue in my change which will make it fail to read
message bases in windows. That will be fixed too.
Nice! I only tested on Linux so far.
| Sysop: | altere |
|---|---|
| Location: | Houston, TX |
| Users: | 66 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 00:10:00 |
| Calls: | 599 |
| Files: | 7,638 |
| Messages: | 291,687 |