toasters January 2005

toasters@lists.teaparty.net

67 participants
75 discussions

RE: IPsec NFS to Unix clients
by Muhlestein, Mark 17 Jun '05

17 Jun '05

Gee, 30,000 * 300 is not even 10 million entries! :-) Yes, you are right that this isn't going to work in every case. But I wanted to mention it because it is useful in some situations. As to the MultiStore comment I made, I was thinking of a case where you want to use the same physical filer to serve an unprotected network (such as your normal campus network, it sounds like) and also serve a trusted network (on a different NIC or VLAN, say). As long as there is no way to access a vfiler's IP address using a client on the untrusted network, the vfiler boundary checks will prevent all access from all protocols (including NFS handle spoofing) coming from those untrusted clients. Mark -----Original Message----- From: Brian Parent [mailto:bparent@calvin.ucsd.edu] Sent: Friday, August 20, 2004 2:41 PM To: toasters(a)mathworks.com Subject: Re: IPsec NFS to Unix clients Thanks Mark. We do have CIFS. However, we have >30,000 accounts, and >300 NFS clients. And besides, any account is allowed access from any NFS client. Plus, it doesn't solve the problem of spoofing IPs. We don't have MultiStore, but even if we did, I don't see how it solves the problem of spoofing IPs. Spoofing IPs is painfully simple here, (as at most Universities, I would think) where labs aren't supervised, and network jacks are not physically secured. Re: > Subject: RE: IPsec NFS to Unix clients > Date: Fri, 20 Aug 2004 13:31:42 -0700 > From: "Muhlestein, Mark" <mark.muhlestein(a)netapp.com> > To: "Steve Losen" <scl(a)sasha.acc.virginia.edu>, > "Brian Parent" <bparent(a)calvin.ucsd.edu> > Cc: <toasters(a)mathworks.com> > > Here are a couple of other things you can do to improve NFS security: > > 1. If you have CIFS you might consider using the > nfs.require_valid_mapped_uid option. That allows you to set up the > usermap.cfg file to do things like this: > > # allow the following UIDs NFS access from the specified IP addresses > tom <= 192.168.3.34:tom > jerry <= jerrypc.dorm.foo.edu:jerry > jerry <= lab1.foo.edu:jerry > jerry <= lab2.foo.edu:jerry # etc. > > # allow root from the admin network > Administrator <= 10.10.20.0/24:root > > # prevent all other NFS access > "" <= * > > The nfs.require_valid_mapped_uid option causes the usermap.cfg entries > to be consulted even for access to data on qtrees with UNIX security. > Combined with the normal export controls, this approach works as long as > clients are not allowed to successfully spoof source IP addresses. It is > also more manageable if the number of combinations of users/hosts is not > overly large or dynamic; however I know we have had sites that have used > this type of approach with a script-generated usermap.cfg. > > 2. If you have MultiStore available you can also use that to fence off > NFS access. NFS clients accessing an IP address associated with a vfiler > are not allowed to access storage assigned to another vfiler. This is > enforced at the WAFL layer, so even if clients attempt handle spoofing > the access is denied as long as the potentially rogue clients are not > allowed to access the other vfilers' IP addresses (e.g. different > networks on separate NICs). > > Mark

2 2

RE: McAfee A/V config
by Merkin, David S 02 Feb '05

02 Feb '05

Did this happen when you upgraded to 6.5.2? -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of jeff.mery(a)ni.com Sent: Monday, January 31, 2005 12:18 PM To: toasters(a)mathworks.com Subject: McAfee A/V config The basics: - F940c systems (one cluster) - ONTAP 6.5.2 - ~4.4 TB of data (90% CIFS) - McAfee VirusScan 7.1 for NetApps - 6 x scanner systems (4 x PowerEdge 650SC, 2 x Precision 420) - All scanners scan both filers - All GbE, all systems & filers on same subnet We've been having a small problem with our McAfee virus scanners lately; they all periodically drop off-line causing much havoc with our pagers. Suggestions from McAfee are that the scanners become too busy and when that happens, they drop off line and reset themselves. However, performance indicators on the scanners don't indicate any problems: CPUs almost idle, no disk I/O, very little network activity. From a filer stand-point, they're practically idle: CPU time averages less than 20%, network and disk I/O is minimal. I'd like to hear how some of you have your McAfee environments configured and what (if any) issues you've had similar to this one. As usual, much thanks in advance! Jeff Mery - MCSE, MCP National Instruments ------------------------------------------------------------------------- "Allow me to extol the virtues of the Net Fairy, and of all the fantastic dorks that make the nice packets go from here to there. Amen." TB - Penny Arcade -------------------------------------------------------------------------

3 2

[SUMMARY]: Archiving, R200 and SnapVault.
by Ngoh, Clarence 31 Jan '05

31 Jan '05

Thanks to the following people who replied: Aaron Hill Bill Holland It turns out that at the end of the day, using SnapVault was not the most straighforward solution. We simply wish to copy an EOM (end-of-month) snapshot to the R200 temporarily to conserve snapshot space on the production filer whilst getting our backup problem fixed. The use of Snapvault did not meet our need to duplicate the whole volume when compared to how how SnapMirror duplicates its volume. One of the significant difference between the two is that the basic unit in Snapvault is NOT the valume, but the qtree. As such, a transfer must be made to replicate each qtree. It was also pointed out that complexity is added to the restoration process because a snapshot from SnapVault is essentially restored and Snapvault has its way of doing its thing. A third point of complexity is configuring Veritas NetBackup to backup the snapshot - an option that we are not willing to experiment with. So, what are we doing? We have two volumes that are running low on disk space on the Production filers. We have created two volumes on the R200 to reflect those on production and we are snapmirring these across. Once the data is replicated, we remove the older EOM snapshot to free disk space. Backups of the snapshots are then done via 3-way-NDMP. A much more simple and elegant solution. Cheers Clarence. > -----Original Message----- > From: Ngoh, Clarence [mailto:clarence.ngoh@cba.com.au] > Sent: Friday, 28 January 2005 2:51 PM > To: toasters(a)mathworks.com > Subject: Archiving, R200 and SnapVault. > > > G'day toaster folks, > > Our backups in Lidcombe are having issues completing its > backups - the cause is yet unknown. As a result of our EOM > backups not completing successfully, it is eating into our > snapshot space. We have raised a case with NetApp and we are > trying to isolate the root case of the problem. I am not > after suggestions to fix this at the moment. Rather ... > > We have just purchased a R200 for achiving purpose and we are > thinking of > utilising this to alleviate the issue we are having. We > wish to dump some > of the EOMs to this box and backup to tape when we resolve > the backup issue. > > > Our scenario is common ... A production site and a DR site. > > We backup our EOMs at the DR site. We are wondering if the > process is as > simple of copying over the EOM snapshots from the DR filer to > the R200 via SnapVault and configuring our backups (Veritas > NetBackup) to backup from the R200 to cassette. > > Question : From what I have read, backups to cassette can be > done straight from the R200. Any real life experiences to > share? Are they any caveats that we should be aware of? > > Sorry if this question seems somewhat simple -- I am still > ploughing through a pile of whitepapers at the moment, but > because this issue is somewhat urgent, any suggestions would > be much appreciated. > > > Cheers > Clarence. > > > ************** IMPORTANT MESSAGE ************** > This e-mail message is intended only for the addressee(s) and > contains information which may be confidential. > If you are not the intended recipient please advise the > sender by return email, do not use or disclose the contents, > and delete the message and any attachments from your system. > Unless specifically indicated, this email does not constitute > formal advice or commitment by the sender or the Commonwealth > Bank of Australia (ABN 48 123 123 124) or its subsidiaries. > We can be contacted through our web site: commbank.com.au. > If you no longer wish to receive commercial electronic > messages from us, please reply to this e-mail by typing > Unsubscribe in the subject line. > *************************************************************** >

2 1

McAfee A/V config
by jeff.mery＠ni.com 31 Jan '05

31 Jan '05

2 1

Re: Converting Netcache to Filer
by masterlolo 28 Jan '05

28 Jan '05

Model is C760 (700 series). Netapp system board V. The problem is why the server accept only netcache license and not nfs license ? Thanks, Laurent. ----- Original Message ----- From: "Reeves, Gary" <garyr(a)netapp.com> To: "masterlolo" <masterlolo(a)noos.fr> Sent: Wednesday, September 22, 2004 4:17 PM Subject: RE: Converting Netcache to Filer What Model Appliance ? if 7xx series, tel me what system board version it is. Open the chassis and pull forward, then look on the motherboard at the back and you should see something like "SYSTEM BOARD V or V or VII" let me know what model it is. One you can, another you can with difficulty and one you cant. Regards -----Original Message----- From: masterlolo [mailto:masterlolo@noos.fr] Sent: 22 September 2004 14:34 To: toasters(a)mathworks.com Subject: Re: Converting Netcache to Filer Hi all, I have replace the HS battery, now the system is ok, but after each initialize all disk the server tell me that i must enter a valid license. As if the server do not reconize my valid license for NFS or CIFS !!! but if I enter a license for netcache, the system valid it but the installation is a netcache system !!! Someone can help me about it ? Maybe jumper on motherboard ?? Thanks, Laurent. ----- Original Message ----- From: "masterlolo" <masterlolo(a)noos.fr> To: <toasters(a)mathworks.com> Sent: Saturday, September 18, 2004 11:51 AM Subject: Re: Converting Netcache to Filer > Hi all, > > I have unset netcache by this command : > ok unsetenv netcache > ok setenv netcache? false > > I have check environnement : > ok printenv > Variable Name Value Default Value > netcache? false > > That's ok at this point. > I boot on DATA ONTAP Diskettes, and choose " (4) Initialize all disks " at > the menu : > Zero disks and install a new file system? y > This will erase all the data on the disks, are you sure? y > Zeroing disks takes about 15 minutes..... > > I enter some configuration information (as hostname, ip...) & i am stopped > by " Please enter your license: " > I have tested to enter a valid license for nfs, cifs : " You must enter a > valid system license " > I have tested to enter a valid license for netcache : that's ok (but after I > have a system problem : low battery and the system shutdown !) > So I would like to know if it's right to enter netcache license to convert > netcache in filer ?? > Do must change the netcache firmware to filer firmware ?? > > Thanks for your help, > Laurent. >

2 1

RE: Solaris patch 118463-01, NetApp filers, and du
by Barnes, Simon 28 Jan '05

28 Jan '05

Hi Chris, Sorry it's taken me a while to reply. I'm very interested in your take on the Solaris 9 du patch, as I was instrumental in its creation. One of the customers I work with at NetApp had noticed that du returned a "cycle detected" error in Solaris 9, whereas it had not in Solaris 8. (Incidentally, I'm told Solaris 10 doesn't return this error either). With the help of my customer and Sun, we were able to identify the code change which had provoked this behaviour. As I understand it, Sun's patch does indeed, as you say, revert to the earlier Solaris 8-like behaviour, in that it ignores the error condition rather than fall over when it hits it. (Although Sun themselves are far better placed to comment than I am). This is what the customer in question wanted from the patch. Unfortunately I will be out of the office all of next week (back on 7th February), but I'd be happy to discuss this further with you when I return. My customer, I'm sure, would also be most interested to hear what you think of this solution, as so far he appears to be the only one to have reported this issue to us - unlikely as that sounds. Please feel free to drop me a line or give me a call. Regards, Simon. Simon Barnes Technical Global Advisor (TGA) Network Appliance simonb(a)netapp.com Tel +31 (0)23 5644262 Mobile: +31 (0)655 773100 -----Original Message----- From: Chris Thompson [mailto:cet1@cus.cam.ac.uk] Sent: Thursday, January 20, 2005 12:37 PM To: toasters(a)mathworks.com Subject: Solaris patch 118463-01, NetApp filers, and du I posted an article about this in the comp.unix.solaris newsgroup back in early December, but I didn't get any response. Maybe I will have more luck here. A patch 118463-01 was released by Sun for Solaris 9 du(1) on 2004-12-06. It "fixes" 5068958 Solaris 9 du exits with "cycle detected" The description of this on SunSolve includes the following: | Description: | | Solaris 9 du exits with: | | du: failed for /: Cycle detected from XXX to XXX | | when a hardlink in the filesystem is detected. While at first sight | this seems reasonable behaviour due to the potentially harmful nature | of hardlinked directories, there is a genuine need to handle this in a more graceful way. | | One such example comes from using a NetApp File Server with snapshots. | The NetApp server exports snapshot heirarchies with file ids (aka | inode | numbers) which appear to be identical to existing directory file ids. | | While this is an implementation issue concerning the interaction | between Sun's NFS clients and NetApp File Servers, in the interests of | interoperability, the Solaris 9 du should simply ignore directories | with apparent duplicate inode numbers. I wonder what other users of Solaris in conjunction with NetApp filers think of this? Personally I thought the change in Solaris 9 was positively beneficial ... an error (even if obscurely expressed from the end-user's point of view) rather than a totally misleading result. It might have been useful if the patch had been to produce warning messages "I've seen this directory inode number before, I'm leaving this [snapshot] out of the space calculation altogether" and carry on with the rest of the tree. (One might think that this was what was implied by "simply ignore directories with apparent duplicate | inode numbers".) But it seems that it actually restores the Solaris 8-and-earlier behaviour, in which you get a total which is a naive sum over all snapshots, which is never (well, hardly ever) meaningful. Chris Thompson Email: cet1(a)cam.ac.uk

1 0

RE: iSCSI and OnTap 7 on F720
by Worby, Chris, VF UK 28 Jan '05

28 Jan '05

Gil, The F720 is not supported hardware for Ontap 7. Extract from Data ONTAP 7.0RC4 Release notes: > Requirements for Running Data ONTAP 7.0RC4 > Supported systems The following storage systems are supported: > FAS900 series > FAS200 series > NearStore R200 > NearStore R150 > NearStore R100 > F800 series > F87 > > Note: > Starting with this release the F700 series and the F85 are no longer supported. > Chris Worby Storage Management, Information Systems, Vodafone UK Vodafone Limited Site Address: Maxwell House, Newbury Business Park, London Road, Newbury, Berkshire RG14 2PZ Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No 1471587 -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Gil Freund Sent: 28 January 2005 11:59 To: toasters(a)mathworks.com Subject: iSCSI and OnTap 7 on F720 Hi, I have an F720 used for CIFS and NFS on a site with about 30 users and a 4 port VIF (100Mbit/s x 4). The filer in constant use, but is not under heavy load. We would like to move data which is in DAS (mainly our mail store, which is a Cyrus IMAP server on Linux), which we would like to move to the filer. Since I don't want to use NFS for this, and the virtual volumes would be very handy in NDMP backups I was wondering whether it made sense to use those on an F720. Any thoughts / field notes welcome Gil

2 1

NFS hangs from linux clients
by Gil Freund 28 Jan '05

28 Jan '05

Hi, We have three Debian systems (two with 2.6.x Kernel and one with 2.4) using a NetApp 720 (6.5.3) as an NFS server. On two occasions in the last two weeks, when one of the Linux hosts tried to mount a file system from the netapp we got the error: Host nono not responding. (nono being the filer name) From that moment, no action could be preformed from any of the Linux hosts on the netapp. We see not errors in the log files of either the Linux nor the netapp. Other functions (CIFS, NIS and DNS lookups) continue with not issues. Attempting to stop and start the NFS service on the netapp did not have any effect, neither did rebooting the clients. The only workaround was rebooting the filer, after which all NFS operations resumed without a problem. I have started a trace on NFS, but did not get the same hangup yet. Did anyone encounter a similar situation, or alternatively can advise on where and what to check? Thanks Gil

4 5

Re: NFS hangs from linux clients
by Gil Freund 28 Jan '05

28 Jan '05

Yizhong Zhou wrote: > > Hi Gil, > > You may want to try 1) forcing tcp (using '-o proto=tcp' on client's > mount command); 2) lowering udp transfer size to 8192 > (using '-o rsize=8192,wsize=8192' on client's mount command). We currently use: rsize=8192,wsize=8192,timeo=14,intr on our fstab. I will look into the tcp option > > We experienced the hanging problem with Linux clients (mostly 2.4 > kernels). Reducing the udp transer size greatly alleviated the problem > and forcing tcp further improve the situation. Starting at kernel 2.4.x > (forgot what x exactly is), they started to use 32KB as the default udp > transfer size. My understanding is that the Linux NFS clients' default > buffer size is too small causing lots of packet loss and retransmission. > This translates to the hanging and 'nfs server not responding' problem. Thanks > > > Yizhong Zhou zhou(a)mathworks.com, (508) 647-7371 > The Mathworks, Inc. 3 Apple Hill Drive, Natick, MA 01760 > > > On Thu, 27 Jan 2005, Gil Freund wrote: > > >>Hi, >> >>We have three Debian systems (two with 2.6.x Kernel and one with 2.4) >>using a NetApp 720 (6.5.3) as an NFS server. >> >>On two occasions in the last two weeks, when one of the Linux hosts >>tried to mount a file system from the netapp we got the error: >>Host nono not responding. >>(nono being the filer name) >> >> From that moment, no action could be preformed from any of the Linux >>hosts on the netapp. We see not errors in the log files of either the >>Linux nor the netapp. >>Other functions (CIFS, NIS and DNS lookups) continue with not issues. >> >>Attempting to stop and start the NFS service on the netapp did not have >>any effect, neither did rebooting the clients. >> >>The only workaround was rebooting the filer, after which all NFS >>operations resumed without a problem. >> >>I have started a trace on NFS, but did not get the same hangup yet. >> >>Did anyone encounter a similar situation, or alternatively can advise on >>where and what to check? >> >> >>Thanks >> >>Gil >> >> > > > -- ================================================ Gil Freund Systems Analyst ------------------------------------------------ Sysnet consulting POB 396 Rehovot 76103 Israel email: gilf(a)sysnet.co.il http://www.sysnet.co.il voice: +972-54-2035888 Fax: +972-8-9356026 ================================================

1 0

iSCSI and OnTap 7 on F720
by Gil Freund 28 Jan '05

28 Jan '05

Hi, I have an F720 used for CIFS and NFS on a site with about 30 users and a 4 port VIF (100Mbit/s x 4). The filer in constant use, but is not under heavy load. We would like to move data which is in DAS (mainly our mail store, which is a Cyrus IMAP server on Linux), which we would like to move to the filer. Since I don't want to use NFS for this, and the virtual volumes would be very handy in NDMP backups I was wondering whether it made sense to use those on an F720. Any thoughts / field notes welcome Gil

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 January 2005