On 04/15/09 17:05, Ethan Quach wrote:
>
>
> jan damborsky wrote:
>> Hi Ethan,
>>
>>
>> On 04/15/09 16:03, Ethan Quach wrote:
>>>
>>> jan damborsky wrote:
>>>
>>>> with respect to
>>>>
>>>> * what are desired install service scopes to be available
>>>> - currently for Sparc we can either explicitly associate install
>>>> service with particular client (identifying it by MAC address)
>>>> and use another one for rest of Sparc clients. More than one
>>>> service can't be created serving broader scope, since only
>>>> one /etc/netboot/wanboot.conf file can be created.
>>>>
>>>> * how Sparc client obtains location of AI images
>>>> - now it is spread across two places - one for boot_archive,
>>>> one for compressed archives. It should be consolidated, so
>>>> that it is less error prone and easier to maintain.
>>>>
>>>> Proposed fix for now:
>>>> ---------------------
>>>> For now any significant design changes are not appropriate,
>>>> since they would be too risky. Based on this I am thinking about
>>>> following temporary solution before final approach can be taken:
>>>>
>>>> * when new service is created, don't touch /etc/netboot/wanboot.conf
>>>> if it contains pointer to existing boot archive. It makes sure
>>>> that once /etc/netboot/wanboot.conf is created for one service,
>>>> it is not accidentaly overwritten by another service. So clients
>>>> would
>>>> continue to use first service as a default (in cases 'create-client'
>>>> is not called) and mismatch would be avoided in this case.
>>>
>>> But if we create a second sparc service (say with build N+3, or N-3
>>> for that matter), then clients trying to use the second sparc service
>>> will get a mismatch still, right?
>>
>> It depends on how the second service is created:
>>
>> [1] installadm create-service -n service_2 -s <ai_iso_2> <ai_image_2>
>>
>> In this case, the only way how client could use service_2 is to
>> associated
>> it with this service explicitly by calling 'create-client'.
>
> But does a sparc create-service without the -i -c not create the
> /etc/netboot/wanboot.conf file?
For now /etc/netboot/wanboot.conf is always written for 'create-service'
command even if it is called w/o -i -c. This is the reason why mismatch
always happens once second service is created.
The temporary fix suggests to 'lock' that file by the service which
accessed it first and 'release' it once service along with AI image
is deleted. I agree there are issues with this approach.
>
> DHCP config is totally secondary. A user who just moderately knows
> what they are doing can subsequently manually add IP addresses associated
> with the service_2 macro created above.
I am not sure we could expect the user to take care of this. My feeling
is that if there are steps required which can't be either accomplished
by installadm(1M) tools itself or by copy-paste of the output those tools
produced we shouldn't support/allow such scenario.
>
>>
>> service_1 will continue to be used by default (if 'create-client' is not
>> called).
>>
>> Mismatch doesn't occur.
>>
>> [2] installadm create-service -n service_2 -i <IP_start_2> -c
>> <IP_pool_size_2>
>> -s <ai_iso_2> <ai_image_2>
>>
>> * /etc/netboot/wanboot.conf will still point to service_1 boot archive.
>> * two disjoint sets of IP pools will be available
>> one for service_1 associated with service_1 dhcp macro,
>> one for service_2 associated with service_2 dhcp macro
>>
>> New client connected to the network would obtain boot archive from
>> image_1,
>> but I am not sure how DHCP server behaves in this situation - from which
>> pool it will assign IP address ? Is this deterministic/supported
>> scenario ?
>
> Nope, its random. A client can be given an IP of either pool.
>
> Its not a deterministic scenario. I've yelled about this before, but its
> apparently a designed usage case.
Is it captured somewhere to take a look at ? To be honest,
I am not sure how it might be useful for client since it
is not known what it is going to boot.
>
>>
>> [3] installadm create-service -n service_2 -i <IP_start_1> -c
>> <IP_pool_size_1>
>> -s <ai_iso_2> <ai_image_2>
>>
>> In this case, IP pool for service_1 is replaced with IP pool for
>> service_2
>> which would mean boot_archive is picked from image_1 and compressed
>> archives
>> from image_2 and mismatch would occur. What is expected result in
>> this case ?
>
> Would our calls to pntadm to set those IPs for service_2 macro
> fail since those IPs already exist in the table for service_1?
It seems it succeeds - here is what I have tried:
# pntadm -P 192.168.100.0
Client ID Flags Client IP Server IP Lease Expiration
Macro Comment
010003BAFB20C1 00 192.168.100.228 192.168.100.2
04/16/2009 dhcp_macro_0906_107_120
0100144F98536E 00 192.168.100.229 192.168.100.2
04/16/2009 dhcp_macro_0906_107_120
00 00 192.168.100.227 192.168.100.2
Zero dhcp_macro_0906_107_120
00 00 192.168.100.226 192.168.100.2
Zero dhcp_macro_0906_107_120
00 00 192.168.100.225 192.168.100.2
Zero dhcp_macro_0906_107_120
00 00 192.168.100.224 192.168.100.2
Zero dhcp_macro_0906_107_120
00 00 192.168.100.223 192.168.100.2
Zero dhcp_macro_0906_107_120
00 00 192.168.100.222 192.168.100.2
Zero dhcp_macro_0906_107_120
00 00 192.168.100.221 192.168.100.2
Zero dhcp_macro_0906_107_120
00 00 192.168.100.220 192.168.100.2
Zero dhcp_macro_0906_107_120
# installadm create-service -n 0906_107_120_new -i 192.168.100.220 -c 10
-s /export/home/iso/sparc/ai_sparc_4443_111.iso
/export/home/images/ai_sparc_4443_111_test_120_new
Setting up the target image at
/export/home/images/ai_sparc_4443_111_test_120_new ...
Registering the service 0906_107_120_new._OSInstall._tcp.local
dhtadm: GrubMenu already exists.
dhcpconfig: Error - creating network macro. 192.168.100.0 already exists.
Service discovery fallback mechanism set up
SPARC configuration file is used by service 0906_107_120
# pntadm -P 192.168.100.0
Client ID Flags Client IP Server IP Lease Expiration
Macro Comment
00 00 192.168.100.229 192.168.100.2
Zero dhcp_macro_0906_107_120_new
00 00 192.168.100.228 192.168.100.2
Zero dhcp_macro_0906_107_120_new
00 00 192.168.100.227 192.168.100.2
Zero dhcp_macro_0906_107_120_new
00 00 192.168.100.226 192.168.100.2
Zero dhcp_macro_0906_107_120_new
00 00 192.168.100.225 192.168.100.2
Zero dhcp_macro_0906_107_120_new
00 00 192.168.100.224 192.168.100.2
Zero dhcp_macro_0906_107_120_new
00 00 192.168.100.223 192.168.100.2
Zero dhcp_macro_0906_107_120_new
00 00 192.168.100.222 192.168.100.2
Zero dhcp_macro_0906_107_120_new
00 00 192.168.100.221 192.168.100.2
Zero dhcp_macro_0906_107_120_new
00 00 192.168.100.220 192.168.100.2
Zero dhcp_macro_0906_107_120_new
Jan
