From Newsgroup: alt.bbs.synchronet

To: Digital Man
Digital Man,

I was curious if you could direct me to any existing documentation or example high-level configuration examples of how to configure Synchronet to split nodes between physical computers / virtual machines.

I've been toying with SBBS over NFS in my home lab, but I continue to run into file locking issues with the .dab files unless I disable local locking on the NFS mount.

Would you be willing to share some insight for how you have VERT and CVS configured? Are you using NFS, CIFS, or another method? Are there any particular tips/tricks/cavaets about your configuration that you can share?

I'm also interested to know what specific folders you host off of shared storage versus what you install locally on each physical node.


Thanks,
-WitNik
--- Synchronet 3.18a-Win32 NewsLink 1.113
* Vertrauen - Riverside County, California - telnet://vert.synchro.net
--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: alt.bbs.synchronet

Re: Vertrauen / SBBS / Shared Storage Configuration
By: Witnik to Digital Man on Mon Jul 27 2020 09:05 pm

I'd like to ask others what their experience is with SBBS when configuring multiple physical nodes. Most of the documentation that I've reviewed talks about using a legacy Network file sharing with something akin to Lantastic or MSClient from the DOS days.

While I understand I can pass provide parameters to SBBS to select the nodes on a given physical machine, the specific sharing methods (ex: cifs, nfs, etc) that are best supported interest me. Currently, I'm using Synology NAS as a storage backend for my BBS project and have gone round and round with various mount options in Linux and have found a combination that seems to work only if I disable remote locking on NFS.

I'm not sure if it is safe to run multiple nodes in this condition or what the optimum storage layout is for leveraging file shares. I've also tried hosting things on a CIFS mount. With CIFS, I'm able to run successfully run SBBS too, but I have not been able to get around the errors thrown when the bbs tries to create spy sockets. I know that I could just disable this feature, but I wanted to know if anyone else is running SBBS complete from a network share.

For others who may be interested this is what I've found to be most successful/stable so far for my RPi 4 running Raspberry PI OS (Buster):

cifs:
//nas/bbs /mnt/bbs cifs credentials=/root/.cifscreds,dir_mode=0770,file_mode=0770,uid=uid#,gid=gid#,iocharset=utf8,rsize=8192,wsize=8192,exec,mfsymlinks 0 0

nfs:
nas:/volume1/bbs /mnt/bbs nfs sec=sys,vers=3,_netdev,rw,exec,sync,nolock,auto,hard,nointr,tcp,rsize=8192,wsize=8192 0 0

Thanks,
-WitNik

Digital Man,

I was curious if you could direct me to any existing documentation or example high-level configuration examples of how to configure Synchronet to split nodes between physical computers / virtual machines.

I've been toying with SBBS over NFS in my home lab, but I continue to run into file locking issues with the .dab files unless I disable local locking on the NFS mount.

Would you be willing to share some insight for how you have VERT and CVS configured? Are you using NFS, CIFS, or another method? Are there any particular tips/tricks/cavaets about your configuration that you can share?

I'm also interested to know what specific folders you host off of shared storage versus what you install locally on each physical node.

Thanks,
-WitNik

--- Synchronet 3.18a-Win32 NewsLink 1.113
* Vertrauen - Riverside County, California - telnet://vert.synchro.net
--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: alt.bbs.synchronet

To: Witnik
Re: Vertrauen / SBBS / Shared Storage Configuration
By: Witnik to Digital Man on Mon Jul 27 2020 09:05 pm

Digital Man,

I was curious if you could direct me to any existing documentation or example high-level configuration examples of how to configure Synchronet to split nodes between physical computers / virtual machines.

I use a different sbbs.ini file for each set of nodes (e.g. sbbs.cvs.ini, sbbs.vert.ini), using the First/LastNode settings to separate them.

I've been toying with SBBS over NFS in my home lab, but I continue to run into file locking issues with the .dab files unless I disable local locking on the NFS mount.

Would you be willing to share some insight for how you have VERT and CVS configured? Are you using NFS, CIFS, or another method?

I'm using CIFS (Samba).

Are there any
particular tips/tricks/cavaets about your configuration that you can share?

Most of the caveats are with mixed-OS stuff, making sure your configuration will correctly exclude externals that are OS-specific or use the command-line magic stuff (e.g. %., %@) to run the right thing for the current server environment.

I'm also interested to know what specific folders you host off of shared storage versus what you install locally on each physical node.

I share my entire sbbs tree between all 3 instances. Only BBS "temp" directories are local.

digital man

Synchronet "Real Fact" #114:
Weedpuller "Geographic" http://youtu.be/cpzBDVgmWSA
Norco, CA WX: 94.1øF, 28.0% humidity, 3 mph ENE wind, 0.00 inches rain/24hrs --- Synchronet 3.18a-Win32 NewsLink 1.113
* Vertrauen - Riverside County, California - telnet://vert.synchro.net
--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: alt.bbs.synchronet

To: Digital Man
Re: Vertrauen / SBBS / Shared Storage Configuration
By: Digital Man to Witnik on Sat Aug 01 2020 12:04 pm

DM,

Thanks for the detailed reply. When I use the CIFS approach, most everything seems to work great and I don't get the odd locking issues with the .dab files like I do with most NFS-related configs; however, I haven't quite figured out the mount options to successful create the spy sockets. Could you share how you worked around this? I am probably not passing the proper mount parameters on the client, or need to place some advanced foo that escapes me on the SAMBA server for the share.

Thanks,
-John (aka WitNik)
--- Synchronet 3.18a-Win32 NewsLink 1.113
* Vertrauen - Riverside County, California - telnet://vert.synchro.net
--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: alt.bbs.synchronet

To: WitNik
Re: Vertrauen / SBBS / Shared Storage Configuration
By: WitNik to Digital Man on Sat Aug 01 2020 10:15 pm

Re: Vertrauen / SBBS / Shared Storage Configuration
By: Digital Man to Witnik on Sat Aug 01 2020 12:04 pm

DM,

Thanks for the detailed reply. When I use the CIFS approach, most everything seems to work great and I don't get the odd locking issues with the .dab files like I do with most NFS-related configs; however, I haven't quite figured out the mount options to successful create the spy sockets. Could you share how you worked around this?

I use local (not shared) directory for temp directories and the spy sockets (localspy#.sock) are created in the sbbs temp directory.

I am probably not passing the proper
mount parameters on the client, or need to place some advanced foo that escapes me on the SAMBA server for the share.

No need to try to share your temp files.

digital man

Sling Blade quote #15:
Doyle Hargraves: What'cha doin' with that lawn mower blade Karl?
Norco, CA WX: 74.7øF, 61.0% humidity, 0 mph SSE wind, 0.00 inches rain/24hrs --- Synchronet 3.18a-Win32 NewsLink 1.113
* Vertrauen - Riverside County, California - telnet://vert.synchro.net
--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: alt.bbs.synchronet

To: Digital Man
Re: Vertrauen / SBBS / Shared Storage Configuration
By: Digital Man to WitNik on Sat Aug 01 2020 10:20 pm

Thank you!
--- Synchronet 3.18a-Win32 NewsLink 1.113
* Vertrauen - Riverside County, California - telnet://vert.synchro.net
--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: alt.bbs.synchronet

To: Digital Man
Re: Vertrauen / SBBS / Shared Storage Configuration
By: Digital Man to Witnik on Sat Aug 01 2020 12:04 pm

I use a different sbbs.ini file for each set of nodes (e.g. sbbs.cvs.ini, sbbs.vert.ini), using the First/LastNode settings to separate them.

Ok, this makes sense because I've seen the command line switches.

I'm using CIFS (Samba).

Ironically, it is more stable in my tests on Linux than multiple flavors of NFS with SBBS.

I share my entire sbbs tree between all 3 instances. Only BBS "temp" directories are local.

While I don't plan on hosting windows binaries on the share, I would like to have AMD64 & ARM7 with Debian, as my goal is to have a non-public nodes for testing on WSL on my Windows computers that shares a common configuration and my prod lifecycle on my RPi4. Since the symbolic links persist between systems, how would you separate the architecturally different binaries? I could create separte exec folders, but I'm unsure about what components are shared. I could also just create different manual symlinks for each architecture like sbbs-arm and sbbs-x64. Would it be detrimental to leave temp and exec local for ease of deployment?

Thanks,
-WitNik
--- Synchronet 3.18a-Win32 NewsLink 1.113
* Vertrauen - Riverside County, California - telnet://vert.synchro.net
--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: alt.bbs.synchronet

To: WitNik
Re: Vertrauen / SBBS / Shared Storage Configuration
By: WitNik to Digital Man on Sun Aug 02 2020 12:21 pm

Re: Vertrauen / SBBS / Shared Storage Configuration
By: Digital Man to Witnik on Sat Aug 01 2020 12:04 pm

I use a different sbbs.ini file for each set of nodes (e.g. sbbs.cvs.ini, sbbs.vert.ini), using the First/LastNode settings to separate them.

Ok, this makes sense because I've seen the command line switches.

I'm using CIFS (Samba).

Ironically, it is more stable in my tests on Linux than multiple flavors of NFS with SBBS.

I haven't tried running Synchronet over NFS. I believe Deuce has (or does?).

I share my entire sbbs tree between all 3 instances. Only BBS "temp" directories are local.

While I don't plan on hosting windows binaries on the share, I would like to have AMD64 & ARM7 with Debian, as my goal is to have a non-public nodes for testing on WSL on my Windows computers that shares a common configuration and my prod lifecycle on my RPi4. Since the symbolic links persist between systems, how would you separate the architecturally different binaries?

The binary executables don't *have* to be located in your sbbs/exec directory. But if you want to keep the binaries in exec, it would take some reconfiguring, but you could make a sub-directory for different Linux archs (e.g. exec/linux-arm64/* and exec/linux-amd64/*) or tack the architecture onto the filenames (e.g. exec/sbbs-linux-arm64). Then your command-lines in SCFG which execute anything from exec (%! prefix), you'd need to add the achitecture and currently there's no command-line specifier ("%x") to achieve that.

I
could create separte exec folders, but I'm unsure about what components are shared. I could also just create different manual symlinks for each architecture like sbbs-arm and sbbs-x64. Would it be detrimental to leave temp and exec local for ease of deployment?

No detriment to having exec as a local directory. That's one of the reasons the location is configurable in SCFG. Just make sure if you modify something in exec for one server/instance, you do so for the others too. That's a good reason to use the mods directory (which could/should remain shared).

digital man

Synchronet "Real Fact" #105:
Synchronet channel: http://www.youtube.com/channel/UCsQ8iXU5yvrybyoEgo__97A Norco, CA WX: 92.9øF, 34.0% humidity, 7 mph NNE wind, 0.00 inches rain/24hrs --- Synchronet 3.18a-Win32 NewsLink 1.113
* Vertrauen - Riverside County, California - telnet://vert.synchro.net
--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: alt.bbs.synchronet

To: Digital Man
Re: Vertrauen / SBBS / Shared Storage Configuration
By: Digital Man to WitNik on Sun Aug 02 2020 01:07 pm

While I don't plan on hosting windows binaries on the share, I would like to have AMD64 & ARM7 with Debian, as my goal is to have a non-public nodes for testing on WSL on my Windows computers that shares a common configuration and my prod lifecycle on my RPi4. Since the symbolic links persist between systems, how would you separate the architecturally different binaries?

The binary executables don't *have* to be located in your sbbs/exec directory. But if you want to keep the binaries in exec, it would take some reconfiguring, but you could make a sub-directory for different Linux archs (e.g. exec/linux-arm64/* and exec/linux-amd64/*) or tack the architecture onto the filenames (e.g. exec/sbbs-linux-arm64). Then your command-lines in SCFG which execute anything from exec (%! prefix), you'd need to add the achitecture and currently there's no command-line specifier ("%x") to achieve that.
No detriment to having exec as a local directory. That's one of the reasons the location is configurable in SCFG. Just make sure if you modify something in exec for one server/instance, you do so for the others too. That's a good reason to use the mods directory (which could/should remain shared).

Thank you for the detailed explaination. While I saw that you could specify specific locations for 'exec' I didn't know if they had to be shared or what the cost was in overall convience of configuration.

-WitNik
--- Synchronet 3.18a-Win32 NewsLink 1.113
* Vertrauen - Riverside County, California - telnet://vert.synchro.net
--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: alt.bbs.synchronet

To: Digital Man
Re: Vertrauen / SBBS / Shared Storage Configuration
By: WitNik to Digital Man on Sun Aug 02 2020 01:56 pm

Digital Man,

The local temp directory did the trick, but it seems I record 1 error now on the latest build:

8/3 00:22:50 stat Unable to bind to /sbbs/ctrl/status.sock

Are you exeriencing this error with your config? If I move the ctrl directory to a local disk (non-SAMBA share) it works fine. I've tried mounting CIFS with the sfu option to see if that helped, but it hasn't made a difference.

Thanks,
-WitNik
--- Synchronet 3.18a-Win32 NewsLink 1.113
* Vertrauen - Riverside County, California - telnet://vert.synchro.net
--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: alt.bbs.synchronet

To: WitNik
Re: Vertrauen / SBBS / Shared Storage Configuration
By: WitNik to Digital Man on Mon Aug 03 2020 12:30 am

Re: Vertrauen / SBBS / Shared Storage Configuration
By: WitNik to Digital Man on Sun Aug 02 2020 01:56 pm

Digital Man,

The local temp directory did the trick, but it seems I record 1 error now on the latest build:

8/3 00:22:50 stat Unable to bind to /sbbs/ctrl/status.sock

Are you exeriencing this error with your config?

No, but my non-local servers are running Windows (not *nix), so that status.sock thing isn't used on them.

Looking at that status socket stuff (I didn't write), it looks like it takes the filename from the sbbs.ini filename specified on the sbbs command-line. So if you use an sbbs.ini file on the local system, not in the ctrl directory, then it should use that location as the base of the status.sock filename. At least, that's what it looks like to me.

If I move the ctrl
directory to a local disk (non-SAMBA share) it works fine. I've tried mounting CIFS with the sfu option to see if that helped, but it hasn't made a difference.

I imagine unix domain sockets require a real (not network-share) file path.

digital man

This Is Spinal Tap quote #43:
I feel my role in the band is ... kind of like lukewarm water.
Norco, CA WX: 64.1øF, 88.0% humidity, 0 mph S wind, 0.00 inches rain/24hrs
--- Synchronet 3.18a-Win32 NewsLink 1.113
* Vertrauen - Riverside County, California - telnet://vert.synchro.net
--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: alt.bbs.synchronet

To: Digital Man
Re: Vertrauen / SBBS / Shared Storage Configuration
By: Digital Man to WitNik on Mon Aug 03 2020 02:16 am

Re: Vertrauen / SBBS / Shared Storage Configuration
By: WitNik to Digital Man on Mon Aug 03 2020 12:30 am

Re: Vertrauen / SBBS / Shared Storage Configuration
By: WitNik to Digital Man on Sun Aug 02 2020 01:56 pm

Digital Man,

The local temp directory did the trick, but it seems I record 1 error now on the latest build:

8/3 00:22:50 stat Unable to bind to /sbbs/ctrl/status.sock

Are you exeriencing this error with your config?

No, but my non-local servers are running Windows (not *nix), so that status.sock thing isn't used on them.

Looking at that status socket stuff (I didn't write), it looks like it takes the filename from the sbbs.ini filename specified on the sbbs command-line. So if you use an sbbs.ini file on the local system, not in the ctrl directory, then it should use that location as the base of the status.sock filename. At least, that's what it looks like to me.

If I move the ctrl
directory to a local disk (non-SAMBA share) it works fine. I've tried mounting CIFS with the sfu option to see if that helped, but it hasn't made a difference.

I imagine unix domain sockets require a real (not network-share) file path.

digital man

This Is Spinal Tap quote #43:
I feel my role in the band is ... kind of like lukewarm water.
Norco, CA WX: 64.1øF, 88.0% humidity, 0 mph S wind, 0.00 inches rain/24hrs

Awesome! I'll try relocating the .ini file. Thank you!
--- Synchronet 3.18a-Win32 NewsLink 1.113
* Vertrauen - Riverside County, California - telnet://vert.synchro.net
--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: alt.bbs.synchronet

To: Digital Man
Re: Vertrauen / SBBS / Shared Storage Configuration
By: WitNik to Digital Man on Mon Aug 03 2020 11:51 am

I imagine unix domain sockets require a real (not network-share) file path.

Awesome! I'll try relocating the .ini file. Thank you!

It worked perfectly. Thank you again for the tip about moving the .ini file to cause the socket to also relocate.

-WitNik
--- Synchronet 3.18a-Win32 NewsLink 1.113
* Vertrauen - Riverside County, California - telnet://vert.synchro.net
--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: alt.bbs.synchronet

Re: Vertrauen / SBBS / Shared Storage Configuration
By: WitNik to All on Thu Jul 30 2020 11:42 pm

For others who may be interested this is what I've found to be most successful/stable so far for my RPi 4 running Raspberry PI OS (Buster):

cifs:
//nas/bbs /mnt/bbs cifs credentials=/root/.cifscreds,dir_mode=0770,file_mode=07 70,uid=uid#,gid=gid#,iocharset=utf8,rsize=8192,wsize=8192,exec,mfsymlinks 0 0

I've gotten a revision to this specifically for those of you who may be using Synology NAS solutions:

cifs:
cifs:
//nas/bbs /mnt/bbs cifs credentials=/root/.cifscreds,vers=3.1.1,dir_mode=0770,file_mode=0770,uid=uid#,gid=gid#,iocharset=utf8,rsize=8192,wsize=8192,exec,mfsymlinks,noserverino 0 0

The addition of specifying the version of SMB/CIFS cleared up console errors, as well as the addition of noserverino.

Also, while tuning and optimizing the connection, I've had stability issues when using opportunistic locks or enabling SMB durable handles (Cross-protocol file locking).

I do have the following advanced Synology CIFS settings enabled only:

Max SMB Protocol = SMB3
Min SMB Protocol = SMB2 & Large MTU
Transport encryption mode = Force (this slows things down, but I'm not a fan of cleartext file-sharing)

+ Enable DirSort VFS module
+ Allow symbolic links within shared folders
++ Allow symbolic links across shared folders
+ Enable MSDFS VGS module

Anyhow, I hope this helps someone else out. I'll continue to post updates as I refine my running config.

Thanks,
-WitNik
--- Synchronet 3.18a-Win32 NewsLink 1.113
* Vertrauen - Riverside County, California - telnet://vert.synchro.net
--- Synchronet 3.19c-Linux NewsLink 1.113