Karen Tung wrote: > Glenn Lagasse wrote: >> Hey Dave, >> >> * Dave Miner (dminer at opensolaris.org) wrote: >> >>> Glenn Lagasse wrote: >>> >>>> Could I get a reviewer (or more) to have a look at the changes I'm >>>> proposing for 5265 (Distro constructor should auto-generate image >>>> hashes) please? >>>> >>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=5265 >>>> http://cr.opensolaris.org/~glagasse/slim_source/ >>>> >>>> In case anyone is curious, I'm generating MD5, SHA-1 and SHA-256 >>>> cryptographic hashes. SHA-256 may be a little overkill but it's *more >>>> secure* than the others and I figured I'd try and appease the security >>>> conscious crowd while I was at it (SHA-256 checksums are also starting >>>> to show up in the wild from other distributors of electronic media such >>>> as ours so I figured I'd get a jump up). >>>> >>>> >>> I'd suggested this be an option controllable in the manifest, which >>> perhaps is overkill, though on many systems it's going to be a bit >>> time-consuming to compute three different hashes on gigabyte-ish >>> files. That could also be accomplished somewhat more obliquely if >>> this were made a separate step in the finalizer, at least; any >>> reason you didn't choose that design? >>> >> >> I did actually consider those designs (manifest option, finalizer >> script). In the end I didn't really see any compelling reason to >> implement them. They're more flexible certainly but I didn't think this >> sort of feature needed that. I considered image checksums part of the >> same process of preparing the image done in create_{iso|usb}. I suppose >> it's possible that someone may not want to generate checksums for their >> images. In my testing (on a quad core 2 duo with 8g of ram) generating >> checksums took on the order of seconds to generate the hashes for the >> liveCD and usb images (less than 20 for a complete set for both) so I >> didn't consider time as a significant issue even if you consider >> building on 'slower' hardware. >> >> But, it's not difficult to implement either of the other designs. I >> think I'd lean more towards a combination of both, specify which hashes >> you want in the manifest which a new finalizer script then parses. You >> then have flexibility in deciding which hashes you want generated as >> well as checkpoint/resume ability when generating them. >> >> How does that sound? >> >> > IMO, generating of the hashes should be part of the same finalizer script > that generates the associated images, that way, there's no ambiguity about > which image the hashes are being generated for. If we were to generate > the hashes in a separate finalizer script, one will have to check > whether the > given image exist or not, and the name also need to be pass in. > It can work, but I think it is not as clean of a solution. >
I don't see where there's potential ambiguity, or why names need to be passed in. My understanding of the architecture was that we maintained the manifest as a document in the ManifestServ that could be queried by each task for the data it needs. This information is seemingly available there. Dave
