Puppet users - May 2013 - Practices: what _not_ to manage with Puppet?

While I prep my scripts and tool up for a large infra, I want to
revisit a question that I ask myself regularly: what do people not
manage with Puppet (or wish they weren''t)?

In my situation (a RH-style world), initial base system install, inc
disk layout and initial networking is handled with kickstart

For example: Do you exclude mountpoints? Network/SAN mountpoints?
Advanced network configs?

What are the reasons to exclude a particular item? How do you manage it instead?

cheers,



m
--
 martin.langhoff@gmail.com
 -  ask interesting questions
 - don''t get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff

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

I want everything managed by puppet because if it is not it only adds 
operational complexity into the environment. I have found that using 
kickstart to bootstrap puppet works well.  Kickstart does the minimum  to 
get puppet running (root volume group, temporary network, puppet rpms) and 
the last line kicks off a puppet run.  Everything else is managed by 
puppet.  This way you can spin up a vm in your favorite virtual machine 
provider and puppet gives you everything you need without any other 
processes involved. 

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

I think that for some things where there are specialized protocols
available to configure certain things it can be easier to use them instead
of trying to make puppet do them same. But I''d definitely configure the
servers and clients for those protocols using Puppet.

Examples would be using nss_ldap and LDAP server instead of having Puppet
query your LDAP server and creating entries in /etc/passwd.
Or using DHCP to configure networking instead of having puppet setting it
statically on your hosts.
Or using pam_krb5 and a Kerberos KDC instead of having puppet distribute
password hashes.



On 3 May 2013 20:02, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> While I prep my scripts and tool up for a large infra, I want to
> revisit a question that I ask myself regularly: what do people not
> manage with Puppet (or wish they weren''t)?
>
> In my situation (a RH-style world), initial base system install, inc
> disk layout and initial networking is handled with kickstart
>
> For example: Do you exclude mountpoints? Network/SAN mountpoints?
> Advanced network configs?
>
> What are the reasons to exclude a particular item? How do you manage it
> instead?
>
> cheers,
>
>
>
> m
> --
>  martin.langhoff@gmail.com
>  -  ask interesting questions
>  - don''t get distracted with shiny stuff  - working code first
>  ~ http://docs.moodle.org/en/User:Martin_Langhoff
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
Erik Dalén

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

On Sat, May 4, 2013 at 7:33 AM, Erik Dalén <erik.gustav.dalen@gmail.com>
wrote:
> I''d definitely configure the servers and
> clients for those protocols using Puppet.
Is that what you do, or what you _would_ do? ;-)
> Or using DHCP to configure networking instead of having puppet setting it
> statically on your hosts.
Do you actually do that? How do you handle complex routing/bonding setups?

cheers,



m
--
 martin.langhoff@gmail.com
 -  ask interesting questions
 - don''t get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff

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

On 4 May 2013 13:37, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On Sat, May 4, 2013 at 7:33 AM, Erik Dalén
<erik.gustav.dalen@gmail.com>
> wrote:
> > I''d definitely configure the servers and
> > clients for those protocols using Puppet.
>
> Is that what you do, or what you _would_ do? ;-)
>
It is what I do :)

Using custom functions that pulls parts of the configuration from other
systems in some cases (like from our inventory system) and feeding that
into some template.

>
> > Or using DHCP to configure networking instead of having puppet setting
it
> > statically on your hosts.
>
> Do you actually do that? How do you handle complex routing/bonding setups?
>
Atm it is a bit of a mix, and yes, setting up bonding and complex routing
is done by puppet. But once bonding is up you could use DHCP to configure
the IP, netmask and DNS for example.

-- 
Erik Dalén

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

On Fri, May 3, 2013 at 4:43 PM, Schofield <dbschofield@gmail.com>
wrote:
> Everything else is managed by puppet.
Do you manage complex network setups (bonding, routing) via puppet?
There is a certain degree of chicken-and-egg in that; how do you
handle managing configuration without breaking the network that
delivers the puppet config to the host?

Do you manage complex disk setups (RAID arrays, DRBD) via Puppet? Any
hints as to how?

Or perhaps you only use Puppet so extensively in VMs, where you don''t
have to deal with all these pesky issues?

For some tasks we _don''t_ use VMs (high perf HA DB servers, asterisk
servers are two top examples). I find that managing the config of
those boxes is enormously important to retain sanity...

Of course, we use lots of almost-identical VMs for things that are a
good fit for VMs (webservers, etc)...



m
--
 martin.langhoff@gmail.com
 -  ask interesting questions
 - don''t get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff

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

On Saturday, May 4, 2013 12:43:57 PM UTC+1, Martin Langhoff wrote:
> On Fri, May 3, 2013 at 4:43 PM, Schofield
<dbsch...@gmail.com<javascript:>>
> wrote: 
> > Everything else is managed by puppet. 
>
> Do you manage complex network setups (bonding, routing) via puppet? 
> There is a certain degree of chicken-and-egg in that; how do you 
> handle managing configuration without breaking the network that 
> delivers the puppet config to the host? 
>
We have a very generic kickstart that runs Puppet as a final step, and in 
that first Puppet run I have a module that writes out 
/etc/sysconfig/network-script/ files, which includes routes, rules, 
bonding, vlans, bridges, etc. All the information is stored in Hiera. We do 
not use Puppet to restart networking or attempt to fix up any 
discrepancies, someone has to come along and "service network
restart". So
we use Puppet to provision what the networking should look like, but not 
enforce it. This means an Admin can come along and mess around with the 
networking and thus things can deviate from what Puppet says they should be.

However, since all the information is stored in Hiera I can have Puppet 
export out nagios checks that do things along the lines of "this interface 
is not up but it should be" and "this interface does not belong to the
bond
it should".

Do you manage complex disk setups (RAID arrays, DRBD) via Puppet? Any
> hints as to how? 
>
I haven''t tried to manage DRBD but the config should be simple.
You''re
going to run into problems if you try to create a DRBD disk across two 
servers at the same time - Puppet can''t orchestrate the commands that
need
to be run on each server, for that you would need MCollective and unless 
you were creating 100s of DRBD disks, I wouldn''t bother and
I''d do it by
hand.

I do manage iSCSI disks, LVM and file systems in Puppet though. There''s
a
manual step where we have to go to our storage appliances and create the 
iSCSI disk first, then put the iSCSI target ID into Hiera, but the rest is 
clockwork. It provisions only, it doesn''t attempt to resize or reformat
file systems if it finds a discrepancy. To counteract that, like the 
networking scripts, I can export nagios checks that say "this file system 
is 30 Gig and ext3, but it''s supposed to be 10 Gig and ext4" which
tells me
someone''s gone and made on-box changes that aren''t back-ported
to Puppet /
Hiera.

Or perhaps you only use Puppet so extensively in VMs, where you don''t
> have to deal with all these pesky issues?
>
I have Puppet create our VMs, which calls our kickstart, which calls Puppet 
;-)

For some tasks we _don''t_ use VMs (high perf HA DB servers, asterisk
> servers are two top examples). I find that managing the config of 
> those boxes is enormously important to retain sanity... 
>
Of course, we use lots of almost-identical VMs for things that are a
> good fit for VMs (webservers, etc)... 
>
>
>
> m 
> -- 
>  martin....@gmail.com <javascript:> 
>  -  ask interesting questions 
>  - don''t get distracted with shiny stuff  - working code first 
>  ~ http://docs.moodle.org/en/User:Martin_Langhoff 
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

What about the larger processes involved in incremental updates?  Eg. 
sequencing your updates so that the service keeps running.   I''m 
considering using Jenkins to orchestrate sequencial activity. 

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

Well, I''ll tell you that for now some kind of configuration is
difficult to
be done with puppet. At least I couldn''t find a way to do it. Ex: 
controlling a /etc/passwd file but partially with a libnss compat syntax. 
This means entries of local users are no controlled but entries beginning 
with a ''+'' are. As I couldn''t find a way to do it,
for now it is not being
controlled by puppet.

Em sexta-feira, 3 de maio de 2013 15h02min18s UTC-3, Martin Langhoff 
escreveu:
>
> While I prep my scripts and tool up for a large infra, I want to 
> revisit a question that I ask myself regularly: what do people not 
> manage with Puppet (or wish they weren''t)? 
>
> In my situation (a RH-style world), initial base system install, inc 
> disk layout and initial networking is handled with kickstart 
>
> For example: Do you exclude mountpoints? Network/SAN mountpoints? 
> Advanced network configs? 
>
> What are the reasons to exclude a particular item? How do you manage it 
> instead? 
>
> cheers, 
>
>
>
> m 
> -- 
>  martin....@gmail.com <javascript:> 
>  -  ask interesting questions 
>  - don''t get distracted with shiny stuff  - working code first 
>  ~ http://docs.moodle.org/en/User:Martin_Langhoff 
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Sun, May 5, 2013 at 2:11 PM, Larry Fast <lfast1234@gmail.com>
wrote:
> What about the larger processes involved in incremental updates?  Eg.
> sequencing your updates so that the service keeps running.   I''m
considering
> using Jenkins to orchestrate sequencial activity.
Coming from an ISConf background, I''d do it makefile-style.

Have actions that indicate completion by touching an empty file, and
tell puppet about it with a "creates".

 exec { "/usr/local/puppetactions/frambulant-upgrade-v1-v2":
           ...
           creates =>
''/var/lib/puppetactions/frambulant-upgrade-v1-v2''}
 }
 exec { "/usr/local/puppetactions/frambulant-upgrade-v2-v3":
           ...
           requires =>
Exec[''/usr/local/puppetactions/frambulant-upgrade-v1-v2'']
           creates =>
''/var/lib/puppetactions/frambulant-upgrade-v2-v3''}
 }

Haven''t actually used this yet, but my reading of
https://groups.google.com/forum/?fromgroups=#!topic/puppet-users/ssn6t2B8us0
is that it would work...

TBH, I am not familiar with Jenkins, perhaps it does something else?



m
--
 martin.langhoff@gmail.com
 -  ask interesting questions
 - don''t get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff

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

On Mon, May 6, 2013 at 8:49 AM, Bernardo Costa <bfcta@ig.com.br>
wrote:
> Well, I''ll tell you that for now some kind of configuration is
difficult to
> be done with puppet. At least I couldn''t find a way to do it. Ex:
> controlling a /etc/passwd file but partially with a libnss compat syntax.
> This means entries of local users are no controlled but entries beginning
> with a ''+'' are. As I couldn''t find a way to do
it, for now it is not being
> controlled by puppet.
Interesting -- that sounds like something that Puppet''s
user/useradd.rb could be taught about? If /sbin/useradd has support
for it, I guess it should be a reasonable patch. If not, that''s a
whole another kettle of fish...

I guess what I mean to say is: if Puppet had support for that case,
you''d use it. There aren''t fundamental or practical reasons no
to. Is
that correct?

cheers,



m
--
 martin.langhoff@gmail.com
 -  ask interesting questions
 - don''t get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff

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

Yes, that''s what I meant, if it were available I would use it. But I
don''t
think useradd knows how to deal with it because AFAIK it only creates local 
users. The same about /etc/passwd could be said about 
/etc/sysconfig/network. You might want to control it partially only, not 
the whole content of the file. In this last case, it is easier to solve the 
problem if you are dealing with templates. Then , you can just set a 
variable and the whole thing is done. But with /etc/passwd it is not 
possible.

Em segunda-feira, 6 de maio de 2013 11h15min52s UTC-3, Martin Langhoff 
escreveu:
>
> On Mon, May 6, 2013 at 8:49 AM, Bernardo Costa
<bf...@ig.com.br<javascript:>>
> wrote: 
> > Well, I''ll tell you that for now some kind of configuration
is difficult
> to 
> > be done with puppet. At least I couldn''t find a way to do it.
Ex:
> > controlling a /etc/passwd file but partially with a libnss compat 
> syntax. 
> > This means entries of local users are no controlled but entries 
> beginning 
> > with a ''+'' are. As I couldn''t find a way to
do it, for now it is not
> being 
> > controlled by puppet. 
>
> Interesting -- that sounds like something that Puppet''s 
> user/useradd.rb could be taught about? If /sbin/useradd has support 
> for it, I guess it should be a reasonable patch. If not, that''s a 
> whole another kettle of fish... 
>
> I guess what I mean to say is: if Puppet had support for that case, 
> you''d use it. There aren''t fundamental or practical
reasons no to. Is
> that correct? 
>
> cheers, 
>
>
>
> m 
> -- 
>  martin....@gmail.com <javascript:> 
>  -  ask interesting questions 
>  - don''t get distracted with shiny stuff  - working code first 
>  ~ http://docs.moodle.org/en/User:Martin_Langhoff 
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On 05/04/2013 01:43 PM, Martin Langhoff wrote:
> On Fri, May 3, 2013 at 4:43 PM, Schofield <dbschofield@gmail.com>
wrote:
>> Everything else is managed by puppet.
>
> Do you manage complex network setups (bonding, routing) via puppet?
> There is a certain degree of chicken-and-egg in that; how do you
> handle managing configuration without breaking the network that
> delivers the puppet config to the host?
I manage all that with Cobbler/kickstart combo. And it''s not like that 
things are changed often, so even if we have to change for example 
IP/netmask, we do it manually, but it''s a 1 change on 100+ servers per 
month, so, it just ain''t worth it IMHO.



-- 
Jakov Sosic
www.srce.unizg.hr

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

On 05/04/2013 02:25 PM, Luke Bigum wrote:
> On Saturday, May 4, 2013 12:43:57 PM UTC+1, Martin Langhoff wrote:
>
>     On Fri, May 3, 2013 at 4:43 PM, Schofield <dbsch...@gmail.com
>     <javascript:>> wrote:
>      > Everything else is managed by puppet.
>
>     Do you manage complex network setups (bonding, routing) via puppet?
>     There is a certain degree of chicken-and-egg in that; how do you
>     handle managing configuration without breaking the network that
>     delivers the puppet config to the host?
>
>
> We have a very generic kickstart that runs Puppet as a final step, and
> in that first Puppet run I have a module that writes out
> /etc/sysconfig/network-script/ files, which includes routes, rules,
> bonding, vlans, bridges, etc. All the information is stored in Hiera. We
> do not use Puppet to restart networking or attempt to fix up any
> discrepancies, someone has to come along and "service network
restart".
> So we use Puppet to provision what the networking should look like, but
> not enforce it. This means an Admin can come along and mess around with
> the networking and thus things can deviate from what Puppet says they
> should be.
>
> However, since all the information is stored in Hiera I can have Puppet
> export out nagios checks that do things along the lines of "this
> interface is not up but it should be" and "this interface does
not
> belong to the bond it should".
>
>     Do you manage complex disk setups (RAID arrays, DRBD) via Puppet? Any
>     hints as to how?
>
>
> I haven''t tried to manage DRBD but the config should be simple.
You''re
> going to run into problems if you try to create a DRBD disk across two
> servers at the same time - Puppet can''t orchestrate the commands
that
> need to be run on each server, for that you would need MCollective and
> unless you were creating 100s of DRBD disks, I wouldn''t bother and
I''d
> do it by hand.
>
> I do manage iSCSI disks, LVM and file systems in Puppet though.
There''s
> a manual step where we have to go to our storage appliances and create
> the iSCSI disk first, then put the iSCSI target ID into Hiera, but the
> rest is clockwork. It provisions only, it doesn''t attempt to
resize or
> reformat file systems if it finds a discrepancy. To counteract that,
> like the networking scripts, I can export nagios checks that say "this
> file system is 30 Gig and ext3, but it''s supposed to be 10 Gig and
ext4"
> which tells me someone''s gone and made on-box changes that
aren''t
> back-ported to Puppet / Hiera.
>
>     Or perhaps you only use Puppet so extensively in VMs, where you
don''t
>     have to deal with all these pesky issues?
>
>
> I have Puppet create our VMs, which calls our kickstart, which calls
> Puppet ;-)
I wrote cobbler module for Puppet, so we have all the cobbler settings 
in hiera and manage it via custom types :D So Puppet manages Cobbler 
which generates kickstart, which runs puppet :D


-- 
Jakov Sosic
www.srce.unizg.hr

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.