toasters February 2003

toasters@lists.teaparty.net

104 participants
136 discussions

RE: DataONTAP and Solaris 8 NIS Update
by ray.griffith＠bt.com 21 Feb '03

21 Feb '03

We have been using NIS+ on a Solaris 2.6 environment for 5 years and NIS+ on a separate environment for over a year with no issues at all. (Both in compatibility mode) We regard to the NIS Group update issue it is probably a line in the group file that is over 1024 characters in length. We have this happen regularly and the effect is that people have access problems usually via CIFS. We have to "manage" the entry to less than 1024 characters and the group update works OK. This will eventually cause us a problem as there is only so much slack in the one entry that we can take out. There is no way that we can split the group as it is used to manage access to a third party product. One to watch for... :) Ray Griffith -----Original Message----- From: Clawson, Simon [mailto:simon_clawson@mentorg.com] Sent: 21 February 2003 09:44 To: 'Brent.Killion(a)pinnaclewest.com'; toasters(a)mathworks.com Subject: RE: DataONTAP and Solaris 8 NIS Update Hi, We have been using a Solaris 8 NIS Slave, and a Solaris 2.6 NIS Master for over a year now. We have no major hassles, though I do see a message in the syslog on the filer - Fri Feb 21 00:00:55 GMT [nis_grp_updater:warning]: NIS group map has invalid entry in line 7. Continuing to build Local NIS Group Cache. Fri Feb 21 00:00:55 GMT [nis_grp_updater:warning]: NIS group map has invalid entry in line 27. Continuing to build Local NIS Group Cache. Which I guess is due to some spurious entry in the group file. I will eventually sort this out (maybe even today) but apart from that there seems to be no NIS issues at all. FYI, I just did a ypwhich on the filer and it binds to the Solaris 8 slave. Recently we had NT PDC issues, and the only way onto the filer was by NFS mounted shares, so it seems to be as robust as ever. Simon -----Original Message----- From: Brent.Killion(a)pinnaclewest.com [mailto:Brent.Killion@pinnaclewest.com] Sent: 31 January 2003 23:10 To: toasters(a)mathworks.com Subject: DataONTAP and Solaris 8 NIS Update Toasters- A rather interesting update for everyone on the problem I posted yesterday with an 880c and FAS960c clusters that refused to bind to a Solaris 8 NIS server. Just to help us isolate the problem between OS and NIS, we initialized a Solaris 2.6 system, as a NIS slave to the Solaris 8 NIS server that we couldn't get the filers to bind to. Surprisingly, the FAS960c bound with no problems to the Solaris 2.6 NIS slave. To us, this rules out a configuration issue with the NIS domain itself and focuses the problem back to an apparent Solaris 8 NIS/DataONTAP incompatibility. I was somewhat surprised that no one replied that they are using Solaris 8 NIS with DataONTAP. I have updated the tech support case I have opened with both Sun and NetApp and I'll keep the list informed as the solution moves along. Thanks, Brent Killion

1 0

RE: DataONTAP and Solaris 8 NIS Update
by Clawson, Simon 21 Feb '03

21 Feb '03

Hi, We have been using a Solaris 8 NIS Slave, and a Solaris 2.6 NIS Master for over a year now. We have no major hassles, though I do see a message in the syslog on the filer - Fri Feb 21 00:00:55 GMT [nis_grp_updater:warning]: NIS group map has invalid entry in line 7. Continuing to build Local NIS Group Cache. Fri Feb 21 00:00:55 GMT [nis_grp_updater:warning]: NIS group map has invalid entry in line 27. Continuing to build Local NIS Group Cache. Which I guess is due to some spurious entry in the group file. I will eventually sort this out (maybe even today) but apart from that there seems to be no NIS issues at all. FYI, I just did a ypwhich on the filer and it binds to the Solaris 8 slave. Recently we had NT PDC issues, and the only way onto the filer was by NFS mounted shares, so it seems to be as robust as ever. Simon -----Original Message----- From: Brent.Killion(a)pinnaclewest.com [mailto:Brent.Killion@pinnaclewest.com] Sent: 31 January 2003 23:10 To: toasters(a)mathworks.com Subject: DataONTAP and Solaris 8 NIS Update Toasters- A rather interesting update for everyone on the problem I posted yesterday with an 880c and FAS960c clusters that refused to bind to a Solaris 8 NIS server. Just to help us isolate the problem between OS and NIS, we initialized a Solaris 2.6 system, as a NIS slave to the Solaris 8 NIS server that we couldn't get the filers to bind to. Surprisingly, the FAS960c bound with no problems to the Solaris 2.6 NIS slave. To us, this rules out a configuration issue with the NIS domain itself and focuses the problem back to an apparent Solaris 8 NIS/DataONTAP incompatibility. I was somewhat surprised that no one replied that they are using Solaris 8 NIS with DataONTAP. I have updated the tech support case I have opened with both Sun and NetApp and I'll keep the list informed as the solution moves along. Thanks, Brent Killion

1 0

RE: Adding two DS14 Disks to a filer with FC7 & FC9 shelves
by Paul McGuinness (ext. 771) 20 Feb '03

20 Feb '03

We have a DS-14 connected to a set of FC-9 shelves. The only issue I remember was making sure that you have your shelf ID's are correct and the last DS-14 shelf properly terminated. Apart from that everything else was fairly straightforward. (there is a useful little pullout card on front of the DS-14 with LED error codes for the DS-14 - check this if you are having any problems) Paul -----Original Message----- From: Eisler, Alex [mailto:alex.eisler@intel.com] Sent: 20 February 2003 11:14 To: Clawson, Simon Cc: toasters(a)mathworks.com Subject: RE: Adding two DS14 Disks to a filer with FC7 & FC9 shelves As far as I can remember, You can't connect a DS14 to a chain that contains an FC7 or FC8 - But I may be mistaken... Anyhow, the DS14 should be the last shelf in the chain, with the shelves going from the oldest (connected to the filer) to the newest. This change requires the filer to be turned off, but any other DS14 you add can be added live afterwards. The connection method is the same for all shelves - there's an "IN" port and "OUT" port on each shelf, and you should only have one "out" port on your FC9, which you connect to the "in" port on the DS14. Just make sure the termination on the DS14 is on. Alex. -----Original Message----- From: Clawson, Simon [mailto:simon_clawson@mentorg.com] Sent: Thursday, February 20, 2003 12:40 To: 'toasters(a)mathworks.com' Subject: Adding two DS14 Disks to a filer with FC7 & FC9 shelves Hi, We are adding two DS14 disk shelves to an F760 this weekend, which already has two FC7 and one FC9 shelves. The FC9 is the last shelf in the current chain. The documentation on how to connect the shelves up is a bit ambiguous. Do we connect the DS14 to the first LRC module on the FC9? etc etc. Has anyone connected these disks in this way? Thanks Simon Simon Clawson Mentor Graphics HDL Designer Series R&D Rivergate Systems Administrator London Road Berkshire RG14 2QB TEL: 01635 811409 ************************************************************************** The information contained in this e-mail is confidential, may be privileged and is intended only for the use of the recipient named above. If you are not the intended recipient or a representative of the intended recipient, you have received this e-mail in error and must not copy, use or disclose the contents of this email to anybody else. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the copy you received. This email has been swept for computer viruses. However, you should carry out your own virus checks. Registered in Ireland, No. 205721. http://www.FINEOS.com **************************************************************************

1 0

SV: snapmirror.conf, destination_filer must be the "hostname"
by Öberg Mats 20 Feb '03

20 Feb '03

Hi, You can use the local hosts files on the filers to "rename" the interfaces so that filer2-e4 points to filer2-e0's ipaddress. ---- Mats -----Ursprungligt meddelande----- Från: Lim, Weng Kiam [mailto:wklim@rand.com] Skickat: den 20 februari 2003 10:04 Till: toasters(a)mathworks.com Ämne: snapmirror.conf, destination_filer must be the "hostname" Hi All, Currently I am having production data traffic and snapmirror traffic both using the Gigabit interface: Source Target Filer1-e0 Filer2-e0 (100Base-T) (inactive) Filer1-e4 Filer2-e4 (Gigabit) Had been trying to set a private network using the inactive onboard interface just to do the snapmirror. Existing snapmirror.conf of Filer2 Filer1-e4:vol1 Filer2-e4:vol1 - 0 5,9,10,11,12,13,14,15,16,17,18,21 * 1,2,3,4,5,6 New snapmirror.conf of Filer2 Filer1-e0:vol1 Filer2-e0:vol1 - 0 5,9,10,11,12,13,14,15,16,17,18,21 * 1,2,3,4,5,6 However, the hostname of Filer2 is Filer2-e4 and the snapmirror destination has to be the hostname according to the DPG, meaning I can't have an exclusive 100Base-T for the snapmirror traffic. The error is /etc/snapmirror.conf: line 2 destination filer "Filer2-e0" does not match hostname "Filer2-e4", ignoring line Is there any way to make this work? Thanks Lim

1 0

RE: Adding two DS14 Disks to a filer with FC7 & FC9 shelves
by Eisler, Alex 20 Feb '03

20 Feb '03

As far as I can remember, You can't connect a DS14 to a chain that contains an FC7 or FC8 - But I may be mistaken... Anyhow, the DS14 should be the last shelf in the chain, with the shelves going from the oldest (connected to the filer) to the newest. This change requires the filer to be turned off, but any other DS14 you add can be added live afterwards. The connection method is the same for all shelves - there's an "IN" port and "OUT" port on each shelf, and you should only have one "out" port on your FC9, which you connect to the "in" port on the DS14. Just make sure the termination on the DS14 is on. Alex. -----Original Message----- From: Clawson, Simon [mailto:simon_clawson@mentorg.com] Sent: Thursday, February 20, 2003 12:40 To: 'toasters(a)mathworks.com' Subject: Adding two DS14 Disks to a filer with FC7 & FC9 shelves Hi, We are adding two DS14 disk shelves to an F760 this weekend, which already has two FC7 and one FC9 shelves. The FC9 is the last shelf in the current chain. The documentation on how to connect the shelves up is a bit ambiguous. Do we connect the DS14 to the first LRC module on the FC9? etc etc. Has anyone connected these disks in this way? Thanks Simon Simon Clawson Mentor Graphics HDL Designer Series R&D Rivergate Systems Administrator London Road Berkshire RG14 2QB TEL: 01635 811409

1 0

Adding two DS14 Disks to a filer with FC7 & FC9 shelves
by Clawson, Simon 20 Feb '03

20 Feb '03

Hi, We are adding two DS14 disk shelves to an F760 this weekend, which already has two FC7 and one FC9 shelves. The FC9 is the last shelf in the current chain. The documentation on how to connect the shelves up is a bit ambiguous. Do we connect the DS14 to the first LRC module on the FC9? etc etc. Has anyone connected these disks in this way? Thanks Simon Simon Clawson Mentor Graphics HDL Designer Series R&D Rivergate Systems Administrator London Road Berkshire RG14 2QB TEL: 01635 811409

1 0

RE: Snapmanager for Exchange
by Simon Probert 20 Feb '03

20 Feb '03

We had 6 x 150 GB information stores and it took in excess of 10 hours per store so we stopped doing the verification. It deosn't really do anything anyway excpet get NetApp a tick in the box for MS support. We have successfully verified a corrpupted 5.5 database. It is possible to snaprestore an exchange database and then manually ship the logs yourself. It then plays all the logs forward to the time of the failure. There are a number of MS support articles that will help you understand how to do this but the Disaster recovery Whitepaper for Exchange 5.5 is probably the best. Good Luck. -----Original Message----- From: Jay Newton (Email) Sent: 02/20/2003 12:33:45 To: 'toasters(a)mathworks.com' [SMTP:toasters@mathworks.com] Subject: Snapmanager for Exchange For those that run Snapmanager for Exchange, what size are your Exchange databases and how long does it take to verify them? It is taking us 5.5 hours to verify a 100 gig InfoStore. I'd like to know what others are experiencing. Thanks! F840 DOT 6.2.2d8 Exchange 5.5 SP4 SME 1.1 Private GIG network for verification and database transactions ____________________________________________________________________ CAUTION - This message may contain privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify Air New Zealand immediately. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of Air New Zealand. _____________________________________________________________________ For more information on the Air New Zealand Group, visit us online at http://www.airnewzealand.com _____________________________________________________________________ _____ This e-mail message has been scanned and cleared by MailMarshal at gen-i limited www.gen-i.co.nz _____

1 0

Snapmanager for Exchange
by Jay Newton (Email) 19 Feb '03

19 Feb '03

For those that run Snapmanager for Exchange, what size are your Exchange databases and how long does it take to verify them? It is taking us 5.5 hours to verify a 100 gig InfoStore. I'd like to know what others are experiencing. Thanks! F840 DOT 6.2.2d8 Exchange 5.5 SP4 SME 1.1 Private GIG network for verification and database transactions

1 0

RE: "disk fail" command
by Toal, Dave 19 Feb '03

19 Feb '03

Dan, disk unfail might work. smith> priv set advanced Warning: These advanced commands are potentially dangerous; use them only when directed to do so by Network Appliance personnel. smith*> disk usage: disk <options> Options are: fail <disk_name> - fail a file system disk remove <disk_name> - remove a spare disk swap - prepare (quiet) bus for swap unswap - undo disk swap and resume service scrub { start | stop } - start or stop disk scrubbing unfail <disk_name> - make a failed disk a spare again shm_stats [<disk_name>] - Storage Health Monitor stats for a disk smith*> -----Original Message----- From: Dan OBrien To: 'toasters(a)mathworks.com' Sent: 2/19/03 12:44 PM Subject: "disk fail" command Question about "disk fail" command. We are running NetApp Release 5.3.6R2. The System Admin guide says that "[t]he disk fail command permanently marks a disk as failed. You cannot reuse the disk; you must replace it." This is pretty strong statement. Can the disk be *unmarked* with some standalone utility or something? Or are we out of luck? :-( Thanks in advance, Dan O'Brien, dmobrien(a)lcsi.net Cell: 614-783-4859 Work: 614-476-8473 Home: 740-927-2178 Pataskala, OH

1 0

RE: using vol0 / consolidation
by Alan McLachlan 19 Feb '03

19 Feb '03

Stephen, That aspect has been previously covered in this thread, albeit not in as much detail. If one ones to get involved in all the possible issues we can talk about volume options like no_atime_update and minra, but I think it's well understood here that the discussion is about using vol0 for regular network file serving, not for application/database data storage. -----Original Message----- From: Stephane Bentebba [mailto:stephane.bentebba@fps.fr] Sent: Friday, 14 February 2003 7:38 PM Cc: toasters(a)mathworks.com Subject: Re: using vol0 / consolidation Having a separate dedicated volume root (vol0 or something else) is usefull in the Disaster Recovery procedure. By example for any kind of databases (oracle or exchange ....) . First, because there is a different consistence point for Ontapp files (/etc, but also mbr's - what startup the Ontapp at Filer boot time) and database files. Just to make this idea clear, imagine you upgrade Ontapp, and reboot the Filer. Then relaunch the database service which suddenly crash due to corupted files. How would you recover the state before the failure. Second, it facilitates migration. A file server generally has its own life and not always stay in a fixed place, with a fixed amount of disks, or fixed clients connected to.Having a volume for db files apart of root volume allows you to move db files to another Filer for example, or facilitate operations like mirroring (what is the need to get /etc in a database consolidation plan). Taking a look at documents related to "Creating backup vfilers for disaster recovery" is a way to understand this interest more about that. Clawson, Simon wrote: > The only benefit as I see it to having the smallest possible vol0 is > recovery time. You can back up and recover the small amount of data in > a few minutes on most tape devices, meaning you are up and running > fairly quickly in the event of losing the volume. > > However, there are methods of replicating the /etc data to another > volume, then telling the filer to boot this as vol0. This would of > course mean any NIS maps etc are broken until you change their paths, > but the filer would be up and running quicker than if you were to have > to restore the whole root volume first, and you would not be using two > 72Gb disks for 40mb of data. > > -----Original Message----- > *From:* Alan McLachlan [mailto:amclachlan@asi.com.au <mailto:amclachlan@asi.com.au> ] > *Sent:* 13 February 2003 01:29 > *To:* Charles Bartels; toasters(a)mathworks.com > *Subject:* RE: using vol0 > > Hi Charles, > > Don't understand why you're asking this. In most cases that I'm > aware of vol0 is used for data. > > In some cluster scenarious, particularly with local or remote > syncmirror, it becomes necessary to burn two disks to have a root > volume that's just for the filer's config files - usually only on > one half of the cluster. > > I can't imagine apart from that why someone would want to consume > two whole drives for the 40MB or so of data in the /etc directory. > > In fact, many of my customers have only configured a second volume > in order to support a database. User home directories and > workgroup data stay on vol0. > > You should of course make use of qutoa'd qtrees within vol0 > extensively to prevent it filling up - theoretically this could > cause a panic in some circumstances although Data OnTap is much > more robust than a Unix or Linux in this regard. > > ---------------------------------------------------------------------------- --------------------------- > > On a related note, one issue that crops up from time to time is > that when a filer is used to replace a bunch of Windows > fileservers on a large CIFS network, it can happen that > well-meaning Domain Admins that don't directly look after the > filer and aren't trained in Data OnTAP may accidently corrupt > config files in the /etc directory. It would be nice to restrict > access to just a select group of trained admins. > > Using a Windows domain group is not the answer, as any Domain > Admin can take ownership of the resource. > > A solution is to turn the /etc directory into a unix security > style qtree: > > * make a new qtree called say "etcnew" > * copy the files from /etc to /etcnew > * rename /etc to "etcold" > * rename /etcnew to "etc" > * set the security style of etc to unix > > This works even if you only have a CIFS licence. You should then > install ssaccess on a workstation to manage the security on the > /etc qtree. > > Then, in the usermap.cfg file in /etc put an entry for each > trusted admin like so: > > *\root => nobody (security defensive entry) > DOMAIN\fred => root > DOMAIN\wilma => root > > As the final step, set *options wafl.nt_admin_priv_map_to_root *to > OFF. > > The result is that, in the example above, only the domain users > "fred" and "wilma" can make changes to the /etc directory. For all > the other resources on the filer (which have NTFS security style), > normal domain security rules apply. > > > > -----Original Message----- > *From:* Charles Bartels [mailto:cbartels@openharbor.com <mailto:cbartels@openharbor.com> ] > *Sent:* Wednesday, 12 February 2003 3:45 AM > *To:* toasters(a)mathworks.com > *Subject:* using vol0 > > Hi, > > I'm configuring an F810 and space is going to be a little > tight. How do people feel about adding disks to vol0 and > using that instead of creating a whole separate volume (and > burning a another parity disk) ? > > -Charles Bartels > > > > **** ASI Solutions Disclaimer **** > > The material transmitted may contain confidential and/or > privileged material and is intended only for the addressee. If you > receive this in error, please notify the sender and destroy any > copies of the material immediately. ASI will protect your Privacy > according to the 10 Privacy Principles outlined under the new > Privacy Act, Dec 2001. > > > This email is also subject to copyright. Any use of or reliance > upon this material by persons or entities other than the addressee > is prohibited. > > > E-mails may be interfered with, may contain computer viruses or > other defects. Under no circumstances do we accept liability for > any loss or damage which may result from your receipt of this > message or any attachments. > > **** END OF MESSAGE **** > **** ASI Solutions Disclaimer **** The material transmitted may contain confidential and/or privileged material and is intended only for the addressee. If you receive this in error, please notify the sender and destroy any copies of the material immediately. ASI will protect your Privacy according to the 10 Privacy Principles outlined under the new Privacy Act, Dec 2001. This email is also subject to copyright. Any use of or reliance upon this material by persons or entities other than the addressee is prohibited. E-mails may be interfered with, may contain computer viruses or other defects. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. **** END OF MESSAGE ****

2 2

← Newer
1
2
3
4
5
6
7
8
...
14
Older →

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