Steve Lawrence wrote: > Call this requirement (no login prompt) out in your use case. I assume > the patch service will patch, set the boot milestone, and reboot before > the patch milestone is actually met, avoiding the maint prompt.
Yes. > Definately get some console messages out of the patch-service so folks don't > think their boot is hung and freak out. :) I believe they're already there. >> There are approximately two tricky parts to this puzzle: >> a) How does the patch tool reboot the system to milestone/patching? It >> could use "reboot -- -m milestone/patching", but that would mean that >> the patching work wouldn't get done if the reboot was done through other >> mechanisms. It could set the system default milestone, but then how >> would it determine the milestone to set the system back to when patching >> was complete? Neither answer is pretty, but either is workable. > > I'm sure you could write the old boot milestone down somewhere. Hmm. I was concerned about that, but also about the possibility that we'd overwrite the admin's subsequent selection with the value that we remembered. I guess that can't really happen, since we won't do the overwriting if the milestone isn't set to our magic one. (Well, except for truly perverse sequences like "we remember A, set it to P, user sets it to B, user boots to P, we reset it to A".) > If the admin modifies the milestone after the patch tool sets it > to milestone-patching, the patch-on-next-boot will just get clobbered. > I suppose the patch-service could then re-instate it on the next boot, and > hope to get it on the subsequent boot. I like that plan. > I suppose being "inside the bounds of SMF" also makes the implementation > vulnerable to other admins manimpulating SMF. The above issue is basically > by design. Sure. It'd just be nice to have a scheme that was both within the bounds *and* didn't offer the user any ways to break it :-) >> b) How do the patching services *avoid* running when the system is >> coming up normally - even if they have work to do? Probably the best >> answer is for them to check the target milestone and fail (or succeed >> without doing anything) if it's not milestone/patching. > > That makes sense. It would have to do-nothing-succeed to work with > milestone "all". Do-nothing-fail would also work - it would just result in a message and putting the service into Maintenance, just like any other miscellaneous failing service. If the patching service has work to do, and isn't able to do it because the system isn't booting the right way, that might be the rightest answer. >> I understand your reluctance to add system/filesystem/local to >> milestone/single-user. If there's consensus that that's an unacceptable >> change, then instead: >> >> 1) Have patchadd mount zone roots if they are not already mounted. >> 2-5) As above. >> >> Hmm. My initial thought was that patchadd could not use >> system/filesystem/local to do these mounts because of deadlock issues. >> However, since we've moved automated patching to slightly *after* >> milestone/single-user, perhaps those deadlock issues do not exist. > > Right. Just make the patch-service depend on filesystem-local. If > then patchadds issued by patch-service enable filesystem-local, it will > be a no-op. No need. The enable done by patchadd will be sufficient. We should represent the dependency on filesystem/local in exactly one place, either in patchadd itself or in the dependency list for milestone/single-user. > Another approach is to just modify patchadd to exec > /lib/svc/method/fs-local if called from SMF context. patchadd also stops > filesystem-local when done, but the stop method for that service is :true, > so stopping it is a no-op. patchadd should really verify fs/local's > dependencies are online before doing this. Patchadd is already parsing > the output of the svcprop command as it is. It could certainly read > start/exec property and whatever else. This would fix both smpatch and > UCE, and whoever else may depend on patchadd working from rcS.d. rcS.d doesn't really work, because of the SMF deadlock issue. (Some SMF operations deadlock when run from rcS.d scripts. Some patches use those SMF operations.) This is kind of unfortunate, because rcS.d is the only way (other than a new milestone) to catch the system in the right state. rcS.d scripts are not the Way Of The Future. It's also just gross :-) However, if we can make it work and everybody can agree that it's THE way to solve the problem, it's OK with me. I like the "new milestone" answer above, plus either moving filesystem/local or enabling it from patchadd, better. --- I know this has looked like wandering in circles, but I think it's been quite helpful - I think we're getting pretty close to a reasonable answer. Thanks. _______________________________________________ zones-discuss mailing list firstname.lastname@example.org