Sarah, thanks for the feedback. Responses below... Sarah Jelinek wrote:
>> - Remove barrier to using native packaging on Solaris. Many >> software vendors spend effort producing parallel distributions >> not based on Solaris packages, or do not produce package-based >> distributions at all. This requires the product group to >> re-invent >> technology already available in the packaging tools. >> >> - Reduce or eliminate need to rely on root privileges and >> root-owned artifacts, thereby meeting higher security >> and responsibility partitioning standards. >> > We have this today with zones. See below.... I concur with the other folks regarding zones - this project is not meant to replace zones, it is targeted at the non-root user who wants to install non-system software without requiring administrative intervention of any kind and without the networking and other system-level overhead of creating new zones. I think it is truly complementary to zones. >> High level Technical description: >> >> This proposal introduces changes into the packaging and >> patching utilities to realize the concept of a "software domain", >> similar to the concept of an alternate root, but with >> different semantics. >> >> > Basically, a software domain is a container of some sort to help fence > off the user access? Yes, it's a container, or grouping mechanism, for software. It's not really about enforcing user access, since we already have that today (unix accounts, permissions, roles, etc). This is more about allowing non-root users to re-use the software lifecycle management features of our packaging system and to hopefully lend some consistency to the non-system software (middleware, desktop apps, etc) deployed on Solaris. >> Users will install packages and patches using similar interfaces >> as the root user. The default install locations will be relative >> to $HOME. Package objects will all be owned by the invoking >> user. >> File locking semantics will be unchanged from the root user's >> usage. Scripts will be run as the invoking user. >> >> > So, if a postinstall script requires changing something in the system > that the user installing the pkg doesn't have the privs to do, what > happens? Is the pkg partially installed? I would assume that having to > be root as we have to today elimates this issue since the postinstall > scripts should be able to run without failure, barring a missing file, > or conf error or something. Is it a valid concern that the scripts > associated with a pkg might not be suitable for a user to run even if > installing the core pkg is? How do we ensure this is not an issue? > Yes, absolutely this is a concern. You are not alone in wondering what happens when a normal user pkgadd's SUNWkvm.u to their home directory. There are a few suggestions thus far: 1. Do not allow non-root users to install packages unless the package is specifically marked as UBI-enabled. (FYI, UBI stands for "user-based install"). This has the drawback that anyone who wants their package to be installable by ordinary users must rev their packages to include a new flag. Sometimes this is too resource intensive, especially for older packages whose original authors are long gone. 2. Add a new switch to the packaging/patching tools that say "yes, I know this package is safe for UBI". This has the drawback that you will have to always add this switch, and it is YOU, not the package author, that must determine whether a package is indeed UBI-compliant. 3. Try to figure out whether scripts really need root privs, and fail gracefully before trying to execute them. This is a difficult problem given that scripts are opaque and could do anything. I'm open to other suggestions. >> Each domain has a "Domain-Home", under which all softare >> belonging >> to that domain is installed. This will by default be within >> $HOME >> for non-root users. >> >> Each domain has a sparse package registry of only those packages >> installed on that domain. The registry shares the format of the >> contents(4) file and by default is installed into ~/.sunw, but is >> overrideable with a CLI switch. >> >> Inter-domain dependencies are resolved by following a per-user >> Domain-Path variable (environment variable, or CLI override). >> The first domain able to satisfy the dependency is used. >> >> The "root" domain (the one that exists today on each Solaris >> OS instance) is always part of everyone's Domain-Path and is >> used to satisfy package dependencies when no other domain can. >> > So, first the users domain is searched, then the root to satisfy > dependencies? > Yep. However, these dependencies are "soft" in that if you change to a different machine (say, you mount $HOME from a windows machine), the system packages aren't the same, and so your dependencies may no longer be met. > So, general questions: > 1. How does upgrade work with this new scheme? Perhaps the answer is > just as it does today, just checking. No changes. Of course, upgrade is not currently supported directly by the packaging tools. The Solaris OS upgrade is done through a combination of RE scripts, metadata above the packaging tools (such as the .pkghistory file), and fancy class action scripts. The packaging tools themselves operate in either "instance=overwrite" or "instance=unique" mode and they have no idea that an OS upgrade is in progress. > 2. Does this affect diskless client installs? No, this project does not change that. It is my intention to not affect existing root-based usage of the tools. The diskless client setup tools will continue to use the exact same interfaces they have been using. > 3. How does patching work? Will users be able to patch their software > domains? > Yep, we are proposing a change to patchadd and friends to similarly be able to patch user-installed packages within a domain. Similar concerns that you raised earlier (regarding scripts that *require* root privs) apply here too. -jhf-
