toasters October 1998

toasters@lists.teaparty.net

60 participants
75 discussions

Re: upgrade problem 4.1 to 5.1
by sirbruce＠ix.netcom.com 13 Oct '98

13 Oct '98

On 10/12/98 10:15:37 you wrote: >The upgrade did fine and the NFS protocol was still working properly. I >could not get CIFS to authenticate with the Primary Domain Controller. >I was getting watchdog reboots most of the time and other times CIFS >would not start. I had to downgrade in order to CIFS back up again. > >Do you think this will happen again if I upgrade to 5.1.2. What do I >need to do to upgrade and get CIFS working correctly. You should report the problem the Netapp support and I'm sure they'll be able to help you figure out what the problem is and what the solution is. Bruce

1 0

Re: 4.x to 5.x upgrade
by Jason D. Kelleher 13 Oct '98

13 Oct '98

In message <7F608EC0BDE6D111B53A00805FA7F7DA010458B9(a)tahoe.netapp.com>, "Tho mpson, Tim" writes: >> So let's suppose my filer dies, double disk failure perhaps. How >> do I get back all these "automatically persistent" configuration >> options? Will things save state with something like the >> undocumented "cifsconfig.cfg" file? > >Yes, it's a single file, which can be backed up and restored. I wasn't refering to the /etc/rc file. I was asking how I get back all my "persistent" configuration changes after a complete failure if they haven't been placed in the /etc/rc...? >> Please don't go and update my rc file. > >Looks like that's a common feeling, thanks! ...Tim... Good to know. So what about NTP...? jason

1 0

Re: 4.x to 5.x upgrade
by Daniel Quinlan 13 Oct '98

13 Oct '98

"Jason D. Kelleher" <kelleher(a)susq.com> writes: > So let's suppose my filer dies, double disk failure perhaps. How do > I get back all these "automatically persistent" configuration > options? Will things save state with something like the > undocumented "cifsconfig.cfg" file? Yuch. One way to look at it is: it should be possible to backup and restore your filer configuration using a line printer and a scanner. > Please don't go and update my rc file. The cifsconfig.cfg file is > bad enough. When I don't want to know what's going on under the > hood (and be forced to re-add a bunch of configs by hand as a result > of my ignorance), I'll transfer over to the NT support group... The way cifsconfig.txt works -- it must be designed for Windows NT admins by Windows NT developers. I wish there was a "behave normal" for Unix admins mode for cifsconfig.txt. I produced some interesting phrases the first time my manual changes to cifsconfig.txt were lost after a reboot. > P.S. I bit my tongue this morning about NTP, but I might as well say > something now... About three years ago I asked about possible NTP > support and got nothing. Six months ago someone on this list > practically begged for at least SNTP support. Well...? I think NTP must be the most common request on toasters. Dan

1 0

Re: (small?) feature request
by Daniel Quinlan 13 Oct '98

13 Oct '98

alexei(a)cimedia.com writes: > I cannot remember if there was a reason this feature had not been > implemented, but here goes: > > can we get command line history/editing? > > Yes, there aren't that many commands you type in repeatedly, but > it would be nice to have for some things. If you use emacs(1), you can use "M-x telnet" or "M-x shell" to get command-line history when you're working on a NetApp. I believe screen(1) also has similar features. - Dan

2 1

Re: 4.x to 5.x upgrade
by Daniel Quinlan 13 Oct '98

13 Oct '98

Tim Thompson <tim.thompson(a)netapp.com> writes: > For this reason, in a future release of ONTAP more things (more than > just the per-volume options) will be automatically persistent. You > can still put them in /etc/rc, but the trend will be toward not > needing to. Seems like a bad trend. I'm not really keen on someone being able to change the configuration of filer without me knowing it. Options should be stored in text files that can be read or edited by a human. Also, all option changes should be logged. Hence, we use RCS on NetApp configuration files (effectively forcing logging). Sticking options into the filesystem metadata makes logging changes harder. > A question. Given the choice between: > > - Having a command tell you "there's a conflicting > command already in /etc/rc, you should change it there as well > (or just remove it)" > vs. > - Having the command automatically update /etc/rc with the change, > if it contains a conflicting command. > > Which do you think would be a better approach? The former. - Dan

1 0

(small?) feature request
by alexei＠cimedia.com 12 Oct '98

12 Oct '98

I cannot remember if there was a reason this feature had not been implemented, but here goes: can we get command line history/editing? Yes, there aren't that many commands you type in repeatedly, but it would be nice to have for some things. Alex

2 2

RE: 4.x to 5.x upgrade
by Thompson, Tim 12 Oct '98

12 Oct '98

> So let's suppose my filer dies, double disk failure perhaps. How > do I get back all these "automatically persistent" configuration > options? Will things save state with something like the > undocumented "cifsconfig.cfg" file? Yes, it's a single file, which can be backed up and restored. > Please don't go and update my rc file. Looks like that's a common feeling, thanks! ...Tim...

1 0

RE: 4.x to 5.x upgrade
by Thompson, Tim 12 Oct '98

12 Oct '98

> > Note that the per-volume options are persistent; their values are > > recorded in the file system "fsinfo block". Thus, for example, you > > don't have to update "/etc/rc" to put > Interesting. Can you share the reasoning behind making these options > persistent? The following scenario is not uncommon: - person executes "options" command to fix/change something - person forgets to add it to /etc/rc - time passes (sometimes a lot of time, i.e. till the next reboot) - after the next reboot, it takes (and wastes) time to re-discover the need for the fix/change, and re-apply it. For this reason, in a future release of ONTAP more things (more than just the per-volume options) will be automatically persistent. You can still put them in /etc/rc, but the trend will be toward not needing to. A question. Given the choice between: - Having a command tell you "there's a conflicting command already in /etc/rc, you should change it there as well (or just remove it)" vs. - Having the command automatically update /etc/rc with the change, if it contains a conflicting command. Which do you think would be a better approach? ...Tim Thompson...Network Appliance, Inc...tjt(a)netapp.com...

3 2

Re: 4.x to 5.x upgrade
by Jason D. Kelleher 12 Oct '98

12 Oct '98

In message <7F608EC0BDE6D111B53A00805FA7F7DA010458B6(a)tahoe.netapp.com>, "Tho mpson, Tim" writes: > >> > Note that the per-volume options are persistent; their values are >> > recorded in the file system "fsinfo block". Thus, for example, you >> > don't have to update "/etc/rc" to put >> Interesting. Can you share the reasoning behind making these options >> persistent? > >The following scenario is not uncommon: > > - person executes "options" command to fix/change something > - person forgets to add it to /etc/rc > - time passes (sometimes a lot of time, i.e. till the next reboot) > - after the next reboot, it takes (and wastes) time to re-discover > the need for the fix/change, and re-apply it. Hopefully said person won't do it twice... Bottom line, it's very hard to defend against operator error. And most attempts either proves annoying and ineffectual, or just plain ineffectual. >For this reason, in a future release of ONTAP more things (more than >just the per-volume options) will be automatically persistent. >You can still put them in /etc/rc, but the trend will be toward not >needing to. So let's suppose my filer dies, double disk failure perhaps. How do I get back all these "automatically persistent" configuration options? Will things save state with something like the undocumented "cifsconfig.cfg" file? Yuch. >A question. Given the choice between: > > - Having a command tell you "there's a conflicting > command already in /etc/rc, you should change it there as well > (or just remove it)" >vs. > - Having the command automatically update /etc/rc with the change, > if it contains a conflicting command. > >Which do you think would be a better approach? Please don't go and update my rc file. The cifsconfig.cfg file is bad enough. When I don't want to know what's going on under the hood (and be forced to re-add a bunch of configs by hand as a result of my ignorance), I'll transfer over to the NT support group... jason P.S. I bit my tongue this morning about NTP, but I might as well say something now... About three years ago I asked about possible NTP support and got nothing. Six months ago someone on this list practically begged for at least SNTP support. Well...? --- Jason D. Kelleher kelleher(a)susq.com Susquehanna Partners, G.P. 610.617.2721 (voice) 401 City Line Ave, Suite 220 610.617.2916 (fax) Bala Cynwyd, PA 19004-1122

1 0

timed
by alexei＠cimedia.com 12 Oct '98

12 Oct '98

ok, so 5.1.1 has timed for syncs between filers (my guess). Any chance we can get xntpd for syncs between filers and clients? Alex

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters October 1998