action: manage and manage_home
Opened this issue · 3 comments
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
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.
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 inI 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?