FAQ
Hi all,

I would appreciate your help clarifying my thinking around the following
problem.

Let's say I have a third-party (one that I didn't write) package x which
depends on a package y.

Package x is installed somewhere and is working fine against package y (as
in package x has been QA'ed and verified to work against package y).

Now, let's imagine I need to spin up another server to meet some load but
when I do so I find that package y has had a security fix that has caused a
problem in package x.
This is probably a bit of contrived case but could at least happen in
theory. Normally, I'd want to test the fix out before I put it live but in
this case because I had to spin a
server to meet some load this wasn't possible and as such my package
versions has skewed between my old and new servers.

The obvious solution to this would be to manage package versions explicitly
but is likely to become cumbersome quite quickly especially since I may not
even be managing
package y in my manifests explicitly.

Another solution might be to have my own package repository containing just
the packages I have tested against and only install from there but that
means another bit of
infrastructure to look after and manage, which I'd like to avoid if at all
possible.

One idea I had was to maybe have a script that dumps out package versions
and use that to either seed hiera or create package resources automatically
but I'm not sure if this
is a good idea or not.

What sort of solutions are people using to get round this?

Thanks for your help,
James

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

Search Discussions

  • David Schmitt at Dec 11, 2012 at 6:03 am
    Hi James,

    On 11.12.2012 05:41, James Gray wrote:
    Now, let's imagine I need to spin up another server to meet some load
    but when I do so I find that package y has had a security fix
    What sort of solutions are people using to get round this?
    You'll have to start managing versions. One way or the other. Client
    side there's apt's pinning, yum probably has some plugin to do so.
    Server side you can use a custom repo or puppet packages's ensure =>
    version.
    Another solution might be to have my own package repository
    containing just the packages I have tested against and only install
    from there but that means another bit of infrastructure to look after
    and manage, which I'd like to avoid if at all possible.
    For any significant amount of machines and packages, you'll really want
    to look into hosting that repo yourself. That way you can

    * stage security and other updates
    * keep most control over package versions with the least
    per-node overhead
    * keep installs repeatable



    Best Regards, David




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

    On 11 December 2012 11:33, David Schmitt wrote:
    You'll have to start managing versions. One way or the other. Client side
    there's apt's pinning, yum probably has some plugin to do so. Server side
    you can use a custom repo or puppet packages's ensure => version.
    I don't think this is workable for the reasons I have described. It's
    not realistic to list packages and versions of everything on my system
    and keep them up to date etc.
    For any significant amount of machines and packages, you'll really want to
    look into hosting that repo yourself. That way you can

    * stage security and other updates
    * keep most control over package versions with the least
    per-node overhead
    * keep installs repeatable
    Sure but the problem I have described is with even small
    infrastructures where you don't want to maintain anymore than you have
    too. If you just have a web server and a database server, you don't
    want to setup a repository too just (and make sure it's
    monitored/always available/update to date) etc. It is also not clear
    to me how you'd manage the process of pulling security fixes into your
    repository from upstream.

    I should say this is on EC2 and so another solution would be just to
    use AMI's I guess. Maybe building the AMI's with Puppet.

    Thanks,
    James

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Walter Heck at Dec 11, 2012 at 12:31 pm
    To me it sounds like you need to make a design decision: Either you care
    enough about these potential version differences to go through all the
    trouble to manage them properly, or you don't. Both are fine, personally I
    feel that the small chances that dependent packages have different versions
    installed with one having more bugs then the other is so negligible that it
    doesn't warrant the time investment needed to manage all those dependencies.

    my 2 cents :)

    Walter
    On Tue, Dec 11, 2012 at 1:10 PM, James Gray wrote:
    On 11 December 2012 11:33, David Schmitt wrote:

    You'll have to start managing versions. One way or the other. Client side
    there's apt's pinning, yum probably has some plugin to do so. Server side
    you can use a custom repo or puppet packages's ensure => version.
    I don't think this is workable for the reasons I have described. It's
    not realistic to list packages and versions of everything on my system
    and keep them up to date etc.
    For any significant amount of machines and packages, you'll really want to
    look into hosting that repo yourself. That way you can

    * stage security and other updates
    * keep most control over package versions with the least
    per-node overhead
    * keep installs repeatable
    Sure but the problem I have described is with even small
    infrastructures where you don't want to maintain anymore than you have
    too. If you just have a web server and a database server, you don't
    want to setup a repository too just (and make sure it's
    monitored/always available/update to date) etc. It is also not clear
    to me how you'd manage the process of pulling security fixes into your
    repository from upstream.

    I should say this is on EC2 and so another solution would be just to
    use AMI's I guess. Maybe building the AMI's with Puppet.

    Thanks,
    James

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

    --
    Walter Heck

    --
    Check out my startup: Puppet training and consulting @
    http://www.olindata.com
    Follow @olindata on Twitter and/or 'Like' our Facebook page at
    http://www.facebook.com/olindata

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Martijn at Dec 11, 2012 at 9:23 pm
    Op dinsdag 11 december 2012 05:41:40 UTC+1 schreef James Gray het volgende:
    What sort of solutions are people using to get round this?

    Thanks for your help,
    James
    Honestly, we're not really managing versions much. We deploy our EC2
    servers from the official Ubuntu 12.04 LTS AMI's to avoid maintaining our
    own AMI's. We bootstrap Puppet via cloud-config metadata (see CloudInit),
    to connect to our Master. The Master autosigns the nodes and configures
    them. Since Ubuntu's stock AMI's are used so often by EC2 customers a new
    instance is booted very quickly. In general a new instance is started and
    fully configured within 7-10 minutes, which is fast enough for our
    auto-scaling demands.

    Some important software-versions are set via Hiera
    (ensure=>'<someversion>'), but we try to avoid that if at all possible. We
    also try to avoid ensure=>'latest'.

    These hosts are mostly public-facing webservers, so we automatically
    install security-updates via 'unattended-upgrades' but we've provided
    exclusions for packages that are set via Hiera since we have to test those
    first. Non-security-updates are periodically evaluated and applied
    'manually' via mcollective.

    This may not be the best way to manage versions, but it works for us. In
    our experience Ubuntu's maintainers generally provide reliable updates, and
    most web-applications are not that dependent on very specific versions so
    we let dpkg figure out the dependency hell. We've not had any issues in the
    9 months since we started using EC2 that we could blame on versions.

    Of course upgrading to a newer Long Term Support release will take some
    serious testing, but so far this simple method seems to work and saves us a
    lot of time.

    Regards, Martijn

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedDec 11, '12 at 4:42a
activeDec 11, '12 at 9:23p
posts5
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2021 Grokbase