provisioning bare metal (best practices)

[David Kavanagh]

I'm about to start playing with Kickstart. I never really had to provision bare servers beyond a normal OS install, so I need something to use along with Puppet. Is there a general consensus on what the best option is?

I'd need to set up the node with IP/hostname/role. (I have a custom fact for role). I figured I'd simply ssh in to write the role file, but if I'd rather not use dhcp, I suppose I'll need to get the network interface configured in another way. What do folks generally do here?

David

[Trevor Vaughan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Why not use DHCP? This is what it's for.

The general standard that I've seen is DHCP + KS + modification scripts/puppet/whatever

Trevor

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

- --
Trevor Vaughan
Vice President, Onyx Point, Inc.
email: tvau...@onyxpoint.com
phone: 410-541-ONYX (6699)
pgp: 0x6C701E94

- -- This account not approved for unencrypted sensitive information --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJNY96DAAoJECNCGV1OLcyp6FoH/1LoCtKepX82ACa2MsAPeUOB
hp+72RZUq6cfUgdiN3JlJWYMqZr2whFmzyPLeqbvNLdRcg2QMdNL5l6lQ5d3Tbt9
q/C4GXJRKTLGUAWBxRu/ij9gAx3ZL77779zaUi6CJ411ftSZuRjjRGYc7v0eo6R0
gXfthQJB8E/jWEFeWhOAhSrfyiLn9uHg8ZjRPz3M3povVBHtk76s1hLMssQbPDsI
SsRcnO016n3dOTul4PcLAPati2pKo32+Md67wI/cqiq+ZOnVXbq925Q0KVbLdyYn
L6faHGe9s1GcrLsH1IDvbFpjMxQiBzXT00uDOsZ7ici4BPYoJoSCxfHM5V6/I7k=
=esai
-----END PGP SIGNATURE-----

[Mohit Chawla]

Foreman could come in handy.

[Jonathan Gazeley]

We have a small pool of DHCP IP addresses for use only in the build
process. This is our process:

1. We boot the servers from PXE network boot

2. They get one of the temporary IPs

3. They start a CentOS network install using a kickstart file with the
bare minimum of packages selected, including puppet

4. The last stage of the kickstart is to set puppet running

5. At this stage, human intervention is required to authorise the new
machine in puppetca. I'm aware that it is possible to have this step
done automatically, but it can be a security risk.

6. Once the server is authorised in puppet, it receives a basic "common"
config from puppet, which gives it the proper static IP that it should
have, disables DHCP, sets the hostname, sets up NTP, etc.

7. From now on, it's dead easy to use puppet to install and configure
everything else.

Cheers,
Jonathan

----------------------------
Jonathan Gazeley
Systems Support Specialist
ResNet | Wireless & VPN Team
IT Services
University of Bristol
----------------------------

[Brian Gallew]

Never forget the DHCP does NOT necessarily mean "dynamic addresses". Depending upon your corporate culture, it may be perfectly acceptable for DHCP to hand out statically assigned addresses to your hosts. This would allow your build process to be easy, and you can have the host never DHCP again after it's up and running (until you rebuild it!).

[David Kavanagh]

I thought about DHCP for static addresses. I'd need the MAC for each machine though. For now, I'm worrying about plugging some media or doing network boot on machines by hand. I suppose I'll need to do something on the host to indicate what the machine role will be. In any case, I could simply use a small pool of dynamic addresses as temporary addresses, and ping for machines in that range from the server, then let the user know there's a new machine waiting and to designate a purpose (role). Then, assign static address and restart it in it's new location, letting puppet finish provisioning. I'll have a look at Foreman. Need to think about my use case, which probably isn't so uncommon.

David

[vagn scott]

Oh, great timing!

I'm working on pretty much the same question. I have used FAI and
Opsware, and homebrewed scripts to do provisioning in the past. I have
never been all that happy with any of them, and am taking another look
at the problem to try to get to as simple and portable a solution as
possible.

I am planning to ask the list to criticize the classes that implement
the various bits. (Is this the right list for that?) I would like the
classes to be 'state of the art'. My own competence with puppet leans
heavily towards 'exec { "some script I wrote": }' and I would like to
get past that.

I intend to create a completely worked out example that addresses
installing to
VirtualBox VMs and real hardware.

The programs I will use are:

dnsmasq for DNS, DHCP, and BOOTP
apache as file server (preseed.cfg, kickstart.cfg, random scripts)
apt-cacher-ng for local apt-proxy
gpxe, undionly.kpxe, pxeboot.0 for booting
redhat kickstart and debian preseed capable kernel/initrd for
install

And the slightly clever bit:

wget or curl to throw triggers into log files
swatch on the logs to trigger state changes, including signing
certs
puppet for configuration beyond the basic install

So how is this a simplification?

1. dnsmasq is much better suited to provisioning than
the combination of named, dhcpd, and tftpd (IMHO)

2. no giant frameworks in sight

3. each component is familiar.

4. modular, none of the components know or care about
the others so they can be versioned or replaced without
problems.

The thinking behind this is:

1. dnsmasqd provides mac/ip/hostname assignments
dnsmasqd configured by puppet class
after provisioning these will show up as facts

2. boot config provides OS and Disk partitions
boot configuration configured by puppet classes
after provisioning these will also show up as facts

3. puppet takes over after the first reboot
puppet bootstrapping set up during install (%post or
last.sh)
puppet style can be nodeless, masterless, whatever

4. flipping a symlink (manually or through a frontend)
configures a client install for the next time it boots.

On 02/22/2011 10:47 AM, David Kavanagh wrote:

[Russell Jackson]

On 02/22/2011 10:14 AM, James A. Peltier wrote:
>
>
> ----- Original Message ----- | I thought about DHCP for static
> addresses. I'd need the MAC for each | machine <snip>
>
> This is not necessarily true. If you configure the client to send a
> requested hostname it will not require you to register the MAC
> address, although, as per the usual this is a security risk since
> anyone on the network could pose as a machine if they knew that was
> the setup. ;)
>

Only if you have a flat network. A host can't get an address for a
subnet they're not in.

--
Russell A Jackson <r...@csub.edu>
Network Analyst
California State University, Bakersfield

[Denmat]

Hi

I use Cobbler for provisioning and it can handle dhcp and dns if you want. It is a bit light on debian support but I run mainly RH severs.

The other that is mentioned already, foreman, maybe better as an integrated solution.

[Thomas Bellman]

James A. Peltier wrote:

> This is not necessarily true. If you configure the client to send
> a requested hostname it will not require you to register the MAC
> address, although, as per the usual this is a security risk since
> anyone on the network could pose as a machine if they knew that
> was the setup. ;)

Not that that is any different from when using the MAC address
to key your DHCP server, since that is just as easily faked.
Or when using static IP addresses configured directly on the
machines themselves.

If you are afraid someone will pose as another machine by
"stealing" their IP address, then you need physical security
on your network.

/Bellman

[James A. Peltier]

----- Original Message -----
| I thought about DHCP for static addresses. I'd need the MAC for each
| machine

<snip>

This is not necessarily true. If you configure the client to send a requested hostname it will not require you to register the MAC address, although, as per the usual this is a security risk since anyone on the network could pose as a machine if they knew that was the setup. ;)

--
James A. Peltier
IT Services - Research Computing Group
Simon Fraser University - Burnaby Campus
Phone : 778-782-6573
Fax : 778-782-3045
E-Mail : jpel...@sfu.ca
Website : http://www.sfu.ca/itservices
http://blogs.sfu.ca/people/jpeltier

[Jonathan Gazeley]

On 22/02/11 16:51, David Kavanagh wrote:
> I thought about DHCP for static addresses. I'd need the MAC for each
> machine though

This is why we have a small pool fully dynamic IP addresses for our
build system that doesn't require any MAC registration. The subnet is
only able to talk to the PXE server, our CentOS mirror and the puppet
server, so it doesn't really matter if someone else did get one of the IPs.

--

[Ohad Levy]

On Wed, Feb 23, 2011 at 11:17 AM, Jonathan Gazeley <jonathan...@bristol.ac.uk> wrote:

On 22/02/11 16:51, David Kavanagh wrote:

I thought about DHCP for static addresses. I'd need the MAC for each
machine though

This is why we have a small pool fully dynamic IP addresses for our build system that doesn't require any MAC registration. The subnet is only able to talk to the PXE server, our CentOS mirror and the puppet server, so it doesn't really matter if someone else did get one of the IPs.

-- 

I find it easier not to flip flop ip addresses during provisioning/configuration, really, if you set it up upfront, reinstallation is a breeze.

 

Ohad

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

+1 for Cobbler.

At my site, we don't kickstart on the production network, in order to
avoid the case where a not-fully-secured machine is exposed to network
attacks. My kickstart network is all in one room, and so is easier to
secure, logically and physically. On such a network, automatic
certificate signing would likely be suitably secure, and assigning roles
by MAC is easy using Cobbler.

While you may not be subject to the same regulatory restraints, David, I
suggest a separate kickstart network as a best practice.

[David Kavanagh]

Jared,

Are you suggesting separate physical subnet, or simply a logical subnet on the same physical network (using netmask)?

David

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

> Jared,
> Are you suggesting separate physical subnet, or simply a logical
subnet
> on the same physical network (using netmask)?

Mine's physically separate. I think it's what is required (google UNIX
STIG; see section 12.6), and it simplifies configuration and usage (this
network does this thing; the other doesn't).

Also once kickstarting is over, I'm going to trust the new host and
allow it access to a bunch of things, calm in knowing that I caused
every formative change to its configuration. I don't want to be wrong
about that.

And there's no effort wasted on this in our office: the IT team receives
all the new systems, and we have to configure the BIOS anyway before
letting one out on the floor, so just drop it in the inner sanctum for
an hour or two to kickstart.