If you chroot to /IASPVERN, , the objects in its /IASPVERN/QSYS.LIB would
seem to be accessible, since they are within the jail, right?

My assumption would be yes, the /QSYS.LIB IFS directory would be accessible
at that point because you are chrooting into an area that is meant to
contain /QSYS.LIB. I've only done chroot in /home/aaron and /QOpenSys.
Note at this point you'd have IFS access to /QSYS.LIB, which isn't super
useful and instead, if you are in PASE, you'd more likely want to work with
ILE objects and DB2 database tables through SQL CLI APIs.

Do you have an IASP to try this on, Aaron? Or anyone?

I don't.

iASPs would be more interesting/useful if they had more Docker.io-like
features.

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


On Tue, Oct 27, 2015 at 5:26 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

Aaron

This fits what I now think I grasp about this.

My question about IASPs still holds - within and IASP there IS a QSYS.LIB
since some release back in the V5 area. In a regular IBM i job that has
activated the IASP, the library list is a combination of *SYSBAS and the
QSYS.LIB of the IASP - seamlessly done by the system.

Now let's say that you have an IASP named IASPVERN - there will be a
directory off the root names IASPVERN, and in that directory will be a
QSYS.LIB. This directory can have most object types that the system has.

If you chroot to /IASPVERN, , the objects in its /IASPVERN/QSYS.LIB would
seem to be accessible, since they are within the jail, right? Now you'd
need to use their IFS path name for some things.

I know I'm talking probably over my head - but the article by Tony does
speak of IASPs helping to solve some of the issues with library-object
kinds of things, as I recall.

Do you have an IASP to try this on, Aaron? Or anyone?

BTW, IASPs are not just for HA - they can be used as I'm describing to
install test and production versions of applications. The concept seems to
fit what y'all are saying about chroot.

Regards
Vern


On 10/27/2015 2:56 PM, Aaron Bartell wrote:

When you ssh into an IBM i environment you can be placed into a chroot
environment by default depending on how the HOMEDIR is set on a user
profile. For example,
HOMEDIR('/QOpenSys/litmis/spaces/ULKUMH/./home/usrlnmki') will run the
chroot command where the period is specified. So when this particular
user
logs in they will be placed in directory
/QOpenSys/litmis/spaces/ULKUMH/home/usrlnmki. If they do a "ls /" they
will see whatever is in directory /QOpenSys/litmis/spaces/ULKUMH. They
will not be able to "cd .." up past /QOpenSys/litmis/spaces/ULKUMH.

Here an example of me SSH'ing into a chroot environment and listing the
root. Note the absence of /QSYS.LIB. Note, though, that I can still
connect to the local database with SQL CLI APIs (per the language database
adapters).

$ ls -all /
total 176
drwxrwsrwx 9 usrlnmki 0 8192 Oct 27 18:15 .
drwxrwsrwx 9 usrlnmki 0 8192 Oct 27 18:15 ..
drwxrwsrwx 5 usrlnmki 0 8192 Sep 10 21:54 QOpenSys
lrwxrwxrwx 1 usrlnmki 0 34 Sep 10 21:49 bin ->
/QOpenSys/usr/bin
drwxrwsrwx 3 usrlnmki 0 8192 Sep 10 21:46 dev
drwxr-xr-x 5 usrlnmki 0 8192 Sep 10 21:52 etc
drwxr-s--- 3 usrlnmki 0 8192 Sep 10 21:46 home
lrwxrwxrwx 1 usrlnmki 0 34 Sep 10 21:49 lib ->
/QOpenSys/usr/lib
lrwxrwxrwx 1 usrlnmki 0 26 Sep 10 21:49 opt ->
/QOpenSys/opt
lrwxrwxrwx 1 usrlnmki 0 36 Sep 10 21:49 sbin ->
/QOpenSys/usr/sbin
drwxrwsrwt 5 usrlnmki 0 8192 Oct 21 00:44 tmp
drwxrwsrwx 4 usrlnmki 0 8192 Sep 10 21:52 usr
drwxrwsrwx 3 usrlnmki 0 8192 Sep 10 21:52 var


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


On Tue, Oct 27, 2015 at 2:40 PM, Nathan Andelin <nandelin@xxxxxxxxx>
wrote:

Thanks for the replies, Jim and Aaron.

Regarding connections to IBM i databases, I'm already familiar with SQL
CLI
DB and toolkit interfaces which accompany *nix language environments
(PHP,
Ruby, Python, Node.js, etc.).

My question about accessing /qsys.lib was a curiosity about "visibility"
and "access" from *nix shells, via *SHHD.

While at the command line, what happens if users enter:

cd /

ls

Would /qsys.lib appear in the directory structure?

I gather from Aaron's response - that it would depend on the authority of
the "user" of the IBM i JOB which accompanies a *SSHD connection.



On Tue, Oct 27, 2015 at 1:20 PM, Aaron Bartell <aaronbartell@xxxxxxxxx>
wrote:

As a follow-up to Vern's question regarding access to /qsys.lib;

Without a

chroot setup, would users of the *SSHD daemon be able to access

/qsys.lib/*

objects otherwise, from remote *nix shells?

When a user logs into the *SSHD daemon from LUW** they are literally on

the

IBM i with a dedicated IBM i job; complete with a library list and all.
Similar in nature to a telnet session where 5250 is your "shell".

**LUW=Linux/Unix/Windows


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.


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



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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.