On 02/17/09 23:40, Volker A. Brandt wrote: > Hello Sundar, hello Andre! > >>> http://www.opensolaris.org/os/project/caiman/auto_install/Design_doc_delta_for_AI_Spring_2009.pdf. > [...] > >> Section 1.2 >> >> Several uses of "could" in the paragraph beginning with "If DNS >> configuration is not possible..." Can you tighten this down >> to say what you intend to do for the spring release? >> >> For the DNS-naive like me, what are the implications of using DNS >> unicast? I believe I understand this means that an install client >> can reside on a different subnet than the server, but specifically >> which server functions (DHCP, DNS, TFTP, http) could be on a different >> subnet and which ones would have to be on the same subnet as the >> client (based on what little I know I'd assume DHCP at least would >> need to be on the local subnet while http can be anywhere). > > I would also be interested in this clarification. Specifically, my > personal opinion is that AI-style installations will typically be done > in medium to large infrastructures rather than in a home or developer > environment. > > Such large infrastructures tend to have different admins, if not > different departments, for network/DNS administration, and Solaris > management. In such environments, it is very difficult or impossible > (for non-technical reasons) to implement any changes in DNS.
This problem can't be probably completely avoided but might be mitigated. Service is in following format _OSInstall._tcp.<domain> Thus it might be possible just to delegate '_tcp' subdomain to other machine than official DNS server (e.g. to AI install server). This change might be more acceptable, since it would need happen only once - all service related operations (registering, removing, ...) would then go to the machine taking care of '_tcp' subdomain. Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090219/aea30a41/attachment.html>
