From: Greg Ercolano <erco@(email surpressed)>
Subject: [OSX/SYSADMIN] Example NFS setup for Rush on a small 'pure OSX' network
   Date: Mon, 22 May 2006 16:03:38 -0400

        ** SETTING UP AN NFS SERVER ON OSX/TIGER (NON-SERVER OSX) **

SITUATION
---------
Let's say you want to set up Rush quickly on a small network of (20) OSX machines:

        o All machines are running regular OSX (ie. no "OSX Server")

        o Each machine configured with one or more local user accounts,
          each with either the same or different user names

        o uid/gid values were assigned haphazardly; different users are sometimes
          sharing the same uid across machines, or the same user account might have
          different uids on some machines.

Due to time pressure, lets say you don't want to clean up the uid/gid mess,
but still want to get things up and running with Rush and NFS quick+dirty+reliable.

POSSIBLE SOLUTION/DESIGN
------------------------
An easy thing to do is create a 'render' user on all machines with a unique uid,
then set up rush to force renders to run as that 'render' user, and set up the
NFS server to map all user access to the 'render' user.

This will avoid permission problems completely, and ensures everyone can
manipulate each other's data without permissions getting in the way.

STEPS TO SETUP
--------------

        1) On all machines, create the "render" user with a fixed UID/GID that
           doesn't conflict with any uid/gid on the network.

           This can be done easily by running the following script on each machine
           as root to create the 'render' account on each machine with the uid=555,
           gid=20, and the password set to 'render'. (Tested under OSX 10.4.x)

               ** UPDATE May 2009: In Leopard (10.5) Apple changed the commands for manipulating
               ** the user database; 'niload' -> 'dscl'. So for the newer OSX releases (Leopard and up)
               ** you'll need an updated version of the following script, which is here:
               ** http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+1839+1839

--- snip
#!/bin/csh -f
#
# make-render-user - Run this script to create the 'render' user on a machine
# 1.0 05/10/06 - erco@(email surpressed) - Supports Tiger (10.4), Panther (10.3)
#

set username = render                   # user's name
set      uid = 555                      # must be an unused uid
set      gid = 20                       # 20=staff
set   passwd = 'oFxbR2cAnG902'          # passwd is 'render'

# CREATE PASSWD ENTRY
echo ${username}:${passwd}:${uid}:${gid}::0:0:${username}:/Users/${username}:/bin/bash | niload passwd /

# CREATE USER'S HOME DIRECTORY
if ( ! -d /Users/${username} ) then
    cp -R '/System/Library/User Template/English.lproj' /Users/${username}
endif

# ENSURE OWNERSHIPS ASSIGNED TO USER'S ENTIRE HOME DIRECTORY
/usr/sbin/chown -R ${uid}:${gid} /Users/${username}
--- snip

           Just make sure 'rsh' is enabled on all machines:
           http://www.seriss.com/rush-current/misc/rsh-config.html#Mac

           ..then you can rcp the file to each machine and run it:

                foreach i ( host1 host2 host3 .. )
                    echo Working on $i
                    rcp makerender ${i}:/var/tmp
                    rsh $i csh /var/tmp/makerender
                end

        2) Enable NFS on the file server.

           Non-server versions of OSX have NFS services disabled by default, and in 10.4.x,
           there is no GUI way to enable/disable NFS services.

           NFS services are not started unless an /etc/exports file exists.
           On boot, if that file is found, the boot scripts automatically start
           the NFS server daemons.

           To configure NFS to export the /Volumes/RAID/jobs directory to all machines,
           such that all user access is mapped to the new 'render' account, you can use
           the following to a) create the /etc/exports file, b) chown the entire directory
           tree to be owned by render:staff, and c) reboot to get NFS started:

                echo '/Volumes/RAID/jobs -mapall=render:staff' > /etc/exports
                chown -R render:staff /Volumes/RAID/jobs
                reboot

           The NFS server should now be ready to be mounted by remote clients.

        3) Verify you can mount the NFS server from one of the clients:

                mkdir -m 777 /Volumes/jobs
                mount -t nfs -o intr,bg 192.168.0.3:/Volumes/RAID/jobs /Volumes/Jobs
                                        -----------
                                             |
                                             IP address of your NFS server

           ..you should then be able to view the files on the server with ls(1):

                ls -la /Volumes/jobs/

        4) Configure all the clients to mount the NFS server.

           An easy way to do this is to add the appropriate mount commands to eg.
           the rush boot script (/usr/local/rush/etc/S99rush) to ensure the mount
           is started /before/ the rush daemon starts.

           Just add these commands at the top of the 'start)' clause of the
           S99rush boot script:

---- snip
    # Mount the drive
    #     > Redirect errors to /var/log/system.log via logger(1)
    #     > When mounting the server, use its IP address, not its hostname.
    #       DNS is often not resolving right after a reboot.
    (
        if [ ! -d /Volumes/jobs ]; then
            echo "Creating /Volumes/jobs mount point"
            mkdir -m 777 /Volumes/jobs
        fi
        echo "Mounting /Volumes/jobs"
        /sbin/mount -t nfs -o intr,bg 192.168.0.3:/Volumes/RAID/jobs /Volumes/jobs
    ) 2>&1 | logger -t "JOB-MOUNT"
---- snip

           Just add the commands to one machine's S99rush script, test it,
           and when it works, just rcp(1) it to all the other machines:

                 foreach i ( host1 host2 host3 .. )
                     echo Working on $i
                     rcp /usr/local/rush/etc/S99rush ${i}:/usr/local/rush/etc/S99rush
                     rsh $i 'mkdir -m 777 /Volumes/jobs'
                     rsh $i '/sbin/mount -t nfs -o intr,bg 192.168.0.3:/Volumes/RAID/jobs /Volumes/jobs'
                 end

           This will install the script, and run the mkdir/mount commands to ensure
           the drive is mounted on each machine.

           ** UPDATE June 3, 2009: A better technique is to create your own
           ** OSX boot script, separate from Rush, using the techniques shown here:
           ** http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+1847

        5) Modify the /usr/local/rush/etc/rush.conf file to force Rush to run
           all renders as the 'render' user we created in step #1:

                forceuid 555
                forcegid 20

           Push these changes to the network with 'rush -push rush.conf +any'

        6) Submit a job from one of the workstations.

           The render should say its owned by the user who submitted the job,
           but the actual frames should run as the user 'render'. Files will appear
           on the disk owned by the user 'render', and all users will be able to
           access and manipulate these files without permission problems.

CAVEATS REGARDING THE ABOVE

   If you are working in a mixed OSX/Windows environment, you can use the
   following "symbolic link" technique to enable UNC paths to resolve your
   /Volumes mounts:
   http://www.seriss.com/rush-current/rush/rush-td-faq.html#TDFAQ-UNC2

   Or, you can configure your mount points to actually follow the UNC
   style naming directly, avoiding the need for symbolic links. OSX
   does not require that mounts be in /Volumes, that's just a default
   convention Apple uses.

   So for instance, if the Windows machines see your file server as:

   	//tahoe/bigdisk/

   ..then you can set up the OSX machines to mount the server as:

   ..via nfs, eg:

   	mkdir -m 755 /tahoe ; mkdir -m 777 /tahoe/bigdisk
	/sbin/mount -t nfs -o intr,bg tahoe:/RAID/bigdisk /tahoe/bigdisk
	                                                  ^^^^^^^^^^^^^^

   ..just change the mkdir/mount commands above accordingly. By default
   OSX puts mounts in /Volumes, but they don't have to be created there.

   This way the mounts will already have a name that follows UNC style
   without the need for the symlink technique.

   The reason to mount via NFS instead of SMB or AFP is described here:
   http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+1062+1062

Feel free to follow up to this thread with questions/comments.

I'd just like to say how useful this paper is. There's a load of stuff in
here that can take a someone new to rush and OSX an age to work out,
including the rather curious niload :) 
About the only thing not mentioned is the DNS side of things and the rush
hosts file.
I notice that you use intr,bg as NFS mount options. Did you come to these
through trail? I have generally been using hard mounts for NFS.

Cheers!!

Dylan

|-----Original Message-----
|From: Greg Ercolano [mailto:erco@(email surpressed)]
|Sent: Tuesday, 23 May 2006 6:04 AM
|Subject: [OSX/SYSADMIN] Example NFS setup for Rush on a small 'pure OSX' network
|
|[posted to rush.general]
|
|         ** SETTING UP AN NFS SERVER ON OSX/TIGER (NON-SERVER OSX) **
|
|SITUATION
|---------
|Let's say you want to set up Rush quickly on a small network of (20) OSX
|machines:
|
|         o All machines are running regular OSX (ie. no "OSX Server")
|
|         o Each machine configured with one or more local user accounts,
|           each with either the same or different user names
|[..]

Dylan Penhale wrote:

[posted to rush.general]

I'd just like to say how useful this paper is. There's a load of stuff in
here that can take a someone new to rush and OSX an age to work out,
including the rather curious niload :)

	Yeah, it's a compilation of various experimentation, and input
	from others. (Thanks to Robert Minsk for the one line passwd approach
	to adding a user)

About the only thing not mentioned is the DNS side of things and the rush
hosts file.

	Right -- I didn't go there because the rush stuff is covered in
	install docs which are subject to change for different releases of rush.

	I guess I should cover the DNS stuff -- I'll try to follow up with that.
	One thing that should help get DNS off the ground easily is this neat little
	perl script I wrote recently that sets up DNS for you based on an /etc/hosts
	file. It works on 10.3.x and 10.4.x, check it out:

	http://seriss.com/people/erco/unixtools/hosts2dns/

	If you use that script, heed the warning about if you have an existing DNS server
	config, back up your existing named.conf and zone files before using it, as this
	script completely takes over those files, overwriting them. I advise experimenting
	on a separate machine before committing your actual DNS server to it.

	I use it here on my network, cause I hate maintaining the zone files
	by hand.. this script makes it easy to just edit the /etc/hosts file,
	and run that one 'hosts2dns -update' command; it builds the forward/reverse
	files, manages the serial number incrementing, and restarts/reloads the DNS server.

I notice that you use intr,bg as NFS mount options. Did you come to these
through [trial]?  I have generally been using hard mounts for NFS.

	Actually, those two flags don't affect hard vs. soft mounts..
	it will be a hard by default. Those flags mean:
	
		bg = background
		intr = interruptible

	The 'bg' flag causes mount command to fall in the background if the
	NFS server isn't responding.

	'interruptible' is kind of a joke -- it's supposed to make hard mounts
	interruptible by the user if they hit ^C while the NFS server is down,
	so they can get their prompts back, but more likely than not, the process
	will be hung in an unkillable state, not even responsive to 'kill -9',
	due to how hard it is for the kernel guys to make all aspects of NFS operations
	interruptible at the kernel level.


--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)(new)

	Just a followup to this thread.

	When creating the 'render' user from the command line,
	Apple changed everything around in Leopard (10.5), so that now
	the 'niload' command is no longer available.

	They now recommend using their new 'dscl' command instead.

	So the Leopard version of the script to create the new 'render'
	user would be:

#!/bin/sh
#
# make-render-user - Run this script to create a 'render' user on Leopard/SnowLep/Lion..
# 1.0 05/10/06 - erco@(email surpressed) (original Tiger version)
# 1.1 05/13/09 - erco@(email surpressed) (changed for Leopard)
#
username=render          # user's name
     uid=555             # must be an unused uid
     gid=20              # 20=staff
  passwd=render          # the actual *cleartext* password for the user

# CREATE THE USER
dscl . -create /Users/$username
dscl . -create /Users/$username UserShell        /bin/bash
dscl . -create /Users/$username RealName         $username
dscl . -create /Users/$username UniqueID         $uid
dscl . -create /Users/$username PrimaryGroupID   $gid
dscl . -create /Users/$username NFSHomeDirectory /Users/$username
dscl . -passwd /Users/$username                  $passwd

# CREATE THE USER'S HOME DIRECTORY
cp -R '/System/Library/User Template/English.lproj' /Users/$username

# ENSURE OWNERSHIPS ASSIGNED TO USER'S ENTIRE HOME DIRECTORY
chown -R ${uid}:${gid} /Users/$username



	So that should be it.
	The older Tiger script is below for reference.

	BTW, if you want the new user to be an "administrator" user,
	you can add this line to the list of dscl commands:

		dscl . -append /Groups/admin GroupMembership $username


> STEPS TO SETUP
> --------------
> 
>          1) On all machines, create the "render" user with a fixed UID/GID that
>             doesn't conflict with any uid/gid on the network.
> 
>             This can be done easily by running the following script on each machine
>             as root to create the 'render' account on each machine with the uid=555,
>             gid=20, and the password set to 'render'. (Tested under OSX 10.4.x)
> 
> --- snip
> #!/bin/csh -f
> #
> # make-render-user - Run this script to create the 'render' user on a machine
> # 1.0 05/10/06 - erco@(email surpressed) - Supports Tiger (10.4), Panther (10.3)
> #
> set username = render                   # user's name
> set      uid = 555                      # must be an unused uid
> set      gid = 20                       # 20=staff
> set   passwd = 'oFxbR2cAnG902'          # passwd is 'render'
> 
> # CREATE PASSWD ENTRY
> echo ${username}:${passwd}:${uid}:${gid}::0:0:${username}:/Users/${username}:/bin/bash | niload passwd /
> 
> # CREATE USER'S HOME DIRECTORY
> if ( ! -d /Users/${username} ) then
>      cp -R '/System/Library/User Template/English.lproj' /Users/${username}
> endif
> 
> # ENSURE OWNERSHIPS ASSIGNED TO USER'S ENTIRE HOME DIRECTORY
> /usr/sbin/chown -R ${uid}:${gid} /Users/${username}
> --- snip