While I would possibly cheer lead for Puppet, I don't think I would have 
specified anything down to the specific kernel version. I would have looked at 
dependencies for the tools, and specified all of that, but the kernel is just 
supposed to work.

----- Original Message -----
> Puppet is great, for sure. In this specific case, I'm not sure it
> would have helped. It's still easy to have drift of packages versions
> in a
> Puppetized environment if you aren't methodical about rolling out
> updates. This is especially true for packages like the kernel, which
> require intervention for the update to take effect. To solve this
> within puppet, I suppose you could have it ensure that only a specific
> kernel version was installed, or have it manage your GRUB
> configuration and
> specify a specific kernel version to boot. It may be smarter to solve
> the problem at the repository level.
> 
> On 03/13/2014 01:55 PM, Kent Perrier wrote:
> > This is actually a good use case for using a configuration
> > management tool like puppet. When you built your new server would
> > would have had
> > a high degree of confidence that it would be identical to the other
> > servers in your environment and you wouldn't have seen this issue!
> >
> > Glad you it got you working! And people say RedHat support isn't
> > worth it! ;)
> >
> > Kent
> >
> >
> > On Thu, Mar 13, 2014 at 1:12 PM, Howard White <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> >     On 03/13/2014 09:44 AM, Kent Perrier wrote:
> >
> >         If you don't have access to this KB article let me know and
> >         I can print
> >         it out for you. Looks to be a kernel bug. A quick cut and
> >         paste of the
> >         workaround section:
> >
> >         This issue is resolved in |kernel-2.6.32.358.16.1.el6| and
> >         later.
> >
> >         Please update the kernel package with |yum update kernel|.
> >
> >
> >               Workaround
> >
> >         Run the following command as the root user:
> >
> >         |echo 1 > /proc/sys/vm/unmap_area_factor
> >         |
> >
> >         If this resolves the issue, then add the following line to
> >         |/etc/sysctl.conf| to persist the change across reboots:
> >
> >         |vm.unmap_area_factor = 1
> >         |
> >
> >
> >     Kent,
> >
> >     I owe you a steak and a beer!
> >
> >     I did the yum update kernel and the problem is solved!
> >
> >     Case closed.
> >
> >     Honorable mention to Brian.
> >
> >
> 
> -- All the best,
> Brian Pitts
> 
> --
> -- You received this message because you are subscribed to the Google
> Groups "NLUG" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected] For more options, visit this
> group at http://groups.google.com/group/nlug-talk?hl=en
> 
> --- You received this message because you are subscribed to the Google
> Groups "NLUG" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [email protected].
> For more options, visit https://groups.google.com/d/optout.

-- 
Steven Critchfield [email protected]

-- 
-- 
You received this message because you are subscribed to the Google Groups 
"NLUG" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/nlug-talk?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"NLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to