There are a handful of .ini files in the /sbbs/exec directory.
Would it be possible to consider supporting moving these from /exec to
/ctrl ?
Mainly, in a containerized environment, I've been keeping the
executables inside the container, but mounting all transient data
(including /xtrn) from outside... but with these configuration files,
it's a bit cumbersome.
I've made an sbbs-init script that runs prior to sbbs/scfg in general
use, that makes sure all the volume mount paths are symlinked under
/sbbs before running... I *could* do similar for exec/*.ini, or for
those specific files, could just copy them.
I'm wanting to pre-configure dosemu(2) as much as reasonable to make setup/configuration a bit more straight forward... This is just
throwing a small kink in that setup.
Would it be possible to consider supporting moving these from
/exec to /ctrl ?
Possible, sure, but not preferable.
...
Sorry, but some of those (e.g. init-fidonet.ini) aren't intended to
be sysop-modified in the first place, while others are used by
programs that don't know anything about the Synchronet CTRL
directory. The reasons are varied (why there are a few .ini files
in exec), but there are reasons.
Tracker1 wrote to Digital Man <=-
On 9/10/22 19:44, Digital Man wrote:
Would it be possible to consider supporting moving these from
/exec to /ctrl ?
Possible, sure, but not preferable.
...
Sorry, but some of those (e.g. init-fidonet.ini) aren't intended to
be sysop-modified in the first place, while others are used by
programs that don't know anything about the Synchronet CTRL
directory. The reasons are varied (why there are a few .ini files
in exec), but there are reasons.
So, it's effectively not possible to separate executable files
from data/configuration for Synchronet... or to cleanly
update/upgrade those executable files in a read-only fashion.
On 9/10/22 19:44, Digital Man wrote:
Would it be possible to consider supporting moving these from
/exec to /ctrl ?
Possible, sure, but not preferable.
...
Sorry, but some of those (e.g. init-fidonet.ini) aren't intended to
be sysop-modified in the first place, while others are used by
programs that don't know anything about the Synchronet CTRL
directory. The reasons are varied (why there are a few .ini files
in exec), but there are reasons.
So, it's effectively not possible to separate executable files from data/configuration for Synchronet... or to cleanly update/upgrade those executable files in a read-only fashion.
So, it's effectively not possible to separate executable files
from data/configuration for Synchronet... or to cleanly
update/upgrade those executable files in a read-only fashion.
The second half of your statement above doesn't make much sense
to me. How would you upgrade something that is "read-only" in
the first place? I don't have any problems updating my ../exec
directory.
i dont know about separation of the ini files.
but everything on mine is on an NFS share on my NAS (which has 30Tb
space compared to the 20G on the machine itself).
so pretty much only thing that's stored on the bbs machine is the sbbs
stuff directly. That RSyncs over the nas as a backup once a day.
not sure if that helps with your docker stuff, but i wonder if there's
a way you can just do something similar.
Tracker1 wrote to Gamgee <=-
On 9/12/22 05:30, Gamgee wrote:
So, it's effectively not possible to separate executable files
from data/configuration for Synchronet... or to cleanly
update/upgrade those executable files in a read-only fashion.
The second half of your statement above doesn't make much sense
to me. How would you upgrade something that is "read-only" in
the first place? I don't have any problems updating my ../exec
directory.
Imagine an executable on a read-only CD... but the data is stored
on a hard drive... to move to the next version, you shut down the
program, and swap out the CD to one with the new version. You
effectively do the same with a docker image. You just get the
new image.
/sbbs/exec - read-only image mount
/sbbs/(data|ctrl|...) - read-write mount
Generally my updates go...
1. cd ~/sbbs
2. docker pull bbsio/synchronet:nightly
3. docker-compose up -d
1. keeping ~/sbbs as my (outside docker) location.
2. pull the latest nightly image from dockerhub
3. detects the underlying image changed, (re)starts related
instance(s)
--------
In practice it's /sbbs-data/(data|ctrl|...) that gets symlinked
at runtime. I also save a version.txt file in exec/ that gets
compared to ctrl/ at startup, so that it runs the js version
update script if/when they don't match.
But having data written to /sbbs/exec that part of it will fail
when moving to a new version. I could move (if not already there) /sbbs/exec/*.ini to /sbbs-data/exec/*.ini, and then symlink back
to exec, which is what I'll probably do... just kind of a pain.
Imagine an executable on a read-only CD... but the data is stored on a hard drive... to move to the next version, you shut down the program,
But having data written to /sbbs/exec that part of it will fail when moving to a new version. I could move (if not already there) /sbbs/exec/*.ini to /sbbs-data/exec/*.ini, and then symlink back to
exec, which is what I'll probably do... just kind of a pain.
As for the rest of that above... I don't use or know anything about
Docker, and can't imagine wanting to go through that much hassle for
some "benefit" that it would gain me...
I'll add this to my list of YARNTWTUD. (Yet another reason not to
want to use Docker). :-)
Imagine an executable on a read-only CD... but the data is stored on a
hard drive... to move to the next version, you shut down the program,
"Synchronet LIVE CD" LOL... pretty much how they work to be honest.
But having data written to /sbbs/exec that part of it will fail when
moving to a new version. I could move (if not already there)
/sbbs/exec/*.ini to /sbbs-data/exec/*.ini, and then symlink back to
exec, which is what I'll probably do... just kind of a pain.
the only thing i cansee with that is if something changes with the INI files, like stuff added or deleted and then things like cnf files
moving to ini files etc.
for the most part it would work, but if something like that changes
then that's going to break it and cause a lot of hassle.
Tracker1 wrote to Gamgee <=-
As for the rest of that above... I don't use or know anything about
Docker, and can't imagine wanting to go through that much hassle for
some "benefit" that it would gain me...
I'll add this to my list of YARNTWTUD. (Yet another reason not to
want to use Docker). :-)
In practice, there are some benefits. Most unixy apps separate configuration (/etc), data (/var) and executables/scripts (/bin)
...
Most docker-friendly applications will take a handful of
environment variables for configuration, leaving only data to
deal with. In this way, you can run a database server only
mounting /data ... while literally everything else can be
read-only file system.
This means that security holes that would require disk write are
largely mitigated. It also means you can upgrade to the new
version, just by running against the new version image. No
downloads, installing prerequisites, building anything... just
*run*.
Those cnf/ini files are in the /ctrl directory, not the /exec directory... what I'm referring to are some utilities/scripts that use/modify an ini file in /exec.
for the most part it would work, but if something like that changesMain risk is a new script/app using something that isn't .ini inside the /sbbs/exec directory, which I *REALLY* hope nothing
then that's going to break it and cause a lot of hassle.
does... as it is, would be nice of everything was limited to ctrl and data.
Those cnf/ini files are in the /ctrl directory, not the /exec
directory... what I'm referring to are some utilities/scripts that use/modify an ini file in /exec.
Most docker-friendly applications will take a handful of
environment variables for configuration, leaving only data to
deal with. In this way, you can run a database server only
mounting /data ... while literally everything else can be
read-only file system.
This means that security holes that would require disk write are
largely mitigated. It also means you can upgrade to the new
version, just by running against the new version image. No
downloads, installing prerequisites, building anything... just
*run*.
I can see how that would work, and that it would be nice in some
abstract way. It's just that.... I don't do anything like that,
and honestly don't even know anybody who does things like that.
So... in practice... it's a very limited scope audience who would
care about something like that. Very.
Those cnf/ini files are in the /ctrl directory, not the /exec
directory... what I'm referring to are some utilities/scripts that
use/modify an ini file in /exec.
I don't know of any utilities/scripts that modify ini files in the exec dir.
On 9/24/22 12:30, Digital Man wrote:
Those cnf/ini files are in the /ctrl directory, not the /exec
directory... what I'm referring to are some utilities/scripts that
use/modify an ini file in /exec.
I don't know of any utilities/scripts that modify ini files in the exec dir.
Didn't you mention that some weren't meant to be user modified? I would presume *something* uses and potentially modifies them.
Didn't you mention that some weren't meant to be user modified? I would presume *something* uses and potentially modifies them.
Tracker1 wrote to Gamgee <=-
Most docker-friendly applications will take a handful of
environment variables for configuration, leaving only data to
deal with. In this way, you can run a database server only
mounting /data ... while literally everything else can be
read-only file system.
This means that security holes that would require disk write are
largely mitigated. It also means you can upgrade to the new
version, just by running against the new version image. No
downloads, installing prerequisites, building anything... just
*run*.
I can see how that would work, and that it would be nice in some
abstract way. It's just that.... I don't do anything like that,
and honestly don't even know anybody who does things like that.
So... in practice... it's a very limited scope audience who would
care about something like that. Very.
Not sure how limited it is in practice... look on job boards for Kubernetes and you'll see *MANY* using it. The core of almost
everything I've done that past 4 years is deployed in
Docker/Kubernetes... and there are distributed databases that
thrive under that model (CockroachDB, Cassandra, etc). So YMMV
of course.
For example on LinkedIn jobs, Kubernetes has 83,244 active
results for just the US.
https://www.linkedin.com/jobs/search/?keywords=kubernetes
For example on LinkedIn jobs, Kubernetes has 83,244 active
results for just the US.
https://www.linkedin.com/jobs/search/?keywords=kubernetes
Perhaps I should have clarified my statement better... Perhaps D/K
is an important thing for those who work in IT for a living. I'll
take your word for it. I guess my point is that that is still a small amount of the workforce overall. It's orders of magnitude smaller
when you consider the BBS/hobbyist computer users who may be reading
this... ;-)
| Sysop: | fluid |
|---|---|
| Location: | wickliffe, ohio |
| Users: | 5 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 214:40:12 |
| Calls: | 50 |
| Files: | 15,838 |
| Messages: | 50,892 |