×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
No, I don't see chroot as a useful solution to this. I frequently have
software that interacts with network file systems, the QSYS.LIB file
system, optical file systems... chroot would restrict access from
everything to /QOpenSys.
Scott, I don't believe you *can* use chroot from software that interacts
with the network filesystems (QSYS.LIB et al) as you suggest. How are you
doing that exactly?
Not only that, but I use these tools from QShell as well as PASE..
QShell itself requires access to the root file system.
You misread me. You mentioned that these packages like to install under
/usr/local. If you use chroot properly, you can (fairly easily) have the
package installed under /QOpenSys/usr/local...
What is your problem with the symlink, exactly?
I use symlink all the time; I have no problems with it per se. I do not
like it as a crutch to avoid something as simple as modifying the system
PATH. I don't use it to appear to join unlike filesystems (tantamount to
installing all your software into a VFAT filesystem and making that part of
your PATH). I like a pure system (as much as possible). You're a purist
when it comes to your area of expertise; this is one of my strong areas.
You agreed (I think) that some of these programs won't run under QSH and yet
you install them under QSH because it's easier (that's the way I read your
post). I am presenting an alternative that allows you to do it right,
keeping the Hatfields and McCoys on their own properties.
Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"The radical of one century is the conservative of the next. The radical
invents the views. When he has worn them out the conservative adopts them."
-- Mark Twain
midrange.com
