An image is a collection of installed package instances. A USER image
is an image that consists of entirely relocatable packages. -
paraphrased from doc/images.txt in the IPS source.
Because a user image has only relocatable packages, it can be installed
at an arbitrary location within the filesystem. One can even install
multiple user images that contain the same packages on different
directories. So one can have, for example:
$HOME/mytestglassfish
$HOME/mystableglassfish
where these two images contain some copies of the same packages and some
packages that are different. Both images are independent of one another
and can be completed managed using IPS. User images can be created and
managed by non-root users.
In this context, and "installer" is the program that is downloaded an
run to get one of these user images on the system. The installer might
create an image and then install packages into it, but more likely the
installer includes pre-installed image and it just copies that image
into place. Even with OpenSolaris, what the installer actually does is
to copy a pre-installed ENTIRE image onto the disk. (An ENTIRE image is
an image that includes non-relocatable packages).
Given the application you describe, it sounds like USER images are not
appropriate since you appear to be taking over the whole machine.
However, there isn't any reason why an installer can't be written that
makes use of IPS commands to get the software installed in the image
that is already there, and then runs various configuration software to
setup the system as desired.
Tom
Volker A. Brandt wrote:
Tom Mueller (pkg-discuss) writes:
There are several characteristics that come to mind for applications:
1) Often, the person installing the application doesn't have root
permission on the system.
2) Often, the person doesn't want the application to run with root
permission
3) Multiple versions of the application may need to run on a single
system (differing at any release level, not just major releases)
4) The application may be intended for only a single user, e.g., a web
server running only in a webservd account.
User images in IPS are intended to deal with these characteristics.
Packages can be pre-installed into a user image, and the pre-installed
user image can then be delivered to the system by an installer. Once
installed, IPS is used to maintain the software within the image. The
installer can deal with initial configuration using whatever means
necessary (independent of the packaging system).
I admit that I am having a hard time following this thread; it continues
to turn in ever widening circles... :-) I still find it interesting,
though.
Anyway, it seems that I need to think a bit more about the distinction
of a package installation environment versus an "installer". I look
at it from a task-oriented angle: My customers (when I have any,
hint hint :-) want jumpstart servers plus custom-built packages.
And they want them integrated. For example, a certain system is
supposed to be a database server with some predefined and preloaded
tables and preallocated database user accounts immediately after reboot,
no interaction required.
So I go and build some SysV database packages and write some clever
SysV package scripts that do most of the work. There are some things
I just cannot do in the jumpstart environment, so I put all those
things into a start/stop script, and drop it into /etc/rcS.d/S99doit
(or write an SMF manifest + start method, which is functionally
equivalent). The S99doit will remove itself once it is done (or
raise an error report somewhere).
Is the S99doit an "installer" in terms of the quote above? If not,
what is an "installer"? What do you mean by "user image"? It really
sounds like a glorified flar delta that I just drop on a Solaris
instance. :-) Why should IPS distinguish between this user image,
and the normal Solaris environment that is just a set of packages,
after all?
I am interested in the design philosophy, but first and foremost
I need to find The Way(tm) to recreate all that I did with
SysV pkg scripts and a start/stop script. The more structure I
am given by the framework, the better. For example, if there
is a predefined "install" milestone that could be used as a hook
for my custom dependencies, fine; I'll use that. Or if there is
a special install service and I need to set some properties
or register my deployment scripts with that service, so be it.
However, like several of my fellow posters, I fear a long row
of triangular and square wheels ahead...
Regards -- Volker
begin:vcard
fn:Tom Mueller
n:Mueller;Tom
org:Sun Microsystems, Inc.;SWI Install/Update Software
adr:;;21915 Hillandale Dr;Elkhorn;NE;68022;USA
email;internet:[EMAIL PROTECTED]
title:Senior Staff Engineer
tel;work:877-250-4011
tel;fax:877-250-4011
tel;home:402-916-9943
x-mozilla-html:TRUE
version:2.1
end:vcard
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
