Well, I finally solved this obscure case. I think this is a silly
way to determine package ordering and dependencies which can cripple
an installation. I believe a bug should be filed, but I'm not sure
what to file it against.
Due to a failed patch update, something happened with the on-disk
directory ordering in /var/sadm/pkg. I found that /etc/pam.conf
is referenced in the packages SUNWcsr SUNWsshdr SUNWtnetr SUNWrcmdr
SUNWwebminu SUNWman. Apparently their installation order is based
on the order they're returned by opendir/readdir. There should be a
dependency on SUNWcsr by all packages that reference /etc/pam.conf
in any class action scripts, since SUNWcsr needs to install it
before any other package can modify it.
So the logic to determine package installation order needs to
be updated to include the above dependency. What dependency checks
are used to calculate the order? Is there any "official" order the
packages should be installed in (so that I may rebuild the /var/sadm/pkg
directory to be in the proper order)?
Should you run into this problem, I'll quickly post how I fixed this.
# cd /var/sadm/pkg
# ls -ltd SUNWcsr SUNWsshdr SUNWtnetr SUNWrcmdr SUNWwebminu
if SUNWcsr isn't at the top of the list, you're going to have problems.
I fixed it by creating a directory and moving the one at the top of the list
into the tmp folder, then mv SUNWcsr to the tmp folder, then mv SUNWcsr back
followed by moving the other directory back.
# mkdir tmp
# mv SUNWtnetr tmp
# mv SUNWcsr tmp
# ls -ltd SUNWcsr SUNWsshdr SUNWtnetr SUNWrcmdr SUNWwebminu
SUNWcsr: No such file or directory
SUNWtnetr: No such file or directory
drwxr-xr-x 4 root root 512 Jul 18 15:22 SUNWsshdr
drwxr-xr-x 4 root root 512 Jul 18 15:21 SUNWrcmdr
drwxr-xr-x 4 root root 512 May 3 2005 SUNWwebminu
# mv tmp/SUNWcsr .
# mv tmp/SUNWtnetr .
# ls -ltd SUNWcsr SUNWsshdr SUNWtnetr SUNWrcmdr SUNWwebminu
and maybe I just got lucky, but SUNWcsr was now at the top of the list.
All zone creations now work properly and /etc/pam.conf matches the global zone.
Brian Kolaci wrote:
Thanks for the reply.
I'm digging through i.pamconf to find out why its not copying the file.
This seems to be the problem. Its doing the editing, but not the
initial copy of the file. I checked the CLEANUP_FILE and found that
it had logged messages "default entries updated", which means it is
not copying the file which means it already exists.
Perhaps there's some kind of package installation ordering issue.
The i.pamconf script checks for the existence of /etc/pam.conf and
only copies it if it doesn't exist. If another package gets installed
before SUNWcsr that tries to manipulate /etc/pam.conf and actually
creates it, then the copy will never be done. This looks like what is
happening.
What order are the packages installed in? Is there a way to adjust
that order to assure that SUNWcsr comes before the other one(s) that
are manipulating the file? What is the correct order for package
installation?
Renaud Manus wrote:
SUNWcsr pkgmap defines /etc/pam.conf as a 'e' (editable) type file
with a class
action script 'pamconf'. In this situation, when you install a new
zone, when
it comes to install the SUNWcsr package, the class action script will
just copy
the file from /var/sadm/pkg/SUNWcsr/save/... to [ZONEROOTPATH]/etc.
After that, it's possible that some packages need to modify the pam.conf
(eg. SUNWtnetr), to add new entries for example, then they do so in their
postinstall script.
You could find all the files on both systems that manipulate pam.conf
and compare them.
eg.
# find /var/sadm/pkg/SUNWcsr -type f -exec /usr/xpg4/bin/grep -q
pam.conf {} \; -print
-- Renaud
Brian Kolaci wrote:
Hi,
I'm still having zone creation issues where my /etc/pam.conf is corrupt.
I have 2 machines, one works fine, the other always creates the
zone with a bad /etc/pam.conf.
I used the Dtrace toolkit "opensnoop" program to watch on both machines.
I see on the "good" machine, where it creates the /etc/pam.conf
correctly
that a process properly copies the file from the pspool directory:
0 29509 cp 4
/var/sadm/pkg/SUNWcsr/save/pspool/SUNWcsr/reloc/etc/pam.conf
This happens during the "Initializing package <x> of <y>: percent
complete: ??%" phase.
I never see this on the machine having issues. In fact what I do see
is:
0 16561 cat -1
/pool1/zones/bktest2/root/etc/pam.conf 0 16564 grep 7
/pool1/zones/bktest2/root/etc/pam.conf 0 16565 sh 7
/pool1/zones/bktest2/root/etc/pam.conf 0 17485 cat 6
/pool1/zones/bktest2/root/etc/pam.conf 0 17487 cat 6
/tmp/pam.conf.17484 0 17489 grep 6
/pool1/zones/bktest2/root/etc/pam.conf 0 17490 sh 6
/pool1/zones/bktest2/root/etc/pam.conf 0 17491 grep 6
/pool1/zones/bktest2/root/etc/pam.conf 0 17492 sh 6
/pool1/zones/bktest2/root/etc/pam.conf
so it appears to be trying to manipulate the file rather than just
copy it.
What determines whether a file is copied from the save/pspool/...
directory
rather than just a postinstall script trying to manipulate it?
I've even upgraded the system to the latest U3 beta and the problem
persists.
Is the process flow for creating zones documented somewhere?
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
