toasters February 2005

toasters@lists.teaparty.net

68 participants
73 discussions

RE: OnTap 7 Aggregates
by Hill, Aaron 03 Feb '05

03 Feb '05

Seems a lot of people are going to 7G quite early. Are there other environments like mine out there where you have been burnt badly by a minor release? We have, more than once and are extremely reluctant to recommend an upgrade before this OS has been seen in the wild for at least 6-12 months. Don't get me wrong, I am 100% confident in the quality control and testing completed by NetApp. My fledgling wisdom tells me to take things very slowly because this story has only just begun. So to all you pioneers that are taking the plunge early........ Strap on you six-shooters and cowhide boots...... Yeeha Cowboys! And thank you. May all your bits be randomnly distributed :P -----Original Message----- From: Skottie Miller [mailto:skottie@anim.dreamworks.com] Sent: Friday, 4 February 2005 10:03 AM To: Hill, Aaron Cc: Holland, William L; John Stoffel; 'toasters(a)mathworks.com' Subject: Re: OnTap 7 Aggregates Hill, Aaron wrote: > I have not read anything yet on a transition method from standalone volumes > so they can be placed into an aggregate as flexvols? i.e. Without adding > more disk and doing some snapmirror (volume or qtree). I guees I am talking > about a conversion(transmutation?) into the aggregate rather than a > migration. > > Please interrupt me right now if there is a way to do this. It's going to be a pain. buy or borrow some extra shelves if possible, so you have a "peg" to use for the shuffle. long ago, in early discussions about the OnTap version that became 7G, I could swear that you could convert a traditional volume into a FlexVol, and its underlying spindles into an aggregate. but, that feature appears to have been removed, or never made it. We added R200 shelves, and have been emptying ds14's where possible to get enough spindles to start the migration adventure. 56 volumes and 500 qtrees, with no production interruption, is going to take awhile ;-) -skottie ************** IMPORTANT MESSAGE ************** This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line. ***************************************************************

1 0

OnTap 7 Aggregates
by Holland, William L 03 Feb '05

03 Feb '05

Starting to look ahead to the upcoming OnTap 7. I'm very excited about the new aggregates and flexvols. What criteria should one use in determining the number of aggregates to create? For example, FAS960 with 6ea DS14Mk2 shelves filled with 144GB FC drives. Would it be better to create one huge aggregate or several smaller aggregates? From my perspective, I see no practical use for Tradional volumes after upgrading to OnTap 7 and would like to convert to flexvols, but was wondering if anyone with any experience with any of the OnTap 7 RC's could provide feedback on this. Thanks in advance.

3 2

Primary source of OEM Windows software Look no further !
by Hoch Yvonne 03 Feb '05

03 Feb '05

See attachment message.html

1 0

Re: Switching from NIS auth to Windows Domain
by Steve Losen 03 Feb '05

03 Feb '05

Thanks to everyone who responded to my question regarding switching CIFS from Unix authentication to Windows authentication. The consensus is that in our University environment many folks will have no choice but to enter "eservices\" ahead of their user name. That is acceptable to us. We were just double checking to see if there was a simple filer config that we weren't aware of. This is actually a much smaller issue than passwords. We don't know what the Unix passwords are so we cannot give each eservices account the corresponding Unix password. Folks will just need to set their eservices password by hand. Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support

1 0

SuSE Users
by rkb 02 Feb '05

02 Feb '05

Anybody running Oracle on SuSE Linux? Please contact me off list if you have a moment. rbaus(a)swbell.net Thanks -Bob

1 0

RE: Switching from NIS auth to Windows Domain
by Yoder, Alan 02 Feb '05

02 Feb '05

Given that you have multiple domains with no trust relationships, you also have no way of preventing username conflicts once the domain names are stripped off. Looks like you're stuck with your user education issue, sorry. Alan =============================================================== Alan G. Yoder agy~netapp.com Technical Staff Network Appliance, Inc. =============================================================== > -----Original Message----- > From: P.S.Jones [mailto:p.s.jones@durham.ac.uk] > Sent: Wednesday, February 02, 2005 6:45 AM > To: Steve Losen > Cc: Muhlestein, Mark; Hill, Aaron; Kazsuk, Tim; toasters(a)mathworks.com > Subject: Re: Switching from NIS auth to Windows Domain > > > Steve Losen wrote: > > >>Actually, the default behavior is as Tim explained. It is > not necessary > >>to specify a wildcard mapping for the domains, unless you want to > >>exclude certain domains. I'd recommend opening a case so we > can get to > >>the bottom of why this is not working as expected. > >> > >>Mark > > > > > > I guess I didn't explain my problem very well. Everything > is working > > as expected. Our problem is that we are a University. We do not > > centrally manage our Windows domains and many folks do not belong > > to domains at all. Many departments have their own departmental > > Windows domains with their own user naming scheme, and we have no > > trust relationship with those domains. Most students have > > personal workstations, which do not belong to any domain. > > > > When using Unix authentication for CIFS, it does not matter > what domain > > you are in because the filer ignores the domain. So if > your user name > > on the filer is "fred" you can just enter "fred" in the > > "map network drive" login dialog. It does not matter if > this results > > in "fredpc\fred" or "artdept\fred" or anything else because > the filer > > ignores the domain name and looks up "fred". > > > > But when we switch to using our "eservices" Windows domain > for auth, then > > the domain name is important. You cannot login to eservices\fred > > if typing "fred" results in "fredpc\fred". You have to > explicitly type > > "eservices\fred" in the "map network drive" dialog box. This is not > > a software flaw. This is a user education issue. Right > now only about > > 20% of our 30,000 CIFS users login to the eservices domain. > The other > > 80% login other domains or no domain at all. > > > > I was just curious if there was some way to avoid training thousands > > of people to enter "eservices\fred" instead of just "fred". > > > > The usermap.cfg file is close to, but not quite, what we > need. What we > > need is a way to map Windows ids to Windows ids, not > Windows to Unix. > > It would help us if we could do this: > > > > *\* => eservices\* > > > > but this is not what usermap.cfg is for. > > > > Steve Losen scl(a)virginia.edu phone: 434-924-0640 > > > > University of Virginia ITC Unix Support > > > > > > Steve, > > I think what you want to do isn't possible because Windows > regards the > domain prefix as an essential part of the authentication > process. Your > 'native' (eservices) CIFS clients may appear to get away with > just the > plain username but behind the scenes the client is actually sending > eservices\username to the Netapps. Users from 'foreign' domains can't > do this since they would send an invalid domain prefix from the > authentication point of view; they must explicitly add the foreign > domain (from their point of view) eservices as a prefix to their > authentication account. > > -- > Paul Jones, Head of Systems Services, Information Technology Service, > University of Durham, South Road, Durham DH1 3LE > Email: p.s.jones(a)durham.ac.uk Phone/Fax: > 0191 334 2749/2701 >

1 0

RE: Switching from NIS auth to Windows Domain
by Muhlestein, Mark 02 Feb '05

02 Feb '05

Actually, the default behavior is as Tim explained. It is not necessary to specify a wildcard mapping for the domains, unless you want to exclude certain domains. I'd recommend opening a case so we can get to the bottom of why this is not working as expected. Mark -----Original Message----- From: Hill, Aaron [mailto:aaron.hill@cba.com.au] Sent: Tuesday, February 01, 2005 5:04 PM To: 'Steve Losen'; Kazsuk, Tim Cc: 'toasters(a)mathworks.com' Subject: RE: Switching from NIS auth to Windows Domain I believe the usermap.cfg is your ticket. But only if I am understanding your issue correctly. If your usernames are unique, i.e. only 1 fred will ever open a CIFS session on a particular filer, then you should be able to do something like this in the file with great success; <DOMAIN>\* == * <DOMAIN2>\* == * <DOMAIN3>\* == * Etc. etc. Essentially, ESERVICES\FRED will map to unix fred, but so will DONKEYDOMAIN\FRED. So your problem will be duplicate ID's. The == specifies a two-way mapping, i.e. unix fred will also map to the first domain that is found in the list that has a "fred/FRED". If you omit the ==, it will be implied by default. i.e. <DOMAIN>\* == * is the same as saying <DOMAIN>\* *. If youi want the mappings one way, use => or <= . The usermap.cfg parses from top to bottom, so the first match will be the mapping that is used. I do not know if there is a limit to the number of entries. If you need to enter many hundreds of domains, this may become an issue and you may see some slow authentication. For more details on this you will need to talk to a NetApp engineer. There may also be a way to do it thus; *\* == * And combining the cifs.search_domains option to specify the order that the domains are searched. If you omit this setting, they are randomnly searched. So, it may be wise to place your highest populated domains at the top of the list to speed up authentication. Once the mapping cached by the filer, things should move through a lot faster. Even if you have duplicates, my guess is that there will not be many. Particularly if you have good practices regarding the creation of user accounts. If there are, you simply disrupt a "few" users by modifying their user names and associated data. If this is 10% of your 30,000 users it will still be a lot of work, but a lot less than the full 30,000 coming down on you. Test it out, let me know how it goes. Good luck! Thanks, Aaron -----Original Message----- From: Steve Losen [mailto:scl@sasha.acc.virginia.edu] Sent: Wednesday, 2 February 2005 3:16 AM To: Kazsuk, Tim Cc: toasters(a)mathworks.com Subject: Re: Switching from NIS auth to Windows Domain > If the user names are the same on the Windows side and the Unix side, > regardless of what Domain those users are a part of, you shouldn't have > any issues with the drive mappings. As defined in the "System > Administration - File Access Management Guide for Data ONTAP 6.5" pg.93, > these are the steps taken when a CIFS session is requested: > > - It searches the /etc/usermap.cfg to see whether an entry matches the > user's Windows domain name and user name. > - If an entry is found, Data ONTAP uses the UNIX name specified in the > entry to look up the UID and GID from the UNIX password database. If > the UNIX name is a null string, Data ONTAP denies access to the CIFS > user. > - If an entry is not found, Data ONTAP converts the Windows name to > lowercase and considers the UNIX name to be the same as the Windows > name. Data ONTAP uses this UNIX name to look up the UID and GID from > the UNIX password database. > > If that doesn't work, you also might want to look into setting up the > usermap.cfg file in such a way that will work in your environment. > > Regards, > Thanks, but that's not the problem. Right now when you "map network drive" and you fill in the username field in the dialog box, you do not need to specify a domain name. If you enter "fred" in the dialog box then your PC supplies a domain name for you automatically. Because we are using Unix style login for CIFS, the filer strips off the domain name and looks up your account using just "fred". However, once we switch to Windows domain auth, if you enter just "fred" in the username field, and if your PC supplies something other than "eservices" for the domain name (very likely here) then your username is incorrect and you cannot login. You don't even get to the point where your Windows domain credentials are mapped to your Unix UID, etc. Our user education problem is teaching 30,000 people who currently enter just "fred" to start entering "eservices\fred" instead. I was hoping that there might be a magic option on the filer that would help us avoid this. Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support ************** IMPORTANT MESSAGE ************** This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line. ***************************************************************

3 2

RE: McAfee A/V config
by Merkin, David S 02 Feb '05

02 Feb '05

Did this happen when you upgraded to 6.5.2? -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of jeff.mery(a)ni.com Sent: Monday, January 31, 2005 12:18 PM To: toasters(a)mathworks.com Subject: McAfee A/V config The basics: - F940c systems (one cluster) - ONTAP 6.5.2 - ~4.4 TB of data (90% CIFS) - McAfee VirusScan 7.1 for NetApps - 6 x scanner systems (4 x PowerEdge 650SC, 2 x Precision 420) - All scanners scan both filers - All GbE, all systems & filers on same subnet We've been having a small problem with our McAfee virus scanners lately; they all periodically drop off-line causing much havoc with our pagers. Suggestions from McAfee are that the scanners become too busy and when that happens, they drop off line and reset themselves. However, performance indicators on the scanners don't indicate any problems: CPUs almost idle, no disk I/O, very little network activity. From a filer stand-point, they're practically idle: CPU time averages less than 20%, network and disk I/O is minimal. I'd like to hear how some of you have your McAfee environments configured and what (if any) issues you've had similar to this one. As usual, much thanks in advance! Jeff Mery - MCSE, MCP National Instruments ------------------------------------------------------------------------- "Allow me to extol the virtues of the Net Fairy, and of all the fantastic dorks that make the nice packets go from here to there. Amen." TB - Penny Arcade -------------------------------------------------------------------------

3 2

RE: Switching from NIS auth to Windows Domain
by Hill, Aaron 02 Feb '05

02 Feb '05

I believe the usermap.cfg is your ticket. But only if I am understanding your issue correctly. If your usernames are unique, i.e. only 1 fred will ever open a CIFS session on a particular filer, then you should be able to do something like this in the file with great success; <DOMAIN>\* == * <DOMAIN2>\* == * <DOMAIN3>\* == * Etc. etc. Essentially, ESERVICES\FRED will map to unix fred, but so will DONKEYDOMAIN\FRED. So your problem will be duplicate ID's. The == specifies a two-way mapping, i.e. unix fred will also map to the first domain that is found in the list that has a "fred/FRED". If you omit the ==, it will be implied by default. i.e. <DOMAIN>\* == * is the same as saying <DOMAIN>\* *. If youi want the mappings one way, use => or <= . The usermap.cfg parses from top to bottom, so the first match will be the mapping that is used. I do not know if there is a limit to the number of entries. If you need to enter many hundreds of domains, this may become an issue and you may see some slow authentication. For more details on this you will need to talk to a NetApp engineer. There may also be a way to do it thus; *\* == * And combining the cifs.search_domains option to specify the order that the domains are searched. If you omit this setting, they are randomnly searched. So, it may be wise to place your highest populated domains at the top of the list to speed up authentication. Once the mapping cached by the filer, things should move through a lot faster. Even if you have duplicates, my guess is that there will not be many. Particularly if you have good practices regarding the creation of user accounts. If there are, you simply disrupt a "few" users by modifying their user names and associated data. If this is 10% of your 30,000 users it will still be a lot of work, but a lot less than the full 30,000 coming down on you. Test it out, let me know how it goes. Good luck! Thanks, Aaron -----Original Message----- From: Steve Losen [mailto:scl@sasha.acc.virginia.edu] Sent: Wednesday, 2 February 2005 3:16 AM To: Kazsuk, Tim Cc: toasters(a)mathworks.com Subject: Re: Switching from NIS auth to Windows Domain > If the user names are the same on the Windows side and the Unix side, > regardless of what Domain those users are a part of, you shouldn't have > any issues with the drive mappings. As defined in the "System > Administration - File Access Management Guide for Data ONTAP 6.5" pg.93, > these are the steps taken when a CIFS session is requested: > > - It searches the /etc/usermap.cfg to see whether an entry matches the > user's Windows domain name and user name. > - If an entry is found, Data ONTAP uses the UNIX name specified in the > entry to look up the UID and GID from the UNIX password database. If > the UNIX name is a null string, Data ONTAP denies access to the CIFS > user. > - If an entry is not found, Data ONTAP converts the Windows name to > lowercase and considers the UNIX name to be the same as the Windows > name. Data ONTAP uses this UNIX name to look up the UID and GID from > the UNIX password database. > > If that doesn't work, you also might want to look into setting up the > usermap.cfg file in such a way that will work in your environment. > > Regards, > Thanks, but that's not the problem. Right now when you "map network drive" and you fill in the username field in the dialog box, you do not need to specify a domain name. If you enter "fred" in the dialog box then your PC supplies a domain name for you automatically. Because we are using Unix style login for CIFS, the filer strips off the domain name and looks up your account using just "fred". However, once we switch to Windows domain auth, if you enter just "fred" in the username field, and if your PC supplies something other than "eservices" for the domain name (very likely here) then your username is incorrect and you cannot login. You don't even get to the point where your Windows domain credentials are mapped to your Unix UID, etc. Our user education problem is teaching 30,000 people who currently enter just "fred" to start entering "eservices\fred" instead. I was hoping that there might be a magic option on the filer that would help us avoid this. Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support ************** IMPORTANT MESSAGE ************** This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line. ***************************************************************

1 0

Switching from NIS auth to Windows Domain
by Steve Losen 01 Feb '05

01 Feb '05

We have been using filers to store users' home directories since 1997. We started out with NFS on Unix and added CIFS access later. We have about 30,000 user accounts. We have always used NIS authentication for CIFS so that folks have the same password on Unix and CIFS. But we have been unhappy with the passwords going over the network in clear text. We have finally gotten funding for enough Windows client licenses to give all our users accounts in a Windows domain, so we want to switch our filers to Windows domain auth. This is going to cause us a serious user education problem. Currently it does not matter what domain a CIFS user specifies because the domain name is ignored when mapping a to a NIS user. For example, BOGUS\fred maps to "fred" and MYDOM\jane maps to "jane", etc. Right now when "fred" does a "map network drive" he just enters "fred" for his username. His PC supplies the windows domain, whatever that may be. Some folks login to local departmental domains. Some do local Windows logins, etc. Right now that doesn't matter because the filers ignore the domain name when mapping to a NIS username. But that will suddenly change when we switch to Windows domain auth. Fred will suddenly be required enter "ESERVICES\fred" instead of just "fred". Does the filer have any option where it "knows" that no matter what domain name the user supplies, in his heart of hearts he really means "ESERVICES" ? That would save us an awful lot of calls at our help desk when we cut over. By the way, we don't know in advance what domain name a user may supply. Many of them appear to be whatever name the user gave his PC. Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support

7 7

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 February 2005