Kickstart / PXE / Cobbler / Ansible

[Benjamin Lefoul]

Hi all,

I am actually interested in the automated install topic (currently taking place 
in the other discussion, but I don't want to feed the troll so I'll start a new 
one).

Someone just mentioned Cobbler, and the fact that it's RH's baby. Is this in 
any way linked to the recent acquisition of Ansible ?
In fact, I never really understood what Ansible was, and does it have its place 
in automated install? Can it replace Kickstart?

As you can see I am pretty naive about the topic...

Thanks,

Benjamin

Re: Kickstart / PXE / Cobbler / Ansible

[lejeczek]

On 14/01/16 13:33, Benjamin Lefoul wrote:

Hi all,

I am actually interested in the automated install topic (currently taking place 
in the other discussion, but I don't want to feed the troll so I'll start a new 
one).

Someone just mentioned Cobbler,
that was the troll himself who has been using cobbler for 
years now.

and the fact that it's RH's baby. Is this in any way linked to the recent 
acquisition of Ansible ?
In fact, I never really understood what Ansible was, and does it have its place 
in automated install? Can it replace Kickstart?

As you can see I am pretty naive about the topic...

Thanks,

Benjamin

Re: Kickstart / PXE / Cobbler / Ansible

[Loris Bennett]

Hi Benjamin,

Benjamin Lefoul  writes:

> Hi all,
>
> I am actually interested in the automated install topic (currently
> taking place in the other discussion, but I don't want to feed the
> troll so I'll start a new one).
>
> Someone just mentioned Cobbler, and the fact that it's RH's baby. Is
> this in any way linked to the recent acquisition of Ansible ?  In
> fact, I never really understood what Ansible was, and does it have its
> place in automated install? Can it replace Kickstart?
>
> As you can see I am pretty naive about the topic...

I don't know very much about kickstart but am currently using ansible to
set up two administration servers for a test cluster.  My meagre
understanding is that kickstart is mainly aimed at the initial
lower-level installation (partitioning the disk, installing the base OS
and other packages, ...).

Ansible on the other hand requires the machines you are managing to be
already up and running and, normally, accessible via ssh.  Thus it seems
it is a more fancy way of doing what kickstart can probably do in the
post-install section.  However, Ansible works with 'playbooks', which are
sets of 'plays', which in turn are sets of tasks to be carried out on a
set of hosts.  You can run entire playbooks or just groups of tasks and
you can also define roles, such as 'ldapserver' or 'dbserver' to bundle
associated tasks together.  In general it seems slightly more orientated
towards automated day-to-day management of multiple, heterogeneous hosts.

That having been said, I am no expert.

Regards

Loris

-- 
Dr. Loris Bennett (Mr.)
ZEDAT, Freie Universität Berlin Email loris.benn...@fu-berlin.de

Re: Kickstart / PXE / Cobbler / Ansible

[Paddy Doyle]

On Thu, Jan 14, 2016 at 03:21:09PM +0100, Loris Bennett wrote:

> Hi Benjamin,
> 
> Benjamin Lefoul  writes:
> 
> > Hi all,
> >
> > I am actually interested in the automated install topic (currently
> > taking place in the other discussion, but I don't want to feed the
> > troll so I'll start a new one).
> >
> > Someone just mentioned Cobbler, and the fact that it's RH's baby. Is
> > this in any way linked to the recent acquisition of Ansible ?  In
> > fact, I never really understood what Ansible was, and does it have its
> > place in automated install? Can it replace Kickstart?
> >
> > As you can see I am pretty naive about the topic...
> 
> I don't know very much about kickstart but am currently using ansible to
> set up two administration servers for a test cluster.  My meagre
> understanding is that kickstart is mainly aimed at the initial
> lower-level installation (partitioning the disk, installing the base OS
> and other packages, ...).
> 
> Ansible on the other hand requires the machines you are managing to be
> already up and running and, normally, accessible via ssh.  Thus it seems
> it is a more fancy way of doing what kickstart can probably do in the
> post-install section.  However, Ansible works with 'playbooks', which are
> sets of 'plays', which in turn are sets of tasks to be carried out on a
> set of hosts.  You can run entire playbooks or just groups of tasks and
> you can also define roles, such as 'ldapserver' or 'dbserver' to bundle
> associated tasks together.  In general it seems slightly more orientated
> towards automated day-to-day management of multiple, heterogeneous hosts.
> 
> That having been said, I am no expert.

Nor I, but just a small note on our setup.

We use PXE+kickstart for a very minimal initial install.

Then, using a provisioning / configuration management tool we configure the
machine with the desired config, including things like:

- software repos and package installation
- configuration files
- user authentication (local users and/or LDAP etc)
- host and user keys
- network settings

We are currently using SaltStack mostly, and have used Ansible and Puppet in
the past. Other similar solutions include Chef and CFEngine, but I don't have
direct experience with them.

They each have pros and cons, depending on your exact local needs, or language
of preference etc.

There is of course the problem of how to initially connect to the
freshly-kickstarted machine, and there are multiple solutions for that depending
on which provisioning tool you're using.

Kind regards,
Paddy

-- 
Paddy Doyle
Trinity Centre for High Performance Computing,
Lloyd Building, Trinity College Dublin, Dublin 2, Ireland.
Phone: +353-1-896-3725
http://www.tchpc.tcd.ie/

Re: Kickstart / PXE / Cobbler / Ansible

[Denice]

On Thu, 14 Jan 2016, Benjamin Lefoul wrote:


...
Someone just mentioned Cobbler, and the fact that it's RH's baby. Is
 this in any way linked to the recent acquisition of Ansible ?
In fact, I never really understood what Ansible was, and does it have
 its place in automated install? Can it replace Kickstart?

As you can see I am pretty naive about the topic...


We have been getting started on Ansible.

Note that Red Hat has purchased Ansible - it has all the hallmarks of
a product that suits Red Hat very well - python-based, a model built
around a readily available, open-source product, with a purchase model
(Ansible Tower) of the GUI-side of the product for an enterprise crowd.

I quite like what I see so far.  It does not replace Kickstart, but
you can use Ansible during kickstart in an 'ansible-pull' mode.
By default, the daily administration mode is typically push mode -
that is - using ssh from a management node you push out your changes.

The idea is to set up 'roles' that manage typical tasks - for example,
configuring local ntp, or managing ssh host keys.  During kickstart you would
just run, or as they say 'play', those roles.

Fedora's infrasture uses Ansible:
  https://infrastructure.fedoraproject.org/cgit/ansible.git

cheers, etc.
--
deatrich @ triumf.ca, Science/ATLAS PH: +1 604-222-7665
<*> This moment's fortune cookie:
Live in a world of your own, but always welcome visitors.

Re: Kickstart / PXE / Cobbler / Ansible

[Stephen John Smoogen]

On 14 January 2016 at 06:33, Benjamin Lefoul  wrote:
> Hi all,
>
> I am actually interested in the automated install topic (currently taking 
> place in the other discussion, but I don't want to feed the troll so I'll 
> start a new one).
>
> Someone just mentioned Cobbler, and the fact that it's RH's baby. Is this in 
> any way linked to the recent acquisition of Ansible ?
> In fact, I never really understood what Ansible was, and does it have its 
> place in automated install? Can it replace Kickstart?
>

Cobbler was born inside of Red Hat but is now run at
http://cobbler.github.io/ versus the fedorahosted where it shows up
the most in google. Cobbler was written by the same person who wrote
Ansible but is not the same or linked to Ansible in anything other
htan that.

> As you can see I am pretty naive about the topic...
>
> Thanks,
>
> Benjamin



-- 
Stephen J Smoogen.

Re: Kickstart / PXE / Cobbler / Ansible

[David Sommerseth]

On 14/01/16 15:21, Loris Bennett wrote:
> Hi Benjamin,
> 
> Benjamin Lefoul  writes:
> 
>> Hi all,
>>
>> I am actually interested in the automated install topic (currently
>> taking place in the other discussion, but I don't want to feed the
>> troll so I'll start a new one).
>>
>> Someone just mentioned Cobbler, and the fact that it's RH's baby. Is
>> this in any way linked to the recent acquisition of Ansible ?  In
>> fact, I never really understood what Ansible was, and does it have its
>> place in automated install? Can it replace Kickstart?
>>
>> As you can see I am pretty naive about the topic...
> 
> I don't know very much about kickstart

As a rough crash-course  checkout /root/anaconda-ks.cfg on a freshly
installed system.  If you want to do the exact same installation once
more, you copy this file to a medium or web server and provide the URI
to this file on the kernel command line before starting the installer.
If anaconda picks it up, you'll have an automated install running instantly.

A more comprehensive guide on kickstart can be found here:


> but am currently using ansible to
> set up two administration servers for a test cluster.  My meagre
> understanding is that kickstart is mainly aimed at the initial
> lower-level installation (partitioning the disk, installing the base OS
> and other packages, ...).

Correct.  Ansible is more for further automated setup tasks after the
core OS has been installed and is ready for the network.

Especially if you're playing with virtualization or containers,
cloud-init might be another useful tool to prepare images when using
image cloning.  In some cases it might be useful for bare-metal installs
too, but it isn't network based.  If 100% network capable setup is
required, ansible is a better alternative.

To start an install without anything else than a local network, PXE boot
can help out.  I've done that at home, that was a fairly straight
forward process.  Bascally you configure the dhcp server to provide PXE
details for computers booting of the network.  Then you need to
configure a tftp server which provides a boot menu/configuration and
boot kernels.  I did that without involving cobbler.  Cobbler might be
beneficial in some setups, but haven't dug deep into that.

How to get ready for network installs can be found here:



-- 
kind regards,

David Sommerseth

Re: Kickstart / PXE / Cobbler / Ansible

[Robert Benjamin]

Sir: Please remove my name and email address from your list. It is 
sent by error. Thank you.


On 1/14/2016 2:37 PM, David Sommerseth wrote:

On 14/01/16 15:21, Loris Bennett wrote:

Hi Benjamin,

Benjamin Lefoul  writes:


Hi all,

I am actually interested in the automated install topic (currently
taking place in the other discussion, but I don't want to feed the
troll so I'll start a new one).

Someone just mentioned Cobbler, and the fact that it's RH's baby. Is
this in any way linked to the recent acquisition of Ansible ?  In
fact, I never really understood what Ansible was, and does it have its
place in automated install? Can it replace Kickstart?

As you can see I am pretty naive about the topic...

I don't know very much about kickstart

As a rough crash-course  checkout /root/anaconda-ks.cfg on a freshly
installed system.  If you want to do the exact same installation once
more, you copy this file to a medium or web server and provide the URI
to this file on the kernel command line before starting the installer.
If anaconda picks it up, you'll have an automated install running instantly.

A more comprehensive guide on kickstart can be found here:



but am currently using ansible to
set up two administration servers for a test cluster.  My meagre
understanding is that kickstart is mainly aimed at the initial
lower-level installation (partitioning the disk, installing the base OS
and other packages, ...).

Correct.  Ansible is more for further automated setup tasks after the
core OS has been installed and is ready for the network.

Especially if you're playing with virtualization or containers,
cloud-init might be another useful tool to prepare images when using
image cloning.  In some cases it might be useful for bare-metal installs
too, but it isn't network based.  If 100% network capable setup is
required, ansible is a better alternative.

To start an install without anything else than a local network, PXE boot
can help out.  I've done that at home, that was a fairly straight
forward process.  Bascally you configure the dhcp server to provide PXE
details for computers booting of the network.  Then you need to
configure a tftp server which provides a boot menu/configuration and
boot kernels.  I did that without involving cobbler.  Cobbler might be
beneficial in some setups, but haven't dug deep into that.

How to get ready for network installs can be found here:

Re: Kickstart / PXE / Cobbler / Ansible

[Nico Kadel-Garcia]

On Thu, Jan 14, 2016 at 2:37 PM, David Sommerseth
 wrote:
> On 14/01/16 15:21, Loris Bennett wrote:
>> Hi Benjamin,
>>
>> Benjamin Lefoul  writes:
>>
>>> Hi all,
>>>
>>> I am actually interested in the automated install topic (currently
>>> taking place in the other discussion, but I don't want to feed the
>>> troll so I'll start a new one).
>>>
>>> Someone just mentioned Cobbler, and the fact that it's RH's baby. Is
>>> this in any way linked to the recent acquisition of Ansible ?  In
>>> fact, I never really understood what Ansible was, and does it have its
>>> place in automated install? Can it replace Kickstart?
>>>
>>> As you can see I am pretty naive about the topic...
>>
>> I don't know very much about kickstart
>
> As a rough crash-course  checkout /root/anaconda-ks.cfg on a freshly
> installed system.  If you want to do the exact same installation once
> more, you copy this file to a medium or web server and provide the URI
> to this file on the kernel command line before starting the installer.
> If anaconda picks it up, you'll have an automated install running instantly.

Really, you don't. "anaconda-ks.cfg" is the anaconda pardsed results
of the deployment procedure, and lacks many critical feautres of a
robust kickstart file for PXE or other common kickstart setups.

* The default installaiton labels partitions by the DHCP or otherwise
configured hostname, which is confusing on multiple hosts using the
same kickstart file.
* It comments out the disk configuration stanza.
* It includes distinct comments and layouts from
"system-config-kickstart" or other constructed kickstart tools.
* It does not correctly handle multple '%pre', '%post', or '%post
--nochroot' stanzas.

If you want to use a consistent kickstart, and have each published
host have a reference copy of its actual upstream kickstart file for
future reference, add this stanza to your published kickstart files
before using them.

%pre --nochroot
cp /tmp/ks.cfg /mnt/sysimage/root/ks.cfg

>
>
> --
> kind regards,
>
> David Sommerseth

Re: Kickstart / PXE / Cobbler / Ansible

[David Sommerseth]

On 15/01/16 02:36, Nico Kadel-Garcia wrote:
> On Thu, Jan 14, 2016 at 2:37 PM, David Sommerseth> 
>  wrote:
>> As a rough crash-course  checkout /root/anaconda-ks.cfg on a freshly
>> installed system.  If you want to do the exact same installation once
>> more, you copy this file to a medium or web server and provide the URI
>> to this file on the kernel command line before starting the installer.
>> If anaconda picks it up, you'll have an automated install running instantly.
> 
> Really, you don't. "anaconda-ks.cfg" is the anaconda pardsed results
> of the deployment procedure, and lacks many critical feautres of a
> robust kickstart file for PXE or other common kickstart setups.
> 
> * The default installaiton labels partitions by the DHCP or otherwise
> configured hostname, which is confusing on multiple hosts using the
> same kickstart file.
> * It comments out the disk configuration stanza.
> * It includes distinct comments and layouts from
> "system-config-kickstart" or other constructed kickstart tools.
> * It does not correctly handle multple '%pre', '%post', or '%post
> --nochroot' stanzas.

Duh!  Too long since I did that obviously.  Thanks for correcting my error!
You are absolutely right.

> If you want to use a consistent kickstart, and have each published
> host have a reference copy of its actual upstream kickstart file for
> future reference, add this stanza to your published kickstart files
> before using them.
> 
> %pre --nochroot
> cp /tmp/ks.cfg /mnt/sysimage/root/ks.cfg

Yupp!  That's the needed detail.


--
kind regards,

David Sommerseth

Re: Kickstart / PXE / Cobbler / Ansible

[S A]

Apologies for being late to this discussion...

I have some history and experience with Kickstart and Cobbler through Red Hat 
Satellite Server.  The current version of Satellite Server (6) is no longer 
using Cobbler.  Instead they have moved into using Foreman+Puppet [1] and 
Katello+Pulp+Candlepin [2] to comprise the Satellite Server Suite.  This is a 
fairly complex set of tools for system lifecycle, configuration, repository, 
and subscription/license management.  In my current role and previous places of 
employment, we used the Foreman+Puppet alone.  One of the beauties of Foreman 
is that it's interface with Config-Management automation tools is that it's 
plugin driven.  The Default is Puppet, but Foreman also already works with 
other tools like Chef and Salt.  There is ongoing development of user stories 
for the integration of Ansible, and I believe early version of the plugins have 
been published.

[1] http://theforeman.org
[2] http://katello.org

Foreman provides an orchestration front end for multi-platform Network or 
Custom Boot ISO based provisioning.  Foreman can be integrated with ISC or MS 
DHCP and DNS to orchestrate the creating of leases and dns records as a new 
system is provisioned.  Foreman supports EL kickstart, Debian preseed, and 
Solaris jumpstart for network provisioning, I have personally used kickstarts 
and jumpstarts (even for sparc) from Foreman.  The provisioning profiles can be 
templated using ERB (ruby) to be made dynamic based on data that surrounds the 
new system (e.g. physical location, subnet, domain, OS, version, system owner, 
etc.).  Foreman also integrates with Docker, Digital Ocean, OpenStack, oVirt, 
Xen, EC2, Rackspace, VMWare, Google Compute and LibVirt for cloud/virtual 
provisioning.

I highly recommend anyone who might be interested in automated provisioning to 
take a look at the tool set.  After 20 years of Solaris/AIX/HPUX and Linux 
system admining, I'm now a puppet guy, but I came to be so through what Foreman 
presented.  The combination of these products revolutionizes the way I look at 
system deployment and ongoing management.  The Foreman Team has produced a lot 
of nice Youtube videos and Google Hangout presentations covering the features 
and capabilities of the product.  Like this mailing list, they are a very 
helpful bunch as well.

In my current role today, we're producing a Foreman/Puppet based solution for 
the directorates in the govt. agency I work for.  We expect to reduce the labor 
time in provisioning, configuring and enforcing policy compliance of Linux 
Desktops and Servers by a ratio of about 6:1.  In most of these directorates 
today, system admins spend about 4-8 hours building and configuring a policy 
compliant linux systems...each uses their own methods.  Foreman reduces the 
provisioning part to a few minutes, Puppet reduces the compliance part by 
hours.  This opens the door for those admins to stop fighting compliance 
issues, even future remediation, as Puppet will continually enforce the policy 
as well as audit and report the actions it takes (reports presented nicely in 
Foreman), so that they can do the real work of supporting their customer's 
needs.

Hope this helps!