toasters

toasters@lists.teaparty.net

13531 discussions

Re: 4.x to 5.x upgrade
by sirbruce＠ix.netcom.com 13 Oct '98

13 Oct '98

On 10/12/98 21:53:10 you wrote: >I produced some interesting phrases the first time my manual changes >to cifsconfig.txt were lost after a reboot. Well, at least said person won't do it twice. :) I know that I pointed out at some point that behavior should be documented, and I believe it was. Assuming it was, and you didn't read the documentation, then you have a conflict of cultures - one person will assume it behaves one way by default and another will assume the other. Whichever is chosen isn't nearly as important as documenting the behavior and making sure people read the documentation! Bruce

1 0

RE: (small?) feature request
by sirbruce＠ix.netcom.com 13 Oct '98

13 Oct '98

On 10/12/98 15:47:32 you wrote: >For commands that can be done via rsh from the admin server, you only need to >use >a shell like bash or tcsh. I'm sure you know that, I only mention it because I >have a related question: > > What is the reasoning behind which commands will work via rsh and which > won't? They are made rsh-able "as needed", because since the filer uses all the same memory space, making a piece of code rsh-safe requires extra effort (think multiple simultaneous executions). Virtually every release, we see a few more commands made rsh-able, but it seems other new features are always more important than cleaning up old code. Bruce

1 0

RE: 4.x to 5.x upgrade
by sirbruce＠ix.netcom.com 13 Oct '98

13 Oct '98

On 10/12/98 11:53:19 you wrote: >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. I do not trust the software to automatically place the new command in the right place in the /etc/rc file - I've very particular about the order. If there is an automatic change to the /etc/rc file, I want an option to turn it off! :) Bruce

1 0

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

Re: special access acl
by Keith Brown 12 Oct '98

12 Oct '98

>I have a requirement for special access acl's from cifs clients. >In particular for directories to which users can add files but can not then >remove them. Fair enough. What you need is either the "special" Windows NT directory permission set called "Add" (actually Write and Execute) or perhaps "Add & Read" (actually Read, Write and Execute). Not a problem. >I understand this to be a function of NT permissions, the options all seem >to be there for the filer but don't seen to have the desired effect. What effect are you seeing? >Can anyone tell me if this is supported functionality. Absolutely. Assuming you have configured the filer to support NTFS semantics in the portion of the file system being accessed by your Windows clients, you should find that these directory permission sets will restrict and allow various client operations exactly as they would on a bona fide NTFS file system partitions of a Windows NT server. Keith

1 0

Re: Logging CIFS logins
by sirbruce＠ix.netcom.com 12 Oct '98

12 Oct '98

On 10/11/98 17:50:55 you wrote: >Is there any way to log CIFS logins? We are using unix authentication, >NIS enabled, and default logging (no /etc/syslog.conf file). We're >running 5.0.2. Not that I know of (cifs sessions will give you the current ones), but perhaps someone more in the know could say for sure... >Is there any way to coax our filer to log the time and loginid of each >CIFS login? CIFS users don't "login" per se, although there are connections that are made and closed associated with a connection. There is the general network authentication, but you say you're using UNIX authentication, not NT. >This information is essential for system administration in a >university environment. Why? You don't have this information available for NFS access. Sure, you record the UNIX login, but you do that in a different place... at the server. A person with a PC and and NFS client could just as easily make a NFS "login", that is make an NFS request as a given userid, without your logging it, just like they can CIFS. Of course, you can restrict all of your NFS access by hsotname, but that's beside the point. The point, I think, is that you're looking in the wrong place. If you want to record logins that could then potentially make CIFS requests, you should be doing it at the PC itself, or use NT authentication. Still, given particular situations, logging CIFS sessions would be useful. So would logging PC-NFS sessions, which I know some servers do but I don't think the filer does. Bruce

2 1

special access acl
by Algar, Christopher [PAI01:8881:EXCH] 12 Oct '98

12 Oct '98

Quick question for you. I have a requirement for special access acl's from cifs clients. In particular for directories to which users can add files but can not then remove them. I understand this to be a function of NT permissions, the options all seem to be there for the filer but don't seen to have the desired effect. Can anyone tell me if this is supported functionality. For info we are running 5.1R1 Thanks in advance Chris Algar UNIX support Nortel Optoelectronics

1 0

upgrade problem 4.1 to 5.1
by Jason Middlebrooks 12 Oct '98

12 Oct '98

I recently had a problem upgrading to 5.1r1 here is the configuration of the filer. F630 4 SCSI Shelves full of 9 Gig drives 2 Quad 10/100 Network Cards (currently using only one port) 256 Meg Ram 8 Meg NVRAM Firmware 1.11_a1 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. Jason Middlebrooks Systems Engineer Direct Connect Systems Phone: 770-933-9327x270 2264 Northwest Parkway, Suite I Pager: 888-502-1625 Marietta, GA 30067 Fax: 770-933-9272

1 0

Logging CIFS logins
by Stephen C. Losen 11 Oct '98

11 Oct '98

Is there any way to log CIFS logins? We are using unix authentication, NIS enabled, and default logging (no /etc/syslog.conf file). We're running 5.0.2. Is there any way to coax our filer to log the time and loginid of each CIFS login? This information is essential for system administration in a university environment. Steve Losen scl(a)virginia.edu phone: 804-924-0640 University of Virginia ITC Unix Support

1 0

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

10 Oct '98

guy(a)netapp.com (Guy Harris) 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? (I'll continue to put them into /etc/rc since I can't use RCS on the fsinfo block to keep track of changes, etc.) - Dan

1 0

Re: working around lack of NTP
by Daniel Quinlan 10 Oct '98

10 Oct '98

sirbruce <sirbruce(a)ix.netcom.com> writes: > If your netapp is really drifting that much during the day, like a > minute or more, then I suspect something is wrong with your netapp > that needs to be address. I'm "only" talking about 2 or 3 seconds, the example I sent was a one second drift. It's not bad hardware or software, but it is a problem. Some programs check timestamps, people have had "make" problems due to file modification times in the future, stat(1) fails if it thinks time is going backwards, etc. > (Note: It could drift farther during RAID scrubs than a minute. If > your schedule your RAID scrub rarely and rdate after it, there should > be no problems). That problem only affects our F330. To compensate, I rdate it every five minutes after the scrub begins. (It was drifting up to 5 minutes off of the correct time, it is down to about 45 seconds now). I also found that turning down the reconstruct speed will help reduce the rate of clock skew during scrubs. > I would normally run rdate every, say, 15 to 20 minutes, and I would > simply offset the times so it didn't run at the 0, 15, 30, or 45 > minutes after (which is when a cron job would normally be scheduled). 0, 15, 30, and 45 are typical for Data ONTAP cron jobs? That's the info I wanted, thanks. > [rdate] works as well as NTP for the granularity most people desire. > I suspect in your environment, your needs are different, but don't tar > and feather rdate for that. :) Yes, rdate has its uses. Well, at least until 2038 it does. It's simple enough for me to completely understand it, which I like. Unfortunately, whenever you set the time with rdate, even under the theoretically ideal conditions, the time can easily be incorrect by as much as one second. Jumping the clock when using rdate? Again, under theoretically ideal conditions, it can jump as much as one second. Real life is much worse, of course. NTP can give you sub-millisecond accuracy on a LAN. - Dan

1 0

Re: working around lack of NTP
by sirbruce＠ix.netcom.com 10 Oct '98

10 Oct '98

On 10/09/98 19:42:19 you wrote: > >NetApp does not support NTP, so we must set the system time via >periodic "rdate" commands. We have found that running rdate too often >(or at the wrong time of day) can cause regularly scheduled jobs (such >as scrubs) to be missed. This is a known bug I discovered. I'd give you the BUGID if I had it. :) >Right now, we're setting the time three times a day, but that doesn't >cut it. Some programs bitch that time is "going backwards" and other >nonsense because the NetApp isn't synchronized with everything else. (*) If your netapp is really drifting that much during the day, like a minute or more, then I suspect something is wrong with your netapp that needs to be address. Various factors in the past - old software releases, old SCSI cards, etc. - have contributed to clock drift. And sometimes, your clock is just bad. I think you should have support look into this and determine exactly how much your are drifting in a day and why. (Note: It could drift farther during RAID scrubs than a minute. If your schedule your RAID scrub rarely and rdate after it, there should be no problems). >I'd like to know when NetApp cron jobs (other than scrubs -- I know >when they happen) are scheduled, so we can run "rdate" more often, but >without causing problems. There are other periodic timed behaviors in a filer, like CIFS and WINS stuff, that are variable. I don't know if throwing off the software clock effects them - hopefully not. The only other major cron jobs you need to be aware of are the snap schedule (I think I've rarely if ever seen clock drift effect this) and the hourly statd message (and support email, whenever that is). I would normally run rdate every, say, 15 to 20 minutes, and I would simply offset the times so it didn't run at the 0, 15, 30, or 45 minutes after (which is when a cron job would normally be scheduled). >What I'm trying to do (fix the time problem we're having) is really >futile, of course. You can't synchronize crap with rdate. It works as well as NTP for the granularity most people desire. I suspect in your environment, your needs are different, but don't tar and feather rdate for that. :) Bruce

1 0

working around lack of NTP
by Daniel Quinlan 10 Oct '98

10 Oct '98

NetApp does not support NTP, so we must set the system time via periodic "rdate" commands. We have found that running rdate too often (or at the wrong time of day) can cause regularly scheduled jobs (such as scrubs) to be missed. Right now, we're setting the time three times a day, but that doesn't cut it. Some programs bitch that time is "going backwards" and other nonsense because the NetApp isn't synchronized with everything else. (*) I'd like to know when NetApp cron jobs (other than scrubs -- I know when they happen) are scheduled, so we can run "rdate" more often, but without causing problems. What I'm trying to do (fix the time problem we're having) is really futile, of course. You can't synchronize crap with rdate. - Dan (*) this is really easy to reproduce, by creating a file and running stat() on it immediately afterwards. This script shows the problem: ------- start of cut text -------------- #!/usr/local/bin/perl require "ctime.pl"; require "stat.pl"; die "usage: $0 [filename]\n" unless $ARGV[0]; open(TEST, "> $ARGV[0]"); close(TEST); do Stat($ARGV[0]); $now = time(); print "atime = ", &ctime($st_atime); print "mtime = ", &ctime($st_mtime); print "ctime = ", &ctime($st_ctime); print "adiff = ", ($now - $st_atime), "\n"; print "mdiff = ", ($now - $st_mtime), "\n"; print "cdiff = ", ($now - $st_ctime), "\n"; ------- end ---------------------------- Run it against a NetApp that is "synchronized": ------- start of cut text -------------- $ ./stat-test foo atime = Fri Oct 9 19:26:11 1998 mtime = Fri Oct 9 19:28:37 1998 ctime = Fri Oct 9 19:28:37 1998 adiff = 145 mdiff = -1 cdiff = -1 ------- end ---------------------------- $now should always be >= than all of the timestamps.

1 0

4.x to 5.x upgrade
by alexei＠cimedia.com 09 Oct '98

09 Oct '98

As I contemplate upgrading all my old filers from 4.x to 5.x, I was wondering what the horror stories are out there. Or is this truly a simple upgrade? Thanks. Alex

6 5

Re: 4.x to 5.x upgrade
by stephen＠netapp.com 09 Oct '98

09 Oct '98

> stephen(a)netapp.com (Stephen Manley) writes: > > > More specifically, in 5.1 (not 5.0) we don't allow tape record sizes > > greater than 64KB and we default to 63KB (rather than 10KB). > Note, that this limitation does not apply to NDMP to locally attached tape, or the NDMP 3-way backup. Sm

1 0

None
by yingchih＠mitac.com.tw 09 Oct '98

09 Oct '98

Unsubscribe toasters

1 0

Jump to page:

2026

2025

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