On 08/05/09 13:03, Jacqueline Tse wrote:
Hi
Hello,
On 08/04/09 14:55, Jacqueline Tse wrote:
The problem I am trying to solve is when a software
scanner is run in a non-global zone, it needs to
decide if a package was inherited from the global
zone, and exclude it from the report. We don't want
to report the same package in the zone because it was
inherited from the global zone.
I have created a package, ABCDtestpkg, and
installed it in the global zone and the non-global
zone.
"pkgparam -v ABCDtestpkg" shows neither one of the
followings was set:
- SUNW_PKG_ALLZONES
- SUNW_PKG_HOLLOW
- SUNW_PKG_THISZONE
So I'm not clear of why you want to report on
essentially omit packages
that either have
1 ALLZONES=true
or
2 have part of their deliverable reside on an
inherited directory.
1 is easy enough, but 2 is not doable from within the
zone itself.
What is the purpose of this tool, is it to identify
software that can be
managed from within the zone?
The tool is used to report information about packages which are installed in the system, which can be run in the global zone, and/or the non-global zone.
When this tool is run in the non-global zone, it needs to find out if the
package was installed from the global zone, and exclude such package info from
the report. Is it possible to find out such info from the command line or API?
The aim is not to report the same package multiple times, when it was installed
from the global zone and inherited by all the non-global zones?
On second thoughts it might be possible to do this to a degree
so from within a non-global zone
1 if /var/sadm/pkg/<pkg-name>/pkginfo has SUNW_PKG_ALLZONES-true then
can only be managed from global,
else if false then check that no entry in /var/sadm/install/contents for
this package lives on an inherited filesystem.
/var/sadm/install/contents is a flatfile maintained by patch/packaging
tools. grep for say SUNWcsr and you will see the structure, or man -s 4
contents.
Still a bit unclear as to the use of this tool, by run in the global
and/or non0-global zone, you mean they can be managed ie patched/removed
etc?
I then removed ABCDtestpkg from the non-global
zone, pkgrm indicated there is a dependency in global
zone.
it is a pkgadd messaging bug, should have said the
zone name instead of
global zone.
[i]zone1 # pkgrm ABCDtestpkg
The following package is currently installed:
ABCDtestpkg ABCD test package
(sparc) 1.0
Do you want to remove this package? [y,n,?,q] y
## Removing installed package instance
<ABCDtestpkg>
## Verifying package <ABCDtestpkg> dependencies in
global zone
ok that is a bug in pkgadd, pkgrm in a non-global
zone does not do
dependency tests int he global zone at all.
So above is a typo, should really say
"Verifying package <ABCDtestpkg> dependencies in
zone1"
But why should pkgrm say the package has dependency in the non-global zone, when it was runnning in the non-global zone?
it a bug, it should not have said this at all.
Perhaps pkgadd/pkgrm should omit the message, if it doesn't check dependency in the non-global zone.
yes it should omit the message.
Many thanks,
Jacqueline
...[/i]
How did pkgrm determine ABCDtestpkg has a
dependency in the global zone? Are there any API/CLI
to find out such info from non-global zone?
Solaris 10 5/08 is used.
Many thanks,
Jacqueline
--
Enda O'Connor x19781 Software Product Engineering
Patch System Test : Ireland : x19781/353-1-8199718
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
--
Enda O'Connor x19781 Software Product Engineering
Patch System Test : Ireland : x19781/353-1-8199718
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
