toasters

toasters@lists.teaparty.net

13514 discussions

RE: converting root volume to flexvol
by Palmer, Jason (EMEA) 24 Mar '05

24 Mar '05

Hi - For info, I generally set my root volumes to 15Gb overall with a 20% Snap reserve (12Gb FS and 3Gb snap) I heavily restrict access to the chosen few and exclude the 'noddy' administrators often found in Domain Admin groups :o) The remainder of the AGGR aggregate I set up as an 'admin' volume where I store install and other misc data away from the user data. From Johns comments, I think what had happened is I had rebooted the filer on the newroot flex vol and issued the command which succeeded because it had already set AGGR aggregate as root. I have another cluster pair I will be playing with and upgrading this weekend. I will check out my theories (we do not have the luxury of a test filer here) That aside, has anyone seen any problems with SID based quotas after upgrading ? It seems that some explicit entries in our /etc/quotas. file which are recognised when the volume is bought online seem to revert to the standard default quota over time. A minor problem (just off/on quotas every now and then to workaround), would be nice to see if anyone else experiences this and if there is a fix available / or in the pipeline ? ~Jason -----Original Message----- From: John Stoffel [mailto:john.stoffel@taec.toshiba.com] Sent: 24 March 2005 17:50 To: Charles Bartels Cc: Palmer, Jason (EMEA); Adam McDougall; toasters(a)mathworks.com Subject: RE: converting root volume to flexvol Charles> A small comment on the plan below. The command to set the root Charles> aggregate (step 4) gives an error: Filer1> aggr options aggr1 root Charles> aggr options: option 'root' can be modified only in maintenance mode Charles> This isn't a problem though since you just need to set the Charles> root volume. The root aggregate will change automatically Charles> upon reboot. Just to clarify things here, since we're looking to goto OnTap 7.0 in the near future... you can just skip step 4 below, since upon reboot the aggregate with the root volume will automatically get the 'root' flag set properly? So you just need to the: vol options root newroot and reboot? Charles> And just a generally comment on the Netapp size Charles> "recommendation" for a flexible root vol. I've seen three Charles> different docs that discuss the size of the root vol. One Charles> suggested 30GB, two others said you should use something Charles> around 90GB. All those suggestions are patently insane. I assume they want to leave room for upgrades and log files. But sure, I think 30gb is way to damm big as well... Charles> I keep 3 months works of root vol snapshots; the total size Charles> is somewhere around 300MB. A few gigs should easily be Charles> enough to handle most situations. I don't understand what Charles> the people who wrote the docs were thinking. Charles> -----Original Message----- Charles> From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] Charles> On Behalf Of Palmer, Jason (EMEA) Charles> Sent: Wednesday, March 02, 2005 5:49 AM Charles> To: 'Adam McDougall'; toasters(a)mathworks.com Charles> Subject: RE: converting root volume to flexvol Charles> Hi Adam, Charles> I successfully moved to a root volume on a flexible volume within an Charles> aggregate last week without any problems... Charles> I used ndmpcopy from the command line of the filer and followed the Charles> steps below - Charles> 1. Create the Aggregate (In our case a 3 disk root aggregate called Charles> AGGR) Charles> 2. Create new flexible root volume within that aggregate (I called Charles> this rootnew as we already have a root volume) Charles> 3. NDMPCOPY -l 0 -f <filer>:/vol/root/etc <filer>:/vol/newroot/etc Charles> 4. aggr options aggr root <-- To set the aggr aggregate to Charles> the root aggregate Charles> 5. vol options newroot root <-- To set the rootnew volume to Charles> the root volume Charles> 6. Reboot the filer and verify everything comes back up OK (If not Charles> you can boot in maintenance mode to reset the root volume) Charles> 7. Check that newroot in aggr is the root volume using vol status Charles> 8. If this is the case, rename root volume to rootold and rootnew Charles> to root Charles> 9. Use vol offline rootold to ofline the old root volume and if Charles> 100% happy use the vol destroy Charles> Worked fine for us - I only used the NetApp KB as a guideline. Charles> I have another 5 machines to convert in the same way - I was lucky, as Charles> the first system I did was not storing production data so there were Charles> plenty of disks and no pressure of system downtime to consider. Charles> I hope this helps, Charles> Jason Palmer Charles> Storage Architecture Charles> MCI EMEA

2 1

RE: converting root volume to flexvol
by Charles Bartels 24 Mar '05

24 Mar '05

A small comment on the plan below. The command to set the root aggregate (step 4) gives an error: Filer1> aggr options aggr1 root aggr options: option 'root' can be modified only in maintenance mode This isn't a problem though since you just need to set the root volume. The root aggregate will change automatically upon reboot. And just a generally comment on the Netapp size "recommendation" for a flexible root vol. I've seen three different docs that discuss the size of the root vol. One suggested 30GB, two others said you should use something around 90GB. All those suggestions are patently insane. I keep 3 months works of root vol snapshots; the total size is somewhere around 300MB. A few gigs should easily be enough to handle most situations. I don't understand what the people who wrote the docs were thinking. -C. -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Palmer, Jason (EMEA) Sent: Wednesday, March 02, 2005 5:49 AM To: 'Adam McDougall'; toasters(a)mathworks.com Subject: RE: converting root volume to flexvol Hi Adam, I successfully moved to a root volume on a flexible volume within an aggregate last week without any problems... I used ndmpcopy from the command line of the filer and followed the steps below - 1. Create the Aggregate (In our case a 3 disk root aggregate called AGGR) 2. Create new flexible root volume within that aggregate (I called this rootnew as we already have a root volume) 3. NDMPCOPY -l 0 -f <filer>:/vol/root/etc <filer>:/vol/newroot/etc 4. aggr options aggr root <-- To set the aggr aggregate to the root aggregate 5. vol options newroot root <-- To set the rootnew volume to the root volume 6. Reboot the filer and verify everything comes back up OK (If not you can boot in maintenance mode to reset the root volume) 7. Check that newroot in aggr is the root volume using vol status 8. If this is the case, rename root volume to rootold and rootnew to root 9. Use vol offline rootold to ofline the old root volume and if 100% happy use the vol destroy Worked fine for us - I only used the NetApp KB as a guideline. I have another 5 machines to convert in the same way - I was lucky, as the first system I did was not storing production data so there were plenty of disks and no pressure of system downtime to consider. I hope this helps, Jason Palmer Storage Architecture MCI EMEA -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com]On Behalf Of Adam McDougall Sent: 02 March 2005 12:37 To: toasters(a)mathworks.com Subject: converting root volume to flexvol I am asking the list because documentation on this process seems to be inconsistant or light in nature on the NOW website. Background: When we setup our Filer, vol0 spanned 24 data disks and contained "etc". The original filer, an F820, booted from this. We've since upgraded to FAS940 and Data ONTAP 7.0 and I want to migrate root to a flexvol. We also have a new disk shelf, so I set it up as aggr0 and already have some production flexvols running from it for data. I created a flexvol named root on aggr0. I want to move the root from vol0 to this new flexvol so I can destroy vol0 (which is larger now and has no remaining production qtrees) and create a second aggregate with the 3 disk shelves that would be freed. Problem: Several articles, such as Solution ID: kb5856 make it sound like you need to copy etc into /aggr0/newvol instead of /vol/newvol. It also demonstrates that the newly created /vol/newvol appears empty after this. Why would you do it that way? Is it an ndmpcopy/rootvol thing that you would want to do this? I have successfully migrated normal data from traditional volumes to flex volumes using various combinations of ndmpcopy, tar, and rsync. Copies that complete successfully work fine. Other articles such as Solution ID: kb5634 make the procedure sound simpler yet more vague: "1. From an Admin host that has access to both traditional vol0 and the new root volume copy the entire /etc directory over to the new volume. " This I can easily handle, but I want to be fairly certain that it will actually boot from the new root vol after doing "vol options root root". I also want to put boot files on the new aggr/root disks so I can boot from that shelf incase I need to replace my compactflash card. Would 'download' do the right thing and place the boot files on the new disk shelf as long as I have set "vol options root root"? Has anyone done something similar, and how large did you make your new root volume? NetApp webpages have widely varying examples varying from 14g to recommendations of 30g or 90g. Our /etc is only 0.25 gigs and I wouldn't expect coredumps to consume more disk space than the filer has memory, and if my filer decides to start coredumping frequently then I will be thinking about the disk space and expanding it, since I can.

2 1

Re: HSM and Netapp
by Louis Elias 24 Mar '05

24 Mar '05

Mike, this is indeed a potential issue. One option might be to use last modified dates in the beginning rather than access dates. Then you can look at the reports to see what the trend is and adjust the policies as necessary. Louis -----Original Message----- From: Sphar, Mike <Mike_Sphar(a)bmc.com> To: toasters(a)mathworks.com <toasters(a)mathworks.com> Sent: Wed Mar 23 19:24:59 2005 Subject: RE: HSM and Netapp Something I'm not clear on for products like these. How do they tell the difference between a user really trying to read a file, and other system level activities that might access the file, such as backups? Whenever we've tried to look into ways of archiving data that isn't being used any more, we always run up against not being able to really tell what isn't being used any more. -----Original Message----- From: Louis Elias [mailto:louis.elias@gmail.com] Sent: Wednesday, March 23, 2005 6:43 PM To: toasters(a)mathworks.com Subject: RE: HSM and Netapp I would like to set the record straight for posterity. NuView has 2 products that can be used to build an ILM strategy. 1.) Virtual File Manager (VFM) is software that can virtualize an enterprise namespace by taking advantage of either MS DFS which is built into the CIFS protocol or NFS. DFS is not an in band solution but rather acts much like DNS by supplying referals to user requests. VFM automates the management of all of the DFS roots through several different policies. One of those policies is a Data Archival Migration policy that will find folders that contain files with attributes you are looking for. So I can say find all of the folders that contain files, 95% of which have not been accessed in 180 days, for instance, and move them to more cost effective storage. If done in conjunction with DFS this move will be transparent to users and applications. It is not HSM but actually moves the files. VFM uses an SQL database (MSDE or SQL server). If it goes down the DFS roots are still available to the users so their is no impact. This is only one small part of what VFM can be used for. 2.) File Lifecycle Manager (FLM) is more like traditional HSM in that it moves files from a filer leaving a stub (not shortcut) behind. When opened the file is pulled back from the nearline storage and opened. This is possible for CIFS and soon NFS (awaiting DOT 7.0.1) data. FLM has other features such as the ability to prevent users from putting or creating files of certain types like .mp3 files on the filer. It is extremely robust and easy to implement. If you have filers whose volumes are filling this is a quick way to alleviate the problem. So depending on your particular need or environment, either of these products can present a lot of possibilities for HSM or ILM. Louis For CIFS data, Microsoft's DFS might also be a usable solution for what the poster had in mind, being able to move data around a bit. *** Are people seeing good results with NuView? I'd heard it runs on the "mini-SQL" database that vendors now ship with products (a subset of Microsoft SQL) and it's not clusterable or configurable in any highly available manner. I understand that if you lose the server running NuView, you lose access to all the migrated data? I'm not trying to lay flamebait, I just want to hear some "5000 mile reports" from people running NuView in the field. JKB

1 0

Re: HSM and Netapp
by Louis Elias 24 Mar '05

24 Mar '05

You can also specify that specific user accounts, machine names, or IP addresses do not cause restores. This is the most common practice for things such as CIFS based backups or virus scanners. Louis -----Original Message----- From: Sto Rage© <netbacker(a)gmail.com> To: Sphar, Mike <Mike_Sphar(a)bmc.com> CC: toasters(a)mathworks.com <toasters(a)mathworks.com> Sent: Wed Mar 23 21:18:58 2005 Subject: Re: HSM and Netapp I have heard that FLM actually has a throttle setting. If it sees a flood of read requests it will disable the recall. On Wed, 23 Mar 2005 19:24:59 -0600, Sphar, Mike <Mike_Sphar(a)bmc.com> wrote: > Something I'm not clear on for products like these. How do they tell the > difference between a user really trying to read a file, and other system > level activities that might access the file, such as backups? > > Whenever we've tried to look into ways of archiving data that isn't being > used any more, we always run up against not being able to really tell what > isn't being used any more. > > -----Original Message----- > From: Louis Elias [mailto:louis.elias@gmail.com] > Sent: Wednesday, March 23, 2005 6:43 PM > To: toasters(a)mathworks.com > Subject: RE: HSM and Netapp > > I would like to set the record straight for posterity. > > NuView has 2 products that can be used to build an ILM strategy. > 1.) Virtual File Manager (VFM) is software that can virtualize an > enterprise namespace by taking advantage of either MS DFS which is > built into the CIFS protocol or NFS. > > DFS is not an in band solution but rather acts much like DNS by > supplying referals to user requests. VFM automates the management of > all of the DFS roots through several different policies. One of those > policies is a Data Archival Migration policy that will find folders > that contain files with attributes you are looking for. So I can say > find all of the folders that contain files, 95% of which have not been > accessed in 180 days, for instance, and move them to more cost > effective storage. If done in conjunction with DFS this move will be > transparent to users and applications. It is not HSM but actually > moves the files. > > VFM uses an SQL database (MSDE or > SQL server). If it goes down the DFS roots are still available to the > users so their is no impact. > > This is only one small part of what VFM can be used for. > > 2.) File Lifecycle Manager (FLM) is more like traditional HSM in that > it moves files from a filer leaving a stub (not shortcut) behind. When > opened the file is pulled back from the nearline storage and opened. > This is possible for CIFS and soon NFS (awaiting DOT 7.0.1) data. > > FLM has other features such as the ability to prevent users from > putting or creating files of certain types like .mp3 files on the > filer. > > It is extremely robust and easy to implement. If you have filers whose > volumes are filling this is a quick way to alleviate the problem. > > So depending on your particular need or environment, either of these > products can present a lot of possibilities for HSM or ILM. > > Louis > > For CIFS data, Microsoft's DFS might also be a usable solution for what > the poster had in mind, being able to move data around a bit. > > *** > > Are people seeing good results with NuView? > > I'd heard it runs on the "mini-SQL" database that vendors now ship with > products (a subset of Microsoft SQL) and it's not clusterable or > configurable in any highly available manner. > > I understand that if you lose the server running NuView, you lose access > to all the migrated data? > > I'm not trying to lay flamebait, I just want to hear some "5000 mile > reports" from people running NuView in the field. > > JKB >

1 0

RE: possible space guarantee "bug" ?
by Stephenson, Burke T. GD 24 Mar '05

24 Mar '05

Did you change/consider the snapshots on your volumes? I would like to know if this is a bug/problem because I am going to 7.x soon. -----Original Message----- From: Charles Bartels [mailto:Charles.Bartels@tradebeam.com] Sent: Tuesday, March 22, 2005 4:50 PM To: toasters(a)mathworks.com Subject: possible space guarantee "bug" ? I've been shuffling around my volumes, migrating to flexible volumes, and noticed an interesting possible bug. I created about a dozen volumes within a large aggregate; using all the space available. All were create with the default space guarantee setting of "volume". As I understand things, this effectively means the space is reserved for each volume (i.e. one volume can't use up space in another volume.) When I rebooted my filer this morning I noticed the warning: [wafl.vol.guarantee.fail:error]: Space for volume vol_test is NOT guaranteed and the space guarantee setting showed up as "volume(disabled)" As soon as I shrunk one of the volumes a bit the following message appeared in the log: [wafl.vol.add.spcGuar:info]: Space for volume vol_test is guaranteed. This seems to imply that one should be very careful whenever you create or increase the size of a flexible volume. You can inadvertently disable the space guarantee on another volume. This *may* be the expected way 7.0 works; I don't know. I'm still in the process of getting the hang of this latest release. But it did seem strange. -C.

1 0

RE: HSM and Netapp
by Sphar, Mike 24 Mar '05

24 Mar '05

Something I'm not clear on for products like these. How do they tell the difference between a user really trying to read a file, and other system level activities that might access the file, such as backups? Whenever we've tried to look into ways of archiving data that isn't being used any more, we always run up against not being able to really tell what isn't being used any more. -----Original Message----- From: Louis Elias [mailto:louis.elias@gmail.com] Sent: Wednesday, March 23, 2005 6:43 PM To: toasters(a)mathworks.com Subject: RE: HSM and Netapp I would like to set the record straight for posterity. NuView has 2 products that can be used to build an ILM strategy. 1.) Virtual File Manager (VFM) is software that can virtualize an enterprise namespace by taking advantage of either MS DFS which is built into the CIFS protocol or NFS. DFS is not an in band solution but rather acts much like DNS by supplying referals to user requests. VFM automates the management of all of the DFS roots through several different policies. One of those policies is a Data Archival Migration policy that will find folders that contain files with attributes you are looking for. So I can say find all of the folders that contain files, 95% of which have not been accessed in 180 days, for instance, and move them to more cost effective storage. If done in conjunction with DFS this move will be transparent to users and applications. It is not HSM but actually moves the files. VFM uses an SQL database (MSDE or SQL server). If it goes down the DFS roots are still available to the users so their is no impact. This is only one small part of what VFM can be used for. 2.) File Lifecycle Manager (FLM) is more like traditional HSM in that it moves files from a filer leaving a stub (not shortcut) behind. When opened the file is pulled back from the nearline storage and opened. This is possible for CIFS and soon NFS (awaiting DOT 7.0.1) data. FLM has other features such as the ability to prevent users from putting or creating files of certain types like .mp3 files on the filer. It is extremely robust and easy to implement. If you have filers whose volumes are filling this is a quick way to alleviate the problem. So depending on your particular need or environment, either of these products can present a lot of possibilities for HSM or ILM. Louis For CIFS data, Microsoft's DFS might also be a usable solution for what the poster had in mind, being able to move data around a bit. *** Are people seeing good results with NuView? I'd heard it runs on the "mini-SQL" database that vendors now ship with products (a subset of Microsoft SQL) and it's not clusterable or configurable in any highly available manner. I understand that if you lose the server running NuView, you lose access to all the migrated data? I'm not trying to lay flamebait, I just want to hear some "5000 mile reports" from people running NuView in the field. JKB

2 1

RE: HSM and Netapp
by Louis Elias 24 Mar '05

24 Mar '05

I would like to set the record straight for posterity. NuView has 2 products that can be used to build an ILM strategy. 1.) Virtual File Manager (VFM) is software that can virtualize an enterprise namespace by taking advantage of either MS DFS which is built into the CIFS protocol or NFS. DFS is not an in band solution but rather acts much like DNS by supplying referals to user requests. VFM automates the management of all of the DFS roots through several different policies. One of those policies is a Data Archival Migration policy that will find folders that contain files with attributes you are looking for. So I can say find all of the folders that contain files, 95% of which have not been accessed in 180 days, for instance, and move them to more cost effective storage. If done in conjunction with DFS this move will be transparent to users and applications. It is not HSM but actually moves the files. VFM uses an SQL database (MSDE or SQL server). If it goes down the DFS roots are still available to the users so their is no impact. This is only one small part of what VFM can be used for. 2.) File Lifecycle Manager (FLM) is more like traditional HSM in that it moves files from a filer leaving a stub (not shortcut) behind. When opened the file is pulled back from the nearline storage and opened. This is possible for CIFS and soon NFS (awaiting DOT 7.0.1) data. FLM has other features such as the ability to prevent users from putting or creating files of certain types like .mp3 files on the filer. It is extremely robust and easy to implement. If you have filers whose volumes are filling this is a quick way to alleviate the problem. So depending on your particular need or environment, either of these products can present a lot of possibilities for HSM or ILM. Louis For CIFS data, Microsoft's DFS might also be a usable solution for what the poster had in mind, being able to move data around a bit. *** Are people seeing good results with NuView? I'd heard it runs on the "mini-SQL" database that vendors now ship with products (a subset of Microsoft SQL) and it's not clusterable or configurable in any highly available manner. I understand that if you lose the server running NuView, you lose access to all the migrated data? I'm not trying to lay flamebait, I just want to hear some "5000 mile reports" from people running NuView in the field. JKB

1 0

MacOS X / Windows NetApp sharing issues
by Rob Winters 23 Mar '05

23 Mar '05

I have a FAS960 and an R200 to deploy. One of the services to be provided is user file services. They will replace Windows servers, which also run MS's AFP services for Macs. The Mac users can currently share files fairly seamlessly with Windows users courtesy of (of all entities) Microsoft. <rant> Despite the decade or so that has passed since everyone stopped thinking it was cool and pretty much started agreeing that it was a bad idea :-), Mac files are still three-dimensional entities with "data forks" (files), and "resource forks" (Mac-specific "stuff"). <sigh> </rant> Apple file servers run a hierarchical file service that will store Mac files or flat files. (Duh.) Microsoft's AFP service also has a facility ("NTFS Streams") to handle the additional information, serve it up to Macs, and allow non-Macs to ignore it, while still presenting a single file image. Good enough. Based on sparse clues, I *think* that all Data ONTAP releases post-6.4 support NTFS Streams in the same way as Microsoft AFP. The Thursby products "DAVE" and "ADmitMac" are smart enough to notice that the NTFS Streams facility exists on the NetApp and make use of it, therefore files stored with these products vis CIFS appear as a single file on disk, and the Mac users still get their resource fork data back. Unfortunately,... Apple's CIFS client is not so bright. It's not smart enough to realize that NTFS Streams is present, or to do anything clever with it. Instead it stores a separate file for the resource fork, i.e.: ._resume.doc resume.doc It *is* smart enough to tag the "._" files as hidden in CIFS, but curious Windows users can see and manipulate them anyway. (We even tested with the yet-to-be-released rev of MacOS X, in case anyone is curious.) Worse, the creating Mac user leaves the "._" file "in use" until it drops the share or shuts down, so other Mac users can edit the corresponding file, but not save it with the same name. Other tests showed the opposite: two Macs with the same file open r/w, happily overwriting the same Office document in turn. ACK! Macs can't share with Macs! We tried Mac via NFS as well as an Xserve accessing via NFS and re-serving AFP to Macs. Both are worse, because the "._" files are then not marked as hidden in CIFS, so the Windows users see all of these junk files sorted to the top, before the "real" files. Finally, the question! What are we missing? Is it really this ugly to share between Macs and PCs on a NetApp? We really wanted to roll out this whole deployment server-side and relatively transparently; now we are looking at having to install ADmitMac on about 700 Macs. I'm hoping that there are some other options out there. Thanks for any ideas, folks! /// Rob

2 1

RE: Needed: A tool for editing CIFS ACLs
by Adrian Phillips 23 Mar '05

23 Mar '05

Hello; There is a utility we use (non GUI, but I'm mentioning it anyways as we've been so pleased with it) to modify ACLs. It is called "NTSec" and is from a company called "Pedestal" (http://www.pedestalsoftware.com/). Allows you to backup up ACLs from folder sets (very useful for restoring these setting should a user with too much privilege mess things up) and other things too. Also allows you to swap users, so will replace user A with user B for any individual access they may have... Anyways, I ramble... :) Cheers, -Adrian -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com]On Behalf Of Warkentin, Grant Sent: Wednesday, March 23, 2005 10:05 AM To: toasters(a)mathworks.com Subject: RE: Needed: A tool for editing CIFS ACLs Thanks. Unfortunately our IT security department has mandated that a whole bunch of stuff be turned on under CIFS audit. This makes these logs mostly useless to us. Too much data. Cacls would work - been wanting to create a less dangerous substitute for ntfschown[1] for file ownership modifications. Still prefer to find a GUI utility for the other admins here. 1. A utility I downloaded from now.netapp. It works well if used properly and can cause a whole mess of trouble if not used properly. NOTICE - This communication is intended ONLY for the use of the person or entity named above and may contain information that is confidential or legally privileged. If you are not the intended recipient named above or a person responsible for delivering messages or communications to the intended recipient, YOU ARE HEREBY NOTIFIED that any use, distribution, or copying of this communication or any of the information contained in it is strictly prohibited. If you have received this communication in error, please notify us immediately by telephone and then destroy or delete this communication, or return it to us by mail if requested by us. The City of Calgary thanks you for your attention and cooperation. -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Holland, William L Sent: Wednesday, March 23, 2005 10:34 AM To: 'toasters(a)mathworks.com' Subject: RE: Needed: A tool for editing CIFS ACLs CIFS security auditing is already a part of the CIFS protocal and configured through options cifs. You can use CACLS (part of the Windows OS) in scripts to manage the ACLs as well. -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:Grant.Warkentin@calgary.ca] Sent: Wednesday, March 23, 2005 12:18 PM To: toasters(a)mathworks.com Subject: Needed: A tool for editing CIFS ACLs Question: Can anyone recommend a 3rd party tool for editing CIFS ACLs on an FAS960. We need: 1. An audit trail. 2. The ability to add additional ACLs without changing the existing ACLs on a folder. Currently we are using FSA (File Security Administrator) by NetIQ on our regular servers. This product needs to run an agent on the server so it's no good for filers. I have been looking at Security Explorer by Script Logic. Some information I have on this product is "We are currently working with Net App to overcome some issues with Compatibility." Do you know of any other programs besides these two? TIA. Grant Warkentin System Administrator II City of Calgary - Information Technology Mail Drop == 8245 Ph: (403) 268-5629 Fax: (403) 268-2546 NOTICE - This communication is intended ONLY for the use of the person or entity named above and may contain information that is confidential or legally privileged. If you are not the intended recipient named above or a person responsible for delivering messages or communications to the intended recipient, YOU ARE HEREBY NOTIFIED that any use, distribution, or copying of this communication or any of the information contained in it is strictly prohibited. If you have received this communication in error, please notify us immediately by telephone and then destroy or delete this communication, or return it to us by mail if requested by us. The City of Calgary thanks you for your attention and cooperation.

1 0

HSM and NetApp
by Holland, William L 23 Mar '05

23 Mar '05

What would you recommend for an HSM product for use with NetApp? I am interested in a product that will periodically scan my file systems on my filers and then, based on criteria that I establish, move those files to an R200. I would like for it to leave a link in place of the original file so that it can be retrieved should it be needed. I would like to be able to further refine the management such that once a file has been moved to the R200 for some period of time let me know to either archive it to tape/DVD/etc and then delete it from the R200 and remove the links.

5 4

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