toasters

toasters@lists.teaparty.net

13520 discussions

DNS problems
by Mohler, Jeff 29 Apr '99

29 Apr '99

Anyone else figure out the heck to resolve this? 08:56:23 CDT [ratbert: rshd_0]: DNS server for domain "wcg.net" not responding : Connection timed out. MY blinkin DNS servers are working just fine...all of 30,000 miles of fiber hardware, routers, and customers have no problems with it either. Why only the NetApp, and a reboot isnt an option.

5 6

Re: netapp meets bugtraq. again.
by sirbruce＠ix.netcom.com 29 Apr '99

29 Apr '99

On 04/28/99 22:06:43 you wrote: >Ok, so I don't have the docs handy.. but if you have an "-access" >options, it just seems kinda intuitive to me that you might actually >*USE IT*. But maybe it's just me. No bug here... that's the way all NFS servers work. It is a little non-intuitive but once you know what you're doing there is no problem. Changing it for Netapp would create another kind of security bug where simply copying what you used on one server wouldn't work on another despite expectations. The problem lies in the documentation, for not explaining this more clearly. The example isn't meant to be taken literally as something all filer admins should do and thus would be appropriate for their environment. It's meant to be an example. Elsewhere the docs do explain the security implications of various options, but it should probably mention it specifically in the section Pete read, to prevent other people overreacting like Pete did and screaming to bugtraq that the sky is falling. Bruce >------- Start of forwarded message (RFC 934 encapsulation) ------- >From: pashdown(a)XMISSION.COM (Pete Ashdown) >Subject: Network Appliance NFS filer root hole >Date: 28 Apr 1999 15:58:45 -0400 >Organization: Bugtraq List >Message-ID: <199904281658.KAA14944(a)slack.xmission.com> >Reply-To: Pete Ashdown <pashdown(a)XMISSION.COM> > >For Network Appliance NFS filer release: > NetApp Release 5.2.1: Thu Dec 31 12:56:45 PST 1998 > >Following "Example 1" on page 136 of the "System Administrator's Guide" for >the Network Appliance results in a gaping hole. In this example, they >explain that "the following line exports the root directory of the default >filter volume to the administration host with root privileges." > > /vol/vol0 -root=adminhost > >This is all fine and good, but it also exports to the WORLD with root >privileges. You have to specify either "-access", or "-rw", or "-ro" in >addition to "-root" for this not to happen. When I mentioned this to my >NetApp SE, I was met with quizzical looks, but no code-update or patch. >Thusly, I sent it to bugtraq. >------- End -------

1 0

Re: SNMP traps
by Keith Brown 28 Apr '99

28 Apr '99

>Seems like the only built-in traps are "linkUp", "linkDown", "coldStart" and >"authenticationFailure", others you have to add manually which would take >_awhile_ to do. Right. The new SNMP trap machinery provided in Data ONTAP 5.3 is very flexible and extremely powerful. As you have probably seen in the documentation, it actually enables you to set a variety of different types of trap on any supported MIB variable you like. You can monitor variables for crossing administrator defined thresholds in either direction (rising above or falling below). You can monitor variables for staying within administrator defined ranges, or even *outside* of ranges if that makes sense for a particular value. You can keep traps firing when variables stay on the wrong side of "lines" (with a backoff cabability). It's thoroughly wicked. However, one of the last little things that unfortunately didn't get implemented in time for the 5.3 release was the "spoon feed some nice traps on a silver platter" component. :-) As you have discovered, you currently have to look at the filer MIB(s) yourself, figure out what variables you are interested in monitoring in your environment, and then put the relevant traps on them "by hand". Sophisticated administrators will probably *always* want to go through such a procedure, but it is not unreasonable to want to be supplied some "starter traps" on the kinds of events that are likely to be interesting to the majority. We do supply a small handful (which you note above), but there's obviously more we could do here, such as: >I am interested in things like: failed disks, stopped fans, cluster status >etc. Yep. In fact, we are always actively seeking input on the kinds of default traps our customers would like to have supplied "out of the box". Any input posted either here or to my inbox will be seen by the folk who can turn the requests into reality. >http://now.netapp.com/knowledge/docs/ontap/rel53/html/sag/net2.htm says >there should be a "traps.dat" file in "the same directory as the MIB" >(=/etc/mib??) but I am unable to locate this file. I'll see if I can find out what happened to it for you. :-) Keith

1 0

SNMP traps
by Erik Stjerna 28 Apr '99

28 Apr '99

Has anyone set up trap definitions for monitoring a filer? Seems like the only built-in traps are "linkUp", "linkDown", "coldStart" and "authenticationFailure", others you have to add manually which would take _awhile_ to do. I am interested in things like: failed disks, stopped fans, cluster status etc. Would be really handy if someone already has done this and is willing to share that info. http://now.netapp.com/knowledge/docs/ontap/rel53/html/sag/net2.htm says there should be a "traps.dat" file in "the same directory as the MIB" (=/etc/mib??) but I am unable to locate this file. Thanks in advance, Erik Stjerna

1 0

please add me to distribution/reflector list
by Horgan, Patrick 28 Apr '99

28 Apr '99

Please add me to distribution/reflector list. horgan_patrick @emc.com Thank you. ~Patrick ____________________________________ EMC2 Patrick A. Horgan Product Manager - Celerra File Server e-mail: horgan_patrick(a)emc.com <mailto:horgan_patrick@isus.emc.com> phone: 508-435-2075 x75672 fax: 508-435-8903 ____________________________________

1 0

EMC email list (was RE: remote support issues)
by Adams, Christian 27 Apr '99

27 Apr '99

G D Geen, Please find the following email to identify the EMC email list/archive as you requested. /Christian Adams System Engineer EMC >Resent-From: emc-request(a)interex.org >Resent-Date: Fri, 18 Dec 1998 15:51:32 -0800 (PST) >X-Sender: bill(a)proaxis.com >X-Mailer: Windows Eudora Pro Version 3.0 (32) >Date: Fri, 18 Dec 1998 15:48:19 -0800 >To: emc(a)interex.org, haforum(a)interex.org >From: Bill Lancaster <bill(a)proaxis.com> >X-Mailing-List: <emc(a)interex.org> archive/latest/2 >X-Loop: emc(a)interex.org >Resent-Sender: emc-request(a)interex.org >Subject: [EMC:2] Welcome! > >Hello and welcome to all who have joined the EMC list! The list was just >created this week and now has 127 people signed up! Clearly, you all have >an interested in seeing a public forum for users of EMC equipment. > >The genesis of this list came through meetings held between the Interex >High Availability Forum members and various EMC staff at EMC headquarters >in December. (There is also a listserver specializing in HP-related High >Availability issues, including EMC issues). The High Availability Forum >Executive Committee members are: > > Myself (Bill Lancaster), co-chair > Chuck Ciesinski, co-chair > Isaac Blake > Steve Guzzi > Chris Rink > Gary Maness > Wesley Sawyer > Deb Lawson (Interex liaison) > >Bob Yach is chairing the EMC SIG. > >I'd like to start the ball rolling by asking all of you what your >discussion interests are for this list. Do you have any pressing concerns >that you would like to throw open for discussion? I understand that >several EMC personnel are participating in this list so you should stand a >good chance getting answers to issues/questions. What kind of EMC >equipment are you using? How has it added to your high availability? > >Jump on in! > > >Bill Lancaster >bill(a)proaxis.com > -----Original Message----- > From: G D Geen [SMTP:geen@msp.sc.ti.com] > Sent: Friday, April 23, 1999 7:02 AM > To: rhodesr(a)firstenergycorp.com > Cc: toasters(a)mathworks.com > Subject: Re: remote support issues > > If you have problems with support, bring it to the attention > of your Sales Advisor. NetApp is very good about communicating > internally the issues of their customers. Also some very heavy > hitters at NetApp read this mail list. So use this forum to > address your concerns. Please note, NetApp is not the only > provider of network filers out there. If you are not happy, > ask Auspex why they don't have a mail list like this. I did and > was surprised by the answer. I have not asked EMC about a mail > list yet, but I am interested in hearing the answer. >

1 0

RE: Digital UNIX clients -- no non-root access
by Davis, John 27 Apr '99

27 Apr '99

I have a site here(CFO 5.2.1P2-F740) attached to a DEC running 4.0E via GigE that is using NFS & CIFS; save installing some DEC patches for their GigE card the system has been running fine.. -----Original Message----- From: Muhlestein, Mark [mailto:mark.muhlestein@netapp.com] Sent: Monday, April 26, 1999 7:49 PM To: 'sirbruce(a)ix.netcom.com'; jgaski(a)WPI.EDU; toasters(a)mathworks.com Subject: RE: Digital UNIX clients -- no non-root access I'm not sure what your problem is, but I can verify that internally here at NetApp we use DU 4.0D (rev 878) extensively on several Alpha machines against multiple filers with no issues. We have also run with 4.0E. What version of the filer software are you running? Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: sirbruce(a)ix.netcom.com [mailto:sirbruce@ix.netcom.com] Sent: Monday, April 26, 1999 6:39 PM To: jgaski(a)WPI.EDU; toasters(a)mathworks.com Subject: Re: Digital UNIX clients -- no non-root access On 04/26/99 21:11:27 you wrote: >I have an open call with Network Appliance, but they have said that >there must be something strange in Compaq's implementation of the NFS >client. The same error occurs on Digital UNIX 4.0D pl3, 4.0E pl1, and >5.0 beta. It occurs whether the mount is soft or hard, udp or tcp, >nfsv3 or nfsv2. > >It seems like such a large, ubiquitous error that I can't believe >noone would have seen it before. I thought that Digital UNIX support >was standard, and I can't imagine how all of our Alpha clients could >be non-standard in such a way. You'd be surprised. Lots of vendors have little quirks in their implementation that, while they happen to work okay with one server, are really out of spec and may not work with another. However, I know that Digital Unix *used* to work, but the last I ever saw personally work was 4.0C. So either they've changed something, or something in the new Netapp release fixed/broke something. Bruce

1 0

Re: Early Access Releases
by sirbruce＠ix.netcom.com 27 Apr '99

27 Apr '99

On 04/26/99 17:11:16 you wrote: > So who tested cluster takeover/giveback during the "comprehensive > development and release procedure"...? Can they tell me what I'm > doing wrong? Was bug 14194 (Filer crashes during boot during > partner giveback) discovered during this testing and 5.3 was > released anyway? If so, I think you guys are carrying that MS > partnership a bit too far... > > Ok, maybe comparing you guys to MS was below the belt. I'll take > that back. But I'm still curious how 5.3 made it as far as it did? > I thought clustering was the hot new thing at NetApp. > > Did somebody decide a boot during giveback was ok for now? It's > not a problem until the partner s fixed or until your testing to > see that you got what you paid for. If this was the case, a "known > bugs list" would've been nice. I believe Netapp has said before publically that they do find bugs during testing that they don't fix by release time. This is not to say that they don't fix any, but that little bugs or big bugs that only appear under relatively rare circumstances won't be addressed until a later release. I've suggested before that Netapp publically reveal bugs that have only been discovered internally at Netapp, but I think their current policy is only to reveal bugs online that customers have encountered themselves. So it is possible they discovered the bug in advance and didn't think anyone (or perhaps very few) would encounter it. Or perhaps they didn't. They do have pretty big testing procedures for new software releases but I don't think they regression test every possible scenario. Bruce

2 1

Re: Digital UNIX clients -- no non-root access
by sirbruce＠ix.netcom.com 27 Apr '99

27 Apr '99

On 04/26/99 21:11:27 you wrote: >I have an open call with Network Appliance, but they have said that >there must be something strange in Compaq's implementation of the NFS >client. The same error occurs on Digital UNIX 4.0D pl3, 4.0E pl1, and >5.0 beta. It occurs whether the mount is soft or hard, udp or tcp, >nfsv3 or nfsv2. > >It seems like such a large, ubiquitous error that I can't believe >noone would have seen it before. I thought that Digital UNIX support >was standard, and I can't imagine how all of our Alpha clients could >be non-standard in such a way. You'd be surprised. Lots of vendors have little quirks in their implementation that, while they happen to work okay with one server, are really out of spec and may not work with another. However, I know that Digital Unix *used* to work, but the last I ever saw personally work was 4.0C. So either they've changed something, or something in the new Netapp release fixed/broke something. Bruce

1 0

Digital UNIX clients -- no non-root access
by Joanna Gaski 27 Apr '99

27 Apr '99

We have recently obtained an F740. I have a problem when I attempt to export a shared area from the filer to any of our Digital UNIX clients. The problem is that on the alpha client, root can read and access files as normal, but if a normal user does even something as simple as a ls -lt /mnt an error message is produced: NFS3 RFS3_ACCESS failed for server toaster : RPC: Server can't decode arguments /mnt: I/O error The exports file has the share exported with -ro,access=hostname,root=hostname where hostname is a FQDN. I have an open call with Network Appliance, but they have said that there must be something strange in Compaq's implementation of the NFS client. The same error occurs on Digital UNIX 4.0D pl3, 4.0E pl1, and 5.0 beta. It occurs whether the mount is soft or hard, udp or tcp, nfsv3 or nfsv2. It seems like such a large, ubiquitous error that I can't believe noone would have seen it before. I thought that Digital UNIX support was standard, and I can't imagine how all of our Alpha clients could be non-standard in such a way. Any help or pointers are appreciated. Thanks. (BTW, I haven't yet dealt with the fact that when exporting from the filer to one of our ULTRIX boxes, a simple "ls -lt /mnt" by a non-root user results in the mount point changing to these permissions, and the share essentially disappearing. ---------- 0 root 0 Dec 31 1969 /mnt I'll get to that eyesore later.)

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