Skeleton User Accounts

If you're going to have any significant number of users on your machine (or machines), you'll soon find that being able to provide a more customized environment than what comes out of the Accounts system preference pane by default is a benefit.

Apple has provided a convenient tool you can use to perform some customization of accounts as created by the Accounts control pane. This is the inclusion of a User Template directory, from which the accounts made by the pane are created by duplication. The family of User Template directories, individualized by locale, are kept in /System/Library/User Template . This system works for simple configuration settings that you might like to configure for each newly created user, but it has some limitations if you'd like to work with more complex setups. The largest logical limitation is that if you're trying to set up complicated startup scripts and sophisticated environment settings, using a real user account as your default template is nice, because then you can log in for testing and tweaking. The largest practical limitation is that Apple has put the default templates in the /System/ hierarchy, where they're Apple-sacrosanct (Apple can modify this directory as they please ), and system updates are likely to tromp on any customizations that you might make.

The easiest way to solve all the problems at once is to create a skeleton user account as a real user account, and to keep it up to date with any environmental customizations that you want to provide for new users when you create accounts. If you create the skeleton user as simply another user account, you can log in to it and then conveniently tweak its settings. Using this method, you can create as many skeleton accounts as you need for different collections of settings.

Even if you prefer to use the Accounts control pane, the creation of skeleton users as real users on the system can be useful for you. You can configure skeleton users, log in for testing, and then populate the /System/Library/User Template directories (if you don't mind incurring the wrath of the Apple installers ), as required for customizing the configuration of users under the Users pane. Alternatively, you can create the accounts with Apple's default templates, and then overwrite the actual user directories with data from your skeleton account.

Every user's shell environment is configured by the .login and . cshrc (presuming you're using the tcsh or csh shell) scripts in the user's home directory. You might also want to provide a more customized starter Web page or assorted bits of default data.

After you configure an account in the fashion you'd like your new users to have, the hard part is done. It would be nice to have a way to use this account directly from the Users pane as the seed for new accounts as they are created, but unfortunately , we aren't yet so lucky. Instead, you have two options for how to use the starter account information. First, you can create a new user through the Accounts control pane. After the account is created, you can replace the user's home directory (that the Accounts control pane created) with a copy of the skeleton account home directory.

Your other option is to ignore the Accounts control pane, and create a new user by duplicating an existing user node from the NetInfo hierarchy, making a copy of the skeleton account home directory for the new user's home directory, and then editing the copy of the NetInfo entry for the new user to reflect the correct information for that user.

The first option is probably easier, but the second has the benefit of being something you can do from the command line with nidump and niload , and therefore, of being automatable.

For the rest of the discussion, it will be assumed that you've created a skeleton account in which you have made any customizations that you want to install for all new users. The account UID will be assumed to be 5002, with a home directory of /Users/skel and a GID of 99. It will also be assumed that you've added the group users to your NetInfo groups directory, with a GID of 99, and that you want to use this GID for normal, nonprivileged users.

To implement the first method of providing local customization for a new user, follow these steps:

Create the new user with the Accounts control pane. Make any necessary changes to the user's configuration, such as the default GID , using NetInfo Manager as shown in Chapter 9, "Everything Else."
Become root ( su , provide password).
Change directories to the skeleton user's directory ( cd ~skel ).
tar the contents of the current directory, using the option to place the output on STDOUT ( tar -cf - . ) and then pipe the output of tar into a subshell. In the subshell, cd to the new user's directory, and untar from STDIN ( ( cd ~ <newusername> ; tar -xf - ) ). The complete command is tar -cf - . ( cd ~ <newusername> ; tar -xf - ) .
Change directories to one level above the new user's directory ( cd ~ <newusername> ; cd ../ ).
Change the ownership of everything in the new user's directory to belong to the new user and, potentially , to the user's default group if it's not the same as the skel account default group ( chown -R <newusername> : <newusergroup> <newuserdirectoryname> ).

For example, if you've just created a new user named jim , assigned to the group users with the Accounts control pane/NetInfo Manager, and want to put the skel account configuration into jim 's home directory, you would enter the following:

 su  (provide password)  cd ~skel tar -cf - .  ( cd ~jim ; tar -xf - ) cd ~jim cd ../ chown -R jim:users jim

If you'd rather create new users from the command line, either because you can't access the physical console conveniently or because you want to use what you know about shell scripting to automate the process, you can use the second method suggested earlier. You might find this method more convenient for creating users in a NetInfo domain other than localhost/local . The Accounts preference pane in the nonserver version of OS X seems incapable of creating users in other NetInfo domains, and this makes using it for managing cluster users difficult.

CAUTION

This process creates a new user by manipulating the NetInfo database directly, so you should remember to back up your NetInfo database directory ( /private/var/db/netinfo ) regularly.

To implement the second method, follow these steps:

Become root ( su , give password).
Change directories to the directory in which you'd like to place the new user's home directory ( cd /Users , for example).
Make a directory with the short name of the user you're about to create ( mkdir <newusername> to create a directory for a new user named <newusername> ).
Change directories to the home directory of the skel account ( cd ~skel ).
tar the contents of the current directory, and use the option to place the output on STDOUT ( tar -cf - ).
Pipe the output of the tar command into a subshell. In the subshell, cd to the new user's directory, and untar from STDIN ( ( cd <pathtonewuserdirectory> ; tar -xf - ) ). Note that you can't use ~ <newusername> because <newusername> doesn't actually exist on the system yet. The entire command syntax is tar -cf - . ( cd <pathtonewuserdirectory> ; tar -xf - ).
Dump your skel account ( UID 5002 here, remember) NetInfo entry, or some other user's entry, into a file that you can edit ( nidump -r /name=users/uid=5002-t localhost/local > ~/ <sometempfile> ). As an alternative to the uid search, you could specify the skel account with /name=users/name=skel .
Edit ~/ <sometempfile> , changing the entries so that they are appropriate for the new user you want to create. You'll want to change at least _writers_passwd , _writers_tim_password , uid , _writers_hint , _writers_picture , gid , realname , name , passwd , and home . It's probably easiest to leave passwd blank for now.
Use niutil to create a new directory for the uid that you've picked for the new user ( niutil -p -create -t localhost/local /name=users/uid= <newuserUID> ; give the root password when asked).
Use niload to load the data you modified in ~/ <sometempfile> back into the NetInfo database ( cat ~/ <sometempfile> niload -p -r /name=users/uid= <newuserUID> -t localhost/local ).
Set the password for the new user ( passwd <newusername> ; ). Provide a beginning password.
Change back to the directory above the new user's home directory ( cd ~ <newusername> ; cd ../ ).
Change the ownership of the new user's directory to the new user's <newusername> and <defaultgroup> ( chown -R <newusername> : <defaultgroup> <newuserdirectory> ).

If you've made a mistake somewhere along the way, just restore your NetInfo database from the backup that you made before you started this. You also might need to find the nibindd process, and send it an HUP signal ( ps -auxww grep "nibindd"; kill-HUP <whatever PID belongs to nibindd> , or killall -HUP nibindd , if you prefer to do things the easy way).

CAUTION

Resource forks get lost in the tar !

The BSD tar distributed by Apple doesn't understand file resource forks, and some software vendors haven't caught on to the idea of using plists properly yet. The unfortunate consequence is that if you've built a highly customized skeleton user (or are trying to use these steps as an example of how to move a real user account), and some of the user's preferences are stored in the resource fork of the preference files, tar is going to make a mess of things when you use it to duplicate the user's directory to the new location.

To overcome this problem, you currently have two options:

Metaobject has developed hfstar , a GNUtar derivative that supports HFS+, allowing it to properly handle resource forks, type and creator codes, and so on. GNUtar is functionally very similar to BSD tar , but the differences that do exist are significant enough that you won't want to simply replace the tar that Apple provides with the hfstar from metaobject. Instead, it'd be better to keep them both around, and use them for their respective strengths. metaobject's hfstar can be downloaded from http://www.metaobject.com/Community.html#hfstar.
Use Apple's already supplied ditto command. ditto doesn't provide nearly the power of tar , but it'll do for copying user directories.

To produce results similar to those from the first method earlier, the following example creates a new user with the username of james , UID 600 , GID 70 , with home directory /Users/james . This again assumes the skel account with UID 5002 and characteristics as described earlier. (Comments or instructions are shown in italics.)

  su  (  provide the password  ) cd /Users mkdir james cd ~skel tar -cf - .  ( cd /Users/james ; tar -xf - ) nidump -r /name=users/uid=5002 -t localhost/local > ~/skeltemp vi ~/skeltemp

Then, in vi , change the contents from this:

 {   "authentication_authority" = ( ";basic;" );   "picture" = ( "/Library/User Pictures/Nature/Zen.tif" );   "_shadow_passwd" = ( "" );   "hint" = ( "Urusei!" );   "uid" = ( "5002" );   "_writers_passwd" = ( "skel" );   "realname" = ( "skeleton account" );   "_writers_hint" = ( "skel" );   "gid" = ( "99" );   "shell" = ( "/bin/tcsh" );   "name" = ( "skel" );   "_writers_tim_password" = ( "skel" );   "passwd" = ( "AtbvqXhZrKJ7A" );   "_writers_picture" = ( "skel" );   "home" = ( "/Users/skel" );   "sharedDir" = ( "Public" ); }

to this:

 {   "authentication_authority" = ( ";basic;" );   "picture" = ( "/Library/User Pictures/Nature/Zen.tif" );   "_shadow_passwd" = ( "" );   "hint" = ( "boggle" );   "uid" = ( "600" );   "_writers_passwd" = ( "james" );   "realname" = ( "Sweet Baby James" );   "_writers_hint" = ( "james" );   "gid" = ( "70" );   "shell" = ( "/bin/tcsh" );   "name" = ( "james" );   "_writers_tim_password" = ( "james" );   "passwd" = ( "" );   "_writers_picture" = ( "james" );   "home" = ( "/Users/james" );   "sharedDir" = ( "Public" ); }

Now load the skeleton into NetInfo:

 #  niutil -p -create -t localhost/local /name=users/uid=600  #  cat ~/skeltemp  niload -p -r /name=users/uid=600 -t localhost/local  #  passwd james  (fill in a good starting value)  #  cd ~james  #  cd ../  #  chown -R james:www james (  GID 70 is group www on this machine  )

NOTE

Depending on whether your NetInfo daemon is feeling well, you might have to HUP the nibindd process ( killall -HUP nibindd ) to get it to recognize that you've made the change. Remember that you can always restore your NetInfo database backup to get out of a mess, if you've created one.

TIP

If you need to delete a user account from the command line, you can destroy the NetInfo information for the user by using the command niutil -p -destroy -t localhost/local /name=users/uid= <userUIDtobedeleted> . Then rm -rf the user's home directory to delete it and all of its contents from the system.

Just to make sure that your user has been created as you think it should have been, you can use niutil to list the /users NetInfo directory. (Don't be surprised if your listing doesn't look quite like thisthis is simply the list of users configured on my machine, so your users are likely to be different.)

 [localhost:/Users/ray] root#  niutil -list -t localhost/local /users  2        nobody 3        root 4        daemon 5        unknown 6        www 154      joray 166      miwa 161      ray 163      software 171      nomad 173      ftp 174      marvin 175      skel 177      bin 179      betty 181      ralph 184      james

As shown, james does now exist in the NetInfo /users directory, although this listing shows only the NetInfo node numbers , rather than the users and property values. To see whether james has the properties intended, you can use niutil to read the info from the node named james :

 [localhost:/Users/ray] root#  niutil -read -t localhost/local /users/james  authentication_authority: ;basic; picture: /Library/User Pictures/Nature/Zen.tif _shadow_passwd: hint: boggle uid: 600 _writers_passwd: james realname: Sweet Baby James _writers_hint: james gid: 70 shell: /bin/tcsh name: james _writers_tim_password: james passwd: aynyjRMfGyH7U _writers_picture: james home: /Users/james sharedDir: Public

Top