toasters

toasters@lists.teaparty.net

2 participants
13529 discussions

RE: nis.group_update.enable
by Krueger, Jeffrey 04 Mar '05

04 Mar '05

Does anyone have experience using LDAP to obtain group information on filers using the RFC 2307 compliant options in DOT 6.5 and up, specifically with Novell eDirectory? I'm also curious about how the ldap.usermap.* options work - the documentation is a bit vague on what the filer expects to see in the .attribute.*account options and how/when lookups are performed. Anyone played this or know what the code does? - Jeff -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Steve Losen Sent: Thursday, March 03, 2005 3:32 PM To: Bob Borowicz Cc: toasters(a)mathworks.com Subject: Re: nis.group_update.enable > I read where it was recommended (I think for Oracle RAC) to enable the > following option: > > nis.group_update.enable > > The man page says this enables a local cache of the group data. > > Are calls to the NIS (ypbind) slow in DOT? > > I'm running 6.4.4R1 > The problem is that NIS provides group maps keyed by group name and by group number (gid). It does not, however, provide a map that is keyed by user that lists all the groups that the user belongs to. But this group list is what a filer needs whenever a user logs in to CIFS (to map windows credentials to Unix credentials) In order to discover which groups a user belongs to, the filer must use NIS to fetch each group entry and see if the user is listed in it. If you have a very long group map, then every time a user logs in to CIFS the filer must fetch each group entry, with a separate NIS transaction for each one. By caching the group map, the filer can get the user's group list without NIS. Who knows, the cache may even be organized as group lists keyed by user name. This is not a problem peculiar to netapps. All Unix systems that use NIS have to linearly scan the entire group map every time a user logs in, to find the user's groups. If you are not using CIFS then you don't have a problem. NFS does not cause the netapp to scan the group map because each NFS packet contains the user's uid, gid, and group list. The NFS client obtains this information once when the user logs in. I also wouldn't worry about it if your group map is not large. Anecdote alert: A few years back one of our NIS servers started chewing up tons of CPU. I traced it and discovered that it was almost 100% sequential scans of our very large group map (almost 700 groups). It turned out that most of these scans were coming from the same machine, which was a busy web server. We had a CGI program run via suexec (which runs the CGI as a particular user). Suexec sets the group list for the user, which requires a linear scan of the NIS group map. So every time this CGI was hit (constantly) the web server was shooting almost 700 NIS requests at the NIS server. On our netapps and web servers we are now using local /etc/group files updated periodically by cron jobs that copy the NIS map to the local file -- much much better. Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support

1 0

nis.group_update.enable
by Bob Borowicz 04 Mar '05

04 Mar '05

I read where it was recommended (I think for Oracle RAC) to enable the following option: nis.group_update.enable The man page says this enables a local cache of the group data. Are calls to the NIS (ypbind) slow in DOT? I'm running 6.4.4R1 Thanks -Rob

4 3

RE: Destroying failed disks
by Hill, Aaron 04 Mar '05

04 Mar '05

Until you get a permanent solution; Please rate this solution at bottom of page. Solution ID: ntapcs9168 Solution Status: Publish-Public Title: How does NetApp ensure the integrity of data on returned disks? What happens to RMA disks? - NetApp appliances Problem Environment: NearStore appliance R100 NetApp filer FAS900 series F800 series F700 series F600 series F500 series F300 series F200 series Data ONTAP Disk drives Problem Description How does NetApp ensure the integrity of data on returned disks? What happens to RMA disks? Solution: All disk drives returned to Network Appliance are subjected to a three part failure verification process. The last step involves a "zero disk" command which does a "Write Same Zero" at the sector level overwriting all data on the drive with zeros. Drives are completely wiped of any and all data. In rare cases, the drive does not function sufficiently to overwrite the data. As a part of the normal warranty processing, the drive would be shipped back to the supplier with customer data intact, although not readily accessible. Because of the way RAID 4 works, with striping of data across multiple disks, even if the data becomes readable by the supplier on a restored disk, it would be almost impossible to make the data usable. For more information on how RAID 4 works, refer to 5.2. Eliminating the Parity Disk Bottleneck in NetApp Tech Report 3001. Network Appliance has non-disclosure agreements with all its suppliers to further ensure that your data is protected. However, for customers on secure sites, or who require an additional level of security regarding their data, there is a "No-Return" service agreement available under which it would not be necessary to return drives that have failed. For more information regarding this type of service agreement, please contact your NetApp sales representative. Last updated: 08 JAN 2003 -----Original Message----- From: Chris Thompson [mailto:cet1@cus.cam.ac.uk] Sent: Friday, 4 March 2005 5:25 AM To: galjan(a)gmail.com Cc: toasters(a)mathworks.com Subject: Re: Destroying failed disks Paul Galjan <galjan(a)gmail.com> writes; > For those interested, this article shows what Netapp does with returned disks: > http://now.netapp.com/Knowledgebase/solutionarea.asp?id=ntapcs9168 > --paul I would love to read this page, but for some reason whenever I display it, after a second or less it gets replaced by the much more boring http://now.netapp.com/NOW/Error/bad_gateway.pl Anyone know how I can prevent that happening? -- Chris Thompson Email: cet1(a)cam.ac.uk ************** 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

RE: nis.group_update.enable
by Jeff Mohler 03 Mar '05

03 Mar '05

Not really slow, but since a filer is meant to consolidate many other servers worth of data, the amount of calls can be obscene in some cases. Either way, it does increase performance. Now..I dont recall, but I -think- that you can place your group/etc files in /etc on a filer, and it will honor them, however you cant do a push from your NIS master to a filer to update them. :( I argued for that years ago, it makes sense to allow it, but it never got anywhere. -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com]On Behalf Of Bob Borowicz Sent: Thursday, March 03, 2005 5:38 PM To: toasters(a)mathworks.com Subject: nis.group_update.enable I read where it was recommended (I think for Oracle RAC) to enable the following option: nis.group_update.enable The man page says this enables a local cache of the group data. Are calls to the NIS (ypbind) slow in DOT? I'm running 6.4.4R1 Thanks -Rob

1 0

RE: Destroying failed disks
by Jeff Mohler 03 Mar '05

03 Mar '05

It's a calculated trade-off. We assume that NetApp does the right thing and crunches the disks once they have done a failure analysis back in their labs. --- If you assume that, and you really care, I would not assume any vendor of drives or storage material does this. I have NO idea what Netapp does, but I would not ASSUME that they physically destroy disks with your data on them. Right now, I assume youre thinking about upping your service contract to be able to keep your own dead disks so that you can destoy them yourself and remove the assumption of the mitigation of risk. But only you can know for sure.

4 3

Automatización de Procesos - Calidad ISO
by Gestion documental - Su empresa sin papel 03 Mar '05

03 Mar '05

www.gitdoc.com <http://www.gitdoc.com> Somos líderes en el desarrollo y personalización de soluciones integrales de gestión documental y automatización de procesos "workflow", adaptadas a procesos específicos de negocio. Nuestra propuesta de valor: GIT-DOC se ha desarrollado como una potente herramienta de gestión documental que permite parametrizar cualquier necesidad a la hora de estructurar documentos, gestionar contenidos o automatizar procesos con ilimitados requerimientos. Consultoría Gestión documental Workflow Gestión de contenidos Soluciones: Registro de entrada-salida Recortes de prensa Pedidos-Albaranes-Facturas Gestión de expedientes Pymes, Clínicas, Abogados Servicios: Digitalización de documentos Grabación de índices Archivo y custodia Ofrecemos distribución Nicolás Mendoza Tel.: 629 80 34 34 - 902 999 073 www.gitdoc.com <http://www.gitdoc.com> gitdoc(a)gitdoc.com <mailto:gitdoc@gitdoc.com> AVISO LEGAL Le recordamos que su cta. de e-mail figura registrada en nuestra base de datos al confirmar su deseo de recibir nuestras ofertas. Dicha información será tratada de forma totalmente confidencial con arreglo a la nueva ley L.S.S.I. y no será vendida ni traspasada a terceros en ningún caso. Si Vd. recibe este e-mail debido algún error o no es su deseo recibir mas e-mail nuestros, puede darse de baja de forma inmediata, simplemente pulsanso sobre B O R R A R <http://ias.cadema-gitdoc.com/webapp/servlet/Sborrar?email=toasters@math works.com>

1 0

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

02 Mar '05

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.

1 0

converting root volume to flexvol
by Adam McDougall 02 Mar '05

02 Mar '05

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.

1 0

Save yourself from Gal Bladder (Kidney Stone)
by Citizen Welfare Organisation 01 Mar '05

01 Mar '05

Following is the article extracted from dawn (28/02/05) KARACHI: Reduction in tea urged to check stone formation - Urolithiasis symposium concludes KARACHI, Feb 27: Health experts at a symposium on Sunday recommended that tea and coffee should be reduced and dark-coloured soft drinks, aerated drinks and alcohol should be avoided to prevent formation of urinary stones. They were speaking at the concluding session of three-day urolithiasis symposium, organized by the Sindh Institute of Urology Transplant in association with the European Urolithiasis Society. During the panel discussion on "Are urinary stones preventable?" health professional said that excess oxalates in diet, less fluid intake particularly in hot climate, and warm working environment were common risk factors for stone formation in the urinary tract. Panellists of the session were Dr S.R. Khan from the USA, Dr A. Rodgers from S. Africa, Dr P.N. Rao from the United Kingdom, Dr A. Hesse from Germany, Dr K. Sarica from Turkey, Dr F. Marickar from India, Dr D. Gohel from Hong Kong, Dr N. Laube from Germany, Dr P. Shrivastav from India and Dr Adibul Hasan Rizvi. Dr A. Naqvi was the moderator. The joint consensus was that recurrence of stones in a person having had stone disease could be decreased. "General recommendations are that fluid intake should be sufficient to make the urine of a light colour. Plain water, barley water and rice water are beneficial. Yoghurt is also beneficial as it helps to disintegrate bacteria," they said. Earlier, describing the history of urinary tract stone disease, Dr F.A. Khan from Lahore stated that Andersen in 1932 had described southern Punjab as the hot spot for kidney stones. Reporting the results of a survey on bladder stone among children in Punjab, he said that the age at onset was as low as one year, while it was also observed that in Northern Punjab upper tract stones were higher in incidence, whereas in Southern Punjab bladder stones were more common. "Bladder stones in children are closely linked with poverty and diarrhoeal disease," he added. Dr M.D.I. Gohel from Hong Kong discussed whether kidney stones be eradicated by herbal medicines. He delivered an interesting talk on Chinese kampou medicine, being used to inhibit calcium oxalate crystallization. He said that experimental studies had proved that herbal medicines contained substances, which could prevent calcium oxalate aggregation and growth. This could prevent renal stone formation and help to expel the crystal easily, he added. Dr Fazil Marickar from India said that plant extracts, especially scoparia dulcis, had proved very successful in clearing renal injuries produced by oxalate crystals. "Substances as tamarind, plantain stem and horse gram help in passage, reduction of size and movement of stones," he added. Talking on ethnobotanic approaches towards treatment of stone disease, Dr I. Chaudhry said that it was conversion of a natural product into a useful substance. He predicted that in future food fossils would be consumed in larger quantities and research on them would help in using them as therapy for many diseases. Discussing the metabolic aspects of stone disease, Dr Shrivastav from India said that low urinary volume, low citrate and high uric acid levels in urine had been observed in significantly large number of patients with renal stones. "These factors could be taken as predictors for stone formation in the future," he added. -PPI This is a public welfare message and sent one time any ways if u want to unsubscribe then send an email with a subject remove to removemefromlist(a)gawab.com If you want to send your offer to 500,000 peoples then email at khimarketing(a)gawab.com

1 0

RE: Quick access to quota information
by barrie_spence＠agilent.com 28 Feb '05

28 Feb '05

I've just been busy writing a script to manage and enforce quotas the "UNIX way" (i.e. lock down the quota at the soft limit if the user doesn't cleanup within 14 days of exceeding it). The CPAN Perl "Quota" module works a treat: use Quota; $host='filer'; $volume_path = '/vol/vol1/users'; $uid = 501; ($block_curr, $block_soft, $block_hard, $block_timelimit, $inode_soft, $inode_hard, $inode_timelimit) = Quota::rpcquery($host, $volume_path, $uid); It's pretty fast and appears to work on HP-UX, Solaris and Linux. The only thing you have to watch for is that the results are low while the quotas are resizing (easy to check with a SNMP query). Regards, Barrie -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Jacek Nogala Sent: 21 February 2005 09:36 To: toasters(a)mathworks.com Subject: Quick access to quota information The landscape: - The company is cable tv providing also Internet services - They intend to use FAS920 in NFS environment (all servers are Linux) - At this very moment they are servicing about 80k users but wanting to be able to service more that 200k - Services for users are to be implemented with UID and GID quotas Requirements: - They need to be able to retrieve quickly information about current quota usage for each specific UID or GID. - The information will be available via: -- Call Center - estimated queries 12 times per minute -- WEB GUI for users - estimated queries 120 times per minute - The quota information should be retrieved within 2 s and should be not older than 30 s - There is not specific requirements regarding method of getting the result (SNMP/RSH/NFS RPC/HTTP are acceptable) We discussed with them SNMPwalk and quota report parsing but they cannot accept it due to high and growing number of users. The most convenient way would be short series of SNMP queries for specific UID / GID. Any suggestions other than "make and parse quota report" are welcome. Best regards, Jacek

2 1

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