Has anyone had any experience using Puppet to manage read-only root /
diskless clients? RedHat / CentOS used to have a utility to do this
(system-config-notboot), but it has been deprecated as of 6.0. Reading
through 5.7's rc.sysinit, it makes references to moving towards using
Puppet to manage the state directories. Anyone know how to do this?
- Scott
On 2011-11-10 08:42, Brandon wrote:
> I'm glad to see this discussion because I was just starting to research
> using Puppet or Chef to help manage a new web server environment I helped
> to build. I've not used either before. We have a small number of servers so
> far and scripts are fine for now but using one of these tools would make my
> life easier in the future. Sounds like puppet would be a good start. I know
> my last employer (GD) used it to manage hundreds of servers.
>
> On Wed, Nov 9, 2011 at 4:35 PM, Kevin Fries <kfries6@gmail.com> wrote:
>
> > At my work, we use AD for access across all our Windows and Linux
> > servers. Then we use puppet to manage consistent permissions on the
> > /etc/sudoers file, auto_home, and ssh access.
> >
> > This combination works great!!!
> > On Nov 9, 2011 4:24 PM, "Dan Dubovik" <dandubo@gmail.com> wrote:
> >
> >> We currently use puppet. We have used it for quite some time, and just
> >> revisited our configuration management system, to see if it was still the
> >> right way to go.
> >>
> >> In looking at Chef, CFEngine and Puppet, we decided to stick with Puppet.
> >> The cost of changing over a number of extremely complex systems to a new
> >> management service was simply too high, for minimal (if any) gain.
> >>
> >> On the topic of user management, while a shell script may be easier /
> >> faster in the short term, over time (and once an environment is
> >> sufficiently large) it can result in an inconsistent environment. Servers
> >> can be down, unresponsive, have some random failure, and if not immediately
> >> and manually remediated, you end up with users on servers that shouldn't
> >> be, missing users on others, and old passwords on yet others.
> >>
> >> Using Puppet, you can either maintain /etc/{passwd|group|shadow}
> >> (wouldn't personally do this, but it is an option, so included here in the
> >> interest of being complete), or you can use the 'user' and 'group' resource
> >> type (http://docs.puppetlabs.com/references/stable/type.html#user) to
> >> maintain users across the environment. This is if you need / want to
> >> continue using local users. Personally, I'm with Bryan, and prefer a
> >> central authentication method, as it resolves many of the problems you
> >> would have with local users, and provides for an easier method of auditing
> >> user accounts.
> >>
> >> -- Dan.
> >>
> >> On Tue, Nov 8, 2011 at 7:43 PM, Lisa Kachold <lisakachold@obnosis.com>wrote:
> >>
> >>> Thanks to all who responded.
> >>> I believe this is an excellent subject for a blog after about 10,000 lab
> >>> testing package comparison hours!
> >>> Laugh!
> >>>
> >>> On Tue, Nov 8, 2011 at 9:34 AM, Bryan O'Neal <
> >>> Bryan.ONeal@theonealandassociates.com> wrote:
> >>>
> >>>> Personal opinion - for large scale use with many people maintaining
> >>>> different sections puppet is one of the best - however it is really
> >>>> only good for file management. Since nearly everything on a linux
> >>>> system is a file, this should not be a problem. As for user management
> >>>> - I am still under the opinion on that (unless you are a pure Linux
> >>>> environment) this should be solved by using Active Directory for
> >>>> authentication and pam for access mismanagement. (if you don't want to
> >>>> integrate your services with pam they probably have a simple
> >>>> configuration file that controls access management that could be
> >>>> handled by puppet just as easily)
> >>>> Chef is more extensible with access to a full ruby stack - however
> >>>> unless you have a very small group of well coordinated developers who
> >>>> insist on adhering to standards you will rapidly find your
> >>>> provisioning code will become unwieldy and almost useless as you
> >>>> inheritances start overriding key portions without notice as to why or
> >>>> what section did what. In the rite hands the flexibly is an asset that
> >>>> may help solve key problems. In the wrong hands it will propagate
> >>>> problems whose effect compound over time until the entire system is
> >>>> scraped.
> >>>>
> >>>> Disclaimer - I know very little regarding this compared to others. I
> >>>> use puppet, write manifests, build systems, etc. I am not responsible
> >>>> for the engineering.
> >>>>
> >>>> On Sun, Nov 6, 2011 at 3:56 PM, Ed <plug@0x1b.com> wrote:
> >>>> > On Sat, Nov 5, 2011 at 4:59 PM, James Mcphee <jmcphe@gmail.com>
> >>>> wrote:
> >>>> >> I am also looking at implementing one of these at some point in the
> >>>> near
> >>>> >> future. The standard scripts over ssh is simple and relatively well
> >>>> >> controlled, but teaching new people how to use them and maintaining
> >>>> them in
> >>>> >> a sane fashion is troublesome. I've used a few HP, Dell, Sun, and
> >>>> IBM
> >>>> >> config products in the past and they were all bad enough I went back
> >>>> to
> >>>> >> scripts in no time.
> >>>> >>
> >>>> >> On Nov 5, 2011 11:33 AM, "Lisa Kachold" <lisakachold@obnosis.com>
> >>>> wrote:
> >>>> >>>
> >>>> >>> Can anyone chime in on using enterprise mass systems configuration
> >>>> and
> >>>> >>> management tools?
> >>>> >>>
> >>>> >>> What are you using? Chef, Puppet or CFEngine and why?
> >>>> >>>
> >>>> >
> >>>> > I like CFengine - the task based focus is on "promises" and the
> >>>> > install is painless. The only ruff spot I could point to is with
> >>>> > application updates - the interface to yum is less polished than some
> >>>> > - updates work if you work on them as groups vs particular apps. There
> >>>> > are many promises online and in the maillists for particular tasks. I
> >>>> > think there is even a starter pack on github somewhere. CFengine fits
> >>>> > well into ITIL and managing IT - lots of IT - and it has it's own
> >>>> > directory in /var too! ;)
> >>>> >
> >>>> > The RH world has worked with Cobbler plus Puppet - this is getting
> >>>> > tighter with Puppet plus TheForman and Pulp - if I remember the
> >>>> > roadmap.
> >>>> > ---------------------------------------------------
> >>>> > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> >>>> > To subscribe, unsubscribe, or to change your mail settings:
> >>>> > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> >>>> ---------------------------------------------------
> >>>> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> >>>> To subscribe, unsubscribe, or to change your mail settings:
> >>>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> (602) 791-8002 Android
> >>> (623) 239-3392 Skype
> >>> (623) 688-3392 Google Voice
> >>> **
> >>> HomeSmartInternational.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------
> >>> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> >>> To subscribe, unsubscribe, or to change your mail settings:
> >>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> >>>
> >>
> >>
> >> ---------------------------------------------------
> >> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> >> To subscribe, unsubscribe, or to change your mail settings:
> >> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> >>
> >
> > ---------------------------------------------------
> > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> > To subscribe, unsubscribe, or to change your mail settings:
> > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> >
>
>
>
> --
> Brandon Haymore
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)