Hi all, I''m a new puppet user and I''m running into some
weirdness
around creating users on solaris. (puppet version 0.23.2)
The virt_all_users way of managing users seems pretty reasonable, but
I don''t see how to deal with user specific groups with that.
I have:
class virt_all_users {
@user { "seph":
ensure => "present",
uid => "1001",
gid => "1001",
comment => "seph",
home => "/home/seph",
shell => "/bin/bash",
}
}
But realizing that on a solaris machine generates an error because
group 1001 doesn''t yet exist. Specifically:
err: //virt_all_users/User[seph]/ensure: change from absent to present failed:
Could not create user seph: Execution of ''/usr/sbin/useradd -u 1001 -s
/bin/bash -d /home/seph -g 1001 -c seph seph'' returned 1536: UX:
/usr/sbin/useradd: ERROR: group 1001 does not exist. Choose another.
So, what''s the recommended way of doing this?
seph
On 11/8/2007 4:18 PM, seph wrote:> The virt_all_users way of managing users seems pretty reasonable, but > I don''t see how to deal with user specific groups with that. > > class virt_all_users { > > @user { "seph": > ensure => "present", > uid => "1001", > gid => "1001", > comment => "seph", > home => "/home/seph", > shell => "/bin/bash", > } > } > > But realizing that on a solaris machine generates an error because > group 1001 doesn''t yet exist. Specifically: > > err: //virt_all_users/User[seph]/ensure: change from absent to present failed: Could not create user seph: Execution of ''/usr/sbin/useradd -u 1001 -s /bin/bash -d /home/seph -g 1001 -c seph seph'' returned 1536: UX: /usr/sbin/useradd: ERROR: group 1001 does not exist. Choose another.I''d guess that you need to define some groups ahead of time: @user { "seph": ensure => "present", uid => "1001", gid => "seph", comment => "seph", home => "/home/seph", shell => "/bin/bash", require => group["seph"] } group { "seph": ensure => "present", gid => "1001", } -- Mike Renfro / R&D Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological University
Mike Renfro <renfro@tntech.edu> writes:> On 11/8/2007 4:18 PM, seph wrote: > >> The virt_all_users way of managing users seems pretty reasonable, but >> I don''t see how to deal with user specific groups with that. >> >> But realizing that on a solaris machine generates an error because >> group 1001 doesn''t yet exist. Specifically: > I''d guess that you need to define some groups ahead of time: > > @user { "seph": > ensure => "present", > uid => "1001", > gid => "seph", > comment => "seph", > home => "/home/seph", > shell => "/bin/bash", > require => group["seph"] > } > > group { "seph": > ensure => "present", > gid => "1001", > }Yes, but I''m not quite sure what the accepted best practice for this is. I''m inclined to drop virt_all_users, and move to having each user and group entries in manifests/users/username.pp, but I''m wondering how other people lay it out. seph
And to follow up to myself... I can''t quite make the virtual resources work the way I want them to. I''d rather not have inapplicable user groups created, which implies I should use virtual groups. But, virtual groups don''t get realized when the user is realized. Which leads me separately realizing the groups, which is a lot of overhead. So I feel like I''m doing this wrong, and fighting the system. seph seph <seph@directionless.org> writes:> Mike Renfro <renfro@tntech.edu> writes: > >> On 11/8/2007 4:18 PM, seph wrote: >> >>> The virt_all_users way of managing users seems pretty reasonable, but >>> I don''t see how to deal with user specific groups with that. >>> >>> But realizing that on a solaris machine generates an error because >>> group 1001 doesn''t yet exist. Specifically: >> I''d guess that you need to define some groups ahead of time: >> >> @user { "seph": >> ensure => "present", >> uid => "1001", >> gid => "seph", >> comment => "seph", >> home => "/home/seph", >> shell => "/bin/bash", >> require => group["seph"] >> } >> >> group { "seph": >> ensure => "present", >> gid => "1001", >> } > > Yes, but I''m not quite sure what the accepted best practice for this > is. I''m inclined to drop virt_all_users, and move to having each user > and group entries in manifests/users/username.pp, but I''m wondering > how other people lay it out. > > seph > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users
On 11/9/2007 10:32 AM, seph wrote:> I can''t quite make the virtual resources work the way I want them to. > I''d rather not have inapplicable user groups created, which implies I > should use virtual groups. But, virtual groups don''t get realized > when the user is realized. Which leads me separately realizing the > groups, which is a lot of overhead. So I feel like I''m doing this > wrong, and fighting the system.How many users and groups are we talking about? My inclination so far has been that puppet was best suited for managing system users (backup, httpd, etc.) and not every login user on the system. Surely the Stanford folks that make virt_all_users from their passwd file are reading a fairly limited number of admin-level accounts and not every authorized user, right? The non-admin folks being authenticated via Kerberos, LDAP, or some other non-passwd method? -- Mike Renfro / R&D Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological University
Mike Renfro <renfro@tntech.edu> writes:> On 11/9/2007 10:32 AM, seph wrote: > >> I can''t quite make the virtual resources work the way I want them to. >> I''d rather not have inapplicable user groups created, which implies I >> should use virtual groups. But, virtual groups don''t get realized >> when the user is realized. Which leads me separately realizing the >> groups, which is a lot of overhead. So I feel like I''m doing this >> wrong, and fighting the system. > > How many users and groups are we talking about? My inclination so far > has been that puppet was best suited for managing system users (backup, > httpd, etc.) and not every login user on the system.Oh yeah, I''m not talking very many, less than 10. Which is below my threshold for directory services. Also, I think I want the admin users to have local accounts on my servers anyhow. seph
On Fri, Nov 09, 2007 at 12:56:01PM -0500, seph wrote:> Mike Renfro <renfro@tntech.edu> writes: > > > On 11/9/2007 10:32 AM, seph wrote: > > > >> I can''t quite make the virtual resources work the way I want them to. > >> I''d rather not have inapplicable user groups created, which implies I > >> should use virtual groups. But, virtual groups don''t get realized > >> when the user is realized. Which leads me separately realizing the > >> groups, which is a lot of overhead. So I feel like I''m doing this > >> wrong, and fighting the system. > > > > How many users and groups are we talking about? My inclination so far > > has been that puppet was best suited for managing system users (backup, > > httpd, etc.) and not every login user on the system. > > Oh yeah, I''m not talking very many, less than 10. Which is below my > threshold for directory services. Also, I think I want the admin > users to have local accounts on my servers anyhow.You want nsscache: http://code.google.com/p/nsscache/ - Matt -- I''m not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else''s.
Matthew Palmer <mpalmer@hezmatt.org> writes:>> > On 11/9/2007 10:32 AM, seph wrote: >> > >> >> I can''t quite make the virtual resources work the way I want them to. >> >> I''d rather not have inapplicable user groups created, which implies I >> >> should use virtual groups. But, virtual groups don''t get realized >> >> when the user is realized. Which leads me separately realizing the >> >> groups, which is a lot of overhead. So I feel like I''m doing this >> >> wrong, and fighting the system. > > You want nsscache: > > http://code.google.com/p/nsscache/Thank you for the suggestion, but no. I do not want nsscache. I want my configuration management stuff to manage my local user accounts. For lack of a cleaner solution, I wrote a perl script to generate the virtual users, virtual group, and disabled users. Not great, but easy to change later. seph Date: Tue, 13 Nov 2007 09:58:08 -0500 In-Reply-To: <20071109205949.GB21641@hezmatt.org> (Matthew Palmer''s message of "Sat, 10 Nov 2007 07:59:49 +1100") Message-ID: <w52pryery4f.fsf@lame.message.id> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)