• NodeX to Node/X directories

    From Michael J. Ryan@1:103/705 to GitLab issue in main/sbbs on Sun Jan 3 10:31:07 2021
    open https://gitlab.synchro.net/main/sbbs/-/issues/199

    I know there was a discussion on this previously in dovenet, and am not sure what came of it.Would be nice if the node directories were easier to move to a shared common subdirectory for easier volume mount/usage with Docker specifically. Instead of `../Node1` it would be `../Node/1` though it would make a nicer default imo, would be a hiccup for migration of existing servers, and the relative path being an extra layer deep, but it might be worth exploring.
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Sun Jan 3 13:32:00 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/199#note_1267

    The resolution was that I again made the node directories configurable (they were in v2 and earlier).http://cvs.synchro.net/gitpushlog.ssjs#87778c43569eb6c3d560f3df063e54d 6b866cb39
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Gamgee@1:103/705 to Michael J. Ryan on Sun Jan 3 14:50:00 2021
    Michael J. Ryan wrote to GitLab issue in main/sbbs <=-

    open https://gitlab.synchro.net/main/sbbs/-/issues/199

    I know there was a discussion on this previously in dovenet, and
    am not sure what came of it.

    Would be nice if the node directories were easier to move to a
    shared common subdirectory for easier volume mount/usage with
    Docker specifically. Instead of `../Node1` it would be
    `../Node/1` though it would make a nicer default imo, would be a
    hiccup for migration of existing servers, and the relative path
    being an extra layer deep, but it might be worth exploring.

    How many people run SBBS in Docker? My guess is < 10.



    ... Backup not found: (A)bort (R)etry (P)anic
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Michael J. Ryan on Mon Jan 4 10:32:12 2021
    Re: NodeX to Node/X directories
    By: Michael J. Ryan to GitLab issue in main/sbbs on Sun Jan 03 2021 10:31 am

    Howdy,

    Would be nice if the node directories were easier to move to a shared
    common subdirectory for easier volume mount/usage with
    Docker specifically. Instead of `../Node1` it would be `../Node/1`
    though it would make a nicer default imo, would be a
    hiccup for migration of existing servers, and the relative path being an
    extra layer deep, but it might be worth exploring.

    Yeah, I bought this up previously. Unfortuantely it might be somewhat breaking for existing users who upgrade.

    There are 2 workarounds:

    * Rob made it easier to change a line in the source code before you compile, that will have the default as you want.

    * Create your own default "main.cnf" with the right paths and include that in your image (that you copy to the ctrl dir on first startup). (You still need this, even if you change the source code above.)

    ...ëîåï

    ... We should weep for men at their birth, not their death.

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Sun Jan 3 17:46:19 2021
    Re: NodeX to Node/X directories
    By: deon to Michael J. Ryan on Mon Jan 04 2021 10:32 am

    Re: NodeX to Node/X directories
    By: Michael J. Ryan to GitLab issue in main/sbbs on Sun Jan 03 2021 10:31 am

    Howdy,

    Would be nice if the node directories were easier to move to a shared common subdirectory for easier volume mount/usage with
    Docker specifically. Instead of `../Node1` it would be `../Node/1` though it would make a nicer default imo, would be a
    hiccup for migration of existing servers, and the relative path being an extra layer deep, but it might be worth exploring.

    Yeah, I bought this up previously. Unfortuantely it might be somewhat breaking for existing users who upgrade.

    There are 2 workarounds:

    * Rob made it easier to change a line in the source code before you
    compile,
    that will have the default as you want.

    * Create your own default "main.cnf" with the right paths and include that in your image (that you copy to the ctrl dir on first startup). (You still need this, even if you change the source code above.)

    What source code change are you referring to?
    --
    digital man

    Sling Blade quote #13:
    Karl: He lives inside of his own heart. That's an awful big place to live in. Norco, CA WX: 55.5øF, 78.0% humidity, 2 mph E wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Digital Man on Mon Jan 4 21:39:07 2021
    Re: NodeX to Node/X directories
    By: Digital Man to deon on Sun Jan 03 2021 05:46 pm

    Howdy,

    There are 2 workarounds:
    * Rob made it easier to change a line in the source code before you compile, that will have the default as you want.
    What source code change are you referring to?

    This one:

    diff --git a/src/sbbs3/scfg/scfgnode.c b/src/sbbs3/scfg/scfgnode.c
    index 54c80f74e..d6db3beeb 100644
    -+- a/src/sbbs3/scfg/scfgnode.c
    +++ b/src/sbbs3/scfg/scfgnode.c
    @@ -118,7 +118,7 @@ void node_menu()
    SAFECOPY(cfg.node_dir,cfg.node_path[cfg.sys_nodes-1]);
    i=cfg.sys_nodes+1;
    load_node_cfg(&cfg,error);
    - sprintf(str,"../node%d/",i);
    + sprintf(str,"../nodes/node%d/",i);
    sprintf(tmp,"Node %d Directory",i);
    uifc.helpbuf=node_path_help;
    j=uifc.input(WIN_MID,0,0,tmp,str,50,K_EDIT);
    diff --git a/src/sbbs3/scfgsave.c b/src/sbbs3/scfgsave.c
    index 9f40f4a4c..a36ad0ce4 100644
    -+- a/src/sbbs3/scfgsave.c
    +++ b/src/sbbs3/scfgsave.c
    @@ -173,7 +173,7 @@ BOOL DLLCALL write_main_cfg(scfg_t* cfg, int backup_level)
    put_int(cfg->sys_nodes,stream);
    for(i=0;i<cfg->sys_nodes;i++) {
    if(cfg->node_path[i][0] == 0)
    - SAFEPRINTF(cfg->node_path[i], "../node%u", i + 1);
    + SAFEPRINTF(cfg->node_path[i], "../nodes/node%u", i + 1);
    put_str(cfg->node_path[i],stream);
    }
    backslash(cfg->data_dir);

    ...ëîåï

    ... When two Englishmen meet their first talk is of the weather.

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Mon Jan 4 11:09:41 2021
    Re: NodeX to Node/X directories
    By: deon to Digital Man on Mon Jan 04 2021 09:39 pm

    Re: NodeX to Node/X directories
    By: Digital Man to deon on Sun Jan 03 2021 05:46 pm

    Howdy,

    There are 2 workarounds:
    * Rob made it easier to change a line in the source code before you compile, that will have the default as you want.
    What source code change are you referring to?

    This one:

    diff --git a/src/sbbs3/scfg/scfgnode.c b/src/sbbs3/scfg/scfgnode.c
    index 54c80f74e..d6db3beeb 100644
    -+- a/src/sbbs3/scfg/scfgnode.c
    +++ b/src/sbbs3/scfg/scfgnode.c
    @@ -118,7 +118,7 @@ void node_menu()

    SAFECOPY(cfg.node_dir,cfg.node_path[cfg.sys_nodes-1]);
    i=cfg.sys_nodes+1;
    load_node_cfg(&cfg,error);
    - sprintf(str,"../node%d/",i);
    + sprintf(str,"../nodes/node%d/",i);
    sprintf(tmp,"Node %d Directory",i);

    That just changes the default string in the edit box. Simply typing "../nodes/nodeX" would accomplish the same thing with no code change.

    uifc.helpbuf=node_path_help;
    j=uifc.input(WIN_MID,0,0,tmp,str,50,K_EDIT);
    diff --git a/src/sbbs3/scfgsave.c b/src/sbbs3/scfgsave.c
    index 9f40f4a4c..a36ad0ce4 100644
    -+- a/src/sbbs3/scfgsave.c
    +++ b/src/sbbs3/scfgsave.c
    @@ -173,7 +173,7 @@ BOOL DLLCALL write_main_cfg(scfg_t* cfg, int backup_level)
    put_int(cfg->sys_nodes,stream);
    for(i=0;i<cfg->sys_nodes;i++) {
    if(cfg->node_path[i][0] == 0)
    - SAFEPRINTF(cfg->node_path[i], "../node%u", i + 1);
    + SAFEPRINTF(cfg->node_path[i], "../nodes/node%u", i

    That code change should not be necessary as the node_path will not normally be blank now.

    Neither of those code changes appear necessary.
    --
    digital man

    Rush quote #59:
    He's got a force field and a flexible plan, got a date w/fate in a black sedan Norco, CA WX: 61.8øF, 53.0% humidity, 0 mph S wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Digital Man on Tue Jan 5 10:42:42 2021
    Re: NodeX to Node/X directories
    By: Digital Man to deon on Mon Jan 04 2021 11:09 am

    That just changes the default string in the edit box. Simply typing
    "../nodes/nodeX" would accomplish the same thing with no
    code change.
    Neither of those code changes appear necessary.

    Sure, but when you are running in a container, you want the "defaults" to be as correct as possible and have less chance of making mistakes - and then figuring out why things are not working as intended. This achieves it.

    It would be nice that this hack could be achieved programatically, during build time, or set in some ini so that the patch is not required. That includes making the "initial" main.cnf with the right paths, without having to edit them on first run for a new instance.




    ...ëîåï

    ... Advertising is legalized lying.

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Mon Jan 4 19:32:28 2021
    Re: NodeX to Node/X directories
    By: deon to Digital Man on Tue Jan 05 2021 10:42 am

    Re: NodeX to Node/X directories
    By: Digital Man to deon on Mon Jan 04 2021 11:09 am

    That just changes the default string in the edit box. Simply typing "../nodes/nodeX" would accomplish the same thing with no
    code change.
    Neither of those code changes appear necessary.

    Sure, but when you are running in a container, you want the "defaults" to
    be
    as correct as possible and have less chance of making mistakes - and then figuring out why things are not working as intended. This achieves it.

    There are hundreds, possibly thousands of default settings in SBBS. You wan't everyone of those settings to be similar to your desired BBS configuration? That doesn't compute.

    It would be nice that this hack could be achieved programatically, during build time, or set in some ini so that the patch is not required. That includes making the "initial" main.cnf with the right paths, without having to edit them on first run for a new instance.

    What "initial" main.cnf - you mean the one from Git?

    I still understand why the would would be "required" by anyone. Are you setting up a new BBS every time you open your BBS container?
    --
    digital man

    Synchronet/BBS Terminology Definition #5:
    BBS = Bulletin Board System
    Norco, CA WX: 53.3øF, 84.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Digital Man on Tue Jan 5 16:31:42 2021
    Re: NodeX to Node/X directories
    By: Digital Man to deon on Mon Jan 04 2021 07:32 pm

    There are hundreds, possibly thousands of default settings in SBBS. You
    wan't everyone of those settings to be similar to
    your desired BBS configuration? That doesn't compute.

    No.

    What "initial" main.cnf - you mean the one from Git?
    I still understand why the would would be "required" by anyone. Are you
    setting up a new BBS every time you open your BBS
    container?

    There are potentially an unlimited number of folks who may use my (or anyone elses) "Synchronet Image". And so yes, the first time they use it, it is likely to be a "new" install. Making this setting improved for "most use cases", means that it is an instruction that doesnt need to be mandatory, but rather optional.

    Oh, and to be clear, its isnt really mandatory, there are workarounds for everything and it would be 1 less workaround which would be a good thing.

    Sure, folks will go into scfg and "change" settings that personalise their SBBS environent, but making changes so that it works without problems is a change that isnt needed if its done upstream. (And this instance upstream means the builder of the image.)

    DM, IMHO, the first time user of Synchronet finds it complicated (I know I did). The method of updating it is also complicated - just revisit the conversations in IRC and DoveNet of when things changed from CVS to GIT.

    A docker image takes away *all* that complexity, is easier to support, standardises installation but still lets end users configure it how they want. Folks wouldnt even see or use git at all. And since you now use gitlab, images can be built automatically from a commit. That's why I use docker images.

    (And sure the above statement references linux installs - probably doesnt help windows users, but I'm sure there are tools on Windows that would make deployment easier.)

    ...ëîåï

    ... Heads will have to roll!

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Digital Man on Tue Jan 5 16:36:42 2021
    Re: NodeX to Node/X directories
    By: Digital Man to deon on Mon Jan 04 2021 07:32 pm

    What "initial" main.cnf - you mean the one from Git?

    Oh, I didnt answer this.

    The main.cnf you have in git references node paths as ../node1, ../node2, and thus are in the parent of the "ctrl" directory.

    From what I can gather (I did ask previously), this main.cnf is not "created" at compile time, but rather a static file with "defaults" for a new install. So folks who want their "initial" nodes in a "nodes" subdirectory would need to change this on first startup.

    And back to the docker discussion, my workaround is to provide my own "main.cnf" in the image so that these values dont need to be changed on a first time install.

    ...ëîåï

    ... Anyone who lives within his means suffers from a lack of imagination.

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Tue Jan 5 02:04:00 2021
    Re: NodeX to Node/X directories
    By: deon to Digital Man on Tue Jan 05 2021 04:36 pm

    Re: NodeX to Node/X directories
    By: Digital Man to deon on Mon Jan 04 2021 07:32 pm

    What "initial" main.cnf - you mean the one from Git?

    Oh, I didnt answer this.

    The main.cnf you have in git references node paths as ../node1, ../node2, and thus are in the parent of the "ctrl" directory.

    From what I can gather (I did ask previously), this main.cnf is not "created" at compile time, but rather a static file with "defaults" for a new install. So folks who want their "initial" nodes in a "nodes" subdirectory would need to change this on first startup.

    And back to the docker discussion, my workaround is to provide my own "main.cnf" in the image so that these values dont need to be changed on a first time install.

    Okay, so if your own main.cnf includes node paths of "../node/nodeX", why do you then need the code change? Is it just in case the sysop wants more than 4 nodes (or however many you have configured), they're not confused and accept the "../nodeX" default? It's a pretty trivial change to have additional node default paths be derived from whatever was configured for the previous node (or node 1). I'll make that change and let me know how that works for you. I don't see any reason for the suggested change to scfgsave.c however.
    --
    digital man

    Synchronet "Real Fact" #87:
    Synchronet Message Base and its library, SMBLIB, was used by AXiS BBS Software.
    Norco, CA WX: 47.0øF, 93.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Digital Man on Tue Jan 5 22:05:14 2021
    Re: NodeX to Node/X directories
    By: Digital Man to deon on Tue Jan 05 2021 02:04 am

    Howdy,

    And back to the docker discussion, my workaround is to provide my own "main.cnf" in the image so that these values dont
    need
    to be changed on a first time install.

    Okay, so if your own main.cnf includes node paths of "../node/nodeX", why
    do you then need the code change? Is it just in
    case the sysop wants more than 4 nodes (or however many you have
    configured), they're not confused and accept the "../nodeX"
    default?

    Yes.

    It's a pretty trivial change to have additional node default paths be
    derived from whatever was configured for the
    previous node (or node 1). I'll make that change and let me know how that
    works for you. I don't see any reason for the
    suggested change to scfgsave.c however.

    I havent tried your change, but I looked at the commit, and it looks like it will help immensely thank you. I agree, with it, my patch is no longer required.

    With this commit, and a modified main.cnf (with the right initial node1-4 paths) include in a docker image, it means that no thought needs to be made when configuring more nodes unless you actually want them in a different location (and in docker, you probably wouldnt do that, but if you did then that can be done "outside" of the container anyway).

    Another thought on this topic if I may.

    Could the nodes directories be considered emphemeral (with the exception of node.cnf)? IE: When sbbs is stopped, if those node dirs were deleted, there is nothing lost? The contents of a node dir is only useful while somebody is actually on the node?

    The reason I'm asking, is I'm considering having nodes/ as a tmpfs mount, which will mean that everytime sbbs is started the contents of that directory (and nodeX subdirectories would be empty).

    If they are emphemeral, then the only problem I have with a tmpfs strategy is the creation of node.cnf in the nodeX directory. I've noticed that scfg creates them, but sbbs will abort if it doesnt exist. (So you need to run scfg before you start sbbs - or I need to copy a "default" node.cnf in place before starting sbbs).

    ...ëîåï

    ... Morality is the attitude we adopt to people whom we personally dislike.

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Gamgee@1:103/705 to deon on Tue Jan 5 07:39:00 2021
    deon wrote to Digital Man <=-

    A docker image takes away *all* that complexity, is easier to
    support, standardises installation but still lets end users
    configure it how they want. Folks wouldnt even see or use git at
    all. And since you now use gitlab, images can be built
    automatically from a commit. That's why I use docker images.

    An "already configured" image like that isn't of any use to people
    that don't use Docker.

    How many people use Docker with SBBS?

    I'd guess that 99% of SBBS users don't use Docker.



    ... Internal Error: The system has been taken over by sheep at line 19960
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Tue Jan 5 11:07:39 2021
    Re: NodeX to Node/X directories
    By: deon to Digital Man on Tue Jan 05 2021 10:05 pm

    It's a pretty trivial change to have additional node default paths be derived from whatever was configured for the
    previous node (or node 1). I'll make that change and let me know how that works for you. I don't see any reason for the
    suggested change to scfgsave.c however.

    I havent tried your change, but I looked at the commit, and it looks like
    it
    will help immensely thank you. I agree, with it, my patch is no longer required.

    Okay, cool.

    Another thought on this topic if I may.

    Could the nodes directories be considered emphemeral (with the exception of node.cnf)? IE: When sbbs is stopped, if those node dirs were deleted, there is nothing lost? The contents of a node dir is only useful while somebody
    is
    actually on the node?

    Probably/usually. The exception would be where the sysop has node-specific configuration files for external programs (e.g. external editors) and wants to store those in the node directories for convenience, but that's an edge-case. I used to do that WWIVedit config files, for example, when I had different nodes with different communications configuration needs. I don't any longer.

    If they are emphemeral, then the only problem I have with a tmpfs strategy is the creation of node.cnf in the nodeX directory. I've noticed that scfg creates them, but sbbs will abort if it doesnt exist. (So you need to run scfg before you start sbbs - or I need to copy a "default" node.cnf in
    place
    before starting sbbs).

    The current builds of Synchronet will "fall back" to the "first node" (e.g. node 1) configuration if the current node's node.cnf file is missing (during node thread initialization, which happens upon terminal-client connection). A warning message is logged, but the node thread still initializes and starts successfully. Are you seeing something different?
    --
    digital man

    This Is Spinal Tap quote #24:
    David St. Hubbins: You're a haughty one, saucy Jack.
    Norco, CA WX: 61.9øF, 65.0% humidity, 1 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to Gamgee on Tue Jan 5 11:17:21 2021
    Re: Re: NodeX to Node/X directories
    By: Gamgee to deon on Tue Jan 05 2021 07:39 am

    deon wrote to Digital Man <=-

    A docker image takes away *all* that complexity, is easier to
    support, standardises installation but still lets end users
    configure it how they want. Folks wouldnt even see or use git at
    all. And since you now use gitlab, images can be built
    automatically from a commit. That's why I use docker images.

    An "already configured" image like that isn't of any use to people
    that don't use Docker.

    And Docker containers run in VMs which come with their own performance penalties and issues (e.g. DOSemu compatibility). The idea is not appealing to me.

    I came upon Linux "snaps" a couple of years ago and created a SyncTERM snap (or tried to) and gave up in frustration after a few days of work into it. I think you're just trading one set of issues for another with these container systems.
    --
    digital man

    Sling Blade quote #1:
    Karl: I've killed Doyle with a lawn mower blade. Yes, I'm right sure of it. Norco, CA WX: 64.7øF, 59.0% humidity, 3 mph N wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Gamgee@1:103/705 to Digital Man on Tue Jan 5 14:07:00 2021
    Digital Man wrote to Gamgee <=-

    deon wrote to Digital Man <=-

    A docker image takes away *all* that complexity, is easier to
    support, standardises installation but still lets end users
    configure it how they want. Folks wouldnt even see or use git at
    all. And since you now use gitlab, images can be built
    automatically from a commit. That's why I use docker images.

    An "already configured" image like that isn't of any use to people
    that don't use Docker.

    And Docker containers run in VMs which come with their own
    performance penalties and issues (e.g. DOSemu compatibility). The
    idea is not appealing to me.

    Nor to me. Don't even see the point of it, other than over-worrying
    about "security".

    I came upon Linux "snaps" a couple of years ago and created a
    SyncTERM snap (or tried to) and gave up in frustration after a
    few days of work into it. I think you're just trading one set of
    issues for another with these container systems.

    I have no use for them (containers), and haven't had the need to use a
    Snap package yet either. Hopefully both trends continue. :-)



    ... A woman drove me to drink, and I never had the courtesy to thank her.
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Gamgee on Wed Jan 6 08:59:39 2021
    Re: Re: NodeX to Node/X directories
    By: Gamgee to deon on Tue Jan 05 2021 07:39 am

    Howdy,

    An "already configured" image like that isn't of any use to people
    that don't use Docker.

    By definition, docker images are not "configured".

    How many people use Docker with SBBS?
    I'd guess that 99% of SBBS users don't use Docker.

    Sure, maybe.

    ...ëîåï

    ... Extremely happy and extremely unhappy men are alike prone to grow hard-hea

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Digital Man on Wed Jan 6 09:38:06 2021
    Re: Re: NodeX to Node/X directories
    By: Digital Man to Gamgee on Tue Jan 05 2021 11:17 am

    And Docker containers run in VMs which come with their own performance
    penalties and issues (e.g. DOSemu compatibility). The
    idea is not appealing to me.

    Sorry not true (the "contains run in VMs part").

    Performance penalties is subjective, but probably true when using docker NAT. Not really an issue for a BBS environment. And "issues" is subjective, because things need to be done differently. IMHO, its a good different, it forces system admins to do things better with an impact if you dont.

    Not sure what the dosemu compatibility is a reference to - but I run my 4 node 1995 Ezycom in a docker container with dosemu.

    This might be helpful: https://containerjournal.com/features/docker-not-faster-vms-just-efficient/

    https://stackoverflow.com/questions/21889053/what-is-the-runtime-performance-co st-of-a-docker-container

    ...ëîåï

    ... Heavy, adj.: Seduced by the chocolate side of the force.

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Gamgee on Wed Jan 6 09:39:15 2021
    Re: Re: NodeX to Node/X directories
    By: Gamgee to Digital Man on Tue Jan 05 2021 02:07 pm

    Nor to me. Don't even see the point of it, other than over-worrying about "security".

    What security do you worry about?

    ...ëîåï

    ... Why risk a hangover? Stay Drunk!!

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Gamgee@1:103/705 to deon on Tue Jan 5 21:13:00 2021
    deon wrote to Gamgee <=-

    An "already configured" image like that isn't of any use to people
    that don't use Docker.

    By definition, docker images are not "configured".

    Well, I'm confused then, because I thought you were talking about
    getting an SBBS configured just the way you want it, running in a
    Docker container, and then "saving" that image so it can be easily re-deployed. I'd call that "configuring" an image.

    How many people use Docker with SBBS?
    I'd guess that 99% of SBBS users don't use Docker.

    Sure, maybe.

    Right. So why alter SBBS code to better suit Docker use, when almost
    nobody uses that?



    ... Gone crazy, be back later, please leave message.
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Gamgee@1:103/705 to deon on Tue Jan 5 21:17:00 2021
    deon wrote to Gamgee <=-

    Nor to me. Don't even see the point of it, other than over-worrying
    about "security".

    What security do you worry about?

    Well, the same as most folks, I guess. Root exploits, basic firewall security, and so forth. But I don't stress over it too much.

    My counter-question to you is: Why would I want/need to run SBBS in a
    Docker container? What benefit does that offer? Do you run it that
    way to improve security? (I might be way off, but I thought I remember
    that as one of the reasons for using containers). If I am mistaken
    about that, please enlighten me as to how a container is beneficial.



    ... All the easy problems have been solved.
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Tue Jan 5 20:42:23 2021
    Re: Re: NodeX to Node/X directories
    By: deon to Digital Man on Wed Jan 06 2021 09:38 am

    Re: Re: NodeX to Node/X directories
    By: Digital Man to Gamgee on Tue Jan 05 2021 11:17 am

    And Docker containers run in VMs which come with their own performance penalties and issues (e.g. DOSemu compatibility). The
    idea is not appealing to me.

    Sorry not true (the "contains run in VMs part").

    Sorry, "OS-level virtualization". :-)

    Performance penalties is subjective, but probably true when using docker NAT. Not really an issue for a BBS environment. And "issues" is subjective, because things need to be done differently. IMHO, its a good different, it forces system admins to do things better with an impact if you dont.

    "virtualization" of any kind to me just implies more layers (be it software or hardware) and those layer incur some amount of performance penalty. Maybe it's immeasurable with Docker, I don't know.

    Not sure what the dosemu compatibility is a reference to - but I run my 4 node 1995 Ezycom in a docker container with dosemu.

    This might be helpful: https://containerjournal.com/features/docker-not-faster-vms-just-efficient/


    https://stackoverflow.com/questions/21889053/what-is-the-runtime-performance
    -co st-of-a-docker-container

    Those articles confirm there is a performance penalty. It does appear negligible, but still measureable.
    --
    digital man

    Rush quote #29:
    Nowhere is the dreamer or the misfit so alone
    Norco, CA WX: 60.4øF, 47.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Gamgee on Wed Jan 6 16:01:20 2021
    Re: Re: NodeX to Node/X directories
    By: Gamgee to deon on Tue Jan 05 2021 09:13 pm

    By definition, docker images are not "configured".
    Well, I'm confused then, because I thought you were talking about
    getting an SBBS configured just the way you want it, running in a
    Docker container, and then "saving" that image so it can be easily
    re-deployed. I'd call that "configuring" an image.

    I wondered if that would be confusing.

    There are 2 concepts. of "configuration" in play here.

    1) Altering configuration items so that the application works.

    2) Personalising the application with "my" data.

    An example of 1) is changing the nodes so that they appear in a nodes/ sub directory, so that the nodes/ sub directory can be a mount from the host (or as per my later discussion, tmpfs). This makes it work without any workarounds.

    An example of 2) is calling my instance of Synchronet "Alterant BBS", so that when it is stopped and started it is still called "Alterant", not ("My BBS" or whatever SBBS's default name is).

    Right. So why alter SBBS code to better suit Docker use, when almost nobody uses that?

    Or rather, why not make it configurable, so that for the default 99% use cases, nobody needs to change that configuration item, and for the 1% that do, they can change that config item, without changing the source code - as another valid use case?

    And as I mentioned early, its no big deal, since I was including my patch in the build process as the workaround - but somebody else was also asking how to do it...

    ...ëîåï

    ... Men seldom make passes at girls who wear glasses.

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Gamgee on Wed Jan 6 16:15:14 2021
    Re: Re: NodeX to Node/X directories
    By: Gamgee to deon on Tue Jan 05 2021 09:17 pm

    Nor to me. Don't even see the point of it, other than over-worrying
    about "security".

    What security do you worry about?

    Well, the same as most folks, I guess. Root exploits, basic firewall
    security, and so forth. But I don't stress over it
    too much.

    Well, I dont worry about the security, probably because I'm under the belief that a container is a more secure environment. Inside the container is a jail - and they only way into the container is via one of the open ports that the container is configured to expose (binkd/telnet). There is no way to get to the "host" from the container (unless you configure that of course).

    If somebody was able to compromise the app and open a shell, they are inside a jail, and could only harm what they see in the jail.

    To me, that means they can destroy my "personalisation" of the application - but that's why we do backups. If they modified any binaries for their exploit to persist (like they old days of replacing sshd, etc with their backdoor version), then all those modifications are lost the minute the running image is destroyed and re-started. And SHA1 hashing protects the image from compromise.

    So from that point of view, I think containers provide better security.

    My counter-question to you is: Why would I want/need to run SBBS in a Docker container? What benefit does that offer?

    I cant say why you would want to or not. I do it because of a multitude of reasons, and the net of them is easier to backup, improved portability, built in HA, more effecient use of resources and less OS's to manage.

    Do you run it that way to improve security? (I might be way off, but I
    thought I remember
    that as one of the reasons for using containers).

    That's not a reason I do it, but it is certainly a benefit (IMHO).

    ...ëîåï

    ... The best number for a dinner party is 2. Myself and a damn good headwaite

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Digital Man on Wed Jan 6 16:43:37 2021
    Re: Re: NodeX to Node/X directories
    By: Digital Man to deon on Tue Jan 05 2021 08:42 pm

    Sorry not true (the "contains run in VMs part").
    Sorry, "OS-level virtualization". :-)
    "virtualization" of any kind to me just implies more layers (be it
    software or hardware) and those layer incur some amount
    of performance penalty. Maybe it's immeasurable with Docker, I don't
    know.

    But there is no virtualisation with docker.

    Sadly if you want to run Docker on Windows, then yes, you need to run Hyper-V and that is virtualisation, but on Linux,
    processes in a container are just another process running from the host.

    Those articles confirm there is a performance penalty. It does appear
    negligible, but still measureable.

    Imagine me saying "tomato" with an Australian accent, and "tomato" with a US one...

    ...ëîåï

    ... Don't go to work, there's a lot to do.

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Tue Jan 5 22:05:58 2021
    Re: Re: NodeX to Node/X directories
    By: deon to Gamgee on Wed Jan 06 2021 04:01 pm

    Or rather, why not make it configurable, so that for the default 99% use cases, nobody needs to change that configuration item, and for the 1% that do, they can change that config item, without changing the source code - as another valid use case?

    Yeah, I'm good with that. Happy in fact to make changes that support both the 99% and 1% with equal convenience. :-)
    --
    digital man

    Sling Blade quote #12:
    Karl (re hammer): I don't rightly know. I just kinda woke up holding it.
    Norco, CA WX: 58.1øF, 46.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Tue Jan 5 22:14:11 2021
    Re: Re: NodeX to Node/X directories
    By: deon to Digital Man on Wed Jan 06 2021 04:43 pm

    Re: Re: NodeX to Node/X directories
    By: Digital Man to deon on Tue Jan 05 2021 08:42 pm

    Sorry not true (the "contains run in VMs part").
    Sorry, "OS-level virtualization". :-)
    "virtualization" of any kind to me just implies more layers (be it software or hardware) and those layer incur some amount
    of performance penalty. Maybe it's immeasurable with Docker, I don't know.

    But there is no virtualisation with docker.

    Wikipedia thinks there is:
    Docker is a set of platform as a service (PaaS) products that use OS-level virtualization to deliver software in packages called containers.

    Sadly if you want to run Docker on Windows, then yes, you need to run Hyper-V and that is virtualisation, but on Linux,
    processes in a container are just another process running from the host.

    Yup, but they're each virtualizing an OS (in software). It's still virtualization.

    Those articles confirm there is a performance penalty. It does appear negligible, but still measureable.

    Imagine me saying "tomato" with an Australian accent, and "tomato" with a
    US
    one...

    I'm sure it depends somewhat on what applications you're running as to how perceptable the penalty is. We (certainlyh, I) trade performance for convenience in other areas too, so it's not like its out of the question. But it can be factor.
    --
    digital man

    Sling Blade quote #11:
    Doyle Hargraves (to Karl): What in the hell you doin' with that hammer?
    Norco, CA WX: 58.1øF, 46.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Digital Man on Wed Jan 6 21:14:30 2021
    Re: Re: NodeX to Node/X directories
    By: Digital Man to deon on Tue Jan 05 2021 10:14 pm

    Sorry, "OS-level virtualization". :-)
    "virtualization" of any kind to me just implies more layers (be it
    software or hardware) and those layer incur some
    amount
    of performance penalty. Maybe it's immeasurable with Docker, I don't
    know.

    Wikipedia thinks there is:
    Docker is a set of platform as a service (PaaS) products that use
    OS-level virtualization to deliver software in packages
    called containers.
    Yup, but they're each virtualizing an OS (in software). It's still
    virtualization.

    This is one of those areas, where it depends on what your definition of virtualisation is and how you use or imply its use.

    So wikipedia goes on to state (on its virutalisation page), that virtualisation is "refers to the act of creating a virtual
    (rather than actual) version of something".

    cambridge.org goes onto define virtualisation as "the process of creating a virtual version or several virtual versions of a
    piece of computer equipment or software".

    Docker doesnt create a virtual something, or virtual versions of equipment - well except the network which is a virtual interface
    (in the same way that OpenVPN creates a virtual interface).

    I've answered this question many times over the years - and my response is docker is not virtualisation, because it doesnt
    emulate hardware when doing I/O or computation. IE: You cant make it appear that there are more processors, more memory, or
    more storage by summing up the containers, than what the host sees, nor does the core docker process pretend to be any of those
    things. Further, when an application in a container uses a processor or block device, it is using the hosts device directly.

    From a marketing point of view, you may consider it virtualisation, because inside each container it appears to be a autonomous
    environment - and a host can have more than 1 container present at any point in time.

    ...ëîåï

    ... I broke a mirror & got 7 years of bad luck; my lawyer thinks he can get me 5.

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Gamgee@1:103/705 to deon on Wed Jan 6 08:27:00 2021
    deon wrote to Gamgee <=-

    By definition, docker images are not "configured".

    Well, I'm confused then, because I thought you were talking about
    getting an SBBS configured just the way you want it, running in a
    Docker container, and then "saving" that image so it can be easily
    re-depl
    oyed. I'd call that "configuring" an image.

    I wondered if that would be confusing.

    There are 2 concepts. of "configuration" in play here.

    1) Altering configuration items so that the application works.

    2) Personalising the application with "my" data.

    Okay... but I'd call the second case "customization" rather than "configuration". Granted, it's a nitpick.

    An example of 1) is changing the nodes so that they appear in a
    nodes/ sub directory, so that the nodes/ sub directory can be a
    mount from the host (or as per my later discussion, tmpfs). This
    makes it work without any workarounds.

    Yep, understood there. I think I somehow was thinking that now
    everybody would have to have a ../nodes/nodeXX arrangement. I realize
    now that I was mistaken on that.

    An example of 2) is calling my instance of Synchronet "Alterant
    BBS", so that when it is stopped and started it is still called "Alterant", not ("My BBS" or whatever SBBS's default name is).

    Yes. Customization. ;-)

    Right. So why alter SBBS code to better suit Docker use, when almost nobody uses that?

    Or rather, why not make it configurable, so that for the default
    99% use cases, nobody needs to change that configuration item,
    and for the 1% that do, they can change that config item, without
    changing the source code - as another valid use case?

    All right, that I can understand and greatly agree with. I may have
    been under the impression that the change you were asking for would
    cause the 99% to have to jump through some hoops, rather than
    requiring the 1% to have to do so. This makes perfect sense and
    requires nobody to do any hoop-jumping. Thanks for clarifying.


    ... Internal Error: The system has been taken over by sheep at line 19960
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Gamgee@1:103/705 to deon on Wed Jan 6 08:34:00 2021
    deon wrote to Gamgee <=-

    My counter-question to you is: Why would I want/need to run SBBS in a Docker container? What benefit does that offer?

    I cant say why you would want to or not. I do it because of a
    multitude of reasons, and the net of them is easier to backup,
    improved portability, built in HA, more effecient use of
    resources and less OS's to manage.

    Okay, I guess it just illustrates the different use-cases we all have.
    My system(s) couldn't be easier to backup (using rsync on Linux).
    Portability and efficient use of resources is not important to me, and
    I only have one OS to manage. ;-)

    Thanks for your replies.



    ... All the easy problems have been solved.
    --- MultiMail/Linux v0.52
    þ Synchronet þ Palantir BBS * palantirbbs.ddns.net * Pensacola, FL
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tracker1@1:103/705 to Gamgee on Thu Jan 21 20:14:18 2021
    On 1/3/2021 1:50 PM, Gamgee wrote:
    Would be nice if the node directories were easier to move to a
    shared common subdirectory for easier volume mount/usage with
    Docker specifically. Instead of `../Node1` it would be
    `../Node/1` though it would make a nicer default imo, would be a
    hiccup for migration of existing servers, and the relative path
    being an extra layer deep, but it might be worth exploring.

    How many people run SBBS in Docker? My guess is < 10.

    How many people run a BBS? My guess is less than 10000, how many people
    use Docker, my guess is greater than 10000. ;-)

    Also, more might do it if it were easier to do.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tracker1@1:103/705 to Digital Man on Thu Jan 21 20:42:44 2021
    On 1/4/2021 8:32 PM, Digital Man wrote:
    It would be nice that this hack could be achieved programatically,
    during build time, or set in some ini so that the patch is not
    required. That includes making the "initial" main.cnf with the
    right paths, without having to edit them on first run for a new
    instance.

    What "initial" main.cnf - you mean the one from Git?

    I still understand why the would would be "required" by anyone.
    Are you setting up a new BBS every time you open your BBS container?

    It shouldn't be... it should be copying over the ctrl/ defaults to the
    runtime ctrl/ at startup, the initial main.cnf should probably be sane
    for the environment to be able to do volume mounts (think symlink
    outside the runtime environment), by having N nodes, you'd need N mounts
    to the directory instead of 1 ... by putting them in a common parent,
    then it kind of "just works".

    By changing the default, you can run:

    docker exec -it sbbs /sbbs/scfg

    assuming your container is named "sbbs" and from there, just add more
    nodes, and the defaults with ../nodes/node%d would be the correct
    relative path, and you only have to worry about running initially with something like the following for when you "setup"

    docker run ... \
    -v "/hostdata/sbbs/nodes:/sbbs/nodes" \
    -v "/hostdata/sbbs/ctrl:/sbbs/ctrl" \
    -v "/hostdata/sbbs/data:/sbbs/data" \
    ...
    bbs-io/synchronet:3.18b

    Or a docker-compose.yml file for that matter... for many/most
    applications you only really need to do a single volume mount (database servers for example) .. in this way, you can upgrade the runtime
    container and keep your volume/data and just run the new version,
    assuming appropriate upgrade scripts are in play and run/detect at startup.

    You can also use a volume container, or volume container driver that
    connects to a networked FS or other more complex orchestration, likely
    beyond what would be needed for Synchronet, but entirely possible to launch-deploy close to 1-click with something like digital ocean.

    Usually initialization scripts will use injected environment variables
    to also configure things like a hostname to use, default
    user/passphrase, etc on first run.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Dream Master@1:103/705 to Tracker1 on Thu Jan 21 22:46:04 2021
    Re: Re: NodeX to Node/X directories
    By: Tracker1 to Gamgee on Thu Jan 21 2021 08:14 pm

    How many people run a BBS? My guess is less than 10000, how many people
    use Docker, my guess is greater than 10000. ;-)

    Actually, the more important question is how many people login to BBSes on a daily basis? Even if there are <10,000 BBSes worldwide, they don't exactly publish themselves on Facebook. Even the Telnet BBS Guide doesn't list every single one (and FidoNet's nodelist is likely inaccurate).

    Also, more might do it if it were easier to do.

    Running a BBS depends on the SysOp and their experience. Running one in Windows is a hell of a lot easier than running one in *nix if you're a newbie. I've actually contemplated seeing if I can get Synchronet to compile on AIX (doubt it), Solaris x86 (maybe), or on Red Hat on IBM POWER9 (potentially). I think I know what I'm going to try this weekend... :)

    Brian Klauss <-> Dream Master
    Caught in a Dream | caughtinadream.com a Synchronet BBS

    ---
    þ Synchronet þ Caught in a Dream - caughtinadream.com
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tracker1@1:103/705 to deon on Thu Jan 21 21:08:59 2021
    On 1/4/2021 10:31 PM, deon wrote:

    (And sure the above statement references linux installs -
    probably doesnt help windows users, but I'm sure there are
    tools on Windows that would make deployment easier.)

    I know docker desktop with wsl2 on windows has been a massive
    improvement to prior releases... don't know if local bindings work over
    a network connection, but could simplify things there too, assuming
    dosemu is preinstalled/configured in the image.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tracker1@1:103/705 to Digital Man on Thu Jan 21 21:16:51 2021
    On 1/5/2021 12:17 PM, Digital Man wrote:
    And Docker containers run in VMs which come with their
    own performance penalties and issues (e.g. DOSemu
    compatibility). The idea is not appealing to me.

    Docker containers are *NOT* VMs... it's more like a BSD Jail or a
    Solaris Container, the overhead is *MUCH* lighter, commands are not
    translated through a VM. Nothing like DOSemu overhead.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tracker1@1:103/705 to Gamgee on Thu Jan 21 21:25:02 2021
    On 1/5/2021 8:17 PM, Gamgee wrote:
    What security do you worry about?

    Well, the same as most folks, I guess. Root exploits, basic firewall security, and so forth. But I don't stress over it too much.

    My counter-question to you is: Why would I want/need to run SBBS in a
    Docker container? What benefit does that offer? Do you run it that
    way to improve security? (I might be way off, but I thought I remember
    that as one of the reasons for using containers). If I am mistaken
    about that, please enlighten me as to how a container is beneficial.

    First run...

    docker run --name sbbs \
    -d --restart unless-stopped \
    -v /host-path/to/data:/sbbs/data \
    ... \
    synchronet/sbbs:3.17b

    Oh, time to upgrade...

    docker stop sbbs
    docker rm sbbs
    docker run --name sbbs ... synchronet/sbbs:3.18b

    Docker desktop on windows/mac same command.

    As to the overhead, the network overhead isn't much different than an
    iptables rule, fs similar for a symlink, no real cpu overhead added for runtime beyond that.

    Security, jailed/isolated environment... breaching a container !=
    breaching the OS.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tracker1@1:103/705 to Digital Man on Thu Jan 21 21:26:45 2021
    On 1/5/2021 9:42 PM, Digital Man wrote:
    Sorry not true (the "contains run in VMs part").

    Sorry, "OS-level virtualization". :-)

    It's not OS level virtualization... unless you consider chroot OS level virtualization.

    "virtualization" of any kind to me just implies more
    layers (be it software or hardware) and those layer
    incur some amount of performance penalty. Maybe it's
    immeasurable with Docker, I don't know.

    FS overhead is similar to symlink and network overhead is similar to an iptables port map.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tracker1@1:103/705 to deon on Thu Jan 21 21:31:39 2021
    On 1/5/2021 10:43 PM, deon wrote:
    But there is no virtualisation with docker.

    Sadly if you want to run Docker on Windows, then yes, you
    need to run Hyper-V and that is virtualisation, but on Linux,
    processes in a container are just another process running
    from the host.

    WSL2 is pretty interresting in this regard... with WSL2 iirc, the entire platform is virtualized and windows (and wsl) both run on that.

    Several apps actually run faster with Docker on Linux/WSL2 than the
    native windows versions.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tracker1@1:103/705 to Digital Man on Thu Jan 21 21:33:16 2021
    On 1/5/2021 11:14 PM, Digital Man wrote:
    Yup, but they're each virtualizing an OS (in software). It's still virtualization.

    No, they don't virtualize an OS... they use the system kernel, and *MAY*
    be based on a full environment, with passthrough kernetl... Rust and Go applications are bare containers with just the executable most of the time.

    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS
    ---
    þ Synchronet þ Roughneck BBS - roughneckbbs.com
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Dream Master on Fri Jan 22 22:45:14 2021
    Re: Re: NodeX to Node/X directories
    By: Dream Master to Tracker1 on Thu Jan 21 2021 10:46 pm

    Running a BBS depends on the SysOp and their experience. Running one in Windows is a hell of a lot easier than running one
    in *nix if you're a newbie. I've actually contemplated seeing if I can get Synchronet to compile on AIX (doubt it), Solaris
    x86 (maybe), or on Red Hat on IBM POWER9 (potentially). I think I know what I'm going to try this weekend... :)

    I have an S/390 environment here that I was going to try and compile SBBS (just because). Might be fun getting Synchronet running under a z/VM environment, where the network is made up of CTC devices :)

    ...ëîåï

    ... Is man one of God's blunders or is god one of Man's blunders?

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Nightfox@1:103/705 to Tracker1 on Fri Jan 22 08:09:45 2021
    Re: Re: NodeX to Node/X directories
    By: Tracker1 to Gamgee on Thu Jan 21 2021 08:14 pm

    How many people run a BBS? My guess is less than 10000, how many people use Docker, my guess is greater than 10000. ;-)

    Also, more might do it if it were easier to do.

    Docker is something I just became aware of within the past couple years. I don't know any stats on usage of Docker offhand, but personally I haven't used Docker in my own personal projects.

    Nightfox

    ---
    þ Synchronet þ Digital Distortion: digitaldistortionbbs.com
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Dream Master@1:103/705 to deon on Fri Jan 22 08:31:19 2021
    Re: Re: NodeX to Node/X directories
    By: deon to Dream Master on Fri Jan 22 2021 10:45 pm

    I have an S/390 environment here that I was going to try and compile SBBS (just because). Might be fun getting Synchronet running under a z/VM environment, where the network is made up of CTC devices :)

    Nice. I ran a bunch of Linux instances in z/VM some years ago. Fun stuff. Now I'm curious if you'll get it to work. :)

    Brian Klauss <-> Dream Master
    Caught in a Dream | caughtinadream.com a Synchronet BBS

    ---
    þ Synchronet þ Caught in a Dream - caughtinadream.com
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tony Langdon@3:633/410 to Tracker1 on Sat Jan 23 06:18:00 2021
    On 01-21-21 21:25, Tracker1 wrote to Gamgee <=-

    First run...

    docker run --name sbbs \
    -d --restart unless-stopped \
    -v /host-path/to/data:/sbbs/data \
    ... \
    synchronet/sbbs:3.17b

    Oh, time to upgrade...

    docker stop sbbs
    docker rm sbbs
    docker run --name sbbs ... synchronet/sbbs:3.18b

    Yeah, I've heard lots of good things about Docker, but haven't yet got my head around it. :/ I suspect Docker would fit in well with how I do things, but I need to understand it more, and build a good working model in my head, so I can then run with it.


    ... White dwarf seeks red giant for binary relationship.
    === MultiMail/Win v0.52
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Tony Langdon@3:633/410 to Nightfox on Sat Jan 23 06:23:00 2021
    On 01-22-21 08:09, Nightfox wrote to Tracker1 <=-

    Docker is something I just became aware of within the past couple
    years. I don't know any stats on usage of Docker offhand, but
    personally I haven't used Docker in my own personal projects.

    I haven't yet, but that's bacically because I don't have enough of a working understanding. I have a bit of a "hump" to get over in learning, where I form a working model of something, before I can really use it - I don't handle fragmented information well. And that needs coherent documentation.

    I had a similar issue with systemd, and am now finally getting comfortable with how to drive it (after a few years), because I could only find bits and pieces of documentation, and it can take that long to gather the fragments in my head.


    ... No amount of planning will replace dumb luck
    === MultiMail/Win v0.52
    --- SBBSecho 3.10-Linux
    * Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)
  • From Digital Man@1:103/705 to Tracker1 on Fri Jan 22 12:13:06 2021
    Re: Re: NodeX to Node/X directories
    By: Tracker1 to Digital Man on Thu Jan 21 2021 09:33 pm

    On 1/5/2021 11:14 PM, Digital Man wrote:
    Yup, but they're each virtualizing an OS (in software). It's still virtualization.

    No, they don't virtualize an OS...

    My point was: there are performance penalties when using Docker.

    Wikipedia calls Docker a product that uses "OS-level virtualization". I suppose that is semantically different than "virtualizing an OS", but not really relevant to my point.
    --
    digital man

    Synchronet "Real Fact" #111:
    Weedpuller "World Of My Own" http://youtu.be/V-gmT5N6kYo
    Norco, CA WX: 64.1øF, 58.0% humidity, 1 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Nightfox@1:103/705 to Tracker1 on Fri Jan 22 13:03:50 2021
    Re: Re: NodeX to Node/X directories
    By: Tracker1 to Digital Man on Thu Jan 21 2021 09:16 pm

    Docker containers are *NOT* VMs... it's more like a BSD Jail or a
    Solaris Container, the overhead is *MUCH* lighter, commands are not translated through a VM. Nothing like DOSemu overhead.

    That was my understanding as well. My understanding is that Docker is a way to package a program along with any prerequisites it has. That way, you don't necessarily have to install the prerequisites, you can just start up the program in the Docker image.

    Nightfox

    ---
    þ Synchronet þ Digital Distortion: digitaldistortionbbs.com
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Dream Master@1:103/705 to Digital Man on Fri Jan 22 16:06:15 2021
    Re: Re: NodeX to Node/X directories
    By: Digital Man to Tracker1 on Fri Jan 22 2021 12:13 pm

    My point was: there are performance penalties when using Docker.

    Wikipedia calls Docker a product that uses "OS-level virtualization". I suppose that is semantically different than "virtualizing an OS", but not really relevant to my point.

    I concur. Docker is still leveraging the paravirtualization of the kernel. I'd almost call it a chroot'd jail for each container but more extreme. There is still a penalty when running it inside an OS.

    Brian Klauss <-> Dream Master
    Caught in a Dream | caughtinadream.com a Synchronet BBS

    ---
    þ Synchronet þ Caught in a Dream - caughtinadream.com
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Digital Man on Sat Jan 23 10:43:38 2021
    Re: Re: NodeX to Node/X directories
    By: Digital Man to Tracker1 on Fri Jan 22 2021 12:13 pm

    My point was: there are performance penalties when using Docker.

    In much the same way there is a performance impact by using https over http. Its close to negligable, unmeasurable these days, especially since today's processors spend more time idle then busy.

    ...ëîåï

    ... The unnatural, that too is natural.

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Nightfox on Sat Jan 23 10:45:00 2021
    Re: Re: NodeX to Node/X directories
    By: Nightfox to Tracker1 on Fri Jan 22 2021 01:03 pm

    That was my understanding as well. My understanding is that Docker is a way to package a program along with any prerequisites it has. That way, you don't necessarily have to install the prerequisites, you can just start up the program in the Docker image.

    Right, on any platform (but same architecture) where the runtime engine is installed. (And installing the engine is pretty much "apt install docker-ce").

    ...ëîåï

    ... The word 'meaningful' when used today is nearly always meaningless.

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tracker1@1:103/705 to Dream Master on Sat Jan 23 07:48:17 2021
    On 1/22/2021 5:46 AM, Dream Master wrote:
    Running a BBS depends on the SysOp and their experience.
    Running one in Windows is a hell of a lot easier than
    running one in *nix if you're a newbie. I've actually
    contemplated seeing if I can get Synchronet to compile
    on AIX (doubt it), Solaris x86 (maybe), or on Red Hat on
    IBM POWER9 (potentially). I think I know what I'm going
    to try this weekend... :)

    A Dockerfile is effectively just a list of instructions for how to
    install a given system/service/application server. An image is a built version of that set of instructions and a container is a running
    instance from that image.

    Getting a container running from a pre-built image is generally easier
    than trying to setup an entire environment by hand. Also, you can have different versions/requirements for the application than what the host
    system is using, reducing the risk of conflict and operation issues.
    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS
    ---
    ï¿­ Synchronet ï¿­ Roughneck BBS - roughneckbbs.com
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tracker1@1:103/705 to deon on Sat Jan 23 07:50:02 2021
    Took some inspirations from I think it was your repo, as well as my
    prior version. I just updated my container scripts for sbbs...

    https://github.com/bbs-io/synchronet-docker

    Will likely add a bit to have it publish under bbs-io/synchronet on
    Docker hub.
    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS
    ---
    ï¿­ Synchronet ï¿­ Roughneck BBS - roughneckbbs.com
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tracker1@1:103/705 to Nightfox on Sat Jan 23 07:54:32 2021
    On 1/22/2021 4:09 PM, Nightfox wrote:
    How many people run a BBS? My guess is less than 10000, how
    many people use Docker, my guess is greater than 10000. ;-)

    Also, more might do it if it were easier to do.

    Docker is something I just became aware of within the past
    couple years. I don't know any stats on usage of Docker
    offhand, but personally I haven't used Docker in my own
    personal projects.

    I like it a lot... though, Docker itself is mostly a set of utility apps around what is being standardized in Linux directly, many will just use
    podman instead of Docker. That said, containers aren't likely going
    anywhere any time soon.

    Biggest advantage is you can have a given application with it's
    environmental dependencies without polluting the host system, or having conflicts with the dependencies of other applications. There's also the ability to share base image details, etc. You can also separate build
    and runtime requirements, such as building against a more full
    development environment and your final application image could be
    against something lighter like alpine, or a bare container which is
    often the case for Rust or Go application outputs.
    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS
    ---
    ï¿­ Synchronet ï¿­ Roughneck BBS - roughneckbbs.com
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tracker1@1:103/705 to Digital Man on Sat Jan 23 07:58:50 2021
    On 1/22/2021 8:13 PM, Digital Man wrote:
    My point was: there are performance penalties when using Docker.

    For the most part, said penalties are roughly the same as running
    SE-Linux, using iptables rules and symlinks with chroot. It's generally
    not enough additional overhead to be concerned with, especially compared
    to full system virtualization or something like WINE or DOSemu.

    Now, you *CAN* do network and file system overlays via drivers, these
    are often done in environments like kubernetes and would be comparable
    to a VPN for networking or NFS mounted filesystem. The out of the box experience is closer to iptables rules with symlinks and chroot.
    --
    Michael J. Ryan
    tracker1 +o Roughneck BBS
    ---
    ï¿­ Synchronet ï¿­ Roughneck BBS - roughneckbbs.com
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Tracker1 on Sun Jan 24 10:06:25 2021
    Re: Re: NodeX to Node/X directories
    By: Tracker1 to deon on Sat Jan 23 2021 07:50 am

    Took some inspirations from I think it was your repo, as well as my
    prior version. I just updated my container scripts for sbbs...

    Good stuff ;)

    You might like to change your build deps install, build and build deps removal as one long changed command.

    Your dep removal "# Cleanup libraries", while results in those devs not appearing in the later layers of the filesystem, they are still present in earlier layers - so your image size doesnt reduce. (Will impact "docker pull" bandwidth and data transferred.)

    (Not sure if docker hub is doing some flattening, or if you are)

    For your upgrade, I wouldnt clobber xtrn - there would be game config (or editor?) that folks would use, which is no dependant on Synchronet's versions.

    In fact, I would not call the clobbering of everything else (esp ctrl) as an "upgrade", but rather a "reset" - and for that matter, a reset could be the user removing the ctrl directory so that it gets re-populated when the container starts (which is my approach).

    ...ëîåï

    ... The earth is a hollow shell and we live on the inside.

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tracker1@1:103/705 to deon on Mon Jan 25 06:44:09 2021
    On 1/23/2021 4:06 PM, deon wrote:
    Took some inspirations from I think it was your repo, as well as my
    prior version. I just updated my container scripts for sbbs...

    Good stuff ;)

    You might like to change your build deps install, build and build deps removal as one long changed command.

    Yeah, was trying to work through the differences and working through
    issues while putting it together... now that I'm live, I can work local
    again to re-assemble some of the longer command chains.

    Your dep removal "# Cleanup libraries", while results in those devs
    not appearing in the later layers of the filesystem, they are still
    present in earlier layers - so your image size doesnt reduce. (Will
    impact "docker pull" bandwidth and data transferred.)

    (Not sure if docker hub is doing some flattening, or if you are)

    I believe that docker hub will only keep what's needed for the final
    runtime image (and base), not including the build image, which should
    keep it smaller.

    For your upgrade, I wouldnt clobber xtrn - there would be game
    config (or editor?) that folks would use, which is no dependant
    on Synchronet's versions.

    Yeah, will probably adjust to check each directory in xtrn to see if it
    exists and only copy if it doesn't, and include the third party
    installer details...

    In fact, I would not call the clobbering of everything else (esp
    ctrl) as an "upgrade", but rather a "reset" - and for that matter,
    a reset could be the user removing the ctrl directory so that it
    gets re-populated when the container starts (which is my approach).

    I am clobbering a /sbbs/references directory that I'm copying the
    originals to for a few of the directories so that they can be used
    outside the container for reference, but will likely remove this as I
    can just docker cp if needed. Or maybe have a /backup from a volume that
    I can copy to as needed...

    Noticing issues with the default binding config(s) where :: gets a
    getaddress error of some sort... so I'm now switching those around.
    Will update my repo in a bit.

    For now, wanting to followup with the web-ui I've been working on. and
    get my old modules/shell setup/configured.
    --
    Michael J. Ryan (tracker1)
    +o roughneckbbs.com
    ---
    ï¿­ Synchronet ï¿­ Roughneck BBS - roughneckbbs.com
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tracker1@1:103/705 to deon on Mon Jan 25 10:37:51 2021
    On 1/23/2021 4:06 PM, deon wrote:
    https://github.com/bbs-io/synchronet-docker

    For your upgrade, I wouldnt clobber xtrn - there would be
    game config (or editor?) that folks would use, which is no
    dependant on Synchronet's versions.

    In fact, I would not call the clobbering of everything else
    (esp ctrl) as an "upgrade", but rather a "reset" - and for
    that matter, a reset could be the user removing the ctrl
    directory so that it gets re-populated when the container
    starts (which is my approach).

    Updated the initialization script, will now only copy xtrn
    directories that don't exist in the target, and update the
    xtrn/3rd-party.

    Also changed the reference directory to ~/sbbs/backup:/backup
    with defaults clobbered as backup on install/upgrade. Not meant
    to be edited.

    Also added a docker-compose file for ref/use. And addressed a
    couple problematic settings in a post-build script.

    Running relatively close to stock on roughneckbbs.com now...

    Kind of a cheat using node for my init/post-install scripts,
    but I'm more familiar with it, and felt like it would be a lot
    of extra effort to get it working with jsexec.
    --
    Michael J. Ryan (tracker1)
    +o roughneckbbs.com
    ---
    ï¿­ Synchronet ï¿­ Roughneck BBS - roughneckbbs.com
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Tracker1 on Tue Jan 26 11:45:40 2021
    Re: Re: NodeX to Node/X directories
    By: Tracker1 to deon on Mon Jan 25 2021 10:37 am

    Had another quick look and noticed you werent doing any special mounts with the node dirs?

    I run one of my SBBS servers in a docker swarm, with "replicas: 2". One instance is responsible for nodes 1-5, and the other nodes 6-10. (Its my game server). In my config, I'm sharing the nodes/ dir across the instances.

    I'm not sure what is needed for one node to see another nodes files. Chat
    maybe?

    Rob, in case you are reading this, it would be great for things like spy, which rely on sockets, that either

    * Spying on another node (that is on another host) that Spy says "no" because it cannot spy on using the socket. In my case, node 6-10 knows node 1-5 is another SBBS instance.

    or

    * Spying on another node (that is on another host), is done over IP?

    ...ëîåï

    ... Whosoever diggeth a pit shall falleth therein.

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to deon on Mon Jan 25 19:44:37 2021
    Re: Re: NodeX to Node/X directories
    By: deon to Tracker1 on Tue Jan 26 2021 11:45 am

    Re: Re: NodeX to Node/X directories
    By: Tracker1 to deon on Mon Jan 25 2021 10:37 am

    Had another quick look and noticed you werent doing any special mounts with the node dirs?

    I run one of my SBBS servers in a docker swarm, with "replicas: 2". One instance is responsible for nodes 1-5, and the other nodes 6-10. (Its my game server). In my config, I'm sharing the nodes/ dir across the instances.

    I'm not sure what is needed for one node to see another nodes files. Chat
    maybe?

    Yes, chat.

    Rob, in case you are reading this, it would be great for things like spy, which rely on sockets, that either

    * Spying on another node (that is on another host) that Spy says "no" because it cannot spy on using the socket. In my case, node 6-10 knows node 1-5 is another SBBS instance.

    or

    * Spying on another node (that is on another host), is done over IP?

    Noted.
    --
    digital man

    Synchronet "Real Fact" #12:
    Synchronet was the first BBS software to ship with built-in RIPscrip support. Norco, CA WX: 43.7øF, 56.0% humidity, 11 mph ENE wind, 0.05 inches rain/24hrs --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tracker1@1:103/705 to deon on Tue Jan 26 10:53:09 2021
    On 1/25/2021 5:45 PM, deon wrote:
    Had another quick look and noticed you werent doing any
    special mounts with the node dirs?

    I run one of my SBBS servers in a docker swarm, with
    "replicas: 2". One instance is responsible for nodes 1-5,
    and the other nodes 6-10. (Its my game server). In my
    config, I'm sharing the nodes/ dir across the instances.

    I'm not sure what is needed for one node to see another
    nodes files. Chat maybe?

    Yeah, I didn't bother with multiple instances as it just
    seems to complicate some things.. I am running the ircd and
    the two different web UIs on separate entries though as
    I'm using the main one just for letsencrypt cert and as a
    redirect to the placeholder for what I'm working on...

    It's nearly all stock at the moment, need to get all my mods
    into place and configured still.
    --
    Michael J. Ryan (tracker1)
    +o roughneckbbs.com
    ---
    ï¿­ Synchronet ï¿­ Roughneck BBS - roughneckbbs.com
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Tracker1 on Wed Jan 27 16:04:46 2021
    Re: Re: NodeX to Node/X directories
    By: Tracker1 to deon on Tue Jan 26 2021 10:53 am

    Yeah, I didn't bother with multiple instances as it just
    seems to complicate some things.. I am running the ircd and
    the two different web UIs on separate entries though as

    Ahh, I actually found it quite easy - leveraging the "hostname" in the ini files.

    So my game servers "hostnames" are bbs_game-1, bbs_game-2 - which is generated by the swarm. If I changed replicas to 3, the 3rd one would be called bbs_game-3, etc

    With haproxy in front (and connected to the swarm network), I can either redirect traffic dirrectly to a specific instance - eg "bbs_game-1", or to any instance using "bbs_game".

    So, sbbs.ini is renamed to sbbs.bbs_game-1.ini, etc and only bbs_game-1 starts the services.

    I've not run into any issues so far.

    (For this to work across hosts, you need a shared filesystem, which is probably a little more complex for some, but NFS should work. I'm not a fan of NFS, so I use a proprietary cross host filesystem.)

    ...ëîåï

    ... All Americans lecture... I suppose it is something in their climate.

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tracker1@1:103/705 to deon on Wed Jan 27 16:25:41 2021
    On 1/26/2021 10:04 PM, deon wrote:
    Yeah, I didn't bother with multiple instances as it just
    seems to complicate some things.. I am running the ircd and
    the two different web UIs on separate entries though as

    Ahh, I actually found it quite easy - leveraging the "hostname"
    in the ini files.

    So my game servers "hostnames" are bbs_game-1, bbs_game-2 -
    which is generated by the swarm. If I changed replicas to 3,
    the 3rd one would be called bbs_game-3, etc

    Gotcha, doing similar for running the different websites, vs
    using the multi-host support in sync... Same host server though.

    With haproxy in front (and connected to the swarm network), I
    can either redirect traffic dirrectly to a specific instance
    - eg "bbs_game-1", or to any instance using "bbs_game".

    So, sbbs.ini is renamed to sbbs.bbs_game-1.ini, etc and only
    bbs_game-1 starts the services.

    Cool... might look into that if I start getting more door traffic.

    I've not run into any issues so far.

    (For this to work across hosts, you need a shared filesystem,
    which is probably a little more complex for some, but NFS should
    work. I'm not a fan of NFS, so I use a proprietary cross host
    filesystem.)

    Just curious, what FS sharing are you using? And have you had
    issues with multi-node DOSemu doors... I haven't even started
    setting up any doors yet.

    Are you using a base volume container for the network mount(s)
    on the docker host systems? Or mounting on the host?
    --
    Michael J. Ryan (tracker1)
    +o roughneckbbs.com
    ---
    ï¿­ Synchronet ï¿­ Roughneck BBS - roughneckbbs.com
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Tracker1 on Thu Jan 28 22:04:36 2021
    Re: Re: NodeX to Node/X directories
    By: Tracker1 to deon on Wed Jan 27 2021 04:25 pm

    Just curious, what FS sharing are you using? And have you had
    issues with multi-node DOSemu doors... I haven't even started
    setting up any doors yet.

    Are you using a base volume container for the network mount(s)
    on the docker host systems? Or mounting on the host?

    I'm using scale, where its a visible filesystem on the host (all hosts), with each running continer effectively a directory, eg: /scale/docker/sbbs.

    I've also used portworx (a while ago), where each container gets a volume as its starts - but I stopped using it because it was kinda buggy (and I kept having to fsck the volumes - which was a challenge). I also lost some data - it didnt handle nodes going offline very well (and it's supposed to).

    On the Pi's I've used gluster, in fact I was using gluster on the Intel server as well, but it kept core dumping - on the Pi its a lot more reliable, although it doesnt do the I/O. I keep hearing that gluster is dead now but I dont think its actually true.

    For dosemu, I havent seen any issues with multinode, but then Ive only tried multinode on a couple of doors. I only just recently set it up, and the new work that's been commited recently has made it super easy. (Kudos to Rob and Mike(?) I think who's worked on that.)

    ...ëîåï

    ... A fool must now and then be right by chance.

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Michael J. Ryan@1:103/705 to GitLab issue in main/sbbs on Mon Feb 1 15:26:39 2021
    close https://gitlab.synchro.net/main/sbbs/-/issues/199
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tracker1@1:103/705 to deon on Thu Feb 4 06:16:31 2021
    On 1/28/2021 4:04 AM, deon wrote:
    Just curious, what FS sharing are you using? And have you had
    issues with multi-node DOSemu doors... I haven't even started
    setting up any doors yet.

    Are you using a base volume container for the network mount(s)
    on the docker host systems? Or mounting on the host?

    I'm using scale, where its a visible filesystem on the host (all
    hosts), with each running continer effectively a directory,
    eg: /scale/docker/sbbs.

    I've also used portworx (a while ago), where each container gets
    a volume as its starts - but I stopped using it because it was
    kinda buggy (and I kept having to fsck the volumes - which was
    a challenge). I also lost some data - it didnt handle nodes
    going offline very well (and it's supposed to).

    On the Pi's I've used gluster, in fact I was using gluster on
    the Intel server as well, but it kept core dumping - on the Pi
    its a lot more reliable, although it doesnt do the I/O. I keep
    hearing that gluster is dead now but I dont think its actually
    true.

    Gotcha... I'm just using a single host with host volumes. Mostly
    using Docker to ease deployments/movement/backup etc... I was able to completely switch hosts/environments a couple times without issue.

    I'm also going to be fronting a website outside/ahead of the BBS host itself... so that will work slightly differently.

    For dosemu, I havent seen any issues with multinode, but then Ive
    only tried multinode on a couple of doors. I only just recently
    set it up, and the new work that's been commited recently has made
    it super easy. (Kudos to Rob and Mike(?) I think who's worked on
    that.)

    Yeah, haven't tried setting up any doors yet at all, though it's on my
    list of things to do... Web messages, chat/telegram and IRC are higher
    on my list though.

    As is getting my old mods (last updated around 2004 mostly) updated and running on a current version.
    --
    Michael J. Ryan (tracker1)
    +o roughneckbbs.com
    ---
    ï¿­ Synchronet ï¿­ Roughneck BBS - roughneckbbs.com
    --- SBBSecho 3.12-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From deon@1:103/705 to Tracker1 on Fri Feb 5 08:46:24 2021
    Re: Re: NodeX to Node/X directories
    By: Tracker1 to deon on Thu Feb 04 2021 06:16 am

    Gotcha... I'm just using a single host with host volumes. Mostly
    using Docker to ease deployments/movement/backup etc... I was able to completely switch hosts/environments a couple times without issue.

    Yup, Ive done the same over the years.

    I now run everything in a 3 host swarm - which is great, because I can take 1 out of the loop, update it or generally do stuff to it, and the containers float to another host. (I do nothing to them specifically.) Swarm take care of which host to load the container and the networking. (Hence the cross host filesystem so that the other host sees the containers data.)

    When I'm finished, I make the host available again, and as containers are restarted they start on the newly up'ed host. The additional instances of replicated containers restart to, and the network takes care of giving them work.

    ...ëîåï

    ... Superior ability breeds superior ambition. Spock, stardate 3141.9.

    ---
    þ Synchronet þ Alterant | an SBBS in Docker on Pi!
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Tracker1@1:103/705 to deon on Sun Feb 21 02:28:12 2021
    FYI, if you're connecting to Doorparty, the dpc2 connector is
    now being published on Docker Hub for easier use.

    https://hub.docker.com/repository/docker/bbsio/doorparty/

    I also have Synchronet going in, but haven't setup daily builds.
    --
    Michael J. Ryan (tracker1)
    +o roughneckbbs.com
    ---
    ï¿­ Synchronet ï¿­ Roughneck BBS - roughneckbbs.com
    --- SBBSecho 3.13-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)