Hello folks, As we rebuild all of our servers from a variety of distributions to one standardised distribution, we''re running into the fact that several servers have conflicting ideas of who UID 501 is. Since we''re rebuilding, that''s not really an issue - I''ve started at 500 in a virtual_users.pp file, and I''m realizing users in the per-node definitions. The sticky bit is what to do about users that will only ever occur on one server. I can either make them virtual in the central file, or I can make them real in the per-node file. The former has the attraction that I can make sure that my UID usage is consistent and non-overlapping, while the latter means I can never accidentally realize an account onto a server where it doesn''t belong. Anyone have a suggested best practice for this? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 30 May 2008, Duncan Hill wrote:> Hello folks, > > As we rebuild all of our servers from a variety of distributions to > one standardised distribution, we''re running into the fact that > several servers have conflicting ideas of who UID 501 is. Since we''re > rebuilding, that''s not really an issue - I''ve started at 500 in a > virtual_users.pp file, and I''m realizing users in the per-node > definitions. The sticky bit is what to do about users that will only > ever occur on one server. I can either make them virtual in the > central file, or I can make them real in the per-node file. The > former has the attraction that I can make sure that my UID usage is > consistent and non-overlapping, while the latter means I can never > accidentally realize an account onto a server where it doesn''t belong. > > Anyone have a suggested best practice for this?Ask yourself: what is the bigger damage if it happens: uid-clashing between a local and a global user or realizing a unneeded user? I''d guess that different organisations and different usage scenarios lead to different answers. Regards, DavidS - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIP9pU/Pp1N6Uzh0URApKXAJ44vfzCGp94eV4jEKjiDu6BwqPdNACgjl+5 s96ZSzkkIpo+qGVLIqyk8RE=JvU5 -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
2008/5/30 David Schmitt <david@schmitt.edv-bus.at>:> >> former has the attraction that I can make sure that my UID usage is >> consistent and non-overlapping, while the latter means I can never >> accidentally realize an account onto a server where it doesn''t belong. >> >> Anyone have a suggested best practice for this? > > Ask yourself: what is the bigger damage if it happens: uid-clashing between a > local and a global user or realizing a unneeded user?Thanks for clarifying the thought process. The drawback to the latter is that if I/we don''t notice, a potential hole may exist on that server (ie, weak password account on a server exposed to the net where the account is normally used on a heavily protected subnet), though the chance is rare, as there''s pretty much one admin doing the puppet work - me! I''d much rather avoid a UID clash, so I think I just answered the question. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 30 May 2008, Duncan Hill wrote:> 2008/5/30 David Schmitt <david@schmitt.edv-bus.at>: > >> former has the attraction that I can make sure that my UID usage is > >> consistent and non-overlapping, while the latter means I can never > >> accidentally realize an account onto a server where it doesn''t belong. > >> > >> Anyone have a suggested best practice for this? > > > > Ask yourself: what is the bigger damage if it happens: uid-clashing > > between a local and a global user or realizing a unneeded user? > > Thanks for clarifying the thought process. The drawback to the latter > is that if I/we don''t notice, a potential hole may exist on that > server (ie, weak password account on a server exposed to the net where > the account is normally used on a heavily protected subnet), though > the chance is rare, as there''s pretty much one admin doing the puppet > work - me! > > I''d much rather avoid a UID clash, so I think I just answered the question.Right. And using puppet, you can afford to require ssh-keys everywhere (distributing authorized_keys with puppet). Regards, DavidS - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIP+K3/Pp1N6Uzh0URAv3PAKCZa08Ll56eAJvXAsHg9f0ZVTf/uQCffnqd fuvqQYY2WYaN7Y+GsLBFkiE=w2Q/ -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Digant C Kasundra
2008-May-30 16:32 UTC
[Puppet Users] Re: Best practice for user accounts
--On Friday, May 30, 2008 11:19 AM +0100 Duncan Hill <bajandude@googlemail.com> wrote:> Hello folks, > > As we rebuild all of our servers from a variety of distributions to > one standardised distribution, we''re running into the fact that > several servers have conflicting ideas of who UID 501 is. Since we''re > rebuilding, that''s not really an issue - I''ve started at 500 in a > virtual_users.pp file, and I''m realizing users in the per-node > definitions. The sticky bit is what to do about users that will only > ever occur on one server. I can either make them virtual in the > central file, or I can make them real in the per-node file. The > former has the attraction that I can make sure that my UID usage is > consistent and non-overlapping, while the latter means I can never > accidentally realize an account onto a server where it doesn''t belong. > > Anyone have a suggested best practice for this?Haven''t had problems with UID conflicts before, I found having everyone in virtual_users.pp was still the best way to go. Having a different approach also lead to cases where someone was only going to be on one machine, and then all of a sudden, they needed to be on more than one and I had to switch them over. So to avoid that headache, I just put them all as virtual and realize where needed. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On May 30, 4:19 am, "Duncan Hill" <bajand...@googlemail.com> wrote:> > Anyone have a suggested best practice for this?For the most part, we followed the puppet best practices document with regard to user configuration. We have a small number of people and groups to configure, and we don''t have an existing LDAP directory. I''ll follow-up this post with a location of our public puppet repository when the details are finalized so you can see how we approached the configuration. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---