1046877 - DS-installed Administrator password is the old KS password

Status: RESOLVED WONTFIX

(Infrastructure & Operations :: RelOps: General, task)

Description

[Dustin J. Mitchell [:dustin] (he/him)]

Amy, we didn't finish this off in IRC, but should.

During install, DeployStudio should set the kickstart root password.  I think you found that it didn't set the *Administrator* password correctly?

Comment 1

[Amy Rich [:arr] [:arich]]

I installed r5-mini-002 as part of bug 1046306. Since it didn't have a puppet entry, there was nothing to change the password. When I tried to connect, I couldn't log in as root (current KS pw didn't work), so I screen shared in as administrator with the old (previous) KS password. So I believe it's hardcoded in the image and not modified as part of the DS install.

Comment 2

[Dustin J. Mitchell [:dustin] (he/him)]

It looks like it's the Administrator account, in particular.  I can't login via SSH as root.

Comment 3

[Jake Watkins [:dividehex]]

First of all, I'm sure the Administrator account and password are baked into the image.  It has always been a requirement of the install process to add an Administrator account and login for the first time.  This is primarily to agree to the EULA. You know, where you sign over your first born to Apple. So that gets captured when building any of the OSX base images.  During the Deploy Studio restore workflow there is a script that enables and sets the root password but not the Administrator account since we have always removed Administrator account in the subsequent puppet run.  Although, with new OSX versions (10.9 and 10.10) it is starting to look like the Administrator account is critical to operation of the OS.  We might want to think about changing this to ensure => present and maintaining the password in puppet.  As for the root kickstart password, I did notice the kickstart password was current in a new script called 'enable_root_kickstart.sh' but all the workflows were pointing at the old 'enable_root.sh' script.  I've corrected all the workflows on install.test.releng.scl3 and I'll need to check install.build.releng.scl3 also.

If we decide to start keeping the Administrator account around, it might be wise to also set the password during the restore workflow.  That way we can ensure it is not using old passwords and we could VNC in (pre-puppet run) since the root account only allows ssh login not VNC.

Deploystudio has the facility to create user account at the end of a restore workflow.  If we go this route, it might require an upgrade to deploystudio to support newer versions of OSX.  We are definitely some old versions.  The other option is to script it and drop it in the workflow.

Comment 4

[Jake Watkins [:dividehex]]

install.build.releng.scl3 was in the same predicament of having the correct password but none of the workflows referenced the updated script name.  I've changed all the workflows and delete the obsolete script.

Comment 5

[Dustin J. Mitchell [:dustin] (he/him)]

For 10.9 at least, we have ensure => present for 'administrator', and are setting the same pw as root.  We could probably do the same for all versions.

Comment 6

[Jake Watkins [:dividehex]]

Attachment: 1046877-1.patch

ensures administrator account is enabled across the board on OSX versions 10.6 to 10.10 and uses the 'user' resource for all.

Comment 7

[Jake Watkins [:dividehex]]

Comment on attachment 8488747 [details] [diff] [review]
1046877-1.patch

remote:   https://hg.mozilla.org/build/puppet/rev/ed862428ec39
remote:   https://hg.mozilla.org/build/puppet/rev/9eede4dfe908

Comment 8

[Jake Watkins [:dividehex]]

Comment on attachment 8488747 [details] [diff] [review]
1046877-1.patch

I had to back this out.  As Dustin pointed out via irc, different versions of OSX require different hash types and options.

Comment 9

[Amy Rich [:arr] [:arich]]

Okay, just had another run-in with DS so I can give more info here. On the following operating systems, I was unable to log in as EITHER root or Administrator with the current kickstart password (the one in the DS script).  I was subsequently able to log in as BOTH root and Administrator with an older version of the password (whatever was part of the image that got created):

10.9.0
10.6.<whatever we're running>

And later I expect the same will apply to 10.8 when I attempt to restore that as well.

I've set the administrator and root passwords on the new image I'm taking of 10.9.5 to be the current kickstart password and I'm setting the hint to indicate that it's the kickstart password (and include today's date).

Comment 10

[Amy Rich [:arr] [:arich]]

And on 10.8. I'm nt sure if this script actually works anywhere.

Comment 11

[Jake Watkins [:dividehex]]

While working on injecting changes into nbi sets, it dawned on my that it could be possible do the same for base builder and test images.  This would resolve the issue of having to know the passwd on the base image in order to change it post deployment.

Comment 12

[Amy Rich [:arr] [:arich]]

We don't have cycles to work on this.