toasters

toasters@lists.teaparty.net

2 participants
13522 discussions

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

Jump to page:

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