toasters

toasters@lists.teaparty.net

2 participants
13529 discussions

32-bit vs. 64-bit FC-AL adapters
by Brian Tao 10 Jul '99

10 Jul '99

I just noticed this on our clustered pair of F740's. The on-board (slot 0) adapter is listed as a 64-bit device, while the secondary adapter (slot 1, connecting to its partner's disk shelf) is listed as a 32-bit device. Is this right? NetApp Release 5.2.2: Sat Apr 17 04:15:20 PDT 1999 System ID: 0016791871 (nfs3); partner ID: 0016791820 (nfs4) slot 0: System Board Memory Size: 512 MB slot 0: FC adapter: isp2100 (chip rev. 3, 64-bit) Firmware rev: 1.15.2 Host Loop Id: 119 FC Node Name: 2:000:00a098:035eff Cacheline size: 8 FC Packet size: 2048 7 Disks: 119.0GB 1 shelf with Eurologic EDM SCSI Host Adapter 0b In-Band Enclosure Services slot 0: Ethernet Controller e0 MAC Address: 00:a0:98:00:50:46 (auto-100tx-fd-up) slot 1: FC adapter: isp2100 (chip rev. 3, 32-bit) Firmware rev: 1.15.2 Host Loop Id: 119 FC Node Name: 2:000:00e08b:00c089 Cacheline size: 8 FC Packet size: 2048 7 Disks: 119.0GB 1 shelf with Eurologic EDM slot 3: Ethernet Controller e3 MAC Address: 00:c0:95:fa:cd:7b (auto-100tx-up) slot 8: Interconnect adapter slot 9: NVRAM Memory Size: 32 MB -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 0

(no subject)
by Mohler, Jeff 08 Jul '99

08 Jul '99

1 0

ForSale F330
by Wifehnter1＠aol.com 08 Jul '99

08 Jul '99

F 330 128megs Ram 2 SCSI controllers 4 meg Cache 4 drive rack consisting of 28 4.3 gig drives This unit is only 18 months old! Craig R. von Esch

2 1

Re: NIS Problems
by dnb＠ccs.neu.edu 07 Jul '99

07 Jul '99

"Sivo, Peter " <peter.sivo(a)netapp.com> writes: > Is this the reason that you all do this? I thought it was because > Corp IT never had reliable NIS services and you were binding to a > server that you knew was "blessed" and stable? On the whole, our NIS servers are rock solid. We bind to a specific IP address for the reasons Jay stated (namely we know not to trust NIS, and especially NIS broadcasts as far as we can throw it/them). > The questions, though, is that are people going to continue to hardcode in a > server, so even if I had 5 NIS servers/slaves per network, it wouldn't make a > difference? There are two separate issues here: 1) The current NetApp NIS client code (especially when run with a single server specified as we do) isn't particularly robust. If we could specify 5 IP addresses instead of one, and the failover went smoothly, this would help quite a bit. Plus you could specify hosts in a different broadcast domain (perhaps on a more protected subnet). 2) NIS will never be secure, but being able to tell a filer not to pay attention to any one who pretends to be your NIS server (via specifying addresses) is a good thing. Not the perfect thing, but better than the current status quo. Besides the scenario Jay proposed where the rogue server is available before the real one after a power blink, you could also probably throw enough of a denial-of-service against either the filer or the NIS server to cause the filer to attempt a rebind. If your filer rebinds to the rogue... To directly answer your question, it's the sixth NIS server on your net (that you didn't put there) that's the real bummer. Peace, dNb eagerly looking forward to the new NIS code

1 0

Re: NIS Problems
by Devi Nagaraj 06 Jul '99

06 Jul '99

Hi, We are revamping our NIS client implementation, one of the changes being an option to specify multiple preferred NIS servers. Please get in touch with NetApp for more information on the availability of these changes. Thanks, -Devi At 09:49 AM 7/6/99 -0600, Graham C. Knight wrote: >Sean Hinchey wrote: > >> >> Does anyone have any recommendations or are we stuck with less stable NIS >> client? >> >> -Sean > >After battling this same problem for months i finally >put some hooks into my makefile.nis that copies >the files locally to all our filers and turned >off NIS. You are correct, Netapp's are not good >NIS clients. > >Graham > >

1 0

RE: NIS Problems
by sirbruce＠ix.netcom.com 06 Jul '99

06 Jul '99

On 07/06/99 11:15:39 you wrote: >Is this the reason that you all do this? I thought it was because Corp IT never >had reliable NIS services and you were binding to a server that you knew was >"blessed" and stable? Hey, NIS services were stable when *I* left Netapp. If you've had problems since then drop me a line and I'll be happy to help out. >Anyways, I'm the Corp IT Manager watching over the LAN, and a boatload of >services, including NIS at this time. I know that Duane is installing new NIS >servers/slaves per network over in San Tomas to improve the quality of our NIS >services. This isn't going to help NIS stability unless it is done correctly. In any case the files should be copied locally to the filers anyway, as was the case when I left Netapp and as others have suggested. If you really want to improve QoS you'll need to realize that some things that the filer does (such as NIS client functionaltiy) are not reliable enough for some networks, and one such network may be yours. >The questions, though, is that are people going to continue to hardcode in a >server, so even if I had 5 NIS servers/slaves per network, it wouldn't make a >difference? Unless you control *every* device on those networks (and I suspect you don't), not hardcoding for a server (although it should be *multiple* servers) is just asking for trouble. It all depends on what your environment is. You can also run into problems with loading... balancing by hand has many advantages. And you always have the local files to fall back on. Jay has it exactly right, and sounds like he speaks from experience. These are practical things you learn that are difficult to teacher younger incoming admins who think things should just work. :) Perhaps someday LDAP can eliminate all of this mess. Bruce

1 0

RE: NIS Problems
by Sivo, Peter 06 Jul '99

06 Jul '99

Is this the reason that you all do this? I thought it was because Corp IT never had reliable NIS services and you were binding to a server that you knew was "blessed" and stable? Anyways, I'm the Corp IT Manager watching over the LAN, and a boatload of services, including NIS at this time. I know that Duane is installing new NIS servers/slaves per network over in San Tomas to improve the quality of our NIS services. The questions, though, is that are people going to continue to hardcode in a server, so even if I had 5 NIS servers/slaves per network, it wouldn't make a difference? (no, we aren't doing 5, ;) but I just threw that out to make a point) Thanks. -----Original Message----- From: Jay Sekora [mailto:jay@ccs.neu.edu] Sent: Tuesday, July 06, 1999 9:43 AM To: toasters(a)mathworks.com Subject: Re: NIS Problems "Graham C. Knight" <grahamk(a)ast.lmco.com> wrote: > After battling this same problem for months i finally > put some hooks into my makefile.nis that copies > the files locally to all our filers and turned > off NIS. You are correct, Netapp's are not good > NIS clients. Another thing to bear in mind is the risk of somebody dropping a laptop on the net with an NIS server claiming to serve your NIS domain. (Think laptop on battery power after a power outage - the legit NIS server is likely to come up after the NetApp, so the intruder's laptop is the only thing there to reply to NIS requests.) If somebody can do that, then they own all the files on the filer. For this reason, we don't broadcast for an NIS server, but explicitly bind to a particular server out of /etc/rc . The problem is that if that machine ever goes down, even for a short time, the NetApp loses its binding to it and we have to re-bind to it by hand. Copying the files to the NetApp would definitely be more robust. (IP spoofing is another potential problem, of course.) -j. Jay Sekora <jay(a)ccs.neu.edu> Unix Systems Administrator Northeastern University College of Computer Science

1 0

Re: NIS Problems
by Jay Sekora 06 Jul '99

06 Jul '99

"Graham C. Knight" <grahamk(a)ast.lmco.com> wrote: > After battling this same problem for months i finally > put some hooks into my makefile.nis that copies > the files locally to all our filers and turned > off NIS. You are correct, Netapp's are not good > NIS clients. Another thing to bear in mind is the risk of somebody dropping a laptop on the net with an NIS server claiming to serve your NIS domain. (Think laptop on battery power after a power outage - the legit NIS server is likely to come up after the NetApp, so the intruder's laptop is the only thing there to reply to NIS requests.) If somebody can do that, then they own all the files on the filer. For this reason, we don't broadcast for an NIS server, but explicitly bind to a particular server out of /etc/rc . The problem is that if that machine ever goes down, even for a short time, the NetApp loses its binding to it and we have to re-bind to it by hand. Copying the files to the NetApp would definitely be more robust. (IP spoofing is another potential problem, of course.) -j. Jay Sekora <jay(a)ccs.neu.edu> Unix Systems Administrator Northeastern University College of Computer Science

1 0

NIS Problems
by Sean Hinchey 06 Jul '99

06 Jul '99

Over the past few months, for various reasons, our F630 has lost it's connection to our NIS slave. Pretty well every time this happens the filer decides not to serve either NFS or CIFS clients(usually CIFS). The only way to get the machine to serve data again is to run ypset and have it bind to a new NIS slave or(as a last resort) reboot the filer and have it automatically discover another slave. Shouldn't the filer bind itself to a new NIS slave after some timeout period without any intervention? We're currently running DOT 5.3.1 but have seen the problem on several 5.2 versions. Does anyone have any recommendations or are we stuck with less stable NIS client? -Sean

2 1

(no subject)
by Krzysztof Miller 05 Jul '99

05 Jul '99

subscribe toasters

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