On 10/ 4/10 03:26 PM, Dave Miner wrote:
On 10/ 4/10 01:16 PM, [email protected] wrote:
Hey Dave,
Thank you for clarifying. My comments in-line below.
Joe
On 09/30/10 06:11 PM, Dave Miner wrote:
On 09/30/10 02:32 PM, [email protected] wrote:
Hey Dave,
I need a little help understanding how P IP Address records be set up.
In looking at the Automated Installation Service and Image Management
Design:
http://hub.opensolaris.org/bin/view/Project+caiman/AI+Image+Management
It is not clear to me how DHCP IP Address records should be structured
when -i and -c flags are specified to create-service sub command.
The first time the user issues:
installadm create-service -n service_A -i 192.168.168.151 -c 5
The default service is aliased to service_A.
How should the DHCP IP Address records be set up in this case?
What happens to the IP Address records when the default service is
aliased to a different service?
Should the IP Address records be associated with the named service or
the default service?
The latter half of the Provisioning section plus the Examples were meant
to answer these questions, but it's probably a little oblique.
Quoting:
The DHCP configuration will be modified to remove the current
implementation's manipulation of the per-network DHCP address assignment
tables to assign clients to services.
The intention is that the address records we generate in create-service
should not reference a specific AI service. The principle here is to
rely on DHCP as little as possible for delivering AI information,
because of the administrative boundaries that often exist at customer
sites. We rely on two things to get the client to the right AI service:
1. The DHCP server's ability to provide configuration automatically to
all clients of a particular class (PXE, or the various SPARC classes)
via a client class macro. We configure the client class macros to
include the macro for the default service, as shown in Examples 1& 2 in
the spec.
My understanding from what Clay has described to me is this may not work
with Solaris DHCP server in a multi-homed environment.
I'll let Clay elaborate.
In a multi-homed environment the network macro might be used to
associate a default service for a network, with the specific address
needed to access that service (assuming a segmented network topology),
but that's all that should be needed to get multi-homed working.
2. The ability of the boot loader (for x86) or wanboot-cgi (for SPARC)
to automatically find client-specific configuration within the
/etc/netboot hierarchy. This allows per-client override of the default
service to use a different service by merely manipulating the
/etc/netboot contents on the AI server.
This allows the administrator of the AI server to point clients at the
right service without the need to modify the DHCP configuration in any
way. Also, aliasing the default service to a different service is
entirely a file system operation on the AI server (your second question
above).
This does leave the question of what value to set in the macro field of
the generated network table entries (your last question), which I guess
I didn't specify. The longstanding convention in the DHCP server is to
have a "server" macro that is used in that field; the server macro is
automatically generated by dhcpconfig or DHCP Manager at initial
configuration of the service and typically has the DNS configuration,
among other things. The current installadm implementation includes that
macro within the generated service macro, which has essentially the same
effect.
Ultimately, this is what all of the generated records should look like
(assuming 172.0.0.0 network, clients starting at 172.0.0.10 and AI
server named "ai-server" is 172.0.0.1):
Cl ID Flags Client IP Server IP Expires Macro
00 00 172.0.0.10 172.0.0.1 0 ai-server
Having the "server" set as the macro field in the generated network
table entries would result in each specified range being available host
"server" wide, even though the user specified specific ranges when
creating specific AI "services"
e.g.: If the user issues:
installadm create-service -n svc1 -i 172.0.0.10 -c 10 ...
installadm create-service -n svc2 -i 172.0.0.20 -c 10 ...
installadm create-service -n svc3 -i 172.0.0.30 -c 10 ...
This would result in IP Address macros:
172.0.0.10 -> 172.0.0.29 all available accross the "host server".
Which, unless I am missing something, would not provide for
distinguishing which range would be associated with which AI "service".
Perhaps this is OK.
Do I have that correct?
Individual IP addresses should not be explicitly associated with a
service; one of the points of this design is to not require that, as
it's a flaw in the existing implementation. There is no control in
create-service to actually assign an address to a particular client, so
the result of your example above is entirely non-deterministic for any
given client. Instead, individual clients are associated with a service
by way of create-client, specifying the client's MAC address.
The capability to configure IP addresses in DHCP is a convenience for
the administrator rather than forcing him to assemble the necessary
sequence of dhcpconfig, dhtadm, pntadm commands to get a working
configuration. Perhaps we should separate it from create-service so that
it doesn't imply a service->address association.
Dave
Ah Thanks! I understand now.
Yes perhaps separating it from create-service might result in less user
confusion.
or
Perhaps we could reduce user confusion by simply including your last
paragraph above, or something of the like, in the user documentation.
Thanks Dave!
Joe
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
