Starting a new thread as we've strayed from original topic of "Early
impressions of Litmis Spaces for Python".
Any thoughts? Especially from Aaron - how about an OSS definition for free
sandbox systems, or are you going only on a commercial setup? ;-)
There are a number of pre-created configurations for chroot environments
here:
https://bitbucket.org/litmis/ibmichroot Specifically, look at the
chroot_xxxx.lst files in that repo. Note you can apply more than one
chroot_xxxx.lst to the same chroot environment (modularity).
The concept of chroot is very simple (I initially overcomplicated it
because it seemed like it was "magic"). The term/command "chroot" stands
for "Change Root". If I run "$ chroot /home/aaron/c1 /usr/bin/sh" I will
change my perceived root directory to be /home/aaron/c1, except at that
point my current shell (/usr/bin/sh) doesn't know it's in a chroot
environment because if I do "$ ls /" it will display the contents of
/home/aaron/c1 because it thinks that's the actual root. I put together a
short tutorial (that requires no additional software) that helps to prove
the concept of chroot: bit.ly/ibmsystemsmag-chroot Do the tutorial on your
system, it should only take 15 minutes or so.
The reason for chroot isn't initially realized until either a catastrophe
happens (i.e. production server won't start) or the PITA factor happens
(i.e. "Aaron is installing more new open source and put symlinks in default
PATH and now my stuff is bombing. The nerve!"). Btw, the PITA factor is
the same thing that can happen in production (i.e. two separate apps have
different dependencies of openssl versions).
Some people go the route of spinning up addtl IBM i instances to create
"containers". There can be good reasons for this. There are also bad
reasons for this (i.e. needing to test a new version of xyz PASE
language). Or in short, application layer software (including language
runtimes) should rarely be a reason to spin up a new OS. Instead you can
use chroot to create separate "containers". If a separate virtual instance
of IBM i is an "operating system container", then chroot is a "IFS file
system container" - a way to create a completely self-sufficient directory
in the IFS where an application will run. By "self-sufficient" I mean the
IFS directory has ~everything~ necessary for the application to run - all
runtimes (i.e. node), all supporting libs (i.e. libssl.a), etc. In short,
when creating this new chroot environment (which is a simple matter of
mkdir and subsequent cp and a few other commands), if you don't copy the
necessary directory structure into it, it doesn't exit. This is a
beautiful thing because it proves the container concept which means a
developer installing stuff in "chroot1" won't affect stuff in "chroot2".
Again, containers, or what are sometimes called "jails" or "chroot jail".
This concept of creating chroot environments (and copying all those
files/runtimes) means A LOT of disk is used.
And finally, while these chroot environments can obviously be used for IBM
i cloud efforts (i.e. spaces.litmis.com), in reality they are near
necessity for any shop deploying multiple PASE stacks in production**. I
have IBM i machines where I'm the only person on it and chroot still makes
sense because then I can easily try out new open source without hosing what
I call "the base of PASE".
**Or you can take the laborious/risky route and plan around it. It works,
I've done it, but chroot makes it better.
Oh, and chroot cleanup is as simple as "rm -rf /path/to/my/chroot/dir".
Nice.
Hope that helps,
Aaron Bartell
litmis.com - Services for open source on IBM i
On Thu, Aug 11, 2016 at 12:48 PM, Holger Scherer <hs@xxxxxxx> wrote:
in my opinion, chroot is suitable for some of the OSS projects,
depending if it is needed or not. At the moment we are busy with
a lot of different projects, PUB400.COM <http://pub400.com/> is only one
of them.
Maybe there should be some documentation project to clearly define
which kind of software (e.g. node.js python php etc) can make good
use of a chroot environment, and others which do not need this.
On a shared public system like PUB400 it is always a good idea to
separate users which is mainly done on object security, but some
OSS software depends on other methods - also they depend on the
knowledge of admin and user ;-)
PUB400.COM <http://pub400.com/> currently has 1300 users (with 30-40 new
users a day),
so i am not sure what would be the impact to the system if
a full chroot environment would be added for each user automatically.
Any thoughts? Especially from Aaron - how about an OSS definition for
free sandbox systems, or are you going only on a commercial setup? ;-)
-h
Am 11.08.2016 um 18:41 schrieb John Yeung <gallium.arsenide@xxxxxxxxx>:
(I don't fully understand chroot, but from what I can gather, it would
seem Litmis Spaces uses it while pub400.com doesn't.)
--
This is the IBMi Open Source Roundtable (OpenSource) mailing list
To post a message email: OpenSource@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/opensource
or email: OpenSource-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/opensource.
midrange.com
