toasters July 2001

toasters@lists.teaparty.net

105 participants
139 discussions

Re: 36F disk
by ScottUCE＠aol.com 05 Jul '01

05 Jul '01

Debbie: Your concern regarding the usability of your NetApp disk drives on other systems notwithstanding, your best investment protection on your NetApp system would be to ask your NetApp salesperson for software license transferability before you buy your next machine (NFS, CIFS, Snap products, etc.) Further, in the event you decide to lease a filer, you might want to select a leasing company that has NetApp's permission to freely transfer software licenses on the resale of used NetApp systems -- they should be able to provide you significantly better rates. Regards, Scott Fischmann Union Computer Exchange, Inc. 6233 Idylwood Lane Minneapolis, MN 55436 Phone: 952 935 7282 FAX: 952 935 5056 scott(a)unioncomputer.com In a message dated 7/3/01 12:49:37 PM Central Daylight Time, Debbie.Lane(a)intermec.com writes: > Can a 36F Fibre Channel disk be used in a system that is not NetApp? I am > asking because the decision to buy or lease was based on the belief that if > at some point we wanted to discontinue using NetApp the disks could be used > elsewhere. > > Thanks for your help. > > --Debbie

2 1

FTP
by Peter Gauthier 04 Jul '01

04 Jul '01

Running 536r2 and 61r1 on my filers and I'm unable to get FTP working, the error is exactly like bug 33218. I have set up my qtree secuiry on vol0 to unix and it made no difference. The other message I get back is: 530 /netservice/ftp: no such file or directory. Then these two directories do exsis and permissions are 777 rwx,rwx,rwx. My passwd file is setup as showen in the man pages and the ftpd.enable is on. Anybody have any tricks

2 1

RE: An idea on migrating NTFS data
by Tom "Mad Dog" Yergeau 03 Jul '01

03 Jul '01

<< Here's an even simpler idea: use global groups to assign permissions. >> You can't do that in a large multi-domain enterprise. Take for example a growing company that uses a new domain for each country. (Back in NT4 days this would be typical and even today with Win2K sites, for security boundary reasons a company might still use a different domain for different countries/depts./areas/whatever.) Files are shared among the different sites. FolderRoot | |-----Folder1 | | | |-------Folder1.1 | |-----Folder2 | | | |-------Folder2.1 | | | | |---Folder2.1.1 | |-----Folder3 ( | | | |-------Folder3.1 Let's say you grant a local group, FilerUsers, access to Folder1. The groups "US-Users, UK-Users, DE-Users" belong to FilerUsers so groups from all three countries can access it Folder 1.1 has some sensitive information in it and only US-Users should be able to access it, FilerUsers access is removed and US-Users access is granted. Now, let's say the same scenario applies to Folder2 and Folder2.1, but instead, Folder2 has access granted to the global groups US-Users, UK-Users and DE-Users. Folder2.1 only has US-Users access. Now, along comes, oh, Canada office. To add access appropriate to folder 1 and all subfolders, you just add CA-Users to the FilerUsers local group. Done. Poof. That's it. Nothing else to do. Folder2, you have to reset ALL the ACLs on Folder2 and all subfolders. Uh-oh. Problem. How do you know which files and folders have more restrictive ACLs? In this example there is only one sub folder with customized ACLs, but in real life, there could be a very large number of files and folders. You just totally ruined the ACLs on all of them in order to give CA-Users access. With Win2K-style ACLs and the inheritance model they use, the problem might be a little less of a problem, but only slightly less. I can go into scenarios where the new inheritance wouldn't help but using local groups would (That's why I've got the extra folders up there, but I'm too lazy to keep going at this point!) So, Local Groups are an evil necessity. I've found a product called "SuperCACLS" from Trusted Systems to be very helpful in dealing with problems like this and it's a lot cheaper than the comparable Alita product. But, it does take forever to walk large directory structures and is not ideal. Tom -----Original Message----- From: Conner, Neil [mailto:neil@mbari.org] Sent: Tuesday, July 03, 2001 6:05 PM To: 'Jeffrey Krueger'; toasters(a)mathworks.com Subject: RE: An idea on migrating NTFS data Here's an even simpler idea: use global groups to assign permissions. Cheers, Neil -----Original Message----- From: Jeffrey Krueger [mailto:jkrueger@qualcomm.com] Sent: Tuesday, July 03, 2001 2:37 PM To: toasters(a)mathworks.com Subject: An idea on migrating NTFS data We are about to migrate a bunch of data between different filers, among which is some NTFS security style data. The only non-slam-dunk about it is NTFS local groups. Background: We use the Microsoft recommended method of assigning rights to filesystems, that is UGLR (phonetic == Uglier). Users belong to ... Global groups, which belong to ... Local groups, which are assigned access to ... Resources. The problem is that Local groups have a non-global SIDs between machines. That is, each filer assigns its own local SID's to local groups in its /etc/lclgroups.cfg on the root volume. That SID gets moved with the ACL data to the destination, but the destination machine can't resolve its membership with its local groups. The traditional approach to fixing this is using a tool from Aelita or subinacl to traverse the entire destination filesystem (post-migration) and replacing any occurrence of the old SID with that of a new SID for a local group on the destination filer. This is all fine and good, but could take forever. -------- THE IDEA -------- Here's my idea on a better way to do this. Simply shutdown CIFS on the destination machine pre-move and create analogous local group entries with SIDs that match the source. NetApp tech support might not like the idea too much, but it would mean that the same global groups would belong to that SID and thus no filesystem traversing or ACL modification! Ta Da! Unfortunately, we are copying data from more source machines than there are destination machines and we are not copying data per filer - that is some data from filer1 will go to filerA, some to filerB, etc. This means that for my scheme to work, we'd need globally unique local group SID's. Since it appears that ONTAP starts assigning local group SID's at 65536 sequentially, we have lots of conflicting local groups with those lower numbered SID's. To still use the original concept, I had the idea of copying the membership of all the groups on the source filers into new local groups with globally unique SID's. Then run one of the ACL tools to create analogous ACE's for the new group wherever it finds the old one. (This is all done pre-migration) After the migration we simply create local groups on the destination machine with SID's of the new, analogous rights granted group. Has anyone tried something like this before?? Can anyone see any problems with this approach?? How about an alternative approach?? Again, the idea is to prevent the requirement of a filesystem traversal during migration. Thanks in advance!! -- Jeff -- ---------------------------------------------------------------------------- Jeff Krueger, NetApp CA E-Mail: jeff(a)qualcomm.com Senior Engineer Phone: 858-651-6709 Storage Lead (NAS/SAN) Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com

1 0

RE: An idea on migrating NTFS data
by Mike Sphar 03 Jul '01

03 Jul '01

There's a reason MS recommends using local groups. For one thing, under NT, you can't add a group to a global group. I believe they changed this with Win2k, but if the original poster has not yet updated their infrastructure to win2k they may still need to use local groups. This was one of the things MS hammered into you during MCSE training years ago. I don't know if they've changed their tune now. -----Original Message----- From: Conner, Neil [mailto:neil@mbari.org] Sent: Tuesday, July 03, 2001 3:05 PM To: 'Jeffrey Krueger'; toasters(a)mathworks.com Subject: RE: An idea on migrating NTFS data Here's an even simpler idea: use global groups to assign permissions. Cheers, Neil -----Original Message----- From: Jeffrey Krueger [mailto:jkrueger@qualcomm.com] Sent: Tuesday, July 03, 2001 2:37 PM To: toasters(a)mathworks.com Subject: An idea on migrating NTFS data We are about to migrate a bunch of data between different filers, among which is some NTFS security style data. The only non-slam-dunk about it is NTFS local groups. Background: We use the Microsoft recommended method of assigning rights to filesystems, that is UGLR (phonetic == Uglier). Users belong to ... Global groups, which belong to ... Local groups, which are assigned access to ... Resources. The problem is that Local groups have a non-global SIDs between machines. That is, each filer assigns its own local SID's to local groups in its /etc/lclgroups.cfg on the root volume. That SID gets moved with the ACL data to the destination, but the destination machine can't resolve its membership with its local groups. The traditional approach to fixing this is using a tool from Aelita or subinacl to traverse the entire destination filesystem (post-migration) and replacing any occurrence of the old SID with that of a new SID for a local group on the destination filer. This is all fine and good, but could take forever. -------- THE IDEA -------- Here's my idea on a better way to do this. Simply shutdown CIFS on the destination machine pre-move and create analogous local group entries with SIDs that match the source. NetApp tech support might not like the idea too much, but it would mean that the same global groups would belong to that SID and thus no filesystem traversing or ACL modification! Ta Da! Unfortunately, we are copying data from more source machines than there are destination machines and we are not copying data per filer - that is some data from filer1 will go to filerA, some to filerB, etc. This means that for my scheme to work, we'd need globally unique local group SID's. Since it appears that ONTAP starts assigning local group SID's at 65536 sequentially, we have lots of conflicting local groups with those lower numbered SID's. To still use the original concept, I had the idea of copying the membership of all the groups on the source filers into new local groups with globally unique SID's. Then run one of the ACL tools to create analogous ACE's for the new group wherever it finds the old one. (This is all done pre-migration) After the migration we simply create local groups on the destination machine with SID's of the new, analogous rights granted group. Has anyone tried something like this before?? Can anyone see any problems with this approach?? How about an alternative approach?? Again, the idea is to prevent the requirement of a filesystem traversal during migration. Thanks in advance!! -- Jeff -- ---------------------------------------------------------------------------- Jeff Krueger, NetApp CA E-Mail: jeff(a)qualcomm.com Senior Engineer Phone: 858-651-6709 Storage Lead (NAS/SAN) Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com

1 0

RE: An idea on migrating NTFS data
by Conner, Neil 03 Jul '01

03 Jul '01

Here's an even simpler idea: use global groups to assign permissions. Cheers, Neil -----Original Message----- From: Jeffrey Krueger [mailto:jkrueger@qualcomm.com] Sent: Tuesday, July 03, 2001 2:37 PM To: toasters(a)mathworks.com Subject: An idea on migrating NTFS data We are about to migrate a bunch of data between different filers, among which is some NTFS security style data. The only non-slam-dunk about it is NTFS local groups. Background: We use the Microsoft recommended method of assigning rights to filesystems, that is UGLR (phonetic == Uglier). Users belong to ... Global groups, which belong to ... Local groups, which are assigned access to ... Resources. The problem is that Local groups have a non-global SIDs between machines. That is, each filer assigns its own local SID's to local groups in its /etc/lclgroups.cfg on the root volume. That SID gets moved with the ACL data to the destination, but the destination machine can't resolve its membership with its local groups. The traditional approach to fixing this is using a tool from Aelita or subinacl to traverse the entire destination filesystem (post-migration) and replacing any occurrence of the old SID with that of a new SID for a local group on the destination filer. This is all fine and good, but could take forever. -------- THE IDEA -------- Here's my idea on a better way to do this. Simply shutdown CIFS on the destination machine pre-move and create analogous local group entries with SIDs that match the source. NetApp tech support might not like the idea too much, but it would mean that the same global groups would belong to that SID and thus no filesystem traversing or ACL modification! Ta Da! Unfortunately, we are copying data from more source machines than there are destination machines and we are not copying data per filer - that is some data from filer1 will go to filerA, some to filerB, etc. This means that for my scheme to work, we'd need globally unique local group SID's. Since it appears that ONTAP starts assigning local group SID's at 65536 sequentially, we have lots of conflicting local groups with those lower numbered SID's. To still use the original concept, I had the idea of copying the membership of all the groups on the source filers into new local groups with globally unique SID's. Then run one of the ACL tools to create analogous ACE's for the new group wherever it finds the old one. (This is all done pre-migration) After the migration we simply create local groups on the destination machine with SID's of the new, analogous rights granted group. Has anyone tried something like this before?? Can anyone see any problems with this approach?? How about an alternative approach?? Again, the idea is to prevent the requirement of a filesystem traversal during migration. Thanks in advance!! -- Jeff -- ---------------------------------------------------------------------------- Jeff Krueger, NetApp CA E-Mail: jeff(a)qualcomm.com Senior Engineer Phone: 858-651-6709 Storage Lead (NAS/SAN) Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com

1 0

An idea on migrating NTFS data
by Jeffrey Krueger 03 Jul '01

03 Jul '01

We are about to migrate a bunch of data between different filers, among which is some NTFS security style data. The only non-slam-dunk about it is NTFS local groups. Background: We use the Microsoft recommended method of assigning rights to filesystems, that is UGLR (phonetic == Uglier). Users belong to ... Global groups, which belong to ... Local groups, which are assigned access to ... Resources. The problem is that Local groups have a non-global SIDs between machines. That is, each filer assigns its own local SID's to local groups in its /etc/lclgroups.cfg on the root volume. That SID gets moved with the ACL data to the destination, but the destination machine can't resolve its membership with its local groups. The traditional approach to fixing this is using a tool from Aelita or subinacl to traverse the entire destination filesystem (post-migration) and replacing any occurrence of the old SID with that of a new SID for a local group on the destination filer. This is all fine and good, but could take forever. -------- THE IDEA -------- Here's my idea on a better way to do this. Simply shutdown CIFS on the destination machine pre-move and create analogous local group entries with SIDs that match the source. NetApp tech support might not like the idea too much, but it would mean that the same global groups would belong to that SID and thus no filesystem traversing or ACL modification! Ta Da! Unfortunately, we are copying data from more source machines than there are destination machines and we are not copying data per filer - that is some data from filer1 will go to filerA, some to filerB, etc. This means that for my scheme to work, we'd need globally unique local group SID's. Since it appears that ONTAP starts assigning local group SID's at 65536 sequentially, we have lots of conflicting local groups with those lower numbered SID's. To still use the original concept, I had the idea of copying the membership of all the groups on the source filers into new local groups with globally unique SID's. Then run one of the ACL tools to create analogous ACE's for the new group wherever it finds the old one. (This is all done pre-migration) After the migration we simply create local groups on the destination machine with SID's of the new, analogous rights granted group. Has anyone tried something like this before?? Can anyone see any problems with this approach?? How about an alternative approach?? Again, the idea is to prevent the requirement of a filesystem traversal during migration. Thanks in advance!! -- Jeff -- ---------------------------------------------------------------------------- Jeff Krueger, NetApp CA E-Mail: jeff(a)qualcomm.com Senior Engineer Phone: 858-651-6709 Storage Lead (NAS/SAN) Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com

1 0

RE: NT And SQL with Network Appliance
by Joe Luchtenberg 03 Jul '01

03 Jul '01

Wow! Can I give you as a reference account to interested NetApp prospects?! Reminds me of the post about 8 months ago (?) from a longtime toaster admin who was griping about something then qualified it with a comment to the effect of, "Don't get me wrong, you can take my filer when you rip it from my cold, dead fingers!" -----Original Message----- From: Gagnon, Steven (P.) [mailto:sgagnon3@visteon.com] Sent: Tuesday, July 03, 2001 3:45 PM To: 'lgartner(a)rpu.org'; 'toasters(a)mathworks.com' Subject: NT And SQL with Network Appliance Hi Lori, Doug Wellbaum asked me to answer some concerns you may have. You may contact me personally if you have any more questions. We have 2 databases running on the filer on the SQL (ver. 6.5) end. Both of them are 500MB. Relatively small but effective. We have encountered no problem with the filer. I haven't used the filer yet in a disaster recovery plan, but I'm sure I would have no issue. Best practice is to use SnapShots or Snap Mirror for added protection. I would consider running your SQL backups (log files) just a few minutes before a snap shot occurs, then in case of disaster, you have to most up to date information and can get your database back on line within minutes. Create a separate ID for the filer and give it Admin privileges. Have it log on as a service. Do not use your Administrator account as if you change your password you will get suspect databases. -- This is from the trenches, things where you go, Ooops! when you are learning for the first time... Make sure it is on a different volume than your data storage. I have never experienced any down time with the filer. We have had it for over a year so far. It's a F740. We have two of them. The other serves UNIX and Oracle. Oracle embraces NetApp. Still wondering why Microsoft is so far behind the ball on this one??? It is as reliable as the hard disk you are using, with snap shot it becomes more reliable and faster than SCSI. As for service from NetApp. It is A1. I have never seen any other company with such dedicated people. You've have already experienced this, I'm sure... They were here late in the evening, early in the morning. Their telephone support is top notch. They will not let you go until your problem is solved, and their expertise is number one. I have 100GB for file storage. This works great too. You can call me if you have any other questions. Thanks Steven Steven Gagnon Visteon Canada Inc. Tel: (905) 475 8510 Ext. 4207 NT / SQL System Administrator Pager: (416) 753 3132 Markham, Ontario, Canada FordNet: 854-4207 Fax: (905) 470 3296 "Man's mind, once stretched by a new idea, never regains its original dimensions." -Oliver Wendell Holmes

1 0

Using a Filer 740 with DFS (Distributed File System)
by Grey, Michael 03 Jul '01

03 Jul '01

I'm having a problem with the filer only supporting 256 characters as a combination of the path and file name. I have an NT Server currently running DFS with local attached storage. I would like to migrate the data from NT to the filer while still keeping the NT Server running DFS as the entry point into the filer. When trying to migrate files with a length greater then 256 characters I receive an error message that the file name or extension is too long. Would anyone happen to know of a workaround for this issue. The Filer is a F740 with 1TB disk space with release 6.1 Regards, Michael Grey Toronto Transit Commission Information Technology Services Client / Server Technical Support 416-393-6791 michael.grey(a)ttc.ca

1 0

NT And SQL with Network Appliance
by Gagnon, Steven (P.) 03 Jul '01

03 Jul '01

Hi Lori, Doug Wellbaum asked me to answer some concerns you may have. You may contact me personally if you have any more questions. We have 2 databases running on the filer on the SQL (ver. 6.5) end. Both of them are 500MB. Relatively small but effective. We have encountered no problem with the filer. I haven't used the filer yet in a disaster recovery plan, but I'm sure I would have no issue. Best practice is to use SnapShots or Snap Mirror for added protection. I would consider running your SQL backups (log files) just a few minutes before a snap shot occurs, then in case of disaster, you have to most up to date information and can get your database back on line within minutes. Create a separate ID for the filer and give it Admin privileges. Have it log on as a service. Do not use your Administrator account as if you change your password you will get suspect databases. -- This is from the trenches, things where you go, Ooops! when you are learning for the first time... Make sure it is on a different volume than your data storage. I have never experienced any down time with the filer. We have had it for over a year so far. It's a F740. We have two of them. The other serves UNIX and Oracle. Oracle embraces NetApp. Still wondering why Microsoft is so far behind the ball on this one??? It is as reliable as the hard disk you are using, with snap shot it becomes more reliable and faster than SCSI. As for service from NetApp. It is A1. I have never seen any other company with such dedicated people. You've have already experienced this, I'm sure... They were here late in the evening, early in the morning. Their telephone support is top notch. They will not let you go until your problem is solved, and their expertise is number one. I have 100GB for file storage. This works great too. You can call me if you have any other questions. Thanks Steven Steven Gagnon Visteon Canada Inc. Tel: (905) 475 8510 Ext. 4207 NT / SQL System Administrator Pager: (416) 753 3132 Markham, Ontario, Canada FordNet: 854-4207 Fax: (905) 470 3296 "Man's mind, once stretched by a new idea, never regains its original dimensions." -Oliver Wendell Holmes

1 0

RE: 34F+ & 36F impact on snapmirror
by Debbie.Lane＠intermec.com 03 Jul '01

03 Jul '01

The 36 GB BCS drive (34F+) is .5GB smaller than the 36GB ZCS (36F) drive. Sorry I can't help with the other questions. -----Original Message----- From: NicholosC(a)maxis.net.my [mailto:NicholosC@maxis.net.my] Sent: Thursday, June 21, 2001 9:19 PM To: toasters(a)mathworks.com Subject: 34F+ & 36F impact on snapmirror All, Had an original F740 with two full shelves of 36F disks. Added a new F740 (for snapmirror purpose) with the same configuration but it came with the new 34F+ disks. Configured the new filer with the identical volume configuration for snapmirror. Original filer was running 5.3.7r3 while the new filer is running 6.1r1 because of the requirement of 34F+ disks. My issues are: (1) Anybody has the information on the "right-size" of the 34F+ disk? My understanding is that 36F has 34,500 KB. The yellow flyer says that 34F+ has lesser capacity but that does not help very much, how much lesser? (2) Because of the lesser capacity (I guess), the target volume can not be snapmirrored. I have to rearrange the volume configuration making the target volumes by one disk more than the source volume, only after that the snapmirror went through. The intention of the snapmirror is for disaster recovery. In the event that the source filer is not available, the target filer will be changed from snapmirrored status to regular volume. When the original source filer is ready for operation again, what is the best practice to move the data back? (3) Snapmirror back on the reverse direction would not work because now the original source filer volume is smaller than the original target volume. (4) Would vol copy falls into the same restriction of target volume has to be equal or larger? In my case, they could not be equal because of one is using 36F and the other is using 34F+. Thanks in advanced for your comments/suggestions. Nic

1 0

Jump to page:

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 July 2001