toasters

toasters@lists.teaparty.net

13531 discussions

Pre-purchase Contemplations...
by Marc Powell 20 Nov '97

20 Nov '97

Greetings everyone. We are very seriously considering the purchase of either 1 F520 or 2-3 F230's to serve as customer FTP/web/mail storage. We are an ISP with approximately 2000+ customers and we expect that to grow significantly in the coming year. There are a couple of things we would like to toss out there and see what people with experience with the boxes have to say. First, and this just came up, let's say you have a F520 with redundant power per shelf. Does that mean that you only have a total of 28 bays for drives? Second, what would you all say the pros and cons of using a single F520 over several F230's would be, and vice-versa, and are the boxes really as reliable as the hype? Third, is anyone aware of any plans to develop multiple file system support into the Filers? Lastly, are there any development plans to incorporate fail-over support like that in the F630 into the F520? -- Marc Powell Systems Administrator

2 1

RE: links using CIFS
by Matt Lewin 19 Nov '97

19 Nov '97

Relative links will mostly work, it is just that ./ and ../ links are suppressed. The idea is to avoid cycles which Windows will not recognize are happening. So for example, if I did mlewin:/u/mlewin/html $ ln -s ../images images will not work because there exists a possibility that in /u/mlewin/images I may have done mlewin:/u/mlewin/images $ ln -s ../html html which will create a nasty cycle as Windows recursively descends through \\filer\mlewin\html \\filer\mlewin\html\images \\filer\mlewin\html\images\html \\filer\mlewin\html\images\html\images . . . This occurs because UNIX directory links appear as directories to a CIFS client. Basically, I personally do stuff like: mlewin:/u/mlewin $ ln -s mlewincvs/internal_homepage web mlewin:/u/mlewin $ ln -s web html so that people can get to .../~mlewin/ from our internal web site, and I can still get to my personally controlled web pages from CIFS without having to remember if I am supposed to go to "web" or "html" Absolute links will only work if somebody has setup /etc/symlink.translations with some directive like Map /u/path/dir/file /filer/dir/path Unfortunately, that is as much as I know about the way that absolute links work. I will see what else I can find out. On Tuesday, November 18, 1997 3:01 PM, Daniel Quinlan [SMTP:quinlan@transmeta.com] wrote: > Could someone explain exactly what works and what doesn't when using > symbolic links from a CIFS client (Windows95 or WindowsNT, primarily) > from a Netapp with Unix symbolic links? > > Thanks. > > - Dan

2 1

links using CIFS
by Daniel Quinlan 19 Nov '97

19 Nov '97

Could someone explain exactly what works and what doesn't when using symbolic links from a CIFS client (Windows95 or WindowsNT, primarily) from a Netapp with Unix symbolic links? Thanks. - Dan

3 2

Re: soft quotas
by mds46523＠ggr.co.uk 18 Nov '97

18 Nov '97

On Nov 15, 17:16, Brian Tao wrote: > Subject: Re: soft quotas > On Wed, 12 Nov 1997, Guy Harris wrote: > > > > If that's acceptable to everyone, we can put that on the schedule; > > there's no technical problem with providing soft quotas compatible > > with those you get from a SunOS 4.x or 5.x *NFS server* when a > > *client* goes over the soft quota. > > I think we need to at least get some of the basic server-side > requirements first: > > 1. Two limits for each quota type (including qtrees) > 2. A grace period after which a soft quota becomes a hard quota > 3. Mechanism to report quota information to a user-level process on > an NFS client (e.g., rpc.rquotad) > > Notifying the user in real time, as writes are performed to exceed > a soft quota, is probably not worth pursuing at this time. Client-side > processes can be developed to handle the reporting and enforcing of > local policy. The filer shouldn't go out of its way to actively warn > the user... if your users don't read their .login warning messages or > their warning e-mail, that's their problem. Having the server somehow > outputting a human-readable message to the associated tty seems rather > messy and icky. Not to mention that the protocol probably doesn't have this feature already else I imagine the R&D guys at NetApp would've included something to use it already 8) I don't like the idea of extending the protocol unless it's through a standards type process, with >1 vendor involved. > > The filer will have to track each individual quota setting, > incrementing and resetting grace timers as appropriate. When a grace > period expires, the soft quota becomes a hard quota, and the NFS > client will get EDQUOT's on writes. That's the only real-time > notification I'm looking for. > > Soft quotas on a quota tree could have some interesting effects. > Doing a 'df' on an NFS filesystem would show the hard quota as the > total fs size, while the "Used" and "Available" numbers would add up > to the soft quota size. The difference between the soft and hard > quotas can then be treated like the minfree threshold of a UFS > filesystem, except you don't have to be root to exceed the soft quota. Yah, Dave Hitz and I had a quick email dialogue where I kinda explained how we (ab)use qtree's here, and how the qtree quota would, for us, be best treated as an entirely different beast. We use qtree's to split up the reservoir of disk space in a filer so that a variety of projects can use network-mounted space but stay easy-to-administer. Lots'o users live in each qtree but you'd want user quotas to apply as well as the qtree quota. The qtree quota, as I see things, has no benefit to acrue from having soft limits - running out of quota in a qtree looks like you've just run right out of disk to a client and folk have learnt to handle that themselves. > -- > Brian Tao (BT300, taob(a)netcom.ca) > "Though this be madness, yet there is method in't" >-- End of excerpt from Brian Tao -- -Mark, TSG Unix admin and support, int 782 4412, ext +44 1438 76 4412. ... an Englishman in London ...

2 1

filers & netnews
by strata＠virtual.net 17 Nov '97

17 Nov '97

Hi fellow filerophiles, I'm trying to gather some working metrics on netnews and filers. I'm told by the folks at HighWind that Cyclone and Typhoon work well with filers, as they care about spool objects and don't care where those spool objects might be. There's always the INN approach, with a master write host and some subsidiary nnrpd hosts mounting the spool dirs read only. Karl Swarz "Brave Little Toaster Meets Usenet" article is the only source of hard metrics I have, and those are primarily benchmark type metrics rather than production environment metrics. Send me your stories of your environment and I'll summarize to the list. I'm looking for: - description of filer (model, os rev, storage, any other workload) - hosts that are moving the netnews (how many per filer, rw vs ro) - software (INN vs HighWind vs homebrew, number of nnrpd's per host) - users (number of real users, simultaneous users, how user population maps to nnrpd or equivalent (eg 4 users per nnrpd, 10 users, where does performance degrade)). I'm exploring the most cost effective way to build a large news server farm, and I will post my findings on the web and send in the URL with the toaster summaries. Pointers to similar work appreciated also! Cheers, _Strata ------------------------------------------------------------------------- Strata Rose (strata(a)virtual.net) 408-534-3714 VirtualNet Consulting http://www.virtual.net/ -------------------------------------------------------------------------

2 1

Teardrop Attack?
by sirbruce＠ix.netcom.com 17 Nov '97

17 Nov '97

Has anyone verified if Data OnTap is susceptible to the "teardrop" attack? For those interested in the information on the specifics, refer to: http://www.rootshell.com/hacking/teardrop.c Bruce

2 1

Re: Upgrading from an F330
by mds46523＠ggr.co.uk 17 Nov '97

17 Nov '97

Here's the idea we like the most round here, but it takes investment. Be persuasive with your salesguy and arrange for a newer box, F520 say, spec'd to cope and arrange for a decent overlap between setting up the new system and taking the old one away - if you get some kinda upgrade deal that is. Sounds like you could probably use a nice stable F330 elsewhere anyway so you might keep the old box too. 8) Use NDMPCopy 1.1 (with DOT4.3 I think) to do a big copy of all the data when things aren't too exciting on the network or the filer. Either that or use a full backup on tape to copy the bulk of the data. (presupposing you take local backups like we do, which most people appear not to for some reason) When you get your chance to actually do the switcheroo take the F330 offline wrt the clients, do a final incremental to the new box over the network, make the new box look like the old one to the world (and make the old one look like something else...too) and do a bit of testing from your clients. If all seems stable at that stage then run with it in full-production style. If problems crop up, you can breath a sigh of relief that all the old data is still safe and instantly accessible on the old filer and deal with things as they happen. If you've gotten through your first, say, couple of weeks then you can have high confidence that the new filer won't give out on you. Certainly this is pretty much how things have worked when we've upgraded our filers here (and believe me, I've now upgraded 8 in different and *interesting* ways). The real enabler for us to do the job without threatening the data (the important stuff after all) was that our NetApp engineers let us sit on kit when things looked dicy and gave us excellent support in putting the boxes together and dealing with the bedding-in problems. I could tell you tales of the late nights they've put in completely stripping down and rebuilding cabinets full of kit... All you need is the option to backout and suddenly going forward doesn't seem quite so nerve-wracking. Plus the visible downtime of the data can be cut to minutes if you have the details down pat. Hope this helps. On Nov 15, 9:39, Daniel Quinlan wrote: > Subject: Upgrading from an F330 > One of our filers, an F330, is very overloaded (80-100% CPU usage and > 1000-1500 NFS ops/sec for most of the 24 hour day) and is always very > close to being full. Both shelf pairs are full of 4 GB disks. We > also have an F540 and an F630, which are far less loaded. > > Interestingly, the F330 is the most stable filer we have had: no disk > failures in over a year, no major problems. I wish our other filers > were so rock solid. *sigh* Our other two filers have had so many > problems, I can't remember them all: failed disks, failed ethernet > transceiver, bad shelves, SCSI problems, etc. > > Unfortunately, the data on the F330 is some of most critical data at > our company. More than a few hours of downtime is *not* an option. > > I read Tom Yates's "migrating an F330 to a mixed-disc configuration" > messages, so I'm not really inclined to try that. Are there any other > options for fixing the performance and disk space problem that you > would recommend? > > - Dan >-- End of excerpt from Daniel Quinlan -- -Mark, TSG Unix admin and support, int 782 4412, ext +44 1438 76 4412. ... an Englishman in London ...

1 0

Re: Experiences with CIFS
by sirbruce＠ix.netcom.com 16 Nov '97

16 Nov '97

On 11/12/97 09:36:10 you wrote: >CIFS is new to the NetApp boxen and it seems to work pretty well, but >NFS was your first baby and you have not done anything yet to help us >in this world who need one item - soft quotas. There may be some confusion as to *exactly* what you mean by soft quotas, and how they work. Someone once asked me that the next time someone mentioned this, to ask them to PLEASE explain what you expect the soft quotas to do, how they work, and how they currently work on your other (say, Sun) machines. Bruce

9 16

Upgrading from an F330
by Daniel Quinlan 15 Nov '97

15 Nov '97

One of our filers, an F330, is very overloaded (80-100% CPU usage and 1000-1500 NFS ops/sec for most of the 24 hour day) and is always very close to being full. Both shelf pairs are full of 4 GB disks. We also have an F540 and an F630, which are far less loaded. Interestingly, the F330 is the most stable filer we have had: no disk failures in over a year, no major problems. I wish our other filers were so rock solid. *sigh* Our other two filers have had so many problems, I can't remember them all: failed disks, failed ethernet transceiver, bad shelves, SCSI problems, etc. Unfortunately, the data on the F330 is some of most critical data at our company. More than a few hours of downtime is *not* an option. I read Tom Yates's "migrating an F330 to a mixed-disc configuration" messages, so I'm not really inclined to try that. Are there any other options for fixing the performance and disk space problem that you would recommend? - Dan

1 0

subscribe toasters
by Waiming Mok 14 Nov '97

14 Nov '97

subscribe toasters

1 0

Re: "fchown: Not owner" errors between Digital Unix 4.0b ftpd and filer
by sirbruce＠ix.netcom.com 13 Nov '97

13 Nov '97

On 11/13/97 12:25:56 you wrote: > >Greetings, > >We operate an anonymous FTP service using the wuarchive FTP daemon >(wu-2.4.2-academ[BETA-13]) on an Alpha running Digital Unix 4.0b. The >files are stored on a filer running 4.0.1c. > >>From time to time we set up anonymous FTP groups, so remote anonymous >users can supply a group password to gain special access to normally >inaccessible areas. When the FTP data area was on a local file system >on an OSF/1 3.2 system, people could use this group access to upload >files onto the FTP server. Now that we have upgraded the OS and moved >the data to a filer, attempts to do this result in the error > 550 fchown: Not owner. > >and a 0-length file on the filer. > >Can anybody shed light on why this might be happening? I ran into a similar problem with BSD/OS doing the same thing. It seems to be like it changes the group first, and then this results in the writes failing when it goes into "normal" permission mode. But it did not occur from a Solaris client. I didn't get a packet trace at the time, so I couldn't figure out if it was a problem with the filer, the OS, or in the way wuftpd is coded. Never tired Digital Unix, but if it's in there, then it is probably worth the time for Netapp to investigate this and determine exactly where the problem lies. Bruce

2 1

F220 needing upgrade
by fred.abounader＠vantis.com 13 Nov '97

13 Nov '97

Situation: I have an F220 with 2 shelves all slots full with 4G drives. I need to more disk space. Problem(s): An F220 can only accomodate 2 shelves. Possible Solution 1: Make the F220 an F330 with an F330 spares kit and add 2 more shelves and drives. Questions: Does anybody have any Storage Work shelves (BA35X-MD-2X) they want to unload? Do I want to mix 9G drives (in the new shelves) with the existing 4G drives (in the existing shelves)? Any other concerns???? Thanks. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Fred Abounader Vantis (AMD's PLD Subsidiary) ~ ~ email: fred.abounader(a)vantis.com Mailstop 546 ~ ~ voice: (512)-602-1644 5300 E. Ben White Blvd. ~ ~ FAX: (512)-602-4148 Austin, TX 78741 ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

"fchown: Not owner" errors between Digital Unix 4.0b ftpd and filer
by Mic Kaczmarczik 13 Nov '97

13 Nov '97

Greetings, We operate an anonymous FTP service using the wuarchive FTP daemon (wu-2.4.2-academ[BETA-13]) on an Alpha running Digital Unix 4.0b. The files are stored on a filer running 4.0.1c. >From time to time we set up anonymous FTP groups, so remote anonymous users can supply a group password to gain special access to normally inaccessible areas. When the FTP data area was on a local file system on an OSF/1 3.2 system, people could use this group access to upload files onto the FTP server. Now that we have upgraded the OS and moved the data to a filer, attempts to do this result in the error 550 fchown: Not owner. and a 0-length file on the filer. Can anybody shed light on why this might be happening? Thanks, Mic Kaczmarczik Unix Services UT Austin Academic Computing -- Mic Kaczmarczik -- Unix Services -- UT Austin Academic Computing (ACITS) --

1 0

Re: NetApp burn-in testing (was "raid swap question")
by sirbruce＠ix.netcom.com 13 Nov '97

13 Nov '97

Another test, that has been talked about by Netapp before but which Dave didn't mention, is in-house production testing. Almost every new software release, hardware model, and new feature (like ATM) gets time in production use in Netapp's own "Real World" corporate network, often within Engineering itself. While not specifically a QA function, Netapp does integrate it's own products into their infrastructure as best as possible and such rollouts have proven to be very fruitful at identifying problems and correcting them before they reach the customers. Bruce

1 0

Re: backing up large filers
by sirbruce＠ix.netcom.com 13 Nov '97

13 Nov '97

>As for stackers directly attached to the filers, what have folks found >that works? When we first tried this (long ago with an ADIC DLT 2500xt >"stacker"), we found that the stacker mechanism was quite lousy and tended >to hang. Thus we had to reboot the filer to "un-hang" the stacker. I >have stayed away from diretly connected drives since. I used directly attached DLT-4700s at Netapp and never had one with a hung stacker mechanism. If the UNIX host firing off the dump over rsh died, it *could* leave the dump/drive hung and thus requiring a reboot of the filer to fix, but that was rare. Bruce

1 0

Re: raid swap question
by sirbruce＠ix.netcom.com 13 Nov '97

13 Nov '97

On 11/04/97 07:02:23 you wrote: > We have a bunch of filers sitting idle waiting for some >back-ordered components, so I've taken the opportunity to "stress" >them and see what breaks. ;-) On a quiet filer (no exports), I >started with a two-disk configuration (it doesn't seem to mind having >only one parity and one data disk) and hot-plugged four more drives in >rapid succession without a `raid swap'. > > The usual warnings on the first write to a new disk were logged, >but then the filer complained about all three SCSI buses (only 9a was >in use at the time). Beyond that there were no other difficulties. Of course, you may have just been lucky. Under different circumstances or configurations it could very easily hang or crash your filer. Don't try this at home, folks (well, at least not until it's supported). You'll note that it had to reset the adapater and the bus to try and regain a sense of sanity. Bruce

3 2

Re: backing up large filers
by mds46523＠ggr.co.uk 13 Nov '97

13 Nov '97

Currently about 700GB's using dump/restore on 6 F330's and F540 and 2 F630's. Judicious snapshotting, decent DLT stackers directly attached to the filers and a reliable admin host mean all but the one F540 (with 200GB totally filled) easily backup overnight - the F540 finishes mid-morning. We've spoken with folk from NetApp who seem to be doing exciting things in the labs, related to faster backups (hopefully more manageable ones, with fast restores too, but I'll take what I can get). Veritas claim they'll support NDMP in one of the next two releases (they do two per year). We're trying to decide upon a backup solution across a large slice of our infrastructure, several flavours of Unix, maybe NT as well, and the filers too (for preference)...Legato and Openvision are still in the running, but Legato has two major demerits: no planned NDMP support and they change the atime values on files during backup and don't rest them! Which is infuriating because backup isn't 'normal use' and you need to know the age of files to be able to make sensible decisions to manage them! 2p or not 2p, yah, let's break the bank. On Nov 13, 9:02, sirbruce(a)ix.netcom.com wrote: > Subject: Re: backing up large filers > On 11/13/97 00:02:12 you wrote: > >dump makes for a fairly poor backup management solution. Ever try to > >maintain ~30 filers with around 600GB? We kinda found that our home > >grown scripts we're scaling to where we needed to be and found it > >increasinly harder to manage the whole mess. > > Well, I admit, not 30. :) But hundreds of gigabytes, yes. The only > real problem in terms of scalability was long restore times; that could > be solved by breaking the backups into smaller chunks. But with > snapshots the need for restores was very rare; I could see how this > could easly be a more frequent need in a different environment. > > Bruce > >-- End of excerpt from sirbruce(a)ix.netcom.com -- -Mark, TSG Unix admin and support, int 782 4412, ext +44 1438 76 4412. ... an Englishman in London ...

2 1

Re: Experiences with CIFS
by mds46523＠ggr.co.uk 13 Nov '97

13 Nov '97

Re: lots of interesting stuff from everybody about quotas. On our toasters we have a huge mess called 'home directories' and another huge mess called 'project areas'. We've glass-walled these various areas with qtrees, thus making ersatz filesystems that behave to clients exactly like filesystems except to the filer and admin host. However, many users 'live' and 'work' in the same areas as each other, so a qtree quota on the filer wouldn't necessarily map to any one user's quota. In fact quite the reverse. Quotas, in the Unixy sense are distinct from this, because they would report information about each numeric uid's usage of space in a given filesystem and so would have to be specified in a table for each qtree, mapping: uid->(soft, hard, timelimit, timeleft {, any other useful stuff}) It would be a nice interface-feature to be able to harness qtree quotas to filer-wide quotas, or even groups-of-filers-wide quotas, but only on demand (!) as the control of each qtree quota table would be more generally useful. Perhaps users could be given default quotas for all qtrees on a filer until they appear in specific tables which override the defaults. The provision of soft and hard quotas per qtree for defined sets of uid's would be a real admin bonus for us. BTW I was under the impression that a machine hosting a quota'd filesystem locally and serving NFS, was able to deny space to a client that didn't observe quotas if a transaction would breach the quota conditions..? I think I need to go find out some more, as this sounds reasonable but doesn't gel with what others have prior to this on this discussion. How quotas per user under NFS would map to CIFS quota'ing (does such a beast exist?) I've no idea yet, though I can see a clear need to have the two work synergistically. (Users who flit from Unix to PC and back using all the same files at the same time make life interesting that way). (dang, another 2p gone) -- -Mark, TSG Unix admin and support, int 782 4412, ext +44 1438 76 4412. ... an Englishman in London ...

1 0

Re: backing up large filers
by sirbruce＠ix.netcom.com 13 Nov '97

13 Nov '97

On 11/13/97 00:02:12 you wrote: >dump makes for a fairly poor backup management solution. Ever try to >maintain ~30 filers with around 600GB? We kinda found that our home >grown scripts we're scaling to where we needed to be and found it >increasinly harder to manage the whole mess. Well, I admit, not 30. :) But hundreds of gigabytes, yes. The only real problem in terms of scalability was long restore times; that could be solved by breaking the backups into smaller chunks. But with snapshots the need for restores was very rare; I could see how this could easly be a more frequent need in a different environment. Bruce

1 0

Re: backing up large filers
by sirbruce＠ix.netcom.com 13 Nov '97

13 Nov '97

On 11/12/97 15:53:59 you wrote: >Any ideas? We're all pretty frustrated at the lack of a solid backup >solution from Network Appliance. Hell, I'd go for something proprietary >so long as it worked! Straight dump and restore works well, IF you have one of the latest versions of the software... at least then if there is a problem, Budtool won't be involved and you can address the bug right to Netapp. I'm not sure why you'd be having so much trouble with Budtool, though. Bruce ]

2 1

Re: backing up large filers
by Lars Wean 13 Nov '97

13 Nov '97

Hi, > > Has anyone found a "good" solution to backing up large filers? No.... > > Someone convinced me that this ndmp thing was the way to go and I bought > into the whole BudTool scheme (since they're the only ones supporting > ndmp). I have an issue with that too - only one vendor. > NetApp tried with us too... > However, it's been nothing but a disaster and I'm looking for something > far better. We've gotten the impression that no one at PDC has bothered > to test BudTool with large filers with BreeceHill stackers (PDC and > NetApp recommeneded these to us). There appears to be a general lack of > interopibility. And finger pointing between Network Appliance and PDC. > > Right now we have an issue that keeps rebooting our filers every few > days. > > Don't even talk about restoring data... as part of our general backup > policy, we do periodic restores. I believe the wording from PDC was > something to the effect that BudTool is a backup management software and > not geared towards restores. Suffice it to say that we rarely have a > successful restore. > > I'm basically fishing for alternative backup solutions. We have three > F540s with ~100GB disk and about 20 other boxes with ~50GB or so each, > all code development and all needs to be backed up. > > Any ideas? We're all pretty frustrated at the lack of a solid backup > solution from Network Appliance. Hell, I'd go for something proprietary > so long as it worked! My best solution is based on using Legato Networker 5.02, running on Solaris 2.6 2 CPUx 200MHz Ultra with 256 MByte of memory, and 2 x 100Mbit ethernet interfaces against the filers.The tape drives are 2 x DLT7000 in a 10 slot jukebox. The filers contains about 5 million files, using 192 Gbyte of data. Occasional restores never failed us, online file indexes has 1 month of history. A restore of a single file usually takes about 5 minutes, including overhead in mounting tapes. A disaster recovery takes *far* to long, but the potential for restoring files to something other than NetApp is promising, I can restore a full saveset of 100GByte in 6 hours ( to /dev/null, or scanning in files not contained in the online index) Needless to say, we are looking into something else..... Best Regards, Lars Wean

1 0

Re: Experiences with CIFS
by sirbruce＠ix.netcom.com 13 Nov '97

13 Nov '97

On 11/12/97 16:13:05 you wrote: >I have answered this question many times, and I am sick of it. Hey, you don't have to convince *me*. I didn't mean it as a personal attack. But I do know it has been a source of confusion. As you see yourself, different people here had different expectations. So perhaps it's not quite as obvious as it seems? >Go onto your own SunOS or Solaris system and try it yourself, soft >quotas have been around for a very long time and so far, I have not >heard a single technical reason why it should not work. My investigations into this tell me they work much like Guy Harris says. Do you agree with his assessment? If your version of soft quotas differs, in what way does it differ? Does your SunOS system report you as over soft quota over NFS as soon as it happens? I'm only trying to facilitate the questions and answers here. >FreeBSD does it, shoddy Linux does it, hell, I can't name a unix >system off the top of my head that doesn't. > >Is it so much to ask? What would a Netapp implementation do, other than report a "time left" or somesuch in the field reported via the quota command? Bruce

7 6

Re: Experiences with CIFS
by Rajiv Khemani 12 Nov '97

12 Nov '97

>I'm considering a F230 with CIFS support to replace several creaking >NT file servers which are being used in a SW development environment. > ... >I note from the netapp site that Windows Networking Software 2.0 is >out, but I quote from the FAQ: > >" The next release of Windows Networking Software will also provide >NTFS-style file and directory permissions for Windows users." > >This is what was said about version 1.0 > >Q to Netapp people on the list (yes, I have asked directly a week or >2 ago and am still awaiting a reply ) > > When can file level ACLs be expected? Garrett, I apologize for the delayed response. Just like the FAQ says, NTFS-style file and directory level ACLs will be available in the next release of Windows Networking Software. This is the first time we have publically said this, and are working hard to deliver on it. We expect that this functionality will be available in the first half of 1998. Rajiv Khemani Group Marketing Manager Network Appliance > I know having file level ACLs is more complex to manage, but it does >allow us to have multiple groups with different ranges of access >(which stops the Analysts & Business people deleting/changing the >developers work and project teams to have read access to other teams >work) > >Even directory level ACLs would go a long way to meeting our >requirements, but I think that if netapp is serious about the CIFS >market then they need to duplicate the NT ACLs on the filers. > >Thanks, >GB > > >-- >Garrett Burke, Network Admin,Managed Solutions Corp. >32 Upper Mount St., Dublin, Ireland. >burkeg(a)msc.ie +353-1-661-4840 >A jug of wine, a loaf of bread and thou. > > ---- Rajiv Khemani Group Marketing Manager Network Appliance, Inc. Direct: 408-367-3758 Fax: 408-367-3151 HTTP: http://www.netapp.com

2 1

Re: rsh and date
by sirbruce＠ix.netcom.com 12 Nov '97

12 Nov '97

On 11/11/97 17:38:46 you wrote: >So my question is: how do I get around this? Change your network configuration so that your filer *does* have access to port 37 on some (reasonably correct) time server, and use rdate. Wait until date is rsh-able or NTP is supported. Bruce

1 0

rsh and date
by Brian Candler 11 Nov '97

11 Nov '97

Hello all from a new member of this list. I want to set the clock on a Netapp like this: # rsh netapp "date +$(date +%y%m%d%H%M)" I can't use rdate because this Netapp is on a private RFC1918 network and doesn't have access to a port 37 time server. NTP _is_ running on the admin host, but NetApp doesn't support NTP :-( However when I try the above command, it gives: date not found. Type '?' for a list of commands It seems that the list of commands which can be executed via rsh is restricted, and 'date' is not on that list :-( # rsh netapp '?' cifs df dump exportfs halt httpstat mt netstat nfsstat options raid reboot quota rdate restore route snap snmp sysconfig sysstat timezone uptime version # rsh netapp version NetApp Release 4.0.1c: Wed Jan 8 05:07:02 PST 1997 So my question is: how do I get around this? [And _please_ can we have NTP support...!] Regards, Brian.

3 2

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