FAI 3.3 released

Stephan Hermann sh at sourcecode.de
Wed Nov 4 14:05:45 CET 2009


Hi Again,

On Wed, 4 Nov 2009 13:22:30 +0100
Henning Sprang <henning.sprang at gmail.com> wrote:

> Hi Joel,
> 
> On Wed, Nov 4, 2009 at 10:26 AM, Joel Merrick
> <joel.merrick at gmail.com> wrote:
> > Exactly the same here... only with Chef[1], rather than Puppet
> >
> > [1] http://www.opscode.com/chef
> 
> Do you have some information on the differences(pros and cons) of
> managing configurations with FAI softupdate versus Chef?
> 
> I have some experience with Puppet, and find it different, but not
> entirely better than softupdates with FAI - but I see these tools as
> important "competitors" of FAI.


I think I need to be more specific, regarding FAI + Configuration File
Management (fai-softupdate, cfengine, puppet etc.).

I thought about using fai-softupdate for some time, and dropped
softupdate, because I don't want to have a FAI setup somewhere in my
production environment. 

Network Design plays a role here. Let me show you how we do it:

1. All machines are connected through some series of switches and
routers (when you think of a Cisco 6509 as a router or as a big beast
switch platform ;))

2. All ports of on the switch do have native vlan ports, which are only
usable during deployment, so the FAI server itself stands only in the
native vlan (native vlan == switch port with trunk config, if there is
an untagged ip package it will be tagged with the native vlan)

3. All ports do have a list of other vlans which are used in production
environment.

4. FAI will setup the machine with an initial OS, initial production
ready network setup, so after reboot into the production environment,
the hosts are only available inside the production network. No untagged
packages are leaving those hosts.

5. Puppetclient is only started the first time, the host comes up with
no configuration, after that, puppetclient is going back into disabled
mode, so if someone changes something on the puppetmaster, we are sure,
that nothing will be destroyed.

6. Only when a a configuration change in puppet is tested, we are
starting the puppetclient remotely on the affected hosts. (hint: we
don't use puppet manifest tags, it's a backlog item on our agenda to
enable puppetclient always by default, and only rolling out config
changes during puppetrun and tags)

Now, why do we use Puppet (s/puppet/{cfengine, chef etc.}/
and not FAI softudate, especially we could design the FAI structure the
same.

There is only one answer to this: Because I'm the only one who knows
FAI. All other colleagues need to learn it, but this is a time
constrain right now. 
Puppet was known by other colleagues, so we choose it, to get things
going and puppet is really nice regarding the syntax. 

The only problem of Puppet: It's Ruby ;)

Regards,

\sh
-- 
| Stephan '\sh' Hermann    | OSS Dev / SysAdmin         |
| JID: sh at linux-server.org | http://www.sourcecode.de/  | 
| GPG ID: 0xC098EFA8	   | http://leonov.tv/          |
| FP: 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 |


More information about the linux-fai mailing list