1:49 a.m.
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?
Regards,
Peter
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.
9:55 a.m.
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.
--Michael
Regards,
Peter
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
2:58 a.m.
> 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
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.
7:50 a.m.
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
8:35 a.m.
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).
Agree, the auto-inventory is a better word. It is an addition to the existing
auto-registration and can (if enabled for the system) also be used for manual added
entries.
The new networking code for bonding requires a MAC address for each NIC.
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.
You mean running a smolt-server on the node where the cobbler-server is running?
Regards,
Peter
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.
9:36 a.m.
-----Original Message-----
From: cobbler-bounces(a)lists.fedorahosted.org [mailto:cobbler-
bounces(a)lists.fedorahosted.org] On Behalf Of Vreman, Peter - Acision
Sent: woensdag 3 december 2008 15:36
To: cobbler mailing list
Subject: RE: autodiscovery questions
> 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).
Agree, the auto-inventory is a better word. It is an addition to the
existing auto-registration and can (if enabled for the system) also be
used for manual added entries.
The new networking code for bonding requires a MAC address for each NIC.
> 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.
You mean running a smolt-server on the node where the cobbler-server is
running?
For the auto-inventory I think we can use the output of the lshal command.
lshal contains all information for the network (MAC,ethX and driver) and also provides
information about the system including vendor and serial information
For the inventory it is also usefull to have additional system information fields
available for filtering. E.g. a systems with 64G memory are better suited for a DB profile
than the systems with 8G memory for webservers.
Regards,
Peter
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.
10:04 a.m.
Vreman, Peter - Acision wrote:
> -----Original Message-----
> From: cobbler-bounces(a)lists.fedorahosted.org [mailto:cobbler-
> bounces(a)lists.fedorahosted.org] On Behalf Of Vreman, Peter - Acision
> Sent: woensdag 3 december 2008 15:36
> To: cobbler mailing list
> Subject: RE: autodiscovery questions
>
>
>> 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).
>>
> Agree, the auto-inventory is a better word. It is an addition to the
> existing auto-registration and can (if enabled for the system) also be
> used for manual added entries.
>
> The new networking code for bonding requires a MAC address for each NIC.
>
>
>> 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.
>>
> You mean running a smolt-server on the node where the cobbler-server is
> running?
>
For the auto-inventory I think we can use the output of the lshal command.
lshal contains all information for the network (MAC,ethX and driver) and also provides
information about the system including vendor and serial information
For the inventory it is also usefull to have additional system information fields
available for filtering. E.g. a systems with 64G memory are better suited for a DB profile
than the systems with 8G memory for webservers.
This sounds excellent.
I think it /seems/ to indicate that the following should exist:
koan --server=cobbler.example.com --register-me
Which would register the box if not already registered and add the
hardware info. If the box already existed in cobbler it would only
update the hardware info (like RAM) (to avoid overwriting other more
important data) and refuse to update the network data if already set up.
The live CD you mention could use this.
As I mentioned earlier, due to security reasons, we'd want this off by
default.
Ideally I think we want a setting like:
extended_registration_enabled: 1
And we could obsolete the existing "register new MACs" functionality as
this would be more feature-rich.
It's a slight weakness in that this would create an API that could allow
data in cobbler to be manipulated without access (like the RAM amounts
as we indicate above), though we do it right it should be reasonably
feature rich.
We could think about requring usernames and passwords but since this is
in a provisioning context those credentials would be exposed anyway, so
it's not that useful to do so.
I've also thought about doing something like this through Func, though
I'm not sure everyone would want to adopt Func for this so something
self contained might be better.
Regards,
Peter
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
5:56 a.m.
Michael DeHaan wrote:
This sounds excellent.
I think it /seems/ to indicate that the following should exist:
koan --server=cobbler.example.com --register-me
Which would register the box if not already registered and add the
hardware info. If the box already existed in cobbler it would only
update the hardware info (like RAM) (to avoid overwriting other more
important data) and refuse to update the network data if already set up.
The live CD you mention could use this.
As I mentioned earlier, due to security reasons, we'd want this off by
default.
Ideally I think we want a setting like:
extended_registration_enabled: 1
And we could obsolete the existing "register new MACs" functionality as
this would be more feature-rich.
It's a slight weakness in that this would create an API that could allow
data in cobbler to be manipulated without access (like the RAM amounts
as we indicate above), though we do it right it should be reasonably
feature rich.
We could think about requring usernames and passwords but since this is
in a provisioning context those credentials would be exposed anyway, so
it's not that useful to do so.
I've also thought about doing something like this through Func, though
I'm not sure everyone would want to adopt Func for this so something
self contained might be better.
Hi all,
I'm interested in this functionality, has work started on this yet, or
is it still in the "good idea" state? :)
Jasper
7:46 a.m.
Jasper Capel wrote:
Michael DeHaan wrote:
> This sounds excellent.
> I think it /seems/ to indicate that the following should exist:
>
> koan --server=cobbler.example.com --register-me
>
> Which would register the box if not already registered and add the
> hardware info. If the box already existed in cobbler it would only
> update the hardware info (like RAM) (to avoid overwriting other more
> important data) and refuse to update the network data if already set up.
>
> The live CD you mention could use this.
>
> As I mentioned earlier, due to security reasons, we'd want this off by
> default.
>
> Ideally I think we want a setting like:
>
> extended_registration_enabled: 1
>
> And we could obsolete the existing "register new MACs" functionality as
> this would be more feature-rich.
>
> It's a slight weakness in that this would create an API that could allow
> data in cobbler to be manipulated without access (like the RAM amounts
> as we indicate above), though we do it right it should be reasonably
> feature rich.
>
> We could think about requring usernames and passwords but since this is
> in a provisioning context those credentials would be exposed anyway, so
> it's not that useful to do so.
>
> I've also thought about doing something like this through Func, though
> I'm not sure everyone would want to adopt Func for this so something
> self contained might be better.
>
>
Hi all,
I'm interested in this functionality, has work started on this yet, or
is it still in the "good idea" state? :)
Jasper
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
Nothing has started on this one yet, so it's fair game should someone
want to take it.
Really the more things we do that allow writing to cobbler's state
remotely, the more we do need something to ensure credentials and
that the system is who it says it is, and that it can't modify other
records.
This may really lead down the Func route entirely, in which case it's a
script to populate cobbler from Func that speaks cobbler's Python API.
Thoughts?
--Michael
1:31 a.m.
>> The live CD you mention could use this.
>>
>> As I mentioned earlier, due to security reasons, we'd want this off by
>> default.
>>
>> Ideally I think we want a setting like:
>>
>> extended_registration_enabled: 1
>>
>> And we could obsolete the existing "register new MACs" functionality
as
>> this would be more feature-rich.
>>
>> It's a slight weakness in that this would create an API that could
allow
>> data in cobbler to be manipulated without access (like the RAM amounts
>> as we indicate above), though we do it right it should be reasonably
>> feature rich.
>>
>> We could think about requring usernames and passwords but since this is
>> in a provisioning context those credentials would be exposed anyway, so
>> it's not that useful to do so.
>>
>> I've also thought about doing something like this through Func, though
>> I'm not sure everyone would want to adopt Func for this so something
>> self contained might be better.
>>
>>
>
> Hi all,
>
> I'm interested in this functionality, has work started on this yet, or
> is it still in the "good idea" state? :)
>
Nothing has started on this one yet, so it's fair game should someone
want to take it.
Really the more things we do that allow writing to cobbler's state
remotely, the more we do need something to ensure credentials and
that the system is who it says it is, and that it can't modify other
records.
This may really lead down the Func route entirely, in which case it's a
script to populate cobbler from Func that speaks cobbler's Python API.
I didn't start development for this yet. But it looks like Eric Raymond
[ecraymond(a)gmail.com] has started creating a "Live Agent" that is similar. See
the thread "XMLRPC definitions". Maybe you can contact him for his work on the
"Live Agent".
Regards,
Peter
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.
8:01 a.m.
Vreman, Peter - Acision wrote:
>>> The live CD you mention could use this.
>>>
>>> As I mentioned earlier, due to security reasons, we'd want this off by
>>> default.
>>>
>>> Ideally I think we want a setting like:
>>>
>>> extended_registration_enabled: 1
>>>
>>> And we could obsolete the existing "register new MACs"
functionality as
>>> this would be more feature-rich.
>>>
>>> It's a slight weakness in that this would create an API that could
>>>
> allow
>
>>> data in cobbler to be manipulated without access (like the RAM amounts
>>> as we indicate above), though we do it right it should be reasonably
>>> feature rich.
>>>
>>> We could think about requring usernames and passwords but since this is
>>> in a provisioning context those credentials would be exposed anyway, so
>>> it's not that useful to do so.
>>>
>>> I've also thought about doing something like this through Func, though
>>> I'm not sure everyone would want to adopt Func for this so something
>>> self contained might be better.
>>>
>>>
>>>
>> Hi all,
>>
>> I'm interested in this functionality, has work started on this yet, or
>> is it still in the "good idea" state? :)
>>
>>
> Nothing has started on this one yet, so it's fair game should someone
> want to take it.
>
> Really the more things we do that allow writing to cobbler's state
> remotely, the more we do need something to ensure credentials and
> that the system is who it says it is, and that it can't modify other
> records.
>
> This may really lead down the Func route entirely, in which case it's a
> script to populate cobbler from Func that speaks cobbler's Python API.
>
>
I didn't start development for this yet. But it looks like Eric Raymond
[ecraymond(a)gmail.com] has started creating a "Live Agent" that is similar. See
the thread "XMLRPC definitions". Maybe you can contact him for his work on the
"Live Agent".
Regards,
Peter
Yep, I remember Eric.
Have a link to the thread archives? It was on this list?
--Michael
10:06 a.m.
Michael DeHaan wrote:
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
I'd use the appliance
creator tools (thincrust.et.redhat.com) -- just so
that it would be easier for more people to develop on it.
Then we can ask them to make it possible to make smaller and smaller
images as needed :)
--Michael
11:26 a.m.
>>>> 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
I'd use the appliance creator tools (thincrust.et.redhat.com) -- just so
that it would be easier for more people to develop on it.
Then we can ask them to make it possible to make smaller and smaller
images as needed :)
The toolchain looks nice to use, but I can't use it out-of-the-box. The toolchain
requires the latest releases of at least livecd-tools, pykickstart and yum. Those are not
available in RHEL4 or RHEL5(-epel).
I rebuild at the livecd-tools rpm under RHEL5, but it failed because it requires at least
python 2.5 for the try..except..finally syntax.
Any idea how to handle such build dependencies?
Regards,
Peter
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.
11:41 a.m.
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
>>>>>
> I'd use the appliance creator tools (thincrust.et.redhat.com) -- just so
> that it would be easier for more people to develop on it.
>
> Then we can ask them to make it possible to make smaller and smaller
> images as needed :)
>
The toolchain looks nice to use, but I can't use it out-of-the-box. The toolchain
requires the latest releases of at least livecd-tools, pykickstart and yum. Those are not
available in RHEL4 or RHEL5(-epel).
I rebuild at the livecd-tools rpm under RHEL5, but it failed because it requires at least
python 2.5 for the try..except..finally syntax.
Any idea how to handle such build dependencies?
Regards,
Peter
Not suprising. livecd-creator itself wasn't usable on EL either when we
doing koan live CD's (now replaced by "cobbler buildiso" because it
works everywhere -- it's just a "dumb" syslinux based ISO so it requires
much less to build and can be exceedingly small). However we really only
have to generate one ISO and then host it, rather than making each
person respin one.
Build it in a Fedora VM, perhaps?
There's also a mailing list:
http://www.redhat.com/mailman/listinfo/thincrust-devel
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
11:49 a.m.
>>>>>> - 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
>>>>>>
>> I'd use the appliance creator tools (thincrust.et.redhat.com) -- just
so
>> that it would be easier for more people to develop on it.
>>
>> Then we can ask them to make it possible to make smaller and smaller
>> images as needed :)
>>
>
> The toolchain looks nice to use, but I can't use it out-of-the-box. The
toolchain requires the latest releases of at least livecd-tools,
pykickstart and yum. Those are not available in RHEL4 or RHEL5(-epel).
>
> I rebuild at the livecd-tools rpm under RHEL5, but it failed because it
requires at least python 2.5 for the try..except..finally syntax.
>
> Any idea how to handle such build dependencies?
Not suprising. livecd-creator itself wasn't usable on EL either when we
doing koan live CD's (now replaced by "cobbler buildiso" because it
works everywhere -- it's just a "dumb" syslinux based ISO so it requires
much less to build and can be exceedingly small). However we really only
have to generate one ISO and then host it, rather than making each
person respin one.
Build it in a Fedora VM, perhaps?
There's also a mailing list:
http://www.redhat.com/mailman/listinfo/thincrust-devel
Only a simple filesystem image is required. I don't think we need the appliance-tools
multiple-fs patch for it. That means I can start already with the current available
livecd-tools from RHEL5-epel.
Later the appliance-tools support can be added to the build process to create a more
optimized image.
Regards,
Peter
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.
12:03 p.m.
Only a simple filesystem image is required. I don't think we need the appliance-tools
multiple-fs patch for it. That means I can start already with the current available
livecd-tools from RHEL5-epel.
Later the appliance-tools support can be added to the build process to create a more
optimized image.
Regards,
Peter
livecd-tools is in EPEL? Great.
Yes, that is definitely all you would need to get going. Sounds good!
--Michael
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
5577
days inactive
5628
days old
cobbler@lists.fedorahosted.org
15 comments
3 participants
participants (3)
-
Jasper Capel -
Michael DeHaan -
Vreman, Peter