toasters

toasters@lists.teaparty.net

13515 discussions

Start a nNew thread

apologies
by kelvin 07 May '99

07 May '99

sorry, i must have been blind um, how about proxy-only mode button on the web manager :) sigh kelvin

1 0

RE: Ontap P* relase mess.
by sirbruce＠ix.netcom.com 07 May '99

07 May '99

On 05/06/99 20:35:58 you wrote: >I'm not surprised to see Bruce has pretty much got the scenario of how this >happened since he's an ex-NetAppian. In fact 5.2.2 was in test as other bugs >came in. Hey, the process can always change. :) I was mostly just guessing given the circumstances, and knowing that Netapp wouldn't not include the patch without a reason. >Since the CIFS problem, 12363, was biting a number of customers and it >caused a Panic, we wanted to get 5.2.2 into manufacturing as fast as possible. >Judgement call on our part, we decided not to restart all the testing and just >go with 5.2.2 as it was in order to have a new GA release that manufacturing >would ship. I was trying to think of possible ways around this and couldn't really think of a good one. One idea, though, would be to make sure that any P releases from a previous version that aren't rolled in have P releases made for the new version by the time it's released. That way customers on 5.2.1P2 can get 5.2.2P2 if they have a specific bug, while 5.2.1 customers can pick the regular 5.2.2. You could put something on NOW basically saying that they shouldn't download 5.2.2P2 unless they were experiencing that particular bug, because it hadn't been thoroughly tested. Bruce

1 0

RE: Ontap P* relase mess.
by Norman, Paul 07 May '99

07 May '99

> -----Original Message----- > From: sirbruce(a)ix.netcom.com [mailto:sirbruce@ix.netcom.com] > Sent: Thursday, May 06, 1999 3:48 PM > To: toasters(a)mathworks.com > Subject: Re: Ontap P* relase mess. > > > On 05/06/99 14:56:52 you wrote: > >So it looks like I'm going to have to downgrade to 5.2.1P2 > from 5.2.2 to > >avoid panics from assertions in the netbios name service.. > Patches for > >5.2.2 are somewhere in the indeterminate future.. (all of > this for bug > >12712, which for some reason isn't listed in Bugs Online) It got moved to REVIEW state today. Should be up on NOW soon. > > I agree... many bugs are missing from Bugs Online and the bugs are > not updated often enough. Perhaps the people making patch releases > don't have full power to update Bugs Online as part of the patch > making and bug reporting process. > > >This brings up one of the points that Tom (?) was ranting on > a week or so > >ago.. Why release 5.2.2, a minor bug-patch revision, that don't > >incorporate patches from its predecessor? > > My guess is something like this. > > When 5.2.1 was released, naturally 5.2.2 was already being considered > and worked on. Shortly thereafter it probably went into testing. > > During 5.2.2 testing, some bugs cropped up in 5.2.1. Various patch > releases were created to fix some of the problems. However, they did > not get as extensive testing as a full "dotdot" release. No doubt > someone wanted to roll the P2 patch into 5.2.2, but someone else > said it was already too late and doing that would require testing > all over again. This was probably unnaceptable for some political > reason - anything from something minor like not wanting to slip on > the schedule to something major like something in 5.2.2 that some > big customer needs and said big customer not being likely to > encounter bug 12712. I'm not surprised to see Bruce has pretty much got the scenario of how this happened since he's an ex-NetAppian. In fact 5.2.2 was in test as other bugs came in. Since the CIFS problem, 12363, was biting a number of customers and it caused a Panic, we wanted to get 5.2.2 into manufacturing as fast as possible. Judgement call on our part, we decided not to restart all the testing and just go with 5.2.2 as it was in order to have a new GA release that manufacturing would ship. > > >Perhaps I shoud've called support first, but I just brought > these 760's > >online with 5.2.2, under the apparently false impression that I was > >getting all the up-to-date fixes.. Was there an erratta for > 5.2.2 that I > >missed that said "THE FOLLOWING IS STILL BROKEN:"? > > Would be nice if they had listed known bugs in 5.2.2. I've burted two RFEs. #14809 RFE - Release notes (Start Here Guide) should list all bugs fixed in a release #14810 RFE - Release notes (Start Here Guide) should list all bugs fixed in "P" or "D" releases but not fixed in this release > > Bruce > >

1 0

Ontap P* relase mess.
by kg 06 May '99

06 May '99

So it looks like I'm going to have to downgrade to 5.2.1P2 from 5.2.2 to avoid panics from assertions in the netbios name service.. Patches for 5.2.2 are somewhere in the indeterminate future.. (all of this for bug 12712, which for some reason isn't listed in Bugs Online) This brings up one of the points that Tom (?) was ranting on a week or so ago.. Why release 5.2.2, a minor bug-patch revision, that don't incorporate patches from its predecessor? Perhaps I shoud've called support first, but I just brought these 760's online with 5.2.2, under the apparently false impression that I was getting all the up-to-date fixes.. Was there an erratta for 5.2.2 that I missed that said "THE FOLLOWING IS STILL BROKEN:"? argh. ..kg..

2 1

Re: A few general bitches and moans. (turning back into what wouldpeoplr like in a very-low-end filer?)
by sthaug＠nethelp.no 06 May '99

06 May '99

> > Wrongo. SCSI is still way more expensive than EIDE. > > Just an example of RETAIL market prices for drives. > > 9.1GB EIDE Ultra DMA / 66 AC29100 7200RPM 9.5NS 2MB Buffer 3 Year Warranty > > $188 > > 9.1GB 3391WD SCSI Wide Differential. > > $219 > > about 15% difference in price. I wouldn't call that much. I think you're > a bit out of touch with the market. The US isn't the whole world. There are other parts of the world where SCSI is significantly more expensive than IDE. Norway is an example of this. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 1

Raid Scrub errors
by scw＠seas.ucla.edu 06 May '99

06 May '99

We've had a 220 for 30 months and a 330 and a 540 for about 18 months. In that time we've never had a raid scrub problem. On April 25 we got 3 raid scrub error messages. I called netapp (that morning) and the CE said that there was nothing to worry about unless they continue and/or there are hard disk errors associated with the problem. I expected that this was the case, and accepted this response. Please note that everything seems to be just fine, and I'm probably being a nervous Nelly. The error didn't reoccur, even though we ran scrub twice on the machine during the week. On Thursday I called back (having had second thoughts, but also having been out of town), and asked for further clarification. In particular: (1) How can there be a parity inconsistency w/o some sort of disk error? If there was a hard error why is there no log entry for same? If there was no error then how can the parity be wrong? Disk_stat reports that since the filer was booted (2 months ago) there have been 3 recovered errors. However I would not expect a recovered error to produce a parity inconsistency, since the correct data should have been recovered. (2) How does the system know that the error is in the parity block and not in a data block? The response that we received from netapp support indicated that it may have in fact rewritten a data block, but logged it as a parity block. In either case how can they determine where the error is if a parity inconsistency occurs w/o a corresponding media error? (3) How can we (as end users) map the stripe number to disk blocks, and then further to the data and/or filesystem info (Inode) blocks. (4) Short of wacky how can we be really sure of our filesystem/data integrity? What I got back was (in essence) don't worry, everything is fine and some canned (RAID for dummies) answers about why raid scrubbing is run and a brief synopsis of the error messages. Except for items 3 and 4... (3) You can't, not really. I believe this and really didn't really expect any other answer, just wishful thinking. (4) Use wacky and don't forget you have to take the filer out of service and it can take up to 10 hours to check the filesystem [for large values of filesystem]. Or upgrade to 5.3 and it only takes about a hour. Could someone give me a pointer to a document that answers questions 1 and 2? Or a brief answer to the group? Does anyone else get these messages? Log file entries: Sun Apr 25 01:00:00 PDT [raid_scrub_admin]: Beginning disk scrubbing... Sun Apr 25 02:39:11 PDT [raid_stripe_owner]: Inconsistent parity on volume vol0, RAID group 0, stripe #606202. Sun Apr 25 02:39:11 PDT [raid_stripe_owner]: Rewriting bad parity block on volume vol0, RAID group 0, stripe #606202. Sun Apr 25 02:39:11 PDT [raid_stripe_owner]: Inconsistent parity on volume vol0, RAID group 0, stripe #606203. Sun Apr 25 02:39:11 PDT [raid_stripe_owner]: Rewriting bad parity block on volume vol0, RAID group 0, stripe #606203. Sun Apr 25 02:39:11 PDT [raid_stripe_owner]: Inconsistent parity on volume vol0, RAID group 0, stripe #606204. Sun Apr 25 02:39:11 PDT [raid_stripe_owner]: Rewriting bad parity block on volume vol0, RAID group 0, stripe #606204. Sun Apr 25 03:48:07 PDT [consumer]: Scrub found 3 parity inconsistencies Sun Apr 25 03:48:07 PDT [consumer]: Scrub found 0 media errors Sun Apr 25 03:48:07 PDT [consumer]: Disk scrubbing finished... ----- Stephen C. Woods; UCLA SEASnet; 2567 Boelter hall; LA CA 90095; (310)-825-8614 Finger for public key scw(a)cirrus.seas.ucla.edu,Internet mail:scw@SEAS.UCLA.EDU

2 1

RE: SNMP traps (+ other monitoring issues)
by Hackworth, Brian 06 May '99

06 May '99

: The [miscGlobalStatus] MIB description is a little woolly however : : Is there a more detailed explanation of what event will : trigger what status? We were intentionally vague in describing the status, to allow us the flexibility to change the algorithm in future releases. The current algorithm is to report "critical" if there are any failed fans, power supplies, or if the chassis temperature is too hot. It reports "nonCritical" if there are any failed disks, or if any volume is 99% full. : However, when doing : the same power supply pull, we only get a message in the : 'info' file. I filed a bug report (14576) on this one. Power supply failures are more serious than "info"; we need both to get the severity right, and to make it consistent across the various flavors of reporting.

4 4

Re: Hardware for F330
by sirbruce＠ix.netcom.com 06 May '99

06 May '99

On 05/05/99 23:35:44 you wrote: >> Netapp has other narrow approved disks they can sell you. You should buy >> those. > >We seem to have some conflicting information here. The Norwegian vendor >claims that there are *no* narrow disks in the Netapp price list any more >- ie. no new narrow disks (of any kind) can be obtained from Netapp. The >best that the Norwegian vendor can do is to get us refurbished narrow >disks. We are only moderately interested in this... Sorry, I was going by what George Kahler said about them being replaced with the Fujitsus. My main point was that they don't *have* to be the same vendor of disks that you already have, which seemed to be a concern of yours. I suppose your vendor may be right bout the price list, although I find it pretty suprising that Netapp wouldn't find a replacement or wouldn't keep enough in stock to cover existing customers. Bruce

1 0

Re: Raid Scrub errors
by sirbruce＠ix.netcom.com 06 May '99

06 May '99

On 05/05/99 13:01:00 you wrote: > On Thursday I called back (having had second thoughts, but also having >been out of town), and asked for further clarification. In particular: > > (1) How can there be a parity inconsistency w/o some sort of disk error? Short of a software error in calculating parity or a similar write problem, there probably isn't a way. > If there was a hard error why is there no log entry for same? > If there was no error then how can the parity be wrong? A variety of ways. Two immediately spring to mind: 1. The block with the error did not go bad until after data had been written to it, but before data was read from it. 2. The drive thought the data was written correctly but was incorrect. 3. The drive thought the data was read correctly but was incorrect. > Disk_stat reports that since the filer was booted (2 months ago) > there have been 3 recovered errors. However I would not expect > a recovered error to produce a parity inconsistency, since the > correct data should have been recovered. I've usually seen parity inconsistencies as a result of an improper shutdown. However these are repaired immediately upon reboot. > (2) How does the system know that the error is in the parity block and > not in a data block? The response that we received from netapp > support indicated that it may have in fact rewritten a data block, > but logged it as a parity block. I don't think it may have in fact rewritten a data block (I could be wrong). Rather, they read all the data, and the parity block was inconsistent with the data, so they rewrote the parity information. I'm not sure if there is any way to know for sure that the parity is actually correct and it is the data block that is wrong. > In either case how can they > determine where the error is if a parity inconsistency occurs w/o > a corresponding media error? I think you're basically saying the same thing here; the problem could be in the data block, not the parity block. In any case, assuming it is parity then they can determine which block goes on that stripe. > (3) How can we (as end users) map the stripe number to disk blocks, and > then further to the data and/or filesystem info (Inode) blocks. I don't think there's any way without an expensive scan of various metadata files. However, it would be nice if every such disk message contained such information. > (4) Short of wacky how can we be really sure of our filesystem/data integrity? No way, but if the filesystem is fine then wacky won't tell you if the data is corrupt either. If the block of zeroes got all flipped to ones, and the parity was rewritten to accomodate that, there's no way to know that it happened unless you happen to know the block should be otherwise in a given file. > What I got back was (in essence) don't worry, everything is fine and >some canned (RAID for dummies) answers about why raid scrubbing is run >and a brief synopsis of the error messages. >Except for items 3 and 4... > >(3) You can't, not really. I believe this and really didn't really expect > any other answer, just wishful thinking. > >(4) Use wacky and don't forget you have to take the filer out of service > and it can take up to 10 hours to check the filesystem [for large values > of filesystem]. Or upgrade to 5.3 and it only takes about a hour. > > > Could someone give me a pointer to a document that answers questions 1 >and 2? Or a brief answer to the group? Does anyone else get these >messages? Yep. The bottom line is - don't worry about it, as they are probably of no consequence. If you continue to get inconsistent parity, it could be a pointer to some other problem. Bruce

1 0

Re: A few general bitches and moans. (turning back into what would peoplr like in a very-low-end filer?)
by mds＠gbnet.net 06 May '99

06 May '99

On Wed 5 May, 1999, tkaczma(a)gryf.net wrote: > > The price differences between SCSI and IDE are not that significant > anymore, but I was wondering why someone didn't come up with and IDE Wrongo. SCSI is still way more expensive than EIDE. It's just the EIDE disk are meant for cheap-and-cheerful low-requirements users and SCSI occupies the middle-high disk market. But we're talking about a VLE filer here, so we can make different assumptions, maybe. > appliance. The argument that I would come up with is that you can only > have 2 devices on one bus, much too few for a RAID 5 set. This also Bzzt. Irrelevant, add more busses because EIDE busses are also quite cheap. > applies to your request for a 3 disk appliance. The power of striping > comes from the number of drives. The more drives you add the smaller the > parity overhead. With 3 drives 33.3 ... % is "wasted" on parity. With 14 > drives the "waste" goes down to about 7%. Parity overhead in terms of space maybe, but computation goes up linearly at best and might go up higher (reconstructing blocks from parity when a disk blows). Tradeoff time. > > > (And no, I'm not interested in the philosophical war of IDE vs SCSI. > > Fact: IDE is currently cheaper than SCSI. Fact: I want this box to be > > cheap. Check and mate. :)) I agree. But I'd do things slightly differently. > No mate, and probably not even check. SCSI drives are not THAT much more > expensive anymore. You must remember that you can have only 2 IDE drives Oh yeah they are. Here in the UK I spent 360quid on an UW 9GB Seagate (end user price) where a 10GB UDMA EIDE drive cost 190quid (end user price). > on the bus, among other limitations. The money you save in drives will > probably be made up in the complexity of the controllers and software. > Everything costs money, the drives are only a fraction of the cost. I've seen PCI-EIDE controllers advertised for about the same as SCSI host adapters, but I'd put them together on the motherboard with an integral network interface (10/100Base-TX). Performance on the SCSI is a bit better but not *that* much better. I'd bet that a good board designer could easily put 3 EIDE controllers on a PCI bus, giving you (4 devices per EIDE controller, last time I counted) 12 disk connections. The motherboard could have the EIDE connections, one cheap integral SCSI host adapter for tapes, one network interface and one set of battery-backed memory (just back up all memory - don't have separate NVRAM, we're talking small and compact here). Given a K6-3 or Celeron and DOT this baby would cost quite a bit less in parts costs than the latest and greatest filers, but wouldn't be an embarrassment to NetApp (of that I'd be quite quietly confident). You could make the mboard quite small and make the whole thing into a single rack-mount shelf/deskside tower style thing, with the disks presented at the front and the power-supply, motherboard access, serial-line, floppy drive, network connector and SCSI connector round the back. >-- End of excerpt from tkaczma(a)gryf.net

4 3

TEST ONLY - DELETE THIS!
by Whitman, Michael 06 May '99

06 May '99

Just a one time TEST -----Original Message----- From: tkaczma(a)gryf.net [mailto:tkaczma@gryf.net] Sent: Wednesday, May 05, 1999 8:00 AM To: toasters(a)mathworks.com Subject: Re: A few general bitches and moans. I agree with you on many points, but ... On Tue, 4 May 1999, Jaye Mathisen wrote: > o CIFS support has got some big holes. > > - The inability to belong to multiple domains. > Not all my domains trust each other. Oops, now the filer > is essentially unusable for some of them. Can NT boxes do this? > - Even the ability to have a different network interface belong to a > different domain would be useful. Not a panacea, but at least > useful. Can NT boxes do this as well? > o The general suckiness of NFS now being insufficient to backup the filer > with CIFS. Probably not a solveable problem, but it still sucks. If NFS sucks so much use CIFS only. Apparently they both suck in some ways that are different from another because you ARE using them to complement each other. > Heck, I saw some very scary numbers from consensys for their IDE raid > product, use IDE drives instead of scsi in this bad boy, and cut them > costs down. WD makes 7200 RPM drives now, at 18GB's a pop, and 5 of 'em > fit in a 3 high bay. The price differences between SCSI and IDE are not that significant anymore, but I was wondering why someone didn't come up with and IDE appliance. The argument that I would come up with is that you can only have 2 devices on one bus, much too few for a RAID 5 set. This also applies to your request for a 3 disk appliance. The power of striping comes from the number of drives. The more drives you add the smaller the parity overhead. With 3 drives 33.3 ... % is "wasted" on parity. With 14 drives the "waste" goes down to about 7%. > (And no, I'm not interested in the philosophical war of IDE vs SCSI. > Fact: IDE is currently cheaper than SCSI. Fact: I want this box to be > cheap. Check and mate. :)) No mate, and probably not even check. SCSI drives are not THAT much more expensive anymore. You must remember that you can have only 2 IDE drives on the bus, among other limitations. The money you save in drives will probably be made up in the complexity of the controllers and software. Everything costs money, the drives are only a fraction of the cost. > Nothing like not having the right serial cable wired up, and > having to type all those stupid commands by hand when you make a booboo, > and plus the grief of having to boot off two floppies. Well, instead of Flash cards carry a serial cable and write macros in your terminal program so you don't have to type commands by hand. Try a terminal program like Telemate or Telix. I assume you're a PC user. > o Or add an option to read rc from disk 3 on a DOS formatted floppy. But it reads it from the drive array, so what's the point? > o Fine, you don't want to use something like PCMCIA cards, then since > Netapp only allows its network cards, allow tftp of the rc file from > one of the interfaces. Why? You should have it on your drives. Besides, you can upload it using the console connection. > I guess the CIFS stuff is what's torquing me off right now the most, I > don't want to have to slap a bunch of storage on some NT boxes when I have > this filer sitting there perfectly suited (in theory) to do the job..., > and I refuse to purchase 1 filer per domain. Can your NT boxes be each in two different domains at the same time? Talk to B. G. III for using such a decrepid protocol as lanmanager. Tom

1 0

Re: Hardware for F330
by sthaug＠nethelp.no 05 May '99

05 May '99

> >- Does anybody know of narrow disks that can be purchased today and which > >will work with 4.3.3D2? (I have come to point that I no longer care if the > >disks are Netapp approved - I just want to have a reasonable chance of the > >disks working.) > > Netapp has other narrow approved disks they can sell you. You should buy > those. We seem to have some conflicting information here. The Norwegian vendor claims that there are *no* narrow disks in the Netapp price list any more - ie. no new narrow disks (of any kind) can be obtained from Netapp. The best that the Norwegian vendor can do is to get us refurbished narrow disks. We are only moderately interested in this... Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

Upgrading F630 from DOT 4.3.4D5 to 5.2.2
by Ozzie Sabina 05 May '99

05 May '99

The problem with our Gigabit NIC which my collegue Jay Soffian has mentioned on the list as of late is continuing to bite us with increasing frequency. Because of this, and the conversation on the list that this has been fixed in the 5.x releases, we want to upgrade that filer ASAP. I know that we need to upgrade our filer firmware to 2.1_a1 (we're currently at 1.8_a1). What I have questions about are the firmware revisions on the disks, SCSI adapters, etc.: 1. I'm most concerned about the disks. This is typical of what is reported about our disks from a sysconfig -v: 0: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) I believe that the "0023" is the firmware revision. I know that in some cases, this has to be upgraded along with the machine's firmware. The documentation of what requirements the different DOT versions have for disk firmware is pretty much non-existant on NOW (or I can't find it). Is this something I'd do after upgrading the DOT version (as http://now.netapp.com/knowledge/docs/ontap/rel512/html/upgrade/fb37.htm seems to hint at ), or something I should do beforehand? 2. The SCSI adapter reports "Firmware Version 2.26". Is this something that would need to be upgraded? Is it even something that can be upgraded? 3. In addition, there are firmware versions reported on what I guess are the shelves themselves: EMU 0: P/N 500408 S/N 2550270236 Firmware Rev 1.19 Is this something we can/need to upgrade as well? 4. Other than that, is there anything else that we should check on beforehand? (We more than meet the memory requirements). Thanks, Oz

1 0

RE: A few general bitches and moans.
by Chen, Ray 05 May '99

05 May '99

Re: SCSI protocol efficiency vs. IDE protocol efficiency: A good point. I'll add another one. One has to think beyond the protocol design and also think about protocol implementation. Even with SCSI drives, not all drives are the same. Some do a better job of implementing the SCSI protocol than others. In a prior life, the workstation I/O folks were qualifying low and mid-cost SCSI drives to ship with the workstations instead of the ~$1000 high-end SCSI drives we were putting in our servers. They found that the lower-cost drives couldn't keep up with the higher-cost drives when you tried things like striping a bunch of the drives together on a bus. When you're pushing SCSI hard, all it takes is something simple like the drive not releasing the bus quickly enough and your performance starts to degrade. (And then there are mechanical issues, too, like how well the enclosures damp vibrations so that the drives don't interfere with each other when seeking.) And I don't even want to talk about data corruption under heavy and demanding workloads. Disk drives are no different from any other commodity product. You get what you pay for. The question is whether or not the extra cost is worth the extra benefit. I use el-cheapo EIDE drives on my PC at home. I'm comfortable with that because I know the I/O workload against the drive is going to pretty minimal so the drive should be just fine. If I wanted to do high-performance I/O and I cared about my data, I'd be using expensive server-class disk drives. I would also eat the extra cost if I could afford it and buy qualified drives directly from my system vendor as opposed to from a 3rd-party (either that or make really certain that my drives were running the same firmware revision as the system vendor's drives. Firmware revisions do matter.). Ray Chen rcc(a)netapp.com > The real issue with SCSI vs IDE is bus utilization. > > The SCSI protocols were designed such that the bus could be > freed for other > users, in-between the time the request for data was sent to > the drive, and the > time data was returned. Thus commands for data could be sent > to several > drives, before the time the first drive could reply with the > requested data. > > The IDE protocols were designed for simplicity, it results in > the bus being > allocated to one request, for the duration of a single > request. It wastes time > for simplicity. > > Due to the sporatic disk access behavior of workstations, IDE > and SCSI drive > perform similarly. > > However, do to the much more consistant but varied disk > access of file servers, > the SCSI bus out-performs the IDE bus due to its time > efficiency. The only > mechanism to combat the IDE bus efficiency would be to have > one IDE bus for > each drive. Having one IDE bus per drive, would eliminates > the minor cost > advantage that IDE drives have over SCSI drives. > > Note: Another issue that has not been mentioned, is system > uptime. I have not > seen an IDE drive that has been adapted to support > hotplugging. This is > critical for online maintenance. > > -- > Matthew Lee Stier * Fujitsu Network Communications > Unix Systems Administrator | Two Blue Hill Plaza > Ph: 914-731-2097 Fx: 914-731-2011 | Sixth Floor > Matthew.Stier(a)fnc.fujitsu.com * Pearl River, NY 10965 > > >

1 0

Re: Running CIFS
by Jason D. Kelleher 05 May '99

05 May '99

In message <7F608EC0BDE6D111B53A00805FA7F7DA03A83938(a)TAHOE.netapp.com>, "Muh lestein, Mark" writes: >A mixed qtree already works exactly as you want it to. In a mixed qtree the >security of a file is based on the last security-setting operation. If an A >CL is >set which denies you access, but you still need to do something with a file, >then as root you can change the security on any files/dirs in that qtree (using >chmod, chown, or chgrp), which changes the security-style to UNIX. After that, Ok, so far I've read this alot. No maybe I'm missing something 'cause I get the following errors trying to put it into practice. Here's a test on a directory w/ NTFS permissions allowing only full control to the owner: root@jagular: fs0/home/kelleher [130] # root@jagular: fs0/home/kelleher [130] # ls -ald test_dir drwx------ 2 kelleher users 4096 May 5 14:47 test_dir root@jagular: fs0/home/kelleher [131] # root@jagular: fs0/home/kelleher [131] # ls -al test_dir test_dir: Permission denied total 8 root@jagular: fs0/home/kelleher [132] # root@jagular: fs0/home/kelleher [132] # chown 755 test_dir chown: test_dir: Not owner root@jagular: fs0/home/kelleher [133] # root@jagular: fs0/home/kelleher [133] # chown root test_dir chown: test_dir: Not owner root@jagular: fs0/home/kelleher [134] # I can however su to the UNIX user, chmod it, and then get access to the file: root@jagular: fs0/home/kelleher [134] # su kelleher jagular% jagular% chmod 755 test_dir jagular% jagular% exit jagular% root@jagular: fs0/home/kelleher [135] # root@jagular: fs0/home/kelleher [135] # ls -al test_dir total 72 drwxr-xr-x 2 kelleher users 4096 May 5 14:47 . drwxr-xr-x 25 kelleher users 32768 May 5 15:25 .. -rwx------ 1 kelleher users 0 May 5 14:47 test_file root@jagular: fs0/home/kelleher [136] # root@jagular: fs0/home/kelleher [136] # Is this what you mean? >those files follow regular UNIX rules, which allows root full access. If the >user wants to put an ACL back on afterwards, no problem. > >We have found that using ACLs in a mixed qtree can be helpful in a number of >situations. That's because ACLs are enforced even for NT Admins and root. For >example, we found that some files were being accidentally deleted by root/Admin >users, so we put an ACL on those files which allows only READ access to all >users. That prevents deleting, even by root or NT Admins. Of course, if we >actually want to delete the files we just change the permissions to allow that, >since in a mixed qtree both root and NT Admins have a special dispensation >tochange the permissions. Sounds like the problem is too many people with root/Admin access. Your solution only requires these people to take an extra step (give themselves the permissions) before they accidentally mess something up. If I were you I'd work on getting rid of their access. (Not that it's an easy thing to do.) jason

1 0

RE: Anybody have any comment on this article, as relating to FCAL reliability?
by Chen, Ray 05 May '99

05 May '99

Speaking not as a NetApp employee but rather as a generic filesystem engineer, I'd say that the fundamental point being raised by the article is valid -- "Is Ultra-SCSI an attractive alternative to FC?" However, if I were being polite, I'd also say that the article was somewhat misleading, dishonest, and inaccurate. If I were being blunt and honest, I'd say ... ah, never mind :-). Personally, I do think there's an open issue as to whether Ultra-SCSI is good enough for small servers with reasonable capacity requirements and I suspect that issue will be driven by cost. If Ultra-SCSI adapters and drives have significantly better price/performance ratio, then Ultra-SCSI will win on the low end and FC will win on the high end. If they're about even, I suspect FC will win. Ray > -----Original Message----- > From: Jaye Mathisen [mailto:mrcpu@internetcds.com] > Sent: Wednesday, May 05, 1999 1:26 AM > To: toasters(a)mathworks.com > Subject: Anybody have any comment on this article, as relating to FCAL > reliability? > > > > (Long night tonight waiting on formatting RAID array.s :() > > > > I do not have an FC-AL arrays at this time, although I know it > is something that is rolling out. > > The comments on reliability concern me a bit, at least for > me, my NetApps > have been "plug" and go. > > No muss, no fuss. > > http://www.performance-computing.com/features/9903sra.shtml > > Just curious if people are having trouble with their FC-Al > disks on their > Netapps... >

1 0

RE: Running CIFS
by Muhlestein, Mark 05 May '99

05 May '99

A mixed qtree already works exactly as you want it to. In a mixed qtree the security of a file is based on the last security-setting operation. If an ACL is set which denies you access, but you still need to do something with a file, then as root you can change the security on any files/dirs in that qtree (using chmod, chown, or chgrp), which changes the security-style to UNIX. After that, those files follow regular UNIX rules, which allows root full access. If the user wants to put an ACL back on afterwards, no problem. We have found that using ACLs in a mixed qtree can be helpful in a number of situations. That's because ACLs are enforced even for NT Admins and root. For example, we found that some files were being accidentally deleted by root/Admin users, so we put an ACL on those files which allows only READ access to all users. That prevents deleting, even by root or NT Admins. Of course, if we actually want to delete the files we just change the permissions to allow that, since in a mixed qtree both root and NT Admins have a special dispensation to change the permissions. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Jason D. Kelleher [mailto:kelleher@susq.com] Sent: Wednesday, May 05, 1999 11:13 AM To: Muhlestein, Mark Cc: 'Mark D Fowle'; 'toasters(a)mathworks.com' Subject: Re: Running CIFS In message <7F608EC0BDE6D111B53A00805FA7F7DA03A83931(a)TAHOE.netapp.com>, "Muh lestein, Mark" writes: >There is a document on the NOW site that should help: > >http://now.netapp.com/knowledge/docs/olio/guides/53_troubleshooting/ > >This is primarily for 5.3, but it is also useful for earlier releases. It h >as a >lot of explanations of our approach, a security FAQ, and a bunch of other >(hopefully useful) security-related stuff. > >Mark Muhlestein -- mmm(a)netapp.com This is nice. Especially since the System Administrator's Guide doesn't talk about the usermap.cfg file. (Even though the sample file refers you to it. Just 'cause the filer is _usually_ simple to setup and maintain is no excuse for poor/missing documentation.) I've been trying to setup access to a "mixed" quota tree such that no NT admin as access to it, but a UNIX root user can over-ride NTFS permissions. I know this sounds weird, but there are _way_ too many NT admin accounts floating around. That's why I don't want NT admins to have access to (read: be able to screw up) the filer. But because I'm one of those "pesky UNIX admins" I can't get and admin account, so I need root to be able to over-ride NTFS permissions. Is this even possible? I'm not having much luck. jason >-----Original Message----- >From: Mark D Fowle [mailto:Fowle_Mark_D@CAT.com] >Sent: Wednesday, May 05, 1999 6:58 AM >To: toasters >Subject: Running CIFS > > >I am trying to set up a mixed environment on 2 720's. I have created a test > share and a usermap.cfg file that has >domain\user unix-user mapped out. My problem is that only 2 our 7 peo >ple > can get access to the share. What >else might I be missing? > >Mark Fowle >Caterpillar - BCP >fowelmd(a)cat.net

1 0

Re: Running CIFS
by Jason D. Kelleher 05 May '99

05 May '99

In message <7F608EC0BDE6D111B53A00805FA7F7DA03A83931(a)TAHOE.netapp.com>, "Muh lestein, Mark" writes: >There is a document on the NOW site that should help: > >http://now.netapp.com/knowledge/docs/olio/guides/53_troubleshooting/ > >This is primarily for 5.3, but it is also useful for earlier releases. It h >as a >lot of explanations of our approach, a security FAQ, and a bunch of other >(hopefully useful) security-related stuff. > >Mark Muhlestein -- mmm(a)netapp.com This is nice. Especially since the System Administrator's Guide doesn't talk about the usermap.cfg file. (Even though the sample file refers you to it. Just 'cause the filer is _usually_ simple to setup and maintain is no excuse for poor/missing documentation.) I've been trying to setup access to a "mixed" quota tree such that no NT admin as access to it, but a UNIX root user can over-ride NTFS permissions. I know this sounds weird, but there are _way_ too many NT admin accounts floating around. That's why I don't want NT admins to have access to (read: be able to screw up) the filer. But because I'm one of those "pesky UNIX admins" I can't get and admin account, so I need root to be able to over-ride NTFS permissions. Is this even possible? I'm not having much luck. jason >-----Original Message----- >From: Mark D Fowle [mailto:Fowle_Mark_D@CAT.com] >Sent: Wednesday, May 05, 1999 6:58 AM >To: toasters >Subject: Running CIFS > > >I am trying to set up a mixed environment on 2 720's. I have created a test > share and a usermap.cfg file that has >domain\user unix-user mapped out. My problem is that only 2 our 7 peo >ple > can get access to the share. What >else might I be missing? > >Mark Fowle >Caterpillar - BCP >fowelmd(a)cat.net

1 0

RE: Running CIFS
by Muhlestein, Mark 05 May '99

05 May '99

There is a document on the NOW site that should help: http://now.netapp.com/knowledge/docs/olio/guides/53_troubleshooting/ This is primarily for 5.3, but it is also useful for earlier releases. It has a lot of explanations of our approach, a security FAQ, and a bunch of other (hopefully useful) security-related stuff. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Mark D Fowle [mailto:Fowle_Mark_D@CAT.com] Sent: Wednesday, May 05, 1999 6:58 AM To: toasters Subject: Running CIFS I am trying to set up a mixed environment on 2 720's. I have created a test share and a usermap.cfg file that has domain\user unix-user mapped out. My problem is that only 2 our 7 people can get access to the share. What else might I be missing? Mark Fowle Caterpillar - BCP fowelmd(a)cat.net

1 0

Re: NetApp Warranty
by sirbruce＠ix.netcom.com 05 May '99

05 May '99

On 05/05/99 11:11:34 you wrote: >Is there a way to purchase this level of support? We have some >non-critical F540s that _if_ they fail, I'd like to get them fixed, >but it doesn't have to happen same day and I don't have a problem >paying for the parts. > >The only hardware support I'm aware of covers cost of repair, so it is >priced accordingly. I'm looking for a more cost-effective level of >support on these non-critical filers. Sorry... I should have said that I'm not speaking from authority here; I was just trying to reconcile what the rep supposedly said with what the web site supposedly said. Either could be wrong and there really could be 1 year of hardware support. As to if you can just purchase software/phone support for additional years, I don't know, but I would assume you can. Surely Netapp wants you to buy more support, yes? I suppose it's possible that any extension includes hardware support too. Bruce

2 1

Re: F540 F520...
by sirbruce＠ix.netcom.com 05 May '99

05 May '99

On 05/04/99 23:43:32 you wrote: >Hmmmm, I have an F540 filer. I'm sure it's a 540. Positive. Says 540 on >it somewhere. I'm sure. > >No such thing as a 540 on www.netapp.com. There's a 520, which looks >pretty darn similar. Can I just s/540/520/g, and be a happy camper? Note to Netapp - All filer models, no matter how old, should still have information accessible off the web site. The price of keeping this information on there is minimal. By not keeping this information someone is just going to wind up doing it third-party with some sort of filer FAQ. Note to Jaye - If you actually have a older file model like the F540, you will need access to more than just general information. Most of the technical details *should*, in an ideal world, be available off now.netapp.com. Have you tried looking there? Bruce

2 1

Re: NetApp Warranty
by sirbruce＠ix.netcom.com 05 May '99

05 May '99

On 05/05/99 09:27:28 you wrote: > ><color><param>0100,0100,0100</param>My Sales rep is saying that a netapp comes with a 3 months hdwr warranty - >that I need to purchase 9mo hdwr support in the first year. Netapp's web >site says the following: > > > "NetApp's hardware warranty program provides customers with free 24x7 > telephone support for one year from the date of purchase along with same > day shipment of replacement parts." > >This sounds like a 1yr warranty. No, it sounds like you get free phone support for 1 year, and if you need a replacement part, they'll ship it same day. However, whether or not you have to pay for that replacement part depends on your hardware warranty. Your Sales rep is saying you've only got 3 months; you need to purchase more if you want more. If you don't, that doesn't mean your 1 year free support is worthless. You can still call them and get help with software issues, or even determine if the problem is in the hardware. They just won't replace it for you for free. Bruce

2 1

Anybody have any comment on this article, as relating to FCAL reliability?
by Jaye Mathisen 05 May '99

05 May '99

(Long night tonight waiting on formatting RAID array.s :() I do not have an FC-AL arrays at this time, although I know it is something that is rolling out. The comments on reliability concern me a bit, at least for me, my NetApps have been "plug" and go. No muss, no fuss. http://www.performance-computing.com/features/9903sra.shtml Just curious if people are having trouble with their FC-Al disks on their Netapps...

2 1

NetApp Warranty
by Richard L. Rhodes 05 May '99

05 May '99

<color><param>0100,0100,0100</param>My Sales rep is saying that a netapp comes with a 3 months hdwr warranty - that I need to purchase 9mo hdwr support in the first year. Netapp's web site says the following: "NetApp's hardware warranty program provides customers with free 24x7 telephone support for one year from the date of purchase along with same day shipment of replacement parts." This sounds like a 1yr warranty. Question: Just what is NetApp's hdwr warranty? Thanks rick <nofill> ---------------------------------------------------------------------- Richard L. Rhodes e: rhodesr(a)firstenergycorp.com Ohio Edison Co. p: 330-384-4904 f: 330-384-2514

2 1

Running CIFS
by Mark D Fowle 05 May '99

05 May '99

I am trying to set up a mixed environment on 2 720's. I have created a test share and a usermap.cfg file that has domain\user unix-user mapped out. My problem is that only 2 our 7 people can get access to the share. What else might I be missing? Mark Fowle Caterpillar - BCP fowelmd(a)cat.net

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