Re: Re: Newbie: Confused about where to start managing users...

On Wed, Feb 8, 2012 at 4:23 PM, jcbollinger
<John.Bol### @stjude.org> wrote:
 To give you a good answer, I need to understand this a bit better, and
 I'm having trouble with that statement.  On Unix-like systems the
user
 name is the primary identifier, and UIDs are only secondary.  It is
 even possible for two or more users to have the same UID.  What,
then,
 does it mean for a user name to change while the UID remains
 constant?  I'm looking for the big picture here, not just the /etc/
 passwd view of the world.

The big picture:

We create an appliance (debian-in-a-pizza-box). In this appliance, one
can create users. There is a "users" database table. In that, the user
ID is unique, but the UI allows the user to modify user names (along
with e.g. password).

A new feature request is that it should be possible for such
configured users to log in vial SSH to the appliance, because it may
have network access to other networks than the user has from his
browser/workstation and use the appliance as a "jump host". So now the
task is to create local users based on the contents of our "users"
database table. The UI for his table also allows configuration of a
password (details about sha512 removed here) and SSH key. They must
have their own home dirs so they can use the appliance as a TFTP
server (details removed).

In order to get a little separation for these "CLI users", we create a
debootstrap/chroot for these users. So sshd_config's ChrootDirectory
is set up appropriately for these users, and for each user, we create
/jail/home/<username>,
/jail/home/<username>/.ssh/authorized_keys,
/home/<username> and /home/<username>/.ssh/authorized_keys that
is a
soft link to /jail/home/<username>/.ssh/authorized_keys (I want the
user to be able to add to configure his own authorized keys via CLI
too, and sshd reads .ssh/authorized_keys from the "outer" root, not
the jail, even for ChrootDirectory users, for some reason I don't
understand.)

As users come and go and get renamed, I expect /home, /jail/home,
/etc/passwd and /jail/etc/passwd to follow suit. I'm thinking that
doing the setup inside the jail can be done with installing puppet
inside the jail too and running puppet once again inside the jail with
setup from outside the jail. Exact same complication in the jail as
outside. Solve it for one and its solved for the other.

 If it would be sufficient to bound the purge range
 only below, then you could do this:

 resources { "user":
    purge => true,
    unless_system_user => 2000
 }

Cool! Yes, that is fine. We just want the possibility of creating real
non-system and non-chroot users too.

 Puppet probably can handle your complex renaming cases by transiently
 leveraging the ability (available on many, but not all, client OSs)
 for one UID to be assigned to multiple users:
...
 So far, none of this touches on user home directories.  Puppet's User
 resource does have the ability to manage home directories on most OSs
 (unless you are relying on LDAP for your user DB), but it's not clear
 to me what management, if any, you might want there.  This is where
my
 confusion over what you mean about renaming accounts comes most to
 bear.

The most important is the user "foo" has home dir "/home/foo" and
correct uid. Ideal would be that if a user is renamed from a to b,
that /home/a is renamed to /home/b. We can live with "sudo rm -r
/home/a; sudo mkdir /home/b; chown b: /home/b; #setup /home/b" too
(don't expect user renames to be frequent). Regardless of whether one
does a "mv" or "rm && mkdir" the complex ( "fred->barney" +
"barney->fred" ) rename will be a two-step process, I'm affraid. How
likely is it? Not very. But there is no good way to fail gracefully,
or alert the user by rejecting the second rename in the UI either.

Doing this:

resources { "user":
  purge => true,
  unless_system_user => 2000
}

user { 'barney':
  uid => 2003,
  allowdupe => true,
}

user { 'fred':
  uid => 2004,
  allowdupe => true,
}

etc.

Is it a valid assumption that this would end with exactly the correct
users created in /etc/passwd? If so, then I guess it wouldn't be hard
to code:

exec { 'handleHomedirs':
   # Prefer ruby in this crowd.. ;-)
   command => '/opt/product/bin/handleHomedirs.rb',
   require => [ User['barney'],..., Resources['user'] ]
}

Is adding "Resources['user']" to exec's require the way to ensure that
the exec gets executed after the purge of stale users?

I'm trying to get my feet wet with puppet with this feature, trying
find out what "the puppet way" is. Perhaps I didn't start with the
easiest of projects.... The handleHomedirs.rb strikes me as quite
non-puppet-esque... But perhaps this is an acceptable compromise :-)
We could just use puppet for so many things, and I decided to start
somewhere.

Thanks for your response, and sorry to burden you with so much detail....

Peter