toasters

toasters@lists.teaparty.net

13531 discussions

RE: Backup alternatives (again)
by Al Phoenix 14 Jul '99

14 Jul '99

I can't speak for other products, but we implemented Veritas to backup our 6 plus filers and we are very happy. Alan R. Phoenix E-mail:phoenix@wnt.sas.com SAS Institute Phone 919-677-8000 ext. 15827 SAS Campus Drive Cary, NC 27513 FAX 919-677-4444 -----Original Message----- From: Lewis [mailto:lsa@netline.net.uk] Sent: Wednesday, July 14, 1999 10:40 AM To: toasters(a)mathworks.com Subject: Backup alternatives (again) Hi everyone, This is a first time posting from someone new to NatApps, so please bare with me. I hve been subscribed to the list for a while and read the archive to get up to speed on passed discussions. I would appreciate it if list members could make suggestions about what alternative backup solutions are available and what kind of (un)recommendations this group puts on these alternatives. This is a follow on from from previous discussions regarding the use of Budtool. I have taken over responsability for the backups as Shiona Mceill (former list contributer is on maternity leave). Due to our lack of success with the implementation of Budtool and their recent demise from the UK market, we have decided not to pursue this solution. We have looked at Netbackup from Veritas. Any comments? We are currently looking at Quick Restore from Workstation Solutions. Any comments? As for platforms and configuration: We have 3+ F720 on 2 sites (ONTAP 5.1.2R3). 3 suns running SunOS 5.7, ATL L500 Library (DTL 7000 drive) and potentially in the future a large number of linux boxes. NDMP has up until now been the preferred option as it seems to be the way forward with the NetApps. However, all that I have seen so far indicates that NDMP support in existing backup tools is a bit of a bolt inclusion that does not sit well with existing products or product architecture. In order to configure the multiplatform network, dubious (built in) workarounds have to be made to get the system to work. These vary from additional links being wired into the library (locally attached to a NetApp), so that the unix data can be backed-up, to dummy library configuration for not local (library) attachments to NetApps. All in all, any comments? Hopefully you will be able to tell me that I don't have a clue what I am on about and that it is all straightforward. Somehow I doubt this to be entirely the case, seeing the hoops we jumps through with budtool. here's hoping, Lewis

1 0

ARP Timeout
by Sean Hinchey 14 Jul '99

14 Jul '99

Does anyone know if you can adjust the ARP cache timeout value in DOT 5.3.1?

2 1

Random reboots on clustered F740 during backups
by Stoltz 14 Jul '99

14 Jul '99

Is anyone else having this problem? We have 2 clustered F740s running 5.3D11 that are backed up via Budtool 4.6, and one of them (bonnie) reboots about every 10 to 15 days during backups. It isn't restricted to a particular level of dump, time of dump, or seemingly anything else non-randomly reproducible :( I've now sent several cores off to netapp for analysis, and to all I've received the same reply: Bug 16084. Problem is that 3 args were expected, but only 2 were given. The following message is what it was trying to print out: "Your dump succeeded, but it could not update the table. The data is safe, but this dump cannot be the base of a future incremental, unless you update the table by hand." Now, the immediate thing every engineer I've talked to has said was "check the permissons on /etc/dumpdates". Of course, the permissions on both boxes in the cluster are exactly the same, the dumpdates file *has* been getting updated, there isn't an issue with space, pretty much every reason we've been given as to why this is happening just ain't so. Besides, the other 740 in the cluster hasn't had any problems with backups as of yet (knock on wood). So, this leaves me wondering, has anyone else seen this and if so, what's your configuration like? Bleah, Mark Susquehanna Partners

1 0

Backup alternatives (again)
by Lewis 14 Jul '99

14 Jul '99

Hi everyone, This is a first time posting from someone new to NatApps, so please bare with me. I hve been subscribed to the list for a while and read the archive to get up to speed on passed discussions. I would appreciate it if list members could make suggestions about what alternative backup solutions are available and what kind of (un)recommendations this group puts on these alternatives. This is a follow on from from previous discussions regarding the use of Budtool. I have taken over responsability for the backups as Shiona Mceill (former list contributer is on maternity leave). Due to our lack of success with the implementation of Budtool and their recent demise from the UK market, we have decided not to pursue this solution. We have looked at Netbackup from Veritas. Any comments? We are currently looking at Quick Restore from Workstation Solutions. Any comments? As for platforms and configuration: We have 3+ F720 on 2 sites (ONTAP 5.1.2R3). 3 suns running SunOS 5.7, ATL L500 Library (DTL 7000 drive) and potentially in the future a large number of linux boxes. NDMP has up until now been the preferred option as it seems to be the way forward with the NetApps. However, all that I have seen so far indicates that NDMP support in existing backup tools is a bit of a bolt inclusion that does not sit well with existing products or product architecture. In order to configure the multiplatform network, dubious (built in) workarounds have to be made to get the system to work. These vary from additional links being wired into the library (locally attached to a NetApp), so that the unix data can be backed-up, to dummy library configuration for not local (library) attachments to NetApps. All in all, any comments? Hopefully you will be able to tell me that I don't have a clue what I am on about and that it is all straightforward. Somehow I doubt this to be entirely the case, seeing the hoops we jumps through with budtool. here's hoping, Lewis

1 0

Re: Anybody seen this crash?
by sirbruce＠ix.netcom.com 13 Jul '99

13 Jul '99

On 07/12/99 23:47:14 you wrote: > > > >My netapp running my news spool is dying with: > >saving 192M to /etc/crash/core.7.nz ("../common/wafl/write_alloc.c:1412: >Assertion failure.") > >F630, 200GB disk, OnTap 5.3.1 > >Thinking of running wack... after idling it. In my experience write_alloc.c crashes are often related to filesystem inconsistencies. Running wack sounds like a good idea. >So far, 7 days, 7 crashes. Haven't touched it in weeks, didn't even know >it had died since it boots up so quick. First, you should put yourself on its autosupport, that way it will notify you as soon as it reboots. You can even link it to your email pager if you like. Then you can either read the full email to see what happened or check the system messages logs. As to the crashes, the fact there is 7 in 7 days would seem important, if indeed you are getting one every day. You don't say if they are all at the same time; if they are, then it might be indicative of a particular process running (cron job) at a particular time every day. Since it's a news spool, it is not unlikely that your entire filesystem gets scanned every day anyway, so even if they are at different times it could be a particular directory or file that is corrupted that crashes the filer ever time the news server tries to modify it. Netapp support, as always, is the best place to get help when you have a crash. Bruce

2 1

Interesting permissions problem
by Graham C. Knight 13 Jul '99

13 Jul '99

A filer of ours (ast-h-dcf04) has NFS exported as root to a system named "nimbus". The filer is giving permission denied messages when trying to access some files as root. This is causing backups to fail for this file (and a few others). Anyone seen this type of behaviour?: [nimbus] ~ 103> sudo file "/data/ast-h-dcf04/ast-h-dcf04-1/kfackler/ups/UPS Server Backup.doc" /data/ast-h-dcf04/ast-h-dcf04-1/kfackler/ups/UPS Server Backup.doc: cannot open: Permission denied Other files in the same directory can be accessed, and they have identical permissions as this one: -rwx------ 1 kfackler nt 19968 Jul 8 09:10 UPS Server Backup.doc* I thought maybe this user had it locked in CIFS, but: ast-h-dcf04> cifs sessions kfackler users shares/files opened MA106734 (ACCT02\kfackler - kfackler) {home_dir} Is there a way to list the files locked by CIFS on a filer? And even if it were locked - why can't root do querires on the file, or back it up? This filer is running 5.3D14. Hopefully I'm missing something very obvious here.... Thx, Graham

2 1

SNMP with netapp?
by Jaye Mathisen 13 Jul '99

13 Jul '99

I am not an SNMP person by any stretch of the imagination... With that said, there's gotta be somebody that's taken the netapp mib and hooked it up with MRTG or something to snarf out some of that great sysstat data and NFS ops data. So if somebody who has done that can make me a fragment of what the OID's would look like, or hell, just get snmpwalk to use the netapp mib, I would be a happy camper. Thanks in advance.

2 3

Anybody seen this crash?
by Jaye Mathisen 13 Jul '99

13 Jul '99

My netapp running my news spool is dying with: saving 192M to /etc/crash/core.7.nz ("../common/wafl/write_alloc.c:1412: Assertion failure.") F630, 200GB disk, OnTap 5.3.1 Thinking of running wack... after idling it. So far, 7 days, 7 crashes. Haven't touched it in weeks, didn't even know it had died since it boots up so quick.

2 1

RE: SNMP with netapp?
by Thompson, Tim 13 Jul '99

13 Jul '99

> > With that said, there's gotta be somebody that's taken the netapp mib and > > hooked it up with MRTG or something to snarf out some of that great > > sysstat data and NFS ops data. > Jaye, > Already on the NetApp NOW web site under the 'Tools' category > Great stuff!! Tom is referring to the "filer-mrtg" package which you'll find in the "Toolshed" list of the "Tools & Utilities". The package contains both MRTG and a Makefile-driven configuration process that will construct the MRTG files needed to monitor your Netapp Filers. It works on Solaris and Linux. A similar arrangement for Netcache can be found in the "netcache-mrtg" package. (If you are using Netcache 3.4, please contact us for a newer version of netcache-mrtg.) You could use the things in the filer-mrtg package and try to merge them with your existing MRTG setup, but my recommendation would be to run the filer-mrtg stuff separate from your existing MRTG setup. This will avoid hassles with compatibility of MRTG versions, and make it much simpler to set up. ...Tim Thompson...Network Appliance, Inc...tjt(a)netapp.com...

2 1

Re: re bug 14004
by quirion＠netapp.com 12 Jul '99

12 Jul '99

In message <19990712200658.24154.qmail(a)ns.gbnet.net>, James R Grinter writes: >[cc'd to netcache-users] > >On Mon 12 Jul, 1999, Colin Johnston <colinj(a)uk.psi.com> wrote: >>just been reading the release notes for NetCache 3.4 >>It seems that unknown to people upto now status reports >>are sent from the NetCache machines each night to NetApp. > >Talking of which, I understand that autosupport might also (well, for >some version of NetCache appliance anyway) have resulted in it sending >referer logs. But that might just be it grabbing a portion of logs when >it crashes and sending it onwards. Autosupport will send the messages file(or some portion I dont remember) when it crashes and come back up. > >>Is is possible for these status reports can also be emailed >>to the customers ?? > Its not autosupport. Its an HTTP POST. >if this *is* part of the autosupport email, and not some other >undeclared feature, you could try changing the address that it sends to >and see what you get (of course, you could also direct its smtp >outbound sessions to a box and mail queue of your own control and take >a look) > >James. >(disclaimer: I don't currently have a NetCache nor access to NOW, so >you could just ignore everything I say) > Brian Quirion Software Engineer Network Appliance Web Products 408-822-6814

3 2

Re: re bug 14004
by jrg＠acm.org 12 Jul '99

12 Jul '99

[cc'd to netcache-users] On Mon 12 Jul, 1999, Colin Johnston <colinj(a)uk.psi.com> wrote: >just been reading the release notes for NetCache 3.4 >It seems that unknown to people upto now status reports >are sent from the NetCache machines each night to NetApp. Talking of which, I understand that autosupport might also (well, for some version of NetCache appliance anyway) have resulted in it sending referer logs. But that might just be it grabbing a portion of logs when it crashes and sending it onwards. >Is is possible for these status reports can also be emailed >to the customers ?? if this *is* part of the autosupport email, and not some other undeclared feature, you could try changing the address that it sends to and see what you get (of course, you could also direct its smtp outbound sessions to a box and mail queue of your own control and take a look) James. (disclaimer: I don't currently have a NetCache nor access to NOW, so you could just ignore everything I say)

1 0

re bug 14004
by Colin Johnston 12 Jul '99

12 Jul '99

Hi, just been reading the release notes for NetCache 3.4 It seems that unknown to people upto now status reports are sent from the NetCache machines each night to NetApp. Is is possible for these status reports can also be emailed to the customers ?? Colin Johnston SA PSINET UK

1 0

RE: Interesting permissions problem
by Muhlestein, Mark 12 Jul '99

12 Jul '99

OK, try going through the security troubleshooter: http://now.netapp.com/knowledge/docs/olio/guides/53_troubleshooting/index.s… If the qtree allows ACLs (i.e. it is not a UNIX qtree) there may be an ACL on the file that does not grant you access. In that case you are actually looking at the display permissions from the UNIX side. Let me know what you find. Mark -----Original Message----- From: Graham C. Knight [mailto:grahamk@ast.lmco.com] Sent: Monday, July 12, 1999 9:08 AM To: Muhlestein, Mark Cc: 'toasters(a)mathworks.com' Subject: Re: Interesting permissions problem The file does not appear in a lock_dump listing. Here is some interesting behaviour: [diamond] ~/ups 3> ls -al total 1000 drwx------ 2 kfackler nt 4096 Jul 8 09:11 ./ drwx------ 4 kfackler nt 4096 Jul 12 08:41 ../ -rwx------ 1 kfackler nt 22528 Jun 24 08:34 UPS Review.doc* -rwx------ 1 kfackler nt 19968 Jul 8 09:10 UPS Server Backup.doc* -rwx------ 1 kfackler nt 202752 Jul 6 09:09 UPStempl.mpp* -rwx------ 1 kfackler nt 194560 Jul 6 09:12 UPStempl.mpt* -rwx------ 1 kfackler nt 45568 Jun 29 09:41 WhoOpsWhat.doc* [diamond] ~/ups 4> whoami kfackler [diamond] ~/ups 5> chmod 700 * chmod: WARNING: can't change UPS Server Backup.doc [diamond] ~/ups 6> more "UPS Server Backup.doc" UPS Server Backup.doc: Permission denied [diamond] ~/ups 7> I cannot do anything with this file - it doesn't appear to matter who i am. I cannot do anything with this file from NT when i'm logged in as a user who has a UID of zero either. It won't let me copy it, or see the permissions. It gives me the "make sure the disk isn't full" error. Any tips appreciated.... Thx, Graham "Muhlestein, Mark" wrote: > > It looks suspiciously like a CIFS lock. There is a hidden command "lock_dump -f" > which is available after doing "rc_toggle_basic". It shows all the cifs locks. > > The reason the files are locked even for root is that SMB locks are mandatory. > We are following NT semantics. It is not perfectly clear that you would always > want to strictly follow NT semantics in all cases, and we are looking at > addressing that issue. > > If you can do your backups from snapshots you will avoid the problem of files > locked by CIFS clients. > > Mark Muhlestein -- mmm(a)netapp.com > > -----Original Message----- > From: Graham C. Knight [mailto:grahamk@ast.lmco.com] > Sent: Monday, July 12, 1999 7:58 AM > To: toasters(a)mathworks.com > Subject: Interesting permissions problem > > A filer of ours (ast-h-dcf04) has NFS exported as > root to a system named "nimbus". The filer is > giving permission denied messages when trying to > access some files as root. This is causing backups > to fail for this file (and a few others). Anyone > seen this type of behaviour?: > > [nimbus] ~ 103> sudo file > "/data/ast-h-dcf04/ast-h-dcf04-1/kfackler/ups/UPS Server Backup.doc" > /data/ast-h-dcf04/ast-h-dcf04-1/kfackler/ups/UPS Server Backup.doc: > cannot open: Permission denied > > Other files in the same directory can be accessed, and they > have identical permissions as this one: > > -rwx------ 1 kfackler nt 19968 Jul 8 09:10 UPS Server > Backup.doc* > > I thought maybe this user had it locked in CIFS, but: > > ast-h-dcf04> cifs sessions kfackler > > users > shares/files opened > > MA106734 (ACCT02\kfackler - kfackler) > {home_dir} > > Is there a way to list the files > locked by CIFS on a filer? And even > if it were locked - why can't root > do querires on the file, or back it up? > > This filer is running 5.3D14. Hopefully > I'm missing something very obvious here.... > > Thx, > Graham

1 0

New shelves on 330
by Jay Orr 12 Jul '99

12 Jul '99

Hi, Ok, so we had gotten an old shelf from our other branch and we tried to bring it online sunday. It seems that the old shelf was the boot shelf (off of controller 0) and we put it on scsi 9b on our system. When the system was rebooted it crashed into PROM mode with the error message raid ID error 0,5. We did this twice and it returned the same error with different drive descriptors both times (but both 0,5 ID error). Anyone know what to do with this? ----------- Jay Orr

1 1

RE: Interesting permissions problem
by Muhlestein, Mark 12 Jul '99

12 Jul '99

It looks suspiciously like a CIFS lock. There is a hidden command "lock_dump -f" which is available after doing "rc_toggle_basic". It shows all the cifs locks. The reason the files are locked even for root is that SMB locks are mandatory. We are following NT semantics. It is not perfectly clear that you would always want to strictly follow NT semantics in all cases, and we are looking at addressing that issue. If you can do your backups from snapshots you will avoid the problem of files locked by CIFS clients. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Graham C. Knight [mailto:grahamk@ast.lmco.com] Sent: Monday, July 12, 1999 7:58 AM To: toasters(a)mathworks.com Subject: Interesting permissions problem A filer of ours (ast-h-dcf04) has NFS exported as root to a system named "nimbus". The filer is giving permission denied messages when trying to access some files as root. This is causing backups to fail for this file (and a few others). Anyone seen this type of behaviour?: [nimbus] ~ 103> sudo file "/data/ast-h-dcf04/ast-h-dcf04-1/kfackler/ups/UPS Server Backup.doc" /data/ast-h-dcf04/ast-h-dcf04-1/kfackler/ups/UPS Server Backup.doc: cannot open: Permission denied Other files in the same directory can be accessed, and they have identical permissions as this one: -rwx------ 1 kfackler nt 19968 Jul 8 09:10 UPS Server Backup.doc* I thought maybe this user had it locked in CIFS, but: ast-h-dcf04> cifs sessions kfackler users shares/files opened MA106734 (ACCT02\kfackler - kfackler) {home_dir} Is there a way to list the files locked by CIFS on a filer? And even if it were locked - why can't root do querires on the file, or back it up? This filer is running 5.3D14. Hopefully I'm missing something very obvious here.... Thx, Graham

2 1

Re: New shelves on 330
by Dave Atkin 12 Jul '99

12 Jul '99

> Ok, so we had gotten an old shelf from our other branch and we tried to > bring it online sunday. It seems that the old shelf was the boot shelf > (off of controller 0) and we put it on scsi 9b on our system. When the > system was rebooted it crashed into PROM mode with the error message raid > ID error 0,5. We did this twice and it returned the same error with > different drive descriptors both times (but both 0,5 ID error). Anyone > know what to do with this? If it's a storageshelf 2, there's a DIP switch on the back that needs to be set. The hardware manual says that for the second shelf the switches (numbered 1-8) should be off,off,off,on,off,off,on,on. Hope this helps. Dave Atkin ------------------------------------------------------ Dave Atkin, Head of Technical Services Computing Service, University of York, YORK YO10 5DD Phone: +44-1904-433804 (ddi) Fax: +44-1904-433740 Email: D.Atkin(a)york.ac.uk ------------------------------------------------------

1 0

ufsdump/ufsrestore and Solaris 2.7
by Dave Atkin 12 Jul '99

12 Jul '99

Sun seem to have "improved" ufsdump/ufsrestore in Solaris 2.7 and they are now so good that they won't talk to a tape drive on a filer. The two utilities now seem to require a feature of the RMT protocol that NetApp don't bother to implement - the "S" (status) command. I've reported the problem to NetApp and they are going to add it to their wish list of enhancements. In the meantime a workaround seems to be to copy over the 2.6 binaries of ufsdump/ufsrestore which seem to work better. Dave Atkin ------------------------------------------------------ Dave Atkin, Head of Technical Services Computing Service, University of York, YORK YO10 5DD Phone: +44-1904-433804 (ddi) Fax: +44-1904-433740 Email: D.Atkin(a)york.ac.uk ------------------------------------------------------

1 0

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

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