Axel Thimm wrote:
On Mon, Sep 15, 2008 at 08:27:46AM -0400, Michael DeHaan wrote:
> Axel Thimm wrote:
>
>> On Fri, Sep 12, 2008 at 05:28:16PM -0400, Michael DeHaan wrote:
>>
>>
>>> Axel Thimm wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> On Mon, Aug 25, 2008 at 03:20:04PM -0400, Michael DeHaan wrote:
>>>>
>>>>
>>>>
>>>>> When pxe_just_once is enabled, Cobbler is smart enough to remove the
>>>>> per-mac-address PXE config file of a system once it is installed to
>>>>> prevent infinite PXE boot loops.
>>>>>
>>>>> Currently Cobbler does this by removing the TFTP config file for that
>>>>> particular MAC address, falling back to whatever is the default. But
>>>>> what happens if your default system is configured, as in something
like
>>>>> this:
>>>>>
>>>>> cobbler system add --name=default --profile=default-profile OR
>>>>> cobbler system add --name=192.168.0.0./24
>>>>> --profile=default-profile-for-network
>>>>>
>>>>> You'd reinstall that system.
>>>>>
>>>>> It's been suggested that a better behavior for this is to change
the
>>>>> template the system uses and save it instead as a PXE config that
>>>>> explicitly local boots the system.
>>>>>
>>>>> I can't see this breaks anyone but I figured it would be
important
>>>>> enough to mention here. (If it does, let me know, and we can talk
>>>>> about making a config option, otherwise I'm not going to worry
about it).
>>>>>
>>>>>
>>>>>
>>>> Will it be possible to have the memtest/rescue etc. profiles still
>>>> available in that template?
>>>>
>>>>
>>> If you disable netboot via the above means it will local boot, so no.
>>> If you wanted to boot those you would instead do:
>>>
>>> cobbler system edit --name=foo --profile=name_of_rescue_profile
>>>
>>> or
>>>
>>> cobbler system edit --name=foo --image=name_of_memtest_image
>>>
>>> which would tell those systems, yes, you should PXE boot something, but
>>> PXE boot this instead of an installation image.
>>>
>>> Hopefully that answers the question and satisifies your use case?
>>>
>>>
>> The old setup would allow local admins to do some fast diagnosis w/o
>> having to change cobbler parameters. It would be nice if this could
>> still be the case by maybe reusing the same template as before but
>> defaulting to localboot.
>>
> I'm not sure what would be being "diagnosed", do you have a particular
> problem in mind?
>
> The idea is that /var/lib/tftpboot and/or /tftpboot is to be edited by
> Cobbler, and this version seems more generally useful in that it does
> not conflict
> with ip-based-defaults or defaults in general.
>
I agree, I just suggest the now not removed system specific pxe menu
to include the old menu items besides localboot.
Ok, I understand what you are asking for now.
> Regardless, I should point out that this is unlikely to change or
become
> an option, as it would be too confusing of an option to explain.
>
I haven't actually tested the latest cobbler bits, so maybe I
misunderstood something, but let me explain the use case: The standard
menu (not the one when the super admin performs a mass reinstall or a
install from scratch) here offers:
localboot
install Fedora 32 bits
install Fedora 64 bits
rescue Fedora 32 bits
rescue Fedora 64 bits
memtest
(actually it is even more convoluted, we have Windows vs Linux dual
boot options here as well, also some reinstall options, but lets keep
it simple for the discussion).
Understood...
This allows local admins to perform some testing or non-central
managed installs themselves. This lifts a lot from the central admins
shoulders especially the 24/7 availability of support.
*If I understand correctly* the new cobbler setup would have managed
systems boot post-install directly into localboot and not offer
anymore a choice of other profiles etc.
So the use case here is that you want to use Cobbler to manage DHCP/DNS
and the profile list, and also the system list, but you still want to be
able to walk up to the machine and reinstall it. This makes perfect sense.
I think this is easily handled by just (instead of creating the new file
in place) just symlinking to the default config. Do you want to take a
shot at making this change or shall I?
Any objections to this behavior? The only downside is it allows someone
with physical access to do "stupid things" but they could do this anyway
if there was no system record defined -- in that case, it does seem like
a bad thing at all.
--Michael