we get these messages on reboot of one netapp ** Option wafl.default_unix_user is being set to "pcuser" in /etc/rc, ... ** Option wafl.default_unix_user is being set to "root" in /etc/rc, anyone know what causes such schizo behaviour?
I'm getting additional info from John, offline, to attempt to see what's going on. (Besides the obvious action of opening a trouble ticket on the issue.)
wher is a netapp's registry?
It's a mechanism introduced in 5.3 for making options and other things persistent. It should be invisible, for the most part.
...Tim Thompson...Network Appliance, Inc...tjt@netapp.com...
It's a mechanism introduced in 5.3 for making options and other things persistent. It should be invisible, for the most part.
Tsk. And this worked so well for Windows, right?
Think ahead. All options and variables, persistent or not, should be documented and modifiable via plain-text files.
Bruce
Tim Thompson tim.thompson@netapp.com wrote:
It's a mechanism introduced in 5.3 for making options and other things persistent. It should be invisible, for the most part.
and Bruce Sterling Woodcock sirbruce@ix.netcom.com comments:
Tsk. And this worked so well for Windows, right?
Think ahead. All options and variables, persistent or not, should be documented and modifiable via plain-text files.
It's not quite as bad as this makes out. The persistent state of the options *is* recorded in a plain-text file, /etc/registry, which however one is [strongly?] discouraged from updating directly.
Before 5.3, options could only be persistent by adding things to /etc/rc, and we kept SCCS histories for that. Being able to strike out the accumulated options commands from /etc/rc was nice in a way, but I was concerned about keeping track of the history of permanent changes. I decided to keep a "master" file under SCCS control, and run
sed '/^#/d' /toaster-mountpoint/etc/registry | diff - /master-options-file
in a weekly crontab, to prompt me to either undo temporary changes, or record them in the SCCS history if I decided they were permanent after all.
Only slight snag so far is that upgrading from 5.3.4R3 to 5.3.5 made some automatic changes to /etc/registry which had to be post hoc recorded in the history.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.
-
Bruce Sterling Woodcock -
Chris Thompson -
Thompson, Tim