Managedmac::Sshd errors

[leafmulch]

Hi hopefully you can help and I apologise if logging an issue here is premature, as I'm fairly new to this stuff. After a lot of time figuring out how to get managedmac to work from my puppetmaster (linux) to my mac agent - I had to run puppet agent -t on the master so it'd copy modules to /var/lib/puppet//lib/puppet/managedmac still confused by that - I've hit a snag enabling ssh in my Darwin.yaml file.

managedmac::sshd::enable: true

Error: undefined method to_i' for :absent:Symbol Error: /Stage[main]/Managedmac::Sshd/Macgroup[com.apple.access_ssh]/gid: change from absent to 399 failed: undefined methodto_i' for :absent:Symbol Error: /Stage[main]/Managedmac::Sshd/Macgroup[com.apple.access_ssh]: Could not evaluate: Execution of '/usr/sbin/dseditgroup -q -o edit -i 399 com.apple.access_ssh' returned 64: GID already exists Warning: /Stage[main]/Managedmac::Sshd/Service[com.openssh.sshd]: Skipping because of failed dependencies

OS X 10.9.2 puppet v3.7.1 ruby 2.0

I've also tried to provide a full sshd_config, explicitly define users and groups etc. but this seems related to the dseditgroup command only.

Thanks,

Jes.

[dayglojesus]

The managedmac::sshd class contains a Macgroup resource "com.apple.access_ssh". Have a look... https://github.com/dayglojesus/managedmac/blob/master/manifests/sshd.pp#L137-L143

This is the ACL group for SSH access. The group becomes managed by Puppet when you set: managedmac::sshd::enable: true.

As you can see, the GID for this group is set to 399 which, at the time the code was written, was what I determined to be the OS X default GID for this group.

I am not sure why you are seeing this error, but it is probably because the GID 399 belongs to another group for some reason. See the comment here... https://github.com/dayglojesus/managedmac/blob/master/lib/puppet/provider/macgroup/default.rb#L141-L151

What is the output of this command? dscl . -search /groups gid 399

And this one? dscl . -read /groups/com.apple.access_ssh gid

[leafmulch]

Thanks for looking into this. I'm still unsure how to proceed, as this is a fresh install - albeit with my turning on some services such as vnc and ssh. I'm getting my manifests/modules from the puppetmaster - I don't know if that affects things, as I said earlier I had some issues to begin with. Here's the outputs you requests:

bash-3.2# dscl . -search /groups gid 399
com.apple.access_ssh-disabled       dsAttrTypeNative:gid = (
    399
)
bash-3.2# dscl . -read /groups/com.apple.access_ssh gid
No such key: gid

and although you didn't ask for it I noticed:-

bash-3.2# grep 399 /etc/group
com.apple.access_ssh:*:399:

[dayglojesus]

Strange. I will be honest, I am not sure whether to classify this as a bug or an edge case. I have never had this issue.

When you say it's a "fresh install", how fresh is it? Did you run the OS X setup and create a user manually? Did you ever toggle any of the service preferences panes for SSH, ARD or Screen Sharing?

[leafmulch]

Hi - the initial config of this test machine involved somebody creating an admin account from the console via a kvm switch and then went onto switch on both ssh and screen sharing for vnc access. After this I was able to login and install puppet and start accepting manifests. I've been able to create users, groups and install java and xcode etc.

Can you advise on how to reset the playing field? We are not that experienced with Macs so don't have any early automation to switch on services, so we can access the machine other than via the console. Hope to get there soon, though.

[dayglojesus]

Okay. I think I understand what's happening.

Have a look at this... http://superuser.com/questions/166179/how-to-enable-remote-access-for-another-account-on-mac-remotely-via-ssh

If you just wanna move on and get it working, do this...

sudo dscl . delete /groups/com.apple.access_ssh-disabled

Then run puppet agent -t. That should fix the issue in this case.

However, this is not a condition the managedmac::sshd class has any contingency for.

Should it? Probably, I will look into it.

[leafmulch]

I had to give this a go before heading to bed! Thanks so much for getting back so frequently. I'm pleased to say that following your advice it is now working, as it should. Strangely, immediately after I ran the dscl command the first run attempt gave the same error, but subsequent runs have been as hoped. In other words I can disable and enable the sshd service to my heart's content.

I'm not sure what the conditions are that we found ourselves in this pickle - but if I figure that part out I'll let you know. Thanks for your help!

[dayglojesus]

Finally looking at this and I realize that your report exposes a hitherto undocumented and perhaps undesirable behaviour in the Macgroup provider. I have opened a new issue (#43) that describes this.

In the meantime, I will publish a patch for this particular edge case, and close the issue.

Because I see the potential for this to be a point of confusion for others, I am resubmitting the issue as a request for enhancement, issue #44.

Thanks for your report!

[dayglojesus]

fixed in 0.5.6