Hi Darren, thank you for your comments.
Please see my response in line. Jan On 05/30/12 15:07, Darren Kenny wrote:
Hi Jan, On 30/05/2012 12:59, Jan Damborsky wrote:Hello caimaniacs, I am currently evaluating following net text install bug (which is in fact regression I caused when fixing 7162079): 7172606 Network text install fails trying to download /etc/shadow I have some idea how it could be addressed, but since this particular issue seems to reveal more generic kind of problem, I would like to verify if approach I am considering seems reasonable. Concurrently I am working on related code changes in order to find out if that approach is feasible or not. Please see proposal below. Thank you very much, Jan Background ========== In cases when CPIO transfer method is used for populating installation target, there are files which need to be reverted to their pristine state on target (shadow(4) being one of examples). Those files are stored within dedicated "save area" during process of media construction. Then during installation they are transferred to appropriate places by CleanupCPIOInstall ICT task. In case of media boot (text installer, GUI installer), those files reside under /.cdrom/save directory while in case of network boot (text installer only) they are downloaded file-by-file from AI server to /tmp/ directory, then copied to the target. Problem statement ================= In general, "save area" may contain files with restrictive combination of ownership/permissions. That turned out to be problematic in case of net boot when files are transferred one by one by webserver running under webservd user. In particular, webserver currently fails to transfer shadow(4) file, since it's root readable only. Proposed solution ================= Since "save area" may contain files webserver may not be able to access directly, I am wondering if instead transferring those files separately, if it may make sense to transfer them in form of archive, then unarchive them on target. In particular, I am thinking if "save area" may be delivered by existing solarismisc.zlibarchive. /.cdrom/save would be just symlink to perhaps /mnt/misc/save directory which would contain populated "save area". Advantages of this approach: - solarismisc.zlibis standard archive delivered in all scenarios. Thus, consistent approach could be used for all types of installations, no need to distinguish between net boot and media boot. Related pros: - simplified code - simplified test matrixLooking for the least-change approach, I'm wondering that given that these files are being served by the webserver, can they not just be made open for reading by the webserver? It's not as if they contain any significantly restricted content at this point in time - the main thing is to ensure they have the correct permissions on the client side...
Yeah, I agree those are pristine files which do not carry any secret. However, that would mean we would still need to keep two mechanisms for handling 'save area' (one for net boot, one for media boot) which is something I think it is worth to eliminate.
But, that said, I do like the idea of transferring them in an archive, where possible, and it wouldn't seem to be that big a change either, since the files are copied to the save dir by DC in the pre_pkg_img_mod checkpoint, which is run before pkg_img_mod that creates the zlib files.
Yep, I agree. _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
