UNIX admin wrote: >> On Solaris 10 you should use a class action script or >> a pre-install >> script, particularly if that user must own files >> installed by the >> package itself. > > Well, I actually split the application from the technical user: the user > comes on as a package, then the application requires that user package before > it can be installed. > > For example, ABCDoracle requires ABCDoracle-user. > > My problem is installation from a JumpStart(TM) server, or to a diskless or > AutoClient systems: to do a -R $PKG_INSTALL_ROOT install, I need some way of > reliably creating users. > > The cleanest way that I can see is using useradd(1M); but useradd(1M) is not > capable of operating on $PKG_INSTALL_ROOT if $PKG_INSTALL_ROOT is not "/". > > So while useradd(1M) is trivial to implement in preinstall and postremove, > the package won't be installable with pkgadd -R. > > That's why I started thinking about SMF manifests, since that would allow for > immediate user creation if pkgadd were running locally, and for deferred user > creation if pkgadd -R /a was executed, but in both instances, I could go > through the operating system's tools, instead of manipulating passwd(4) and > shadow(4) directly. > >> The IPS model of self-assembling pkgs/software >> applies just as well to >> SVR4 packaging; applying the IPS model to SVR4 >> packaging is commendable. > > Thank You for the compliment.
Commendable indeed. On the other hand, a discussion with the team concludes such effort is probably not worthwhile for two reasons: 1) pkg(5) user action reduces this SMF service to very little value since OpenSolaris has no such need. 2) For pre-OpenSolaris, we get little benefit for this work. Immediate user creation for pkgadd to a running root is the same as pre/post install scripts. For user creation on -R $PKG_INSTALL_ROOT, we'll need to boot using that root to import the service which is the same as pkgadd and run pre/post install scripts on a live root. That said, if you are still interested, we can pursue this further with discussion of dependency for other services, service states implications , and property organization. cheers, -tony
