FAQ
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.

Search Discussions

  • Schofield at May 3, 2013 at 8:43 pm
    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.
  • Martin Langhoff at May 4, 2013 at 11:44 am

    On Fri, May 3, 2013 at 4:43 PM, Schofield 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.
  • Luke Bigum at May 4, 2013 at 12:25 pm

    On Saturday, May 4, 2013 12:43:57 PM UTC+1, Martin Langhoff wrote:
    On Fri, May 3, 2013 at 4:43 PM, Schofield 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.
  • Larry Fast at May 5, 2013 at 6:11 pm
    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.
  • Martin Langhoff at May 6, 2013 at 1:59 pm

    On Sun, May 5, 2013 at 2:11 PM, Larry Fast 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.
  • Jakov Sosic at Jul 2, 2013 at 9:56 pm

    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.
  • Jakov Sosic at Jul 2, 2013 at 9:52 pm

    On 05/04/2013 01:43 PM, Martin Langhoff wrote:
    On Fri, May 3, 2013 at 4:43 PM, Schofield 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.
  • Erik Dalén at May 4, 2013 at 11:33 am
    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 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.
  • Martin Langhoff at May 4, 2013 at 11:38 am

    On Sat, May 4, 2013 at 7:33 AM, Erik Dalén 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.
  • Erik Dalén at May 4, 2013 at 11:43 am

    On 4 May 2013 13:37, Martin Langhoff wrote:
    On Sat, May 4, 2013 at 7:33 AM, Erik Dalén 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.
  • Bernardo Costa at May 6, 2013 at 12:49 pm
    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.
  • Martin Langhoff at May 6, 2013 at 2:16 pm

    On Mon, May 6, 2013 at 8:49 AM, Bernardo Costa 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.
  • Bernardo Costa at May 7, 2013 at 10:52 pm
    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 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedMay 3, '13 at 6:02p
activeJul 2, '13 at 9:56p
posts14
users7
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase