Ralf Weber writes:
> or your zone path when the package gets created inside a zone. So I
> would rewrite your scripts as:
[...]
> ${BASEDIR}/usr/sbin/chroot ${BASEDIR} /usr/sbin/groupadd -g 27 mysql
> ${BASEDIR}/usr/sbin/chroot ${BASEDIR} /usr/sbin/useradd -u 27 -d /var/
> lib/mysql -s /bin/false -G mysql mysql
I wouldn't. There's no guarantee at all that $BASEDIR refers to an
instance of the OS that can run at all with the current running
kernel.
In more detail: when you use chroot, the system reads *everything*
from the given base directory, including the system libraries. That
means you'll load up $BASEDIR/usr/sbin/groupadd and try to link in
$BASEDIR/lib/libc.so.1 (among many other things). That library makes
undocumented system calls that in turn depend on the exact rev of the
kernel.
What happens when you do that is arbitrary. It may work, as the
system call interface usually changes slowly, but it may not. It all
depends on the calls made by the application and the nature of the
user/kernel flag days that have passed between these two images.
(Note that Sun's ABI guarantee applies at the ABI level -- meaning the
documented system library interfaces -- and not at the system call
level.)
What you're suggesting isn't supported and can't be supported.
Instead of that, I'd suggest using nawk for now, and adding a call
record to CR 6387333. useradd/groupadd should know how to deal with
alternate roots.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
