Installing the nightly build on a remote machine
You might want to use one machine for builds and another (perhaps a VM or a local zone) to test the resulting binary code. One way to achieve this is to fire up an IPS package depot server instance to publish your freshly-built repository. Then you would configure the target machine to use this new publisher and update its boot environment in standard ways. This is detailed in Installing built illumos packages into BEs on a remote host and non-onu updates.
You can run a package depot server instance from command-line, usually to install a single build, or you can set it up as an SMF service instance maintained by the build host's OS as any other service (including
svcadm disable and
svcadm restart actions). Both methods are described below.
Note that the build process and the package repository publishing service can be executed in a local zone, or perhaps in separate OE's (i.e. via shared storage or by publishing built packages from the build host to a remote package depot); however this is a rather advanced topic and not explored below, to keep it short. See http://wiki.openindiana.org/oi/Building+in+zones for example setup of a zone for building OpenIndiana userland software; similar setup can be done for illumos kernel builds.
Run the IPS pkg.depotd server manually
Running a package depot can be done as a one-shot operation like this in a terminal session:
8151is an arbitrarily chosen available port number (8 for HTTP, 151 for oi_151-based build). You might want to pick an available port number under 1024 to ensure that no unprivileged userland program grabs it occasionally for its communications, and use RBAC privileges to allow this service to use the privileged port.
- If you need to publish the depot through an HTTP reverse-proxy server, you can offset with a fully-qualified URL (like shown above). This is not generally required for local operations.
pkg.depotdversions might also require that you add this option (not needed as of oi_151a based server):
Run the IPS pkg.depotd server as an SMF service instance
You can also create an SMF instance to run this server (here we create a dedicated instance which should not be overwritten by OS upgrades; you can also override the
default instance's settings, but such customization may be lost during upgrades or migrations):
NOTE: Like above, the last setting of
proxy_base URL is optional.
Enable the SMF server instance:
Optionally, monitor its SMF log file for errors, etc.:
If you rebuild your
on-nightly repository, it might make sense to recycle the package depot server, just in case, like this:
For more information about
pkg.depotd server, see the man pages: