Dave Miner wrote:
> Clay Baenziger wrote:
>> Hi Dave,
>> As our resident DHCP guru, what are your thoughts about us
>> stripping out service specific data from a installadm(1) created DHCP
>> macro?
>> My arguments for it would be that leaving the service specific
>> data behind (BootSvrA, BootFile) is troubling for a system admin (i.e.
>> the system won't boot if it tries PXE Booting (and Access Exception is
>> only such a helpful error). Further, the paths on the server may be
>> inadvertently redeployed leading to a client getting unindented data.
>> An argument against is the admin may have modified the macro and
>> expect it to stay around. I would say that we can use the data we
>> already have about a service to check the macro values are original
>> and if they've changed, we could take no action.
>> I like the idea in bug 4566 about splitting into a client
>> specific macro (router, DNS server, etc.) and having that include the
>> service specific macro. But for now, I'm working on installadm
>> delete-service/delete-client and think this should make life easier
>> for an admin (and with relatively little code too).
>> Do you have any thoughts to add?
>
> I would prefer to see the effort expended to restructure the macros a I
> suggested in the comments on this bug. It seems likely to be little
> more difficult to do that work and then allow for clean deletion of the
> macro than to spend effort attempting to do detailed editing of the
> macro. To me, this falls into fixing it right rather than introducing
> band-aids.
At first glance, this appears to factor out pretty easily:
- a Sparc client macro would just need to include the
a sparc install service macro.
(currently, the macro content for a sparc service, and
a sparc client that's set up to use said service are
identical)
- an x86 client macro would need BootFile, GrubMenu, and
inclusion of an x86 install service macro.
(though 7481 says we need to get rid of GrubMenu usage
anyway)
-ethan
