toasters

toasters@lists.teaparty.net

13531 discussions

Named Pipes?
by Brian Shamblin 18 Jun '99

18 Jun '99

We are trying to move our database files (not the database, just the data) from an NT server to our filer. The database application, DOCS Open from PC DOCS, insists on using Named Pipes to access the files (we're telling the application that they reside on NTFS). It appears that the filer has no support for this type of access method. Has anyone else encountered this problem? Any plans to add this support to ONTAP? Thanks in advance. ==================================================================== Brian Shamblin shamblin(a)mayo.edu Mayo Foundation voice: (507)284-4069 Rochester, MN fax: (507)284-9171 ====================================================================

2 1

Re: Virus
by yann.golanski＠ThePLAnet.net 17 Jun '99

17 Jun '99

Quoting Mark D Fowle <Fowle_Mark_D(a)CAT.com>: > Our NT Administrator wants to know how to protect the NetApps from viruses. > Unlike running on an NT server he > says he can't autoprotect data. Does anyone know how this might be done? Two ways. Use exim as a mail agent (yes, that DOES involve having a *nix box) and set a filter so that all attachemtn that match a list are `canned' or frozen. Then he can look thrugh them and only allow those he knows are not viruses. Of course, a list of known viruses can be set up to send the mail to /dev/null. The second: move to *nix. Check out VMware as a way to migrate. Remeber the filer is an appliance. It stores data. That's it. The security needs to come from somewhere else. -- Yann Golanski Internet Systems Developer yann.golanski(a)theplanet.net The Planet Online

1 0

RE: CIFS and the MaxMpxCt parameter
by Muhlestein, Mark 16 Jun '99

16 Jun '99

We have a fix for that in 5.3D14. The value is set via the cifs.max_mpx option, which has a maximum of 255, same as NT. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Graham C. Knight [mailto:grahamk@ast.lmco.com] Sent: Wednesday, June 16, 1999 3:12 PM To: toasters(a)mathworks.com Subject: CIFS and the MaxMpxCt parameter We have a windows NT terminal server that servers out up to 60 Windows NT sessions at a time. The Windows NT people are complaining because after a certain amount of connections to our filer they start getting errors that look like this: "\\filername is not accessible. The remote procedure call failed and did not execute." So, they opened a call with Microsoft, and after 3 or 4 days of wrangling Microsoft has told them that the MaxMpxCt needs to be increased on the file server. Well, i can find no reference to this anywhere in NetApp's documentation, so i'm figuring that this is a Windows NT server thing and that it has nothing to do with a filer. But i don't know for sure, or if there is something else i can set that does the same type of thing. Here's the blurb from M$. Any ideas? Cause: During negotiation of the SMB dialect, the MaxMpxCt parameter (NT server registry, option in NetApp filer?) is passed to the client's (Terminal Server's) redirector where the limit of outstanding network requests is enforced. Explorer makes extensive use of directory notifications, resulting in a number of NTNotifyDirectoryChange SMBs being sent to the server (NetApp filer). This SMB request is classified as a long term request and is received by the server but not sent back until a change occurs. When several clients connect to the Terminal Server, the number of outstanding commands against the server can exceed the default maximum of 50. If this situation arises, other SMB requests will wait in the redirector until previous requests complete, timeout, or are cancelled. Resolution: Increase the MaxMpxCt parameter on the remote server to allow more simultaneous SMB connections. Thanks, Graham

1 0

CIFS and the MaxMpxCt parameter
by Graham C. Knight 16 Jun '99

16 Jun '99

We have a windows NT terminal server that servers out up to 60 Windows NT sessions at a time. The Windows NT people are complaining because after a certain amount of connections to our filer they start getting errors that look like this: "\\filername is not accessible. The remote procedure call failed and did not execute." So, they opened a call with Microsoft, and after 3 or 4 days of wrangling Microsoft has told them that the MaxMpxCt needs to be increased on the file server. Well, i can find no reference to this anywhere in NetApp's documentation, so i'm figuring that this is a Windows NT server thing and that it has nothing to do with a filer. But i don't know for sure, or if there is something else i can set that does the same type of thing. Here's the blurb from M$. Any ideas? Cause: During negotiation of the SMB dialect, the MaxMpxCt parameter (NT server registry, option in NetApp filer?) is passed to the client's (Terminal Server's) redirector where the limit of outstanding network requests is enforced. Explorer makes extensive use of directory notifications, resulting in a number of NTNotifyDirectoryChange SMBs being sent to the server (NetApp filer). This SMB request is classified as a long term request and is received by the server but not sent back until a change occurs. When several clients connect to the Terminal Server, the number of outstanding commands against the server can exceed the default maximum of 50. If this situation arises, other SMB requests will wait in the redirector until previous requests complete, timeout, or are cancelled. Resolution: Increase the MaxMpxCt parameter on the remote server to allow more simultaneous SMB connections. Thanks, Graham

1 0

Re: Data Ontap 5.3 and snapshots
by Jason D. Kelleher 16 Jun '99

16 Jun '99

In message <199906162020.NAA14794@tooting>, Guy Harris writes: >> >Has anyone fond a quick way to touch all CIFS shares and directories on >the >> >filer to convert the directories immediately to Unicode so all snapshots >> >thereafter are clean? >> >> From UNIX: >> >> find /filer_root -name .snapshot -prune -o -name SOMETHING_THAT_W >ONT_MATCH -print > >That works only if your UNIX box is a Linux box using "smbfs" to access >the filer (and I have the impression that may not work), or you have >some other UNIX client that uses CIFS rather than NFS. > >Otherwise, they'll be NFS accesses, which don't cause directory >conversion. NFS access triggers conversion with ONTAP 4.0 or later, unless I'm misreading the 5.3 docs. Check here: http://now.netapp.com/knowledge/docs/ontap/rel53/html/sag/multi12.htm Of course this could be wrong, wouldn't be the first error in the 5.3 documentation. BTW, when does NetApp plan on releasing non-ambiguous docs for second level virtual interfaces? jason

2 1

Re: Data Ontap 5.3 and snapshots
by Jason D. Kelleher 16 Jun '99

16 Jun '99

In message <000101beb7fa$c40f32f0$08ffa8c0(a)ossmball.rtp.opensystems.com>, "M ike Ball" writes: [...] >Has anyone fond a quick way to touch all CIFS shares and directories on the >filer to convert the directories immediately to Unicode so all snapshots >thereafter are clean? From UNIX: find /filer_root -name .snapshot -prune -o -name SOMETHING_THAT_WONT_MATCH -print From a Win box: Start file manager and do a search for "SOMETHING_THAT_WONT_MATCH" with the "Start From" being the root of the filer. That should do it. jason

2 1

Re: Virus
by Graham C. Knight 16 Jun '99

16 Jun '99

Mark D Fowle wrote: > > Our NT Administrator wants to know how to protect the NetApps from viruses. > Unlike running on an NT server he > says he can't autoprotect data. Does anyone know how this might be done? > > Mark Fowle > Caterpillar-BCP We run Mcafee virus scans on our filers nightly with very good results. We created a username in NT that maps to root on the filer and let it rip. Initially i was concerned with the mix of Unix and NT files on our volumes confusing the virus scanner, but after a lot of testing I'm satisfied that it's not a problem. GRaham

2 2

Re: Data Ontap 5.3 and snapshots
by Joan Pearson 16 Jun '99

16 Jun '99

As another has mentioned, from the Windows client start a Find in the root directory. All directories will be converted to unicode format as they are traversed. By default, new directories created from CIFS are in unicode format. If you want to ensure all directories created from NFS are also in Unicode format, set the wafl.create_ucode option to True. You may be able to access your unconverted snapshot directories from NFS. Joan Pearson At 06:18 AM 6/16/99 , you wrote: >I have noticed in snapshots taken since I upgraded to 5.3, I am receiving >"access is denied" on various directories in the snapshots. > >This is due to the directories not being converted to Unicode as they have >not been accessed since the upgrade. I understand with 5.3, until a CIFS >directory is accessed it is not converted to Unicode. The problem I have >hear is I had some corrupted files last week in one of my directories on my >filer. When I went back to recover from any of the previous snapshots taken >since the 5.3 upgrade, I received "Access is denied" since those directories >where never touched since the 5.3 upgrade and therefore never converted to >Unicode. > >Has anyone fond a quick way to touch all CIFS shares and directories on the >filer to convert the directories immediately to Unicode so all snapshots >thereafter are clean? > Thank you, > Mike >

1 0

RE: Virus
by Muhlestein, Mark 16 Jun '99

16 Jun '99

If by "autoprotect data" you mean run a server-based scan, that is correct, the filer does not have a built-in virus scanner. However, there are good reasons why you don't want to do that. One obvious reason is that the filer would be slowed down because every file access requires the virus scanner to get involved, which penalizes all users. It is much better to do the scanning on the clients since that has the correct scaling properties. You should have virus scanning software loaded on all your clients, but you should also have one or more clients run periodic on-demand scans of the filer data. There are several advantages to running the scans from standard PC clients, not least of which is the rapid availability of updated versions to catch the latest viruses. Another advantage is that with multiple PC clients you can parallelize the scans, which can be a great timesaver if you have a large amount of data to scan. You should also make sure your NT administrator understands the advantages of snapshots, which can be used to very good effect when a new virus is found for which there is no anti-virus software yet. And, of course, the filer is not directly susceptible to viruses because it does not run general applications. Overall, I'd say the filer has a very good anti-virus story compared to NT server. Mark -----Original Message----- From: Mark D Fowle [mailto:Fowle_Mark_D@CAT.com] Sent: Wednesday, June 16, 1999 7:03 AM To: toasters Subject: Virus Our NT Administrator wants to know how to protect the NetApps from viruses. Unlike running on an NT server he says he can't autoprotect data. Does anyone know how this might be done? Mark Fowle Caterpillar-BCP

1 0

Virus
by Mark D Fowle 16 Jun '99

16 Jun '99

Our NT Administrator wants to know how to protect the NetApps from viruses. Unlike running on an NT server he says he can't autoprotect data. Does anyone know how this might be done? Mark Fowle Caterpillar-BCP

1 0

Data Ontap 5.3 and snapshots
by Mike Ball 16 Jun '99

16 Jun '99

I have noticed in snapshots taken since I upgraded to 5.3, I am receiving "access is denied" on various directories in the snapshots. This is due to the directories not being converted to Unicode as they have not been accessed since the upgrade. I understand with 5.3, until a CIFS directory is accessed it is not converted to Unicode. The problem I have hear is I had some corrupted files last week in one of my directories on my filer. When I went back to recover from any of the previous snapshots taken since the 5.3 upgrade, I received "Access is denied" since those directories where never touched since the 5.3 upgrade and therefore never converted to Unicode. Has anyone fond a quick way to touch all CIFS shares and directories on the filer to convert the directories immediately to Unicode so all snapshots thereafter are clean? Thank you, Mike

1 0

RE: the virus
by Sam Schorr 15 Jun '99

15 Jun '99

Is this the same logic that says its okay to rape based on how women dress? -----Original Message----- From: tkaczma(a)gryf.net [mailto:tkaczma@gryf.net] Sent: Monday, June 14, 1999 12:26 PM To: toasters(a)mathworks.com Subject: Re: the virus On Mon, 14 Jun 1999, Douglas Ritschel wrote: > I think it should be a capital offense. But not to the virus writers, but the people that ignorantly open them. I think that Microsoft at al. should be held accountable for the ease with which the worm takes advantage of those systems. Tom

5 6

Re: Converting F230 SCSI drives to F740
by sirbruce＠ix.netcom.com 15 Jun '99

15 Jun '99

On 06/15/99 11:18:54 you wrote: >If there is a problem with the boot image on disk, Intel when you really need >Alpha would be considered a problem, you can boot from floppy and run the >`download' command to refresh the boot image. Right. Although for the move, it doesn't sound like he'll need to do this; if he can set the alpha to use vol1 and make it the root volume and move the other disks over as vol0 (can you do that without the filer wanting to rename things?) then he can just type "download" on the running filer after the move and refresh the vol0 disks with the alpha image. Bruce

1 0

Re: the virus
by sirbruce＠ix.netcom.com 15 Jun '99

15 Jun '99

On 06/14/99 10:45:48 you wrote: > >In theory, The worm/trojan he wrote could have deleted the research for >the drug that would one day save his life... Unfortunately Netapp probably sold them a filer so snapshots allowed them to recover the data. :) Bruce

1 0

Re: the virus
by sirbruce＠ix.netcom.com 15 Jun '99

15 Jun '99

On 06/14/99 14:26:05 you wrote: >On Mon, 14 Jun 1999, Douglas Ritschel wrote: > >> I think it should be a capital offense. > >But not to the virus writers, but the people that ignorantly open them. I >think that Microsoft at al. should be held accountable for the ease with >which the worm takes advantage of those systems. I can't resist this opportunity to take a jab at Microsoft by noting that I think the people who ignorantly use Microsoft mail clients that allow them to be taken advantage of are partly accountable too. :) Bruce PS - No, I'm not really defending the virus writers. And oddly enough I didn't get hit, despite being on several lists.

1 0

Re: AFS/DFS??!! :-) (and FTP!)
by sirbruce＠ix.netcom.com 15 Jun '99

15 Jun '99

On 06/14/99 14:35:34 you wrote: > >> Are the binaries modular, i.e. only licensed modules are installed into >> memory? > >No - ONTAP is a single image with all modules linked into it. > > Right... my point was that it's still a very small code image compared to the 128MB+ your filer is going to have, even if the image is (allegedly) ten times larger than it used to be. I suppose certain features like CIFS will use more memory to allocate certain data structures for buffers and the like, but I was under the impression that if you weren't using it, this memory wasn't going to be allocated. (Ditto anything extra a particular network card like ATM may need to allocate to operate.) Bruce

1 0

Converting F230 SCSI drives to F740
by Mike Ball 15 Jun '99

15 Jun '99

We have a F230 with about 100GB of data. We have just purchased a F740 with a shelf of 18GB Fibre drives and two empty dual SCSI shelves. We have 9GB SCSI drives on the F230 which can be moved to the F740 Dual SCSI shelves. My question is since we are running a Data Ontap 4.3.3 on the F230, I will be upgrading it to 5.2.2 before I physically move the SCSI drives over to the F740 system. Since the source code for the Data Ontap on the F230 is Intel based versus Alpha based on the F740 am I going to run into issues. As it stands right now, I am planning on having my root volume to boot off of on the Fibre drives. Since the volume on the F230 is already named vol0 I am renaming the root volume on the F740 Fibre drives to vol1. Once this has been completed, it looks like I can simply power down both the F230 and the F740, move the disks from the F230 SCSI shelves to the F740 SCSI shelves. Power up the Fibre and SCSI shelves on the F740, and be on my way. The F740 will boot off the root volume on the Fibre drives and I should be able to see both volumes once the system has completed the boot process. Once both volumes are confirmed to be online and functioning , I would then make vol0 (volume on SCSI disks) the root volume and reboot the system. Does everything here sound correct and if so how will the Intel Data Ontap code on the SCSI drives from the F230 be converted to Alpha code?

2 1

Thanks.
by Shaun T. Erickson 15 Jun '99

15 Jun '99

I recently mentioned that we were having major trouble with our F540. I just wanted to thank the NetApp folks who've been so helpful the past week: Puneet Anand, Jim Ripley, Kirk & Pamela. They really came through for us. Our system isn't fixed, but our replacement loaner system is up and running and serving our data just fine. Thanks, NetApp. :-) -ste Work: (908) 582-7629 Pager: (800) 756-1133 Cell: (201) 310-9941

1 0

NFS ACLs
by tkaczma＠gryf.net 14 Jun '99

14 Jun '99

Just came across this in Solaris docs: --- NFS Parameters for the nfs Module [...] nfs_acl_cache - This symbol controls whether ACLs are cached on clients that are using the NFS_ACL protocol. --- Does anyone know of any info on the NFS ACL protocol? Is this what we were just speaking of? Tom

2 4

Re: AFS/DFS??!! :-) (and FTP!)
by sirbruce＠ix.netcom.com 14 Jun '99

14 Jun '99

On 06/12/99 17:04:02 you wrote: > >>DFS is a pretty small market. AFS isn't much better, assuming you >>mean Andrew. If you're talking Apple, now there's a potential market. >Apple toooooo. >In fact we have over 400 of those puppies in our dept alone and when we >bough the very first FAServer450 (No, not the F540, the 450 with 2 G disks!) Actually, before the 450 was the 400, which could only hold half as many disks (7). If you wanted 14 you had to buy a second cabinet and run an external SCSI cable to it. I thought the cabinets looked pretty cool, but the 450 was certainly impressive. I've never seen a bigger PC tower case in my life! Also, for a while 1G disks were supported as well. (Actually, I suspect they still are, if you had one lying around that you could fit!) But by the time Netcom got its first filer in late 1993 2G disks were the norm. >in early '94 that was the very first request I had with their then V.P. >On the other hand I have mixed feeling when requesting new features >and additional protocol support. One of the key strength of an appliance, >in my school, is it's simplicity of usage and administration. >When the first FAServer's rolled out it had fewer than 50 commands with >a 300 page admin book and hell of a fewer lines of code compared to other >traditional UNIX systems. However, the admin book, while thin, was seriously lacking in a lot of important details! The appliance is still really simple *except* in the edge cases, and then you have to know exactly what you're doing. This is the trade-off you get for faster response when there's a failure -- you can fix the problem yourself. >As we request all these neat features I wonder how much are we shooting >ourselves on the foot. I think so long as the filer sticks to *file service* and the related protocols it will be fine. For the most part having the other features "around" doesn't hurt performance for the other functions. In other words, having the trunking code or the PC-NFS support doesn't hurt your NFS access performance when you aren't using them (or even when you are). If the filer got into other areas... for example, trying to be a DNS server and a SMTP server on the same box, then I'd be annoyed. (I must reluctantly accept the idea that the filer should be a Domain Controller for NT, simply because that's a necessary component for their file service.) >Once I heard that just adding ATM support on the NIC increased the number >of lines of code by an order of magnitude! I doubt ATM alone was that bad. 10 times, no. 2 times, maybe. :) I don't know exactly how small the 1.0 version code was; I suppose it could have taken up as little as 10% of the original floppy. So today's code might be 10 times bigger now, but I don't think that's all due to ATM. I suspect CIFS support must be a big chunk. But you're still talking a very small part of the filer's overall memory reserve, so bigger executables aren't really a factor in performance. Most of code size concerns are a maintenance issue. It is all supposedly highly segmented and integrated, however, so all those extra lines of code don't slow down the data path from the network interface down to WAFL appreciably compared to the original code. There is more work to be done in a multiprotocol environment, but it is well worth the tradeoff. Bruce

3 2

RE: the virus
by Garrett Burke 14 Jun '99

14 Jun '99

Hi, Files on the toaster will be set to size zero. Be very careful if your toaster contains source code as the virus attacks .cpp, .c and .h files. Thank god for snapshots. GB > ---------- > From: Steve Armijo[SMTP:armijo@cs.unm.edu] > Sent: 11 June 1999 09:17 > To: toasters(a)mathworks.com > Subject: the virus > > > ok, so amid all this wild virus scare, does anyone here know what the > potential of this is to affect PC users who have shortcuts/mapped drives > pointing at toasters? > > -steve > > -- > Cue the music, fade to black, no such thing as no payback. -PWEI > > [ armijo(a)cs.unm.edu ] >

9 11

RE: NFS ACLs
by tkaczma＠gryf.net 14 Jun '99

14 Jun '99

Warning, he worm finaly made it to the newsgroup. Tom On Mon, 14 Jun 1999, Kinney, Roger wrote: > Hi ! > I received your email and I shall send you a reply ASAP. > Till then, take a look at the attached zipped docs. > bye. > <<zipped_files.exe>> >

1 0

Re: the virus
by Jason D. Kelleher 14 Jun '99

14 Jun '99

In message <1BF7EB8768B8D211B29400E02905846232C38F(a)atlas.rsinc.com>, Jim San ford writes: >Public canings are an option, but how about a public "live hookup" to about >4000 volts?? Wouldn't smell as nice, but I think it's an alternative worth considering... :) jason

1 0

RE: Quickest way to move data.
by Melvin, Grant 14 Jun '99

14 Jun '99

Hi Shaun, > We would like to know what would be the quickest way to get the data moved > from one system to the other. Doing it accross our 100Mb net could take a > couple of days, which is unacceptable. Could we put a scsi card in the > F740, attach our F540's shelves and do volcopys? Any other suggestions? We > need the downtime to be the absolute minimum. We've recently updated "Migrating Data Between NetApp Filers" paper on the NetApp web site. Hopefully this can be of some help in explaining the different methods that we support, check it out at: http://www.netapp.com/technology/level3/3018.html > Also, if it's fibre-channel only, how am I supposed to attach my > scsi-based DLT jukebox, so I can continue to back up the replacement filer > via NDMP? Is there a scsi port on an F740, just for use by a tape drive? The F700 series has an on-board fast/wide/differential for tape backup. Cheers, Grant

1 0

RE: the virus
by Jim Sanford 14 Jun '99

14 Jun '99

Public canings are an option, but how about a public "live hookup" to about 4000 volts?? ********************************* Jim Sanford IS Department Research Systems, Inc. ********************************* -----Original Message----- From: Marc A Levy [mailto:malevy@dnrc.bell-labs.com] Sent: Monday, June 14, 1999 8:46 AM To: Jason D. Kelleher Cc: tkaczma(a)gryf.net; toasters(a)mathworks.com Subject: Re: the virus In theory, The worm/trojan he wrote could have deleted the research for the drug that would one day save his life... "Jason D. Kelleher" wrote: > > In message <Pine.LNX.4.04.9906111910090.1584-100000(a)gryf.gryf.net>, tkaczma@ > gryf.net writes: > > > >On Fri, 11 Jun 1999, Brian Pawlowski wrote: > > > >> Were any customers on this alias affected by the worm? > >> I will understand if you don't want to tell me. > > > >I didn't , I feel left out. I don't think the trojan worm made it out to > >the alias. > > I got a copy of it, but wasn't affected. Large mailing lists in > address books give these "new" worms interesting vectors. The > subject "RE: Early Access" combined with the worm message text and > the fact that it came from a vendor employee gave it a nice > illusion of legitimacy. Unpleasant. > > So, quick vote: Those in favor of public canings for virus authors > say aye. > > jason

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