On May 15, 9:19 am, jcbollinger <john.bollin...@stjude.org> wrote:
> That's excellent advice, but regardless of POSIX, there is a wide
> variety of real-world systems that do not enforce such a constraint,
> and there are many machines that have users and/or groups with
> duplicate IDs. Therefore POSIX, too, is irrelevant to the question.
Well, sorry but you said unix before. so I thought you wanted to
actually look at what UNIX specifies. enough talking about unix specs
then.
> Indeed you do, and that's an area Puppet is good at dealing with.
> Note that already there is the concept that the login name is the key
> identifier -- UIDs *for a given login* should be the same across
> machines.
not exactly. it can push out new users,groups but it can't out of the
box make a given machine match the user,group manifest that is desired
by a system administrator. you have said this yourself in that puppet
will error out and you have to go and fix it.
> > what I am wondering is why not support that mapping coded into a
> > puppet data structure? specify I want uid 542 to have a 'foo' and a
> > 'bar' entry and then using the API functions make it so.
>
> You mean like this?
>
> user {
> 'foo': uid => 542, allowdupe => true;
> 'bar': uid => 542, allowdupe => true;
> }
nope. the other way around :) using the uid as a key. but anyways
was just a quick thought. not sure it would be practical to make that
change. so we can ignore that thought.
> User and group data other than ID numbers are all userland concepts in
> the first place, so it is natural that that Puppet's data model for
> these is matched to userland. The specific tools Puppet uses on
> various systems are really not the point. Puppet goes to considerable
> effort to provide a system abstraction that is internally consistent
> and that is as suitable as possible across a wide variety of systems.
> User and group names are the identifiers that work for that. UID and
> GID just aren't suitable.
I get that puppet has decided on using the account name and group name
as keys.
and yes userland (aka not kernel). but there is a difference between
having a program using API calls and calling an external binary.
think of it like it you are writing perl code to update a mysql
database. do you exec the mysql command line binary and screen scrape
the output? or do you use DBD::mysql via the DBI module?
if you use an API you get a MUCH better view of the environment and
can handle errors far better.
for example right now. just delete a line for a user out of /etc/
shadow that puppet is controlling. will it put it back? no. it
errors out. this isn't a duplicate userid case. this is unique
usernames just a missing line and poof. puppet (out of the box) can't
make the system match the manifest.
to repair you have to manually delete that user out of /etc/passwd
and /etc/group as well and then re-apply puppet.
That just feels VERY fragile to me.
> > My preference is to have it set the state to how I want it without
> > having to cleanup the mess on a box.
>
> And here we're heading back toward DWIM. Puppet provides means to
> achieve each task you have brought up, just not the particular means
> you would prefer it to have. You already acknowledged that you
> weren't expecting a DWIM oracle. If you give Puppet a configuration
> description that doesn't match what you really want, then a need for
> some sort of cleanup is likely.
actually no it really doesn't. bombing out with an error and
requiring manual patch up on potentially thousands of systems seems be
be a really bad lack of feature. Having bad operators that sometimes
do things they shouldn't is reality. If I was in a small shop that
had 2-3 admins sure it would be fine.
puppet is billed as a tool to define a manifest and then have that
manifest applied to a given target system and puppet will make the
system look like the manifest that was specified.
> It is unfortunate that you didn't realize in advance that the
> description you were giving didn't match what you really wanted, but
> that sort of problem is commonplace for anyone learning a new system
> or language. Puppet has good and valid reasons for its data model
> choices, and those are part of the package deal.
I am not sure where you are coming up with this comment from.
You are missing the point if you think I am concerned about initial
typos
and glitches learning a system.
I am concerned about the robustness of the system and how much custom
coding we might need to do to get puppet to be able to keep a system
at a defined manifest. I've contacted the person at puppetlabs we
have been working with to get his take on things. may even be part of
a professional services implementation for him at this point.
Where are those design and data model decisions documented and
discussed? if you could point me at those docs that might help shed
light on why the puppet Resources look the way they do. The generated
docs at puppetlabs.com don't really don't give a whole lot of
information.
So to reiterate I get that it was easier to get a working User
resource by just invoking the useradd tool. and that means you just
deal with names since that is what that toolset presents.
Steve
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
