On 05/17/10 11:15 AM, Sebastien Roy wrote:
On 05/17/10 10:10 AM, [email protected] wrote:
Hey Clay,
I'm ccing- Sebastien Roy, "Seb".
Seb is a staff engineer and architect in the networking group.
I don't think using driver name or IP address may be the correct thing
to do. I believe the future direction is to use vanity naming.
Please connect with Seb on what the best way is to identify the
interfaces.
Unfortunately, I don't have enough context to be able to know what
you're trying to do. Can you explain?
-Seb
Hum, I thought I had sent you the context... ?
In brief Clay is working on an approach to support a multihomed
Automated Installation Server.
When I read the below message Clay had sent out my understanding was he
is proposing using the driver name for the interfaces AI should server.
I just wanted to suggest he contact you to discuss what would be the
best approach to do this moving forward. I am not sure but I suspected
you would know. I cc-ed you as a heads up that Clay would likely be
contacting you.
Joe
On 05/13/10 07:43 PM, [email protected] wrote:
Hi all,
Here's what I'm envisioning for the AI multihomed implementation
plan. Please let me know your oppinion of it or if it looks like
anything is missing.
Thank you,
Clay
UI Impact:
---------
*SMF
Changes to service (svc:/system/install/server:default):
-------------------------------------------------------
*New interfaces astring value (will hold comma separated list)
(I believe interfaces (e.g. e1000g0, nge3) to be easier for an
admin. to reconcile than a list of network IPs (e.g.
192.168.0.1/24, 10.10/16) perhaps others feel differently?)
*New interface_mask property
(will accept "include" or "exclude" to either only serve on or
exclude from serving on the listed interfaces)
If an interface listed is not on the machine, a warning will be
printed to the SMF log every service start of the service. If the
interface_mask property is set to something other than "include" or
"exclude" the service will print an error to the SMF log and exit the
start method with $SMF_EXIT_ERR_CONFIG.
Method Changes:
--------------
*refresh -
Will refresh which interfaces are served by AI (the
list of interfaces is not a public interface to modify
other than this SMF action and the SMF properties)
*start -
Will first perform a refresh and then start serving on the
interfaces to be served by AI
Both start and refresh:
If a new interface is brought up or an old one removed,
suggested Solaris DHCP server commands will be provided to
setup or tear down the interfaces in DHCP through the SMF
log.
* DHCP
The -i and -c create-service arguments will not be supported when
multiple interfaces are present, an error message will be output
if attempted.
(As the SPARC BootFile URL has a hard coded IP address,
SPARC and X86 will differ in their DHCP requirements.
SPARC will require only a per subnet macro nothing more,
to the per-subnet BootSvrA data and per-service BootFile
data for an X86.)
SPARC:
Will provide an AI macro per subnet which will provide a
specific BootFile URL specifying the subnet correct
webserver location to provide the wanboot CGI.
X86:
Will provide an AI macro for each service with a BootFile
file path, however, it will be desired that a separate
macro configure the BootSvrA location on a per-subnet
basis. For example, this data could be included by the
network macro or some other macro which is included for
AI client use in a network specific manner.
* mDNS
Will have a separate mDNS responder listening on each interface to
respond with the correct IP address to advertise for the AI
webserver and interface. Responders will no longer be dns-sd(1)
based per work happening as part of the AI Webserver project.
* GRUB
Will extend the install_media and install_svc_address fallback
mechanisms in slim_source's
usr/src/cmd/auto-install/svc/manifest-locator as
currently delivered by GRUB to flag for using dhcpinfo(1) instead
to locate which machine provided the boot server via DHCP and use
that IP address in downloading .zlib files.
* Wanboot
Wanboot in its wanboot.conf provides a root_server value which has
an IP address in it. This project will modify ON's
usr/src/common/net/wanboot/bootconf.c valid_root_server()
function to populate a variable substitution similar to GRUB's
handling of variables (e.g. kernel$ enabling $ISADIR) for
providing a subnet specific IP to clients; the incoming subnet's
interface is returned in place of the token (envisioned to be
'$serverIP').
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
