Installing a package, verifying its content, and fixing the package corruption
This time, we have sufficient conditions to install a package and verify its contents, and if we find a problem with any package, we are able to fix it. This is an exciting section because it will introduce us to many useful commands, and all of them are used in day-to-day Solaris 11 administration.
Getting ready
We'll learn the next procedure using the nmap package, but the same can be done using any other Solaris 11 package.
How to do it…
We execute the following command:
root@solaris11:~# pkg install -v nmap
Packages to install: 1
Estimated space available: 71.04 GB
Estimated space to be consumed: 51.67 MB
Create boot environment: No
Create backup boot environment: No
Services to change: 1
Rebuild boot archive: No
Changed packages:
solaris
diagnostic/nmap
None -> 5.51,5.11-0.175.1.0.0.24.0:20120904T171749Z
Services:
restart_fmri:
svc:/application/desktop-cache/desktop-mime-cache:default
DOWNLOAD PKGS FILES XFER (MB) SPEED
Completed 1/1 523/523 3.3/3.3 24.1k/s
PHASE ITEMS
Installing new actions 581/581
Updating package state database Done
Updating image state Done
Creating fast lookup database Done According to the output, Solaris 11 didn't create a BE. Sure, it was a very simple package installation. However, if we had installed a Solaris patch, the scenario would have been very different. We can check our installation by typing the following command:
root@solaris11:~# pkg list nmap
NAME (PUBLISHER) VERSION IFO
diagnostic/nmap 5.51-0.175.1.0.0.24.0 i--The last column shows us that the package has been installed, so to show the content of our installation, we type the following:
root@solaris11:~# pkg contents nmap
PATH
usr
usr/bin
usr/bin/ncat
usr/bin/ndiff
usr/bin/nmap
usr/bin/nmapfe
usr/bin/nping
usr/bin/xnmap
usr/bin/zenmap
usr/lib
usr/lib/python2.6
usr/lib/python2.6/vendor-packages
usr/lib/python2.6/vendor-packages/radialnet
usr/lib/python2.6/vendor-packages/radialnet/__init__.py
usr/lib/python2.6/vendor-packages/radialnet/__init__.pyc
…......................We can use an alternative form, with presentation of additional information, by running the following command:
root@solaris11:~# pkg contents -t file -o owner,mode,pkg.size,path nmap
OWNER MODE PKG.SIZE PATH
root 0555 166228 usr/bin/ncat
root 0555 48418 usr/bin/ndiff
root 0555 1540872 usr/bin/nmap
root 0555 608972 usr/bin/nping
root 0555 6748 usr/bin/zenmap
…...................Additionally, every package has an associated file named manifest, which describes details such as the package content, its attributes, and dependencies. We can view this manifest file of an installed package using the following command:
root@solaris11:~# pkg contents -m nmap | more
set name=pkg.fmri value=pkg://solaris/diagnostic/nmap@5.51,5.11-0.175.1.0.0.24.0:20120904T171749Z
set name=pkg.debug.depend.bypassed value=usr/lib/python2.6/vendor-packages/zenmapGUI/SearchWindow.py:.*
set name=variant.arch value=i386 value=sparc
set name=org.opensolaris.consolidation value=userland
set name=org.opensolaris.arc-caseid value=PSARC/2007/129
set name=info.upstream-url value=http://insecure.org/
set name=info.source-url value=http://nmap.org/dist/nmap-5.51.tgz
set name=pkg.summary value="Network exploration tool and security / port scanner."
set name=info.classification value="org.opensolaris.category.2008:System/Administration and Configuration"
…................................................
…...............................................Tip
You might wonder whether it is possible to check whether a package installation has kept its integrity. Yes, you can manage this issue using the following command:
root@solaris11:~# pkg verify -v nmap
PACKAGE STATUS
pkg://solaris/diagnostic/nmap OKLet's create a simple test where we break any file from the nmap package; afterwards, we check the package status by running the following command:
root@solaris11:~# find / -name nmap
/usr/bin/nmapWe continue further by executing the following commands:
root@solaris11:~# mkdir /backup root@solaris11:~# cp /usr/bin/nmap /backup/ root@solaris11:~# echo GARBAGE > /usr/bin/nmap root@solaris11:~# pkg verify -v nmap PACKAGE STATUS pkg://solaris/diagnostic/nmap ERROR file: usr/bin/nmap Unexpected Exception: Request error: class file/memory mismatch
Wow! The command used to detect the nmap package corruption detected the exact problem. We can fix this potential problem in a very simple and quick way:
root@solaris11:~# pkg fix nmap
Verifying: pkg://solaris/diagnostic/nmap ERROR
file: usr/bin/nmap
Unexpected Exception: Request error: class file/memory mismatch
Created ZFS snapshot: 2013-10-10-22:27:20
Repairing: pkg://solaris/diagnostic/nmap
Creating Plan (Evaluating mediators): \
DOWNLOAD PKGS FILES XFER (MB) SPEED
Completed 1/1 1/1 0.5/0.5 97.0k/s
PHASE ITEMS
Updating modified actions 1/1
Updating image state Done
Creating fast lookup database Done An overview of the recipe
During the nmap package installation, we realized that it takes 51.67 MB after it is installed and that it hasn't created a new BE. In the remaining commands, we found out a lot of information; for example, the files are contained in the nmap package, this package runs on x86 or SPARC, it comes from the Solaris repository and has been developed by http://insecure.org, its source file is nmap-5.51.tgz, and it only runs on userland. Afterwards, we verified the nmap integrity, corrupted it, and fixed it.
