On 12/ 8/10 04:32 PM, Scott Dickson wrote:
On 12/ 8/10 03:21 PM, Dave Miner wrote:
On 12/ 8/10 02:48 PM, Scott Dickson wrote:
Looking at AI (and even bootable AI), finish scripts are sort of a
hassle.
It appears that if I want to have my own finish scripts, there's a lot
of overhead: I have to bundle it all up into a package, complete with
SMF manifest and activations, put it into my own repository, make sure I
install that package, and *then* do whatever I wanted the finish script
to do. Seems a lot.
What about having an almost empty package that I can add, for the sake
of discussion service/finish-script, that includes the SMF
infrastructure to make it execute at first boot (and only first boot),
along with a named exit that I can use for the payload. So, this package
provides a null script called /etc/init.d/finish-script, for example. I
can then either put my code there or make it call my code.
This really reduces the overhead in terms of development for adoption.
Having do build my own packages, using the distro constructor, or
anything like that is way too burdensome.
Or have I missed something really simple here?
Scott, we've been discussing ways we might make this process easier.
One thing I don't understand is how you're proposing to deliver the
contents of your hypothetical /etc/init.d/finish-script to an AI client?
Constructing an SMF manifest and IPS package is really not that
difficult, though I agree it's daunting at first to figure it out from
the pretty general documentation that SMF and pkg provide. I'm
looking to provide a pretty simple cookbook approach real soon that
should shorten the distance to happiness while we consider
enhancements that could make this
A lot of the customers I talk to already have an NFS infrastructure that
they use to deliver the finish scripts, the packages they load, etc.
But that doesn't really help here. Clearly, I had no thought through
the entire process.
I suppose my notion was that I would want to leverage existing
infrastructure as much as possible.
Understood. A noble goal :-)
I guess this very quickly gets to a chicken & egg scenario. Even with a
well known name for the hook, as you asked, how to get that content to
the system. And presuming the NFS world or something strange like that
is almost always going to fail to suffice.
NFS will be available in a lot of cases, I'm sure, but I don't want to
produce a design that requires it, as there intentionally isn't any
other case in AI that does (allows AI services to run in a non-global
zone as one benefit). But, like the recent change we made to turn on
the automounter so that file-based pkg repo access could be used, we're
certainly happy to optionally use NFS where it's preferred by the
customer for whatever reason.
One thing to know is that, because we're using the wanboot
infrastructure under the covers, we actually have a dynamic web server
in wanboot-cgi that can scoop up content automatically and supply it to
the clients as part of the boot payload. We're not leveraging it as
well as we could yet, but it's one mechanism that can be used in solving
some of these problems.
This really isn't an easy problem. Folks often have very complicated
scenarios. Perhaps an easy, canned cookbook to set up a minimal repo on
whatever system they would have used for their finish scripts would be
the best bet.
The thing I keep coming back to is the simpler this is, the more it
wears down the adoption hurdle. If I have to figure out all of this
just to install a server in my environment, it's going to really slow
down folks adoption.
I agree, and let's keep brainstorming. Glad to have the input!
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
