Did this email make it through to anyone on this list? I understand that there's a lot of activitity here so people are probably busy, but I've never seen 2+ weeks go by without some sort of response to a message like this. Made me wonder fi it even got through?
-Kyle On 7/13/2010 12:21 PM, Kyle McDonald wrote: > On 6/24/2010 8:12 PM, Ethan Quach wrote: > > >> I have posted an updated revision to the derived manifests design. > >> http://hub.opensolaris.org/bin/download/Project+caiman/DerivedManifests/DerivedManifestsDesignSpec.pdf > > >> Deltas from the previous version are interspersed throughout, but >> the relevant areas of change are Section 5. > >> Also note, I am taking a look a the ManifestParser/Writer design to >> understand how the Manifest Input Module proposed in this design >> would fit in with that, so further changes there may occur. However, >> majority of the document should be reviewable. In particular, I would >> like to get any additional feedback on the AI server changes (Section >> 5.3) sooner than later. > > >> Comments by 7/1 appreciated. > > > I've been away from this list for a while. So my appologies of finding > this new project so late. > > I'm actually very excited to see this is under development. I had given > up hope a while ago. > > I've nearly completed extending the scripting framework I used for years > with JumpStart so that it can configure both KickStart and AutoYast > installs also. I'm excited to see how easy/hard it will be to extend it > to producing AI Manifests also. > > So far I've only read part of the way through the document, but I read > one thing that, while I don't object to (at least I can't think of any > issues it will cause me yet,) I'm very curious why it's needed. > > The section is: > >> 5.2.6.1 Special aiuser account > . > . > . >> The script will only have limited write access to the system however, >> to prevent misuse of the script doing anything other than deriving a >> manifest file. > > Why care? > > If the system at this point is booted over the network (or media for > that matter,) and running from a ramdisk, nothing the script might > change will be permanent, or could affect the system. > > Why is this 'Jail' required? let alone desirable? > > If someone somewhere comes up with some great new thing that it makes > sens to piggy back on this (related or not) why prevent that? That's not > far fetched - I think JumpStart (but can't name any specific examples) > was used a s building point for a number of other things. What's wrong > with that? > > I can understand wanting to only support a limited usage model, but do > you have to actively put up barriers? > > What's the difference between me developing and testing and debugging a > script that breaks because a command is no longer available, and me > developing testing and debugging a script that breaks because the > command I wanted to run is not allowed to be used? > > Seems like the same amount of hassle and work to me. I think you'll have > more frustrated users complaining when the commands are there and > available but they aren't allowed to use them, then if they are there > and unsupported, and change in some way some day. > > That said, as long as HW details can be determined, Other NFS > directories mounted, and temporary files created, cat'd, grep'd, sed'd, > and awk'd. I can't (off the top of my head) think of any reason why it > would cause any problems for what I want to do. > > I'm excited to read further. Thank you! > > > -Kyle > > > > > > > > > >> thanks, >> -ethan > >> _______________________________________________ >> caiman-discuss mailing list >> [email protected] >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss _______________________________________________ install-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/install-discuss
