Re: chroot, Doctrine, ZendFrameWork

I suppose you could get at data in the QSYS.LIB that shows up within an IASP - but not be able to run programs - am I getting it?

On 10/27/2015 7:39 AM, Aaron Bartell wrote:

I am using the one included with PASE.

Correct, QSYS.LIB can't go into a chroot environment. And also correct
that iASPs can help (because they introduce boundaries, and that is what
the likes of chroot, Docker.io, etc are all about). For example, with
iASPs you can have same named libraries from one iASP to the next which
might be nice for SaaS providers.

Aaron Bartell
litmis.com - Services for open source on IBM i


On Tue, Oct 27, 2015 at 7:33 AM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

Hi Aaron

So is the chroot y'all are talking about - is it just the command that's
already in PASE (AIX)? Or a special version for the i?

Tony mentions that you can't get at QSYS.LIB SYSBAS when you use chroot -
but he does say that IASPs can help - I can see how that could be.

Thanks
Vern


On 10/27/2015 7:27 AM, Aaron Bartell wrote:

​Here some areas I've found chroot to be useful.

1 - I can have different versions of the same software (i.e. Node.js,
Ruby,
PHP, etc) all installed on the same machine but separated out into
different chroot environments. This is GREAT for testing new versions or
being able to easily rollback if a deploy to a new version doesn't go as
expected.

2 - If you aren't sure how an install of software is going to affect your
system (i.e. something from perzl.org) then you can install it in a
chroot
without if affecting other areas of PASE on the same machine.

3 - As mentioned by others, chroot also provides a very nice means for
allowing users/developers to log in and have the perception they are at
the
root of the machine when in reality they are many levels deep in a
"jailed"
environment.

4 - Some software (i.e. RubyGems, Node.js npm, etc) like to install things
globally. This is problematic on a machine where you might have multiple
developers or multiple environments (testing/staging/production), or both.
Using chroot you can have the software believe it is installing globally
(meaning you don't need to retrofit the install) even though it is local
to
the chroot directory.

5 - chroot is great for things like CI (Continuous Integration) and CD
(Continuous Deployment). Simply put, when you do your unit testing (CI)
you can spin up a new environment that is *scripted* - meaning it is
created exactly the same each time without the chance of a developer
forgetting a step and creating a false positive in a unit test scenario.
Similar is true for automated CD - when a git commit happens you can do a
webhook on the git repo to automatically trigger a CI and if all unit
tests
pass it will automatically deploy to production (CD) in a auto-generated
chroot space (again, one that is create the same *each* time). CI and CD
are things I am just now getting further into on IBM i with chroot.
​
​chroot on IBM i holds a lot of promise.

Aaron Bartell
litmis.com - Services for open source on IBM i

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.