Hi All
ON PIT are in the process of qualifying new IPS based automation for ON PIT and
DIY PIT.
The rest of this email describes how we propose to validate that the correct
IPS packages
have been installed on our test systems.
Your review and feedback on this proposal would be appreciated.
thanks
Brian Keane
Proposal:
There is a need in ON-PIT (and by extension in DIY) for a facility that enables test systems to verify that what they have been
installed with is indeed what they were meant to be installed with.
Such a facility has existed in PIT for some time in the case of WOS-based
installs and an analog for IPS is now required.
Here is a synoptic overview of the logic that will be used to achieve that purpose. Implementation for that logic is more or less
halfway through:
---
Step 1. A new build of Solaris is made known to ON-PIT's tools. This step is driven either by an engineer from PIT or by a
customer of our DIY service.
If this build is based on IPS, then the URL of one or more IPS repository is
supplied. A checksum is created in the following way:
Step 1.1 A meta-package that is significant for this repository is manually selected. The meta-package of choice for content
repositories would be slim_install, on_all for nightly repos and on_extra for on_extra repos.
Step 1.2.Two ordered lists of package FMRIs are built for all packages that
would be installed on a x86 and on a sparc system.
For instance, the list created for build 132 on a x86 system would look like:
---
[email protected],5.11-0.132:20100130T055919Z
[email protected],5.11-0.132:20100130T055936Z
[email protected],5.11-0.132:20100130T055952Z
[email protected],5.11-0.132:20100130T060135Z
[email protected],5.11-0.132:20100130T060242Z
[email protected],5.11-0.132:20100130T060303Z
[email protected],5.11-0.132:20100130T060217Z
<SNIP>
[email protected],5.11-0.132:20100130T063034Z <--- this package is x86 specific
<SNIP>
---
Step 1.3. Each list is then digested into a SHA1 checksum.
Step 1.4. The checksum, the meta-package it was derived from and the
architecture it is concerned with are stored in a database.
Step 2. (Optional). A local mirror of the supplied repository(ies) is created.
Step 3. Clients are installed using either the repository URL(s) supplied or
local mirrors thereof.
Step 4. Once installed, each client is supplied with the meta-package chosen for this repository as well as the reference checksum
that is relevant to its architecture.
Step 4.1. The client builds an ordered list of packages required by the meta-package using 'pkg contents -m'. Packages that do not
apply to its architecture are filtered out of the list.
Step 4.2. This list is digested into a SHA1 checksum
Step 4.3. The checksum thus obtained is compared against the reference
checksum. An error is raised if they do not match.
Note that this does nothing for the internal consistency of each package, ie. to ascertain that the files present on a client
really match what the packages' manifests prescribe. This latter function could be handled by 'pkg verify'/'pkg fix' if needed.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
