Vreman, Peter - Acision wrote:
>> I want to add an autodiscovery feature. I have some questions
how to
>>
> start:
>
>> - What kind of initrd shall be used?
>> o Use livecd-tools to build the initrd+kernel from Fedora/RHEL/CentOS?
>> * Minimum size is 150MB
>> * Easy to maintain and regenerate
>> o Create a small busy-box initrd+kernel
>> * Minimum size is 20MB
>> * Harder to understand
>> * Requires more indepth linux knowledge
>> - Which API to use?
>> o HTTP services?
>> o XMLRPC read/write API? (listens currently only on localhost)
>> - Instead of creating something new extend koan with a new --discover
>>
> function?
>
> I take it you're more interested in auto-discovering what's on the
> network than where the cobbler server is, but anyway, some background
> info:
>
> I wrote the opposite kind of auto-discovery feature (using Avahi MDNS)
> into koan a while back for implementation of the koan live CD, which has
> been replaced by "cobbler buildiso" because it's much easier and
> reliable. The auto-discovery feature, however, is still in the code. You
> can read a bit about it here:
>
https://fedorahosted.org/cobbler/wiki/KoanAndAvahiServiceDiscovery
>
> Somewhat related, cobbler also has an auto-registration feature here
> that will allow new machines, set to boot a "default" profile, to
> register themselves (with the mac address as the initial name) in
> cobbler so you can reassign them with simple commands like "cobbler
> system edit --name=$macaddress --profile=foo". This allows you to use a
> simple basic kickstart, install systems to a very basic profile, and get
> them registered. However, this does currently require an installation to
> register them for the first time. See more here:
>
https://fedorahosted.org/cobbler/wiki/AutoRegistration
>
> While koan's live CD didn't pan out, making a live image that simply
> calls cobbler's registration API without doing an install might be a
> very useful feature, especially when coupled with some very basic
> instructions about how to set that up for the default profile in
> cobbler. It could perhaps be written to learn more about the system than
> the registration API currently allows, and storing more in Cobbler,
> though we have to be careful to only create new system records ... if we
> allow overwriting of existing ones, it's a potential security concern as
> there's no good way to authenticate bare-metal hardware :)
>
> I'd look over the auto-registration info and see if that is enough, or
> if you think a live CD based approach (and existing those APIs) might be
> able to accomplish more.
>
Maybe I should call it auto-provision instead of auto-discovery.
The new network code requires that all physical NICs have a MAC assigned. I want to have
an auto-provision of the NICs with a MACs for all detected NICs.
I have also thought about making the auto-provision-live-cd similar to buildiso option so
you may build the auto-provision-live-cd using the kernel of the distro you want to match
the hardware-discovery.
Regards,
Peter
Provision is a complicated word, so I am trying to avoid using it where
I can now, despite a history of using that word :)
I think what you are describing is auto-inventory, seeding Cobbler with
all of the MAC address info it can, and then provisioning later once you
assign them to certain profiles.
You don't need all the NIC info in Cobbler to provision, certaintly...
folks can also deploy using profile records if they don't want to create
the system records.
The MAC is of course required to pin a specific piece of hardware to a
specific profile without using the menus or the default profile, or
without using a "per-network" profile mapping (cobbler system record
with --ip input in CIDR notation to assign only certain systems to
certain profiles).
The inventory probe sounds interesting to me, otherwise improving and
adding to the registration mechanism could be very interesting.
(Especially if it described a bit more about the system maybe in the
comment field, and maybe had options on also registering inventory with
a Smolt server?) We haven't persued any kind of trivial cobbler+smolt
integration in the past though it may be something we can do in the future.
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential information and/or be
subject to legal privilege. It should not be copied, disclosed to, retained or used by,
any other party. If you are not an intended recipient then please promptly delete this
e-mail and any attachment and all copies and inform the sender. Thank you.
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler