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)
|