toasters

toasters@lists.teaparty.net

3 participants
13514 discussions

NIS problem
by Haim Dimermanas 09 May '00

09 May '00

Hello, I have been spending days with tech support on this one, and nobody seems to have a clue. This is the first time I post on this list so please excuse me for any mistake contained within this message. I searched the archives of the list but did not find anything related to this problem. I have an F740 running 5.3.4R3. The box is not yet in production because of an annoying problem regarding NIS (also known as Yellow Page). My NIS server is a Linux box running Debian 2.1 with the kernel 2.2.14 and Portmap version 5. I must say that the dns resolution on the filer works, that I am able to mount shares from any clients in my class C (including the NIS server) and of course I can ping the filer from the NIS server and I can ping the NIS server from the filer. This makes me believe that the network part of it is fine. The problem is the following : the Filer does not have access to the maps when a single server is specified in the option nis.servers. It works with a lot of garbage in the logs when I specify server,* in this same option. Just in case it helps when reading the logs, my NIS server is named "aux" (ip : 192.168.1.152). The F740 is named "filer" (ip : 192.168.1.240). I took out the dates and time to make it easier to read. -------------------- First Scenario : options nis.servers my_nis_server Message on the filer : [nis_poll]: NIS server(s) not available Message on the NIS server : (repeated every minute or so) aux portmap[14166]: connect from 192.168.1.240 to callit(ypserv): request not forwarded 'ypcat group' on the filer : No such map group.byname. Reason: Local resource allocation failure Conclusion : it does not work :( ------------------ Second Scenario : options nis.servers my_nis_server,* Message on the filer : [nis_poll]: Bound to preferred NIS server 192.168.1.152 [nis_grp_updater]: Local NIS group update successful. (and the following every two minutes or so) [nis_main]: Preferred NIS Server 192.168.1.152 not responding [nis_main]: NIS server(s) not available [nis_poll]: Bound to preferred NIS server 192.168.1.152 Message on the NIS server : (every minute or so) aux portmap[14223]: connect from 192.168.1.240 to callit(ypserv): request not forwarded 'ypcat group' on the filer : Print the proper groups from the NIS map. Works to with ypcat passwd and ypcat hosts. Conclusion : it works, sort of. ------------------- So what exactly is happening? I have an explanation, but I am IN NO WAY SURE THAT IT IS THE CORRECT ONE. It just seemed to me that it would be the more possible one. I must say that I am in no way an NIS expert but I know Linux pretty well. All this to say that yes, the hosts.allow - hosts.deny and other yp.securenets are set correctly. I think the problem comes from the portmap security scheme. I looked into portmap source code and found this in pmap_check.c : /* * pmap_check - additional portmap security. [Stuff deleted] * Refuse to forward requests to NIS (YP) daemons; The only exception is the * YPPROC_DOMAIN_NONACK broadcast rpc call that is used to establish initial * contact with the NIS server. [More stuff deleted] */ line 89 : #define log_no_forward(addr, proc, prog) \ logit(deny_severity, addr, proc, prog, ": request not forwarded") line 200 (the actual check_callit function) : check_callit(addr, proc, prog, aproc) struct sockaddr_in *addr; u_long proc; u_long prog; u_long aproc; { #ifdef HOSTS_ACCESS if (!(from_local(addr) || good_client(addr))) { log_bad_host(addr, proc, prog); return (FALSE); } #endif if (prog == PMAPPROG || prog == NFSPROG || prog == YPXPROG || (prog == MOUNTPROG && aproc == MOUNTPROC_MNT) || (prog == YPPROG && aproc != YPPROC_DOMAIN_NONACK)) { log_no_forward(addr, proc, prog); return (FALSE); } if (verboselog) log_client(addr, proc, prog); return (TRUE); } I think it nails exactly where the problem is coming from. The Filer is sending a forward request and gets denied. Why does the filer do that after the broadcast, I don't know. I am not sure if the problem comes from the filer or from my portmap implementation on my NIS server (or even my server itsef). I do really hope someone out there has a clue. Thank you for reading this and I hope to get an answer soon. Haim. -- @o=qw(Nu Wjoepxt2l Mjdsptpgu);@p=("jt gvdlfe vq","jt tiju","tvdlt"); for($i=0;$i<@p;$i++){$o[$i]=~y/b-y/a-z/;$p[$i]=~y/b-y/a-z/;} while(){print $o[((rand)*3)]." ".$p[((rand)*3)]."\n";}

3 6

NetApp 202: Advanced System Admin
by Douglas Ritschel 09 May '00

09 May '00

Has anyone taken the "NetApp 202: Advanced System Administration and Troubleshooting for Network Appliance Filers class. And if so, was it useful? -- Douglas Ritschel Fujitsu Network Communications Two Blue Hill Plaza, Sixth Floor P.O. Box 1609 Pearl River, NY 10965 Ph: 914.731.2101 Douglas.Ritschel(a)fnc.fujitsu.com

4 3

RE: NetApp 202: Advanced System Admin
by Mohler, Jeff 09 May '00

09 May '00

I might add to this, that the 202 class has been rewritten top-to-bottom and is now a much more complete 2-day class than it was in the old format. It gets much deeper into the how and _why_ things happen in ONTAP, and the applies that to how to troubleshoot failures or performance issues as they come up in the field. It covers a lot of background for what will be considered 'certification' material in the future. -----Original Message----- From: Douglas Ritschel [mailto:Douglas.Ritschel@fnc.fujitsu.com] Sent: Monday, May 08, 2000 2:22 PM To: toasters(a)mathworks.com Subject: NetApp 202: Advanced System Admin Has anyone taken the "NetApp 202: Advanced System Administration and Troubleshooting for Network Appliance Filers class. And if so, was it useful? -- Douglas Ritschel Fujitsu Network Communications Two Blue Hill Plaza, Sixth Floor P.O. Box 1609 Pearl River, NY 10965 Ph: 914.731.2101 Douglas.Ritschel(a)fnc.fujitsu.com

1 0

revert_to
by jmiddlebrooks＠datalink.com 08 May '00

08 May '00

If you are at 5.3.4r2 and you want to back down to 5.3.4 do you first have to run revert_to 5.2 and then upgrade to 5.3.4? When you run revert_to is says you can only revert to 5.0, 5.1, or 5.2 Thanks for any help. Jason Middlebrooks Systems Engineer Datalink Corp. 888-933-9327 x2970

3 2

Re: Error from filer; bad RAM?
by Jamie A. Lawrence 08 May '00

08 May '00

>> Hi - >> >> Once again, Netapp tech support seems to be taking their sweet >> time about responding to my support email, so I'm going to folks >> that actually respond... >> >> Got this in the logs of one of my 720s. Is this telling me >> I've got bad RAM? > >There was an error in the J28 DIMM that was corrected, a couple of times. > >> It hasn't recurred since that date, but still worries me. > >Since it hasn't happened again, I wouldn't worry about it. >The timing seems to indicate that perhaps something was >going on unusual at that time, perhaps a raid scrub or a >heavy load from cron or somesuch? It is not unusual to >see more errors during times of heavier stress. > >You might want to consider reseating that DIMM just >to make sure it has a good connection. Then I wouldn't >worry unless you start seeing a LOT more errors. But >support may tell you different. > >Bruce Thanks, Bruce. Actually, it repeated several hundred times that night, never since. First time for that error in over a year in owning it, which is why it made me twitchy. Cron-wise, nothing interesting changed. Scrubbing has been going on forever. Yikes, I hate to play this loose with it, but it will be mirrored to another 720 in a few weeks, so hopefully it won't matter. We're extremely dependent on this filer. I know we're a minor player in Netapp's realm ( we own 4 720s ), but the lack of response for such a critical piece of machinery for me makes me wonder. Guess I won't blow off the next EMC call that is due to hit voice mail in a couple of weeks. Thanks again for the note, Bruce. -j

3 2

RE: Solaris 7 & NFS2/NFS3/TCP/UDP....
by Rainchik, Aleksandr (MED, Non GE) 08 May '00

08 May '00

Thank you, That really helped (boosted TPS from 38 to 83 :). Is this option documented or not? I can't find it in the manual... P.S. Still a big problem with NFS2 performance. We have (besides of Solaris) lots of IRIX boxes, and (surprise) if you use automount on IRIX all mounts are NFS2 only... -----Original Message----- From: Keith Brown [mailto:keith@netapp.com] Sent: Wednesday, March 22, 2000 4:23 PM To: Rainchik, Aleksandr (MED, Non GE) Subject: Re: Solaris 7 & NFS2/NFS3/TCP/UDP.... > b) There is no way to use w/rsize=32768 with > NetApp with NFS3 over UDP. Why? I can do it > when mounting from Solaris. Did you set the nfs.udp.xfersize set to 32768? Like so.... filer> options nfs.udp.xfersize 32768 Keith

5 5

RE: autosupport retries (was Re: Apology and Request)
by Hackworth, Brian 08 May '00

08 May '00

: From: dnb(a)ccs.neu.edu [mailto:dnb@ccs.neu.edu] : Quick question: once upon a time, machine-gone-kablooey autosupport : mail was only sent when a filer booted. It was the Yoda scenario : ("there is no retry, only do!"). If something went awry in that : sending, the message was just dropped on the floor, no queuing, no : retrying. Beginning in ONTAP 5.3.4, autosupport that can't be sent is queued and retried periodically, with messages written to /etc/messages describing what's going on. The autosupport mail eventually gets dropped if the net or NIS (or whatever) situation isn't fixed, and it's dropped if the filer reboots before the mail goes out, but when the filer eventually comes up, we can patch together much of what happened from the message log. The retry window is 15 minutes in 5.3.4, lengthened to an hour in the "next major release". - Brian -- Brian Hackworth hackwort(a)netapp.com Network Appliance 408.822.6654 Sunnyvale, CA USA

3 2

RE: 18GB drive performance versus 36BG
by Mohler, Jeff 08 May '00

08 May '00

The new 9G drive is a 10K RPM drive from the same family as the Hi-Po 18 and 36G drive, and can only be used in the new FC9 storage shelves. ONTAP, firmware, and head/model limitaion apply. See now.netapp.com or your salesdude for more info. -----Original Message----- From: Brian Tao [mailto:taob@risc.org] Sent: Friday, May 05, 2000 12:10 AM To: Mohler, Jeff Cc: toasters(a)mathworks.com Subject: RE: 18GB drive performance versus 36BG On Thu, 4 May 2000, Mohler, Jeff wrote: > > There is also a new high-performance (spindle rate/seek rate) 9G > drive now as well for those special environments. Which drive is this? -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 0

Budtool
by Jay Orr 08 May '00

08 May '00

Humm.. I was visiting PDC's web site to see if there was any new info about the migration of Budtool (will be EOL'd Jan 2001), and noticed the one year mark for the beginning of their migration program has passed : http://www.pdc.com/BTMigration.html Still am unable to find out anything - has anyone else? Wondering if they're ignoring everyone or just us... ----------- Jay Orr Systems Administrator Fujitsu Nexion Inc. St. Louis, MO

2 2

Error from filer; bad RAM?
by Jamie Lawrence 06 May '00

06 May '00

Hi - Once again, Netapp tech support seems to be taking their sweet time about responding to my support email, so I'm going to folks that actually respond... Got this in the logs of one of my 720s. Is this telling me I've got bad RAM? It hasn't recurred since that date, but still worries me. Sun Apr 30 12:01:28 PDT [de1]: 11 CORR SYS ERR 201 eia:6cfce0058930000 fs:1ee0015 eis:0 isr:80000001 Sun Apr 30 12:01:28 PDT [de1]: ...SYS ECC error: address=0x6cfce00, bit=19, DIMM=J28 Sun Apr 30 12:02:43 PDT [de3]: 12 CORR SYS ERR 201 eia:3ced0058930000 fs:1ee0015 eis:0 isr:80000001 Sun Apr 30 12:02:43 PDT [de3]: ...SYS ECC error: address=0x3ced00, bit=19, DIMM=J28 Sun Apr 30 12:02:50 PDT [de3]: 13 CORR SYS ERR 201 eia:47634058930000 fs:1ee0015 eis:0 isr:80000001 Sun Apr 30 12:02:50 PDT [de3]: ...SYS ECC error: address=0x476340, bit=19, DIMM=J28 Sun Apr 30 12:03:09 PDT [de2]: 14 CORR SYS ERR 201 eia:6cfce0058930000 fs:1ee0015 eis:0 isr:80000001 Sun Apr 30 12:03:09 PDT [de2]: ...SYS ECC error: address=0x6cfce00, bit=19, DIMM=J28 Sun Apr 30 12:03:37 PDT [de3]: 15 CORR SYS ERR 201 eia:6cfce0058930000 fs:1ee0015 eis:0 isr:80000001 Sun Apr 30 12:03:37 PDT [de3]: ...SYS ECC error: address=0x6cfce00, bit=19, DIMM=J28 -j

2 1

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