Added feature for creating home directory

[benedicteb]

It seems like the home directory doesn't get created by default and I saw you'd created #17. Since we have many who'd like to be able to log in via the GUI or with su I've added a checkbox «Create home directory» which simply adds

/usr/sbin/createhomedir -b -u "_USERNAME_"

to the postinstall-script after flushing of the ds-cache. Tested on two 10.11-systems.

I've tried to follow your code style but in create_package.py I needed to switch a set with a list since order was important. I hope this is useful.

[benedicteb]

[MagerValp]

Nice, it's an oft requested feature. I'll check out your implementation tomorrow when I'm back in the office.

Two questions though: does this work all the way back to 10.5, or at least 10.7? Does it work when including the package e.g. in an AutoDMG workflow?

[benedicteb]

Cool!

does this work all the way back to 10.5, or at least 10.7?

I've found some old articles, for example this suggesting that createhomedir also exists as far back as 10.5, however that should really be tested. Might be it behaves differently. I can fire up some virtual machines with older OS'es tomorrow and give you a report.

Does it work when including the package e.g. in an AutoDMG workflow?

I haven't tested that either. I can't think of any reason it shouldn't, so long as the postinstall-script is run. But I can test that tomorrow as well.

[benedicteb]

I have managed to test it on 10.7, 10.8 and 10.9. It works well. I don't have a 10-5 system available. Do you?

It does not work when included in an AutoDMG-image. Probably because createhomedir works on the host OS and not the image. I've tried circumventing this by removing createhomedir and instead copying the user template and setting permissions.

    /bin/cp -R "$3/System/Library/User Template/English.lproj" "$3/Users/_USERNAME_"
    /usr/sbin/chown -R _USERNAME_:staff "$3/Users/_USERNAME_"

Which works when installing on the host OS. However changing the permissions of the files to the newly created user won't work in AutoDMG since the user doesn't exist while the host-OS is running I assume?

Even when removing the chown-line AutoDMG won't copy the files to /Users/_USERNAME_. Might be I'm not completely read up on how AutoDMG works. Should I spend some more time trying to make it work with AutoDMG?

[MagerValp]

10.5/10.6 support is in no way critical at this point, so 10.7+ is fine, thanks for testing it.

Support for installation in images and on unbooted systems is vital though, there are a lot of people that use the packages that way. Copying the user templates manually instead of with createhomedir is of course another approach, but as you noticed there are a lot of pitfalls. The failing chown can be solved by exposing a _UID_ placeholder since numeric IDs will work even if the user hasn't been created. cp also needs the -p flag to preserve the ACLs when copying.

However, I'm not comfortable with hard coding home directories to English.lproj, but I can't think of a strategy to select which language to use. There's also the Non_localized folder which I'm not sure when to use. Do you have any ideas on how to tackle that?

[benedicteb]

I've gotten it to work with both AutoDMG and a live-booted system by copying the user template and using chown with the UID of the new user. Tested and worked with creating a 10.11 image and installing it via DeployStudio.

However it copies the English.lproj which I agree is bad. I have no ideas off the top of my head on how else to do this. But I can look into it.

Am I right to assume that the system creating the pkg might have different languages than the system installing the pkg? Maybe a search through the User Template directory from the postinstall-script and if not the same language as the one used on the host system (which created the pkg) is found, use the default English.lproj? I'll do some googling if you don't have any specific opinions.

[marrkkuu]

Maybe defaults read ${TARGET}/Library/Preferences/.GlobalPreferences.plist OR or provide a UI option for people to specify if they wish?

In my use case I deploy CreateUsers to a system as a local admin user. The system auto boots for post imaging. During the latter phase we offer options for localisation depending on the machine location but the local account stays in English.

On Tue, Feb 23, 2016, 5:47 PM Benedicte Emilie Brækken < notifications@github.com> wrote:

I've gotten it to work with both AutoDMG and a live-booted system by copying the user template and using chown with the UID of the new user. Tested and worked with creating a 10.11 image and installing it via DeployStudio.

However it copies the English.lproj which I agree is bad. I have no ideas off the top of my head on how else to do this. But I can look into it.

Am I right to assume that the system creating the pkg might have different languages than the system installing the pkg? Maybe a search through the User Template directory from the postinstall-script and if not the same language as the one used on the host system (which created the pkg) is found, use the default English.lproj? I'll do some googling if you don't have any specific opinions.

— Reply to this email directly or view it on GitHub https://github.com/MagerValp/CreateUserPkg/pull/47#issuecomment-187628136 .

[benedicteb]

Thanks marrkkuu! My system says

aiaiai:~ root# defaults read /Library/Preferences/.GlobalPreferences.plist AppleLanguages
(
    no
)

And

/System/Library/User\ Template/no.lproj/

does exist. Maybe try that first but also add an if-check that returns English.lproj if the first doesn't exist?

[marrkkuu]

Give a few mins, I will kick start my 3 test macs (10.11/10.10/10.9) and tell you exactly what I see. I vaguely remember Apple changing things across major versions when it comes to Locale settings.

On Tue, Feb 23, 2016 at 6:04 PM Benedicte Emilie Brækken < notifications@github.com> wrote:

Thanks marrkkuu! My system says

aiaiai:~ root# defaults read /Library/Preferences/.GlobalPreferences.plist AppleLanguages ( no )

And

/System/Library/User\ Template/no.lproj/

does exist. Maybe try that first but also add an if-check that returns English.lproj if the first doesn't exist?

— Reply to this email directly or view it on GitHub https://github.com/MagerValp/CreateUserPkg/pull/47#issuecomment-187633649 .

[marrkkuu]

There are several parts to locale. (Forgetting the existence of any users or user homes for a moment). The files below seem to affect the default settings for ¨new users.

Language & Regional Settings /Library/Preferences/.GlobalPreferences.plist

Keyboard Input /Library/Preferences/com.apple.HIToolbox.plist

Keyboard Input (Login Window) /var/tmp/com.apple.HIToolbox.loginwindow.plist

For a "VANILLA" OS install created with AutoDMG not adding any custom packages.....

_/var/root_/Library/Preferences/.GlobalPreferences.plist

• Does not seem to have any bearing on NEW users default settings.

• Contains the following values on first boot;

  AppleLanguages = ( en );

• After Setup Assistant is run, this plist value is deleted.

/Library/Preferences/.GlobalPreferences.plist

• This guy seems to be the main driver of default settings for new users.

• Contains the following values on first boot;

  AppleLanguages = ( en );

• After Setup Assistant is run, this plist value changes to;

  AppleLanguages = ( en, fr, de, "zh-Hans", "zh-Hant", ja, es, it, nl, ko, "pt-BR", "pt-PT", da, fi, nb, sv, ru, pl, tr, ar, th, cs, hu, ca, hr, el, he, ro, sk, uk, id, ms, vi, "es-MX" ); AppleLocale = "en_AU"; Country = AU;

• This plist has changed through different major os releases.
• prior to 10.11 you had to set AppleMeasurementUnits and AppleMetricUnits values in this file. But now it seems if AppleLocale and Country are set correctly, 10.11 will fill these values automatically into each /Users/xxxx/Library/Preferences/.GlobalPreferences.plist file.

/Library/Preferences/com.apple.HIToolbox.plist

• Doesn't exist on first boot, only after initial Setup Assistant is run.

_/var/tmp/_com.apple.HIToolbox.loginwindow.plist

• Doesn't exist on first boot, only after initial Setup Assistant is run.

On Tue, Feb 23, 2016 at 6:42 PM Chris Gerke chris.gerke@gmail.com wrote:

Give a few mins, I will kick start my 3 test macs (10.11/10.10/10.9) and tell you exactly what I see. I vaguely remember Apple changing things across major versions when it comes to Locale settings.

On Tue, Feb 23, 2016 at 6:04 PM Benedicte Emilie Brækken < notifications@github.com> wrote:

Thanks marrkkuu! My system says

aiaiai:~ root# defaults read /Library/Preferences/.GlobalPreferences.plist AppleLanguages ( no )

And

/System/Library/User\ Template/no.lproj/

does exist. Maybe try that first but also add an if-check that returns English.lproj if the first doesn't exist?

— Reply to this email directly or view it on GitHub https://github.com/MagerValp/CreateUserPkg/pull/47#issuecomment-187633649 .

[MagerValp]

Having thought a bit about this, I think it's best to use the current locale of the application when the package is created. The assumption is that the locale you're using when creating the package is the locale that you expect when logging in to your deployed account. It also gives you implicit control as you can set the locale via System Preferences before creating a package.

Thinking a bit ahead, my original intent with issue #17 was to add the home directory to the static payload of the package, rather than dynamically creating it in the postinstall script. By locking down the locale at creation time it wouldn't change the behavior of packages if home directory customization is added.

[benedicteb]

I agree to your point about locale. However I still think we need a more precise method of getting the appropriate user template from the locale. I've found that some of my systems have the language set to nb as well while the user template is no.lbproj so I don't think the .GlobalPreferences.plist can be used directly.

And yes, adding the home directory to the static payload is a very good idea (it would also make it easier to let users add files like ssh-keys ++ as well later), and shouldn't be too difficult to implement. But doesn't it require root privileges to copy the user template?

[marrkkuu]

I haven't been able to find any documentation from Apple on this. For me it was trial and error.

You would get cases where the language is English but the Users are using CA.lproj too.

I believe the best approach is to use the AppleLocale variable (checking the first two chars) and writing your own logic for those countries that need it.

On Tue, Feb 23, 2016, 10:58 PM Benedicte Emilie Brækken < notifications@github.com> wrote:

I agree to your point about locale. However I still think we need a more precise method of getting the appropriate user template from the locale. I've found that some of my systems have the language set to nb as well while the user template is no.lbproj so I don't think the .GlobalPreferences.plist can be used directly.

And yes, adding the home directory to the static payload is a very good idea (it would also make it easier to let users add files like ssh-keys ++ as well later), and shouldn't be too difficult to implement. But doesn't it require root privileges to copy the user template?

— Reply to this email directly or view it on GitHub https://github.com/MagerValp/CreateUserPkg/pull/47#issuecomment-187729829 .

[MagerValp]

Just wanted to apologize for the lack of updates from me here. I'm home with a cold, but hopefully I'll be back in the office tomorrow.

[MagerValp]

Finally back, sorry about the delay.

I did a code review, and the only showstopper is that the homedir path is configurable, so another placeholder (e.g. HOMEDIR) needs to be put in the postinstall script, rather than /Users/USERNAME.

As a usability note I think that maybe the checkbox should be labeled Pre-create home directory, to make it clearer that the home directory will be created as usual on first login even if you leave it unchecked.

[MagerValp]

Good catch on the User Template only being accessible by root, d'oh. The app is sandboxed too.

Thanks for the assist on locale digging @marrkkuu. I think @pudquick messed around a bit with that a few months ago too, maybe he has suggestions.

[MagerValp]

Oh, and in my excitement over getting a pull request for this long neglected project I forgot ask the all important question: what's the benefit of precreating the homedir in the package? As a stepping stone towards adding customization it makes obvious sense, but is there a scenario today where creating the homedir at installation time rather than at first login solves a problem?

[benedicteb]

Thanks for the followup! I hope you're feeling better :)

I'm about to commit the changes for fixing the things you pointed out.

We wished for this feature because we were experiencing that the home directory wasn't created at all. The user couldn't be logged in to via su nor through the GUI and if we logged in with SSH it would complain that it couldn't chdir to home directory. We then noticed that if we created the home directory from some other root user and then trying the log-in again it would work. This isn't default behaviour?

[marrkkuu]

I can't see one.

I think the most obvious reason to do this would be to add files or customizations to your created user. But wouldn't you do this with another package, profile, lauchagent ? On Fri, Feb 26, 2016, 8:46 PM Per Olofsson notifications@github.com wrote:

Oh, and in my excitement over getting a pull request for this long neglected project I forgot ask the all important question: what's the benefit of precreating the homedir in the package? As a stepping stone towards adding customization it makes obvious sense, but is there a scenario today where creating the homedir at installation time rather than at first login solves a problem?

— Reply to this email directly or view it on GitHub https://github.com/MagerValp/CreateUserPkg/pull/47#issuecomment-189260771 .

[MagerValp]

ssh logins is an excellent point, thanks!

[marrkkuu]

I must be missing something. I can ssh login prior to the homedir creation, and although it complains about chdir it's more of an annoyance than problem, unless you have to deal with private keys?

On Fri, Feb 26, 2016, 9:07 PM Per Olofsson notifications@github.com wrote:

ssh logins is an excellent point, thanks!

— Reply to this email directly or view it on GitHub https://github.com/MagerValp/CreateUserPkg/pull/47#issuecomment-189265999 .

[benedicteb]

SSH works. But does it work via the GUI or via su - localadmin?

[benedicteb]

Hah, it seems I never tested this enough. su doesn't work. But the GUI works. So yeah, I guess I can say this isn't too useful. Would you like me to write the feature for populating the home directory with custom files without merging this? ;)

[MagerValp]

su flat our refuses when there's no homedir, but login works (with the same warning as ssh).

And if you have ideas for #17 I'm all ears, every design that I've thought up is horribly complex and way beyond my meager Cocoa skills.

[marrkkuu]

It would be ugly and maybe buggy, but a self destructing launch daemon?

On Fri, Feb 26, 2016, 9:31 PM Per Olofsson notifications@github.com wrote:

su flat our refuses when there's no homedir, but login works (with the same warning as ssh).

And if you have ideas for #17 https://github.com/MagerValp/CreateUserPkg/issues/17 I'm all ears, every design that I've thought up is horribly complex and way beyond my meager Cocoa skills.

— Reply to this email directly or view it on GitHub https://github.com/MagerValp/CreateUserPkg/pull/47#issuecomment-189274728 .

[marrkkuu]

Or maybe /etc/rc.installer_cleanup if you wanted it to happen early in the boot process

On Fri, Feb 26, 2016, 9:39 PM Chris Gerke chris.gerke@gmail.com wrote:

It would be ugly and maybe buggy, but a self destructing launch daemon?

On Fri, Feb 26, 2016, 9:31 PM Per Olofsson notifications@github.com wrote:

su flat our refuses when there's no homedir, but login works (with the same warning as ssh).

And if you have ideas for #17 https://github.com/MagerValp/CreateUserPkg/issues/17 I'm all ears, every design that I've thought up is horribly complex and way beyond my meager Cocoa skills.

— Reply to this email directly or view it on GitHub https://github.com/MagerValp/CreateUserPkg/pull/47#issuecomment-189274728 .

[benedicteb]

Maybe it'll be a bit more tedious than I first thought. Anyway I think I'll comment on #17 or open a new PR if I've come up with something.

You can go ahead and close this if you want. Without taking locale into account I think it's finished. So it kind of depends on whether or not this is actually useful and in keeping of how you'd like the app to work :)

[MagerValp]

Definitely want to keep, merged into a branch called precreatehome to close this PR.