Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

action: manage and manage_home #9

Open
afletch opened this Issue · 3 comments

3 participants

@afletch

I'm trying to add authorized_keys to a user (the root user) but not modify anything else.

I therefore have manage_home set to false...

"manage_home": "false",

However, despite this it's still executing usermod with parameters '-d /home/root'

[Fri, 08 Jun 2012 14:32:32 +0100] INFO: Processing user[root] action manage (/var/chef/cache/cookbooks/user/providers/account.rb line 94)
[Fri, 08 Jun 2012 14:32:32 +0100] DEBUG: user[root] setting home to /home/root
[Fri, 08 Jun 2012 14:32:32 +0100] DEBUG: Executing usermod -d '/home/root' root
[Fri, 08 Jun 2012 14:32:32 +0100] DEBUG: ---- Begin output of usermod -d '/home/root' root ----
[Fri, 08 Jun 2012 14:32:32 +0100] DEBUG: STDOUT:
[Fri, 08 Jun 2012 14:32:32 +0100] DEBUG: STDERR: usermod: user root is currently logged in
[Fri, 08 Jun 2012 14:32:32 +0100] DEBUG: ---- End output of usermod -d '/home/root' root ----
[Fri, 08 Jun 2012 14:32:32 +0100] DEBUG: Ran usermod -d '/home/root' root returned 8

I'm not sure if this is a bit in the useradd provider of chef, or the user cookbook. Certainly if manage_home is being set to false when setting up the user resource in account.rb:102 then useradd.rb should be realising this and not passing the flag.

I'm rather new to Chef, but having traced this back as far as I can, it does seem like the chef user provider isn't working as it should. I wanted to get your thoughts on this.

Thanks
A

@patcon

Might be that manage_home expects a boolean value, and so "false" is read as a string and so true?
https://github.com/fnichol/chef-user/blob/master/resources/account.rb#L32

I think setting :default => nil without specifying a :kind_of value will default to :kind_of => Boolean.

If that's the case, probably could do with making the resource a little more forgiving, so I'm sure a pull request would be appreciated :)

EDIT: Hm. Doesn't seem that would be the case... seems any apparent "default" was the result of logic that the maintainer implemented... Unless chef itself changed behavior, I don't think my guess is on the right track.

@fnichol
Owner

So after tracking this down, it appears as thought the Chef user resource calls usermod with a -d flag whether or not the resource is managing the home directory. The -m flag is what would move or create the user's home directory.

The interesting bit of the logging output are these lines:

[Fri, 08 Jun 2012 14:32:32 +0100] DEBUG: STDERR: usermod: user root is currently logged in
[Fri, 08 Jun 2012 14:32:32 +0100] DEBUG: ---- End output of usermod -d '/home/root' root ----
[Fri, 08 Jun 2012 14:32:32 +0100] DEBUG: Ran usermod -d '/home/root' root returned 8

I haven't come across this particular error before, but it does produce the same output if you attempt this command as root (I tried from a vagrant/lucid32 VM):

vagrant@user:~$ sudo su - root
root@user:~# usermod -d '/home/root' root
usermod: user root is currently logged in

I think the crux of this problem is that the command is declaring root's home directory to be /home/root when it's most likely /root (depending on your platform). When I looked in one of my Chef repos, I had the following data bag item set up:

{
  "id" : "root",
  "home" : "/root",
  "ssh_keys" : [ "ssh-rsa AAAA...", "ssh-rsa AAAB..." ]
}

@patcon Looking back I wish I didn't account for so many values of truthyness and falsyness. At the time I wan't 100% sure if a JSON false would map across to a Ruby false. That could be something I trim out in a minor version bump, thoughts?

@patcon

@fnichol I'd leave it up to your sense of what fits. Was just an extra layer of indirection when I was going through, but seemed to make sense by the end :) ie. no preference on my end

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.