Hi Dave, Just a couple follow up comments inline. I deleted everything that I have no further comments on.
On 02/23/10 07:55 AM, Dave Miner wrote: > >> 3) create-service command allows one to specify an alternate package >> name. To me, >> that means, people can just use it to install any package. Is there any >> changes needed >> in installadm to validate that all the files downloaded actually >> comprised of a "valid" AI image? >> Or do we assume that people know what they are doing? >> > > installadm could take action to validate against the presence of the > property defined to identify the image's default service name, but I'm > not certain we'll want to do that as the benefit seems relatively low. > Most likely we'd fail unless they assigned a specific service name to > overcome the lack of that property; to me, that's enough protection here. Since we know about the structure of the AI image, I thought we can do some simple checks to validate it. One thing to check is the property defined to identify the image's default service name, like you mentioned above. Other quick and simple things that come to mind is the presence of the .auto_install file, solaris.zlib, solarismisc.zlib....etc...basically, all the files that will get downloaded to the client. I understand that we can not check every single thing and be 100% sure, but since these checks are very simple to code/maintain/execute, I thought it will provide a better user experience for cases when the person setting up the service accidentally put in the wrong package name, or pointing to a repo in an odd state or something like that... > >> >> Update section >> -------------------------- >> 1) Users are allowed to specify a FMRI or URI for -s in this case. >> Since this operation is meant for "update", >> and people can specify anything in the FMRI or URI, even a different >> package name than what is currently >> there. The image might be greatly altered if people do that. Does the >> update-service command >> prevent that from happening? >> > > Yes, it can be greatly altered; that's an intentional byproduct of > updating, especially if there's a significant redesign of the media > architecture. Why would we want to prevent it, and in what way would > you suggest doing so? Since this an "update" operation, I was thinking that we just do a "pkg image-update" to the user image. Adding more packages and updating existing ones is certainly another method of update. If we allow that, we can also perform the simple sanity checks discussed above. Thanks, --Karen
