Why doesn't setting the manifest file's class (in prototype/pkgmap) to "manifest" do the right thing?
Peter Cudhea wrote: > Maybe I should be more clear. I don't see any bug in SMF. I do see an > issue in the way PSARC 2007/414 for the iscsitgt service was introduced > -- it could have then introduced a postinstall script (I think) to do > the steps I am discussing today. But even then, I am not sure there is > a bug that should be turned into a CR. Here are the details. If you > see a CR in the following I am happy to file one. > > When PSARC 2007/414 was integrated, it required that the iscsitgt > service would run with the proc_setid privilege. A new copy of the > manifest /var/svc/manifest/system/iscsi_target.xml was introduced that > gave the service that privilege. The method of updating the system to > the new bits always involved doing a pkgrm followed by a pkgadd. This > always caused the new manifest to be imported, so the service always > started up with the correct privilege. > > But now, PSARC 2007/414 is being ported back to S10. In this case, the > code will be installed by patchadd, which does not remove the manifest > and reimport it. So the observed symptom is that the iscsitgt service > fails to start. > > And my proposed "fix" is to introduce a postinstall script as part of > the SUNWiscsitgtu package, in S10 only. The postinstall script detects > if the start/privileges property for the iscsitgt service is lacking the > proc_setid privilege. If so, it "knows" that the boot environment > being installed into does not have a current version of the > above-mentioned manifest, so it re-imports the manifest. That > postinstall process must run correctly whether the patchadd is being > done either to a live boot environment (with no reboot) or to an > alternate boot environment (e.g. by luupgrade -t). So we want to make > use of the /var/svc/profile/upgrade mechanism to cause the correct > import to happen later when the system is activated/rebooted. (One > minor wrinkle is that when this patch is created as a test IDR, I have > to manually insert the correct sections of the postinstall script from > my SUNWiscsitgtu package into the IDR's own postinstall script. As far > as I can tell is the way IDR postinstall scripts are designed to work.) > > Given this longer description (many of the details of which got fleshed > out in the last few days since my original query) do you have any > additional comments or requests? I have a contract request outstanding > to the contract manager for the /var/svc/profile/upgrade mechanism so I > can use it. I have implemented all of the above and it seems to work. > > Comments? > > Peter > > David Bustos wrote: >> Quoth Peter Cudhea on Thu, Nov 13, 2008 at 12:09:48PM -0500: >> >>> I don't think there is a bug to file. I think the workaround is >>> required in this case. Thanks. >>> >> If there isn't a bug, then your workaround is not a workaround. Please >> file a bug. >> >> >> David >> > _______________________________________________ > smf-discuss mailing list > smf-discuss at opensolaris.org >
