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.

Most *nix services are pretty easy, as you can inject/mount the data
directory and configuration separately from the executable and dependencies.
--
Michael J. Ryan - tracker1@roughneckbbs.com
---
� Synchronet � Roughneck BBS - roughneckbbs.com

-=> Tracker1 wrote to Gamgee <=-

Tr> 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.

Tr> Imagine an executable on a read-only CD... but the data is stored
Tr> on a hard drive... to move to the next version, you shut down the
Tr> program, and swap out the CD to one with the new version. You
Tr> effectively do the same with a docker image. You just get the
Tr> new image.

Tr> /sbbs/exec - read-only image mount
Tr> /sbbs/(data|ctrl|...) - read-write mount

Tr> Generally my updates go...

Tr> 1. cd ~/sbbs
Tr> 2. docker pull bbsio/synchronet:nightly
Tr> 3. docker-compose up -d

Tr> 1. keeping ~/sbbs as my (outside docker) location.
Tr> 2. pull the latest nightly image from dockerhub
Tr> 3. detects the underlying image changed, (re)starts related
Tr> instance(s)

Tr> --------

Tr> In practice it's /sbbs-data/(data|ctrl|...) that gets symlinked
Tr> at runtime. I also save a version.txt file in exec/ that gets
Tr> compared to ctrl/ at startup, so that it runs the js version
Tr> update script if/when they don't match.

Tr> But having data written to /sbbs/exec that part of it will fail
Tr> when moving to a new version. I could move (if not already there)
Tr> /sbbs/exec/*.ini to /sbbs-data/exec/*.ini, and then symlink back
Tr> to exec, which is what I'll probably do... just kind of a pain.

Okay...... I don't believe you had mentioned anything about docker in
this context up until now...., so perhaps you can understand my original
confusion...?

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). :-)

.... 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

Re: Re: Move .ini files from /sbbs/exec to /sbbs/ctrl
By: Tracker1 to Gamgee on Wed Sep 21 2022 22:09:00

Tr> Imagine an executable on a read-only CD... but the data is stored on a
Tr> 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.

Tr> But having data written to /sbbs/exec that part of it will fail when
Tr> moving to a new version. I could move (if not already there)
Tr> /sbbs/exec/*.ini to /sbbs-data/exec/*.ini, and then symlink back to
Tr> 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.

regards
---

Charles Blackburn
The F.B.O BBS 21:1/221 618:250/36
bbs.thefbo.us IPV4/V6
DOVE-Net FSX-Net MicroNET USENET
---
■ Synchronet ■ The FBO BBS - bbs.thefbo.us - A place for aviation fun....

On 9/22/22 05:37, Gamgee wrote:
>
> 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*.
--
Michael J. Ryan - tracker1@roughneckbbs.com
---
� Synchronet � Roughneck BBS - roughneckbbs.com

On 9/22/22 04:39, Charles Blackburn wrote:
>> 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.

pretty much.

>> 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.

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 changes
> then that's going to break it and cause a lot of hassle.

Main risk is a new script/app using something that isn't .ini inside the
/sbbs/exec directory, which I *REALLY* hope nothing does... as it is,
would be nice of everything was limited to ctrl and data.
--
Michael J. Ryan - tracker1@roughneckbbs.com
---
� Synchronet � Roughneck BBS - roughneckbbs.com

-=> 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). :-)

Tr> In practice, there are some benefits. Most unixy apps separate
Tr> configuration (/etc), data (/var) and executables/scripts (/bin)
Tr> ...

Tr> Most docker-friendly applications will take a handful of
Tr> environment variables for configuration, leaving only data to
Tr> deal with. In this way, you can run a database server only
Tr> mounting /data ... while literally everything else can be
Tr> read-only file system.

Tr> This means that security holes that would require disk write are
Tr> largely mitigated. It also means you can upgrade to the new
Tr> version, just by running against the new version image. No
Tr> downloads, installing prerequisites, building anything... just
Tr> *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.

.... Backup not found: (A)bort (R)etry (P)anic
--- MultiMail/Linux v0.52
� Synchronet � Palantir BBS * palantirbbs.ddns.net * Pensacola, FL

Re: Re: Move .ini files from /sbbs/exec to /sbbs/ctrl
By: Tracker1 to Charles Blackburn on Fri Sep 23 2022 22:14:27

Tr> Those cnf/ini files are in the /ctrl directory, not the /exec
Tr> directory... what I'm referring to are some utilities/scripts that
Tr> use/modify an ini file in /exec.

I have these in my exec directory and i think the only ones i have modified are dosemu and init-ticket. i would think to be honest that even just a symlink should work fine.

sbbs@sbbs:~/exec$ ls *.ini
dosemu.ini init-fidonet.ini init-tickit.ini kermit.ini sbbsexec.ini sutils.ini

>> 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.
Tr> Main risk is a new script/app using something that isn't .ini inside the /sbbs/exec directory, which I *REALLY* hope nothing
Tr> does... as it is, would be nice of everything was limited to ctrl and data.

totally... i dont know why they're split up with most being in one and a couple in the main directory.

all my stuff i write, i either use the exec directory, or if i have something with a separate config directory then everything goes in there.

regards
---

Charles Blackburn
The F.B.O BBS 21:1/221 618:250/36
bbs.thefbo.us IPV4/V6
DOVE-Net FSX-Net MicroNET USENET
---
■ Synchronet ■ The FBO BBS - bbs.thefbo.us - A place for aviation fun....

Re: Re: Move .ini files from /sbbs/exec to /sbbs/ctrl
By: Tracker1 to Charles Blackburn on Fri Sep 23 2022 10:14 pm

> 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.
--
digital man (rob)

Rush quote #39:
Sounds that build high like a mountain or notes that fall, gently, like rain
Norco, CA WX: 89.9°F, 37.0% humidity, 8 mph ESE wind, 0.00 inches rain/24hrs
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

On 9/24/22 05:23, Gamgee wrote:
>> 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
--
Michael J. Ryan - tracker1@roughneckbbs.com
---
� Synchronet � Roughneck BBS - roughneckbbs.com

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.
--
Michael J. Ryan - tracker1@roughneckbbs.com
---
� Synchronet � Roughneck BBS - roughneckbbs.com

Re: Re: Move .ini files from /sbbs/exec to /sbbs/ctrl
By: Tracker1 to Digital Man on Mon Sep 26 2022 04:50 pm

> 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.

Not normally.
--
digital man (rob)

This Is Spinal Tap quote #3:
How much more black could this be? and the answer is none. None more black.
Norco, CA WX: 81.7°F, 40.0% humidity, 4 mph SSE wind, 0.00 inches rain/24hrs
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

Re: Re: Move .ini files from /sbbs/exec to /sbbs/ctrl
By: Tracker1 to Digital Man on Mon Sep 26 2022 04:50 pm

>
> Didn't you mention that some weren't meant to be user modified? I would
> presume *something* uses and potentially modifies them.

only like one of them.
the rest are okay.
---
■ Synchronet ■ ::: BBSES.info - free BBS services :::

-=> 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.

Tr> Not sure how limited it is in practice... look on job boards for
Tr> Kubernetes and you'll see *MANY* using it. The core of almost
Tr> everything I've done that past 4 years is deployed in
Tr> Docker/Kubernetes... and there are distributed databases that
Tr> thrive under that model (CockroachDB, Cassandra, etc). So YMMV
Tr> of course.

Tr> For example on LinkedIn jobs, Kubernetes has 83,244 active
Tr> results for just the US.

Tr> 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... ;-)

.... Computer Hacker wanted. Must have own axe.
--- MultiMail/Linux v0.52
� Synchronet � Palantir BBS * palantirbbs.ddns.net * Pensacola, FL

On 9/27/22 05:33, Gamgee wrote:
>> 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... ;-)

While it is a very small segment of an overall workforce... I think it's
fair to assume that there would be a larger overlap of those who might
want to run a hobby BBS that professionally work in IT than the general
population.
--
Michael J. Ryan - tracker1@roughneckbbs.com
---
� Synchronet � Roughneck BBS - roughneckbbs.com