Until recently, I've used an OpenIndiana system to build the illumos packages that go into Tribblix. Clearly this is less than ideal - it would be nice to be able to build all of Tribblix on Tribblix.
This has always been a temporary expedient. So, here's how to build illumos-gate on Tribblix.
(Being able to do so is also good in that it increases the number of platforms on which a vanilla illumos-gate can be built.)
First, download and install Tribblix (version 0m10 or later). I recommend installing the kitchen-sink.
Then, if you're running 0m10, apply some necessary updates. As root:
zap refresh-overlays
zap refresh-catalog
zap update-overlay develop
zap uninstall TRIBdev-object-file
zap install TRIBdev-object-file
This won't be necessary in future releases, but I found some packaging issues which interfered with the illumos build (although other software doesn't bother), including some symlinks so that various utilities are where illumos-gate expects.
I run the build in a zone. It requires a non-standard environment, and using a zone means that I don't have to corrupt the global zone, and I can repeatably guarantee that I get a correct build environment.
Then, install a build zone. This will be a whole-root zone in which we copy the develop overlay from the global zone, and add the illumos-build overlay into the zone. (It will download the packages for the illumos-build overlay the first time you do this, but will cache them so if you repeat this later - and I tend to create build zones more or less at will - it won't have to). You need to specify a zone name and give it an IP address.
zap create-zone -t whole \
-z il-build -i 172.18.1.206 \
-o develop -O illumos-build
This will automatically boot the zone, you just have to wait until SMF has finished initialising.
Configure the zone so it can resolve names from DNS:
cp /etc/resolv.conf /export/zones/il-build/root/etc/
cp /etc/nsswitch.dns /export/zones/il-build/root/etc/nsswitch.conf
Go into the zone
zlogin il-build
In the zone, create a user to do the build, and a couple of hacky fixes
rm /usr/bin/cpp
cd /usr/bin ; ln -s ../gnu/bin/xgettext gxgettext
(The first is a bug in my gcc, the latter is a Makefile bug.)
If you want to build with SMB printing
zap install TRIBcups
Now, as the user, the build largely follows the normal instructions: you can use git to clone illumos-gate, unpack the closed bins, copy illumos.sh and nightly.sh, and edit illumos.sh to customize the build.
There are a few things you need to do to get a successful build. The first is to add the following to illumos.sh
export SUPPRESSPKGDEP=true
this is necessary as the IPS dependency step uses the installed image; as Tribblix uses SVR4 packaging, there isn't one. You can still create the IPS repo (and I do, as that's what I then turn into SVR4 packages), but the dependency step needs to be suppressed.
If you want to build with CUPS, then you'll need to have installed cups, and you'll need to patch smb. Alternatively, avoid pulling in CUPS by adding this to illumos.sh:
export ENABLE_SMB_PRINTING='#'
As Tribblix uses newer glib, the API has changed slightly and hal uses the old API. There is a proper fix, but you can simply:
gsed -i '/g_type_init/d' usr/src/cmd/hal/hald/hald.c
Note that this means that you won't be able to run the hal components on a system with a downrev glib.
Then you should be able to run a build:
time ./nightly.sh illumos.sh
The build should be clean (I see ELF runtime attribute warnings, all coming from glib and ffi, but those don't actually matter, and I'm not sure illumos should be complaining about errors in its external dependencies anyway).
Wednesday, May 21, 2014
Friday, May 16, 2014
Software verification of SVR4 packages with pkgchk
On Solaris (and Tribblix) you can use the pkgchk command to verify that the contents of a software package are correctly installed.
The simplest invocation is to give pkgchk the name of a package:
pkgchk SUNWcsl
I would expect SUNWcsl to normally validate cleanly. Whereas something like SUNWcsr will tend to produce lots of output as it contains lots of configuration files that get modified. (Use the -n flag to suppress most of the noise.
If you want to check individual files, then you can use
pkgchk -p /usr/bin/ls
or (and I implemented this as part of the OpenSolaris project) you can feed a list of files on stdin:
find /usr/bin -mtime -150 | pkgchk -i -
However, it turns out that there's a a snag with the basic usage of pkgchk to analyze a package, in that it will trust the contents file - both for the list of files in the package, and for their attributes.
Modifying the list of files can be a result of using installf and removef. For example, I delete some of the junk out of /usr/ucb (such as /usr/ucb/cc so as to be sure no poor unfortunate user can ever run it), and use removef to clean up the contents file. A side-effect of this is that pkgchk won't normally be able to detect that those files are missing.
Modifying file attributes can be the result of a second package installing the same pathname with different attributes. Having multiple packages deliver a directory is common, but you can also have multiple packages own a file. Whichever package was installed last gets to choose which attributes are correct, and the normal pkgchck is blind to any changes as a result.
There's a trick to get round this. From Solaris 10, the original package metadata (and unmodified copies of editable files) are kept. Each package has a directory in /var/sadm/pkg, and in each of those you'll find a save directory. This is used when installing zones, so you get a pristine copy. However, you can also use the pkgmap file to verify a package:
pkgchk -m /var/sadm/pkg/SUNWscpu/save/pspool/SUNWscpu/pkgmap
and this form of usage will detect files that have been removed or modified by tools that are smart enough to update the contents file.
(Because those save files are used by zones, you'll find they don't exist in a zone because they wouldn't be needed there. So this trick only works in a global zone, or you need to manually copy the pkgmap file.)
The simplest invocation is to give pkgchk the name of a package:
pkgchk SUNWcsl
I would expect SUNWcsl to normally validate cleanly. Whereas something like SUNWcsr will tend to produce lots of output as it contains lots of configuration files that get modified. (Use the -n flag to suppress most of the noise.
If you want to check individual files, then you can use
pkgchk -p /usr/bin/ls
or (and I implemented this as part of the OpenSolaris project) you can feed a list of files on stdin:
find /usr/bin -mtime -150 | pkgchk -i -
However, it turns out that there's a a snag with the basic usage of pkgchk to analyze a package, in that it will trust the contents file - both for the list of files in the package, and for their attributes.
Modifying the list of files can be a result of using installf and removef. For example, I delete some of the junk out of /usr/ucb (such as /usr/ucb/cc so as to be sure no poor unfortunate user can ever run it), and use removef to clean up the contents file. A side-effect of this is that pkgchk won't normally be able to detect that those files are missing.
Modifying file attributes can be the result of a second package installing the same pathname with different attributes. Having multiple packages deliver a directory is common, but you can also have multiple packages own a file. Whichever package was installed last gets to choose which attributes are correct, and the normal pkgchck is blind to any changes as a result.
There's a trick to get round this. From Solaris 10, the original package metadata (and unmodified copies of editable files) are kept. Each package has a directory in /var/sadm/pkg, and in each of those you'll find a save directory. This is used when installing zones, so you get a pristine copy. However, you can also use the pkgmap file to verify a package:
pkgchk -m /var/sadm/pkg/SUNWscpu/save/pspool/SUNWscpu/pkgmap
and this form of usage will detect files that have been removed or modified by tools that are smart enough to update the contents file.
(Because those save files are used by zones, you'll find they don't exist in a zone because they wouldn't be needed there. So this trick only works in a global zone, or you need to manually copy the pkgmap file.)
Subscribe to:
Posts (Atom)