Bart,
Specifically for the user and group actions, what is the expected
behavior for user images, i.e., images being managed by a user without
root privilege and who cannot modify the passwd and group files?
I've noticed that currently, file actions that specify a user/group for
which the user isn't allowed to make the change just install the file as
the current user/group. The specification in the action is just
ignored. Unless... the user or group doesn't exist at all in OS and
then you get a stack trace.
I'd like to clear up the semantics of this so that I can make it work
correctly for other platforms. Also, for SWI, we expect most images to
be user images.
Thanks.
Tom
Bart Smaalders wrote:
Danek Duvall wrote:
On Fri, Feb 08, 2008 at 12:49:21AM -0500, Dennis Clarke wrote:
Where do we stand wrt pre-remove and post-install scripts ?
Still not going to happen. IPS will not execute arbitrary code delivered
by a package, except in the case of a severe security bug.
It appears that the vast majority of postinstall scripts and class-action
scripts exist to update databases (like the various driver-related files,
/etc/passwd, and so on).
For the databases that are required for correct images, or for booting,
there will be custom actions, such as the driver (already available) and
user (in progress) actions.
We also need a group action. The reason user and group are needed is
that files need to be installed w/ the correct uid/gid, which is needed
to boot.
Otherwise, we could delay adding entries to user and group files until after
boot.
For the databases that aren't needed until later in boot, we're proposing
that whatever component utilizes the database should provide a directory
where files can be placed, and an SMF method which, on start / refresh
(potentially kicked by a generic "kicker" action in the package manifest),
import the new files in that directory into the database.
This mechanism is idempotent; repeating the action produces the same
result. This makes the end result independent of package installation
order,
something that is needed to support filtering, downloading just the new
portions
of packages, etc.
For example, rebuilding the catman database needs to occur after man pages
are added or removed. If I install 50 packages that contain man pages
to the running image,
I don't want each package to run the catman command in a postinstall
script. With the kicker
action, upon completion of the pkg install the rebuilding would occur
once. The same
mechanism would rebuild catman once after changed the image filters to
install
man pages and refreshing the pkgs...
- Bart
begin:vcard
fn:Tom Mueller
n:Mueller;Tom
org:Sun Microsystems, Inc.;Portal Server Software
adr:;;2572 County Road 12 ;Fremont;NE;68025;USA
email;internet:[EMAIL PROTECTED]
title:Senior Staff Engineer
tel;work:877-250-4011
tel;fax:877-250-4011
tel;home:402-727-6933
x-mozilla-html:TRUE
version:2.1
end:vcard
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
