toasters

toasters@lists.teaparty.net

3 participants
13513 discussions

Autosupport HTTPs receiver self hosted
by Alexander Griesser 18 Jul '19

18 Jul '19

Hey there, when using SMTP for autosupports, one can add additional e-mail addresses which will also receive the SMTP notifications and we're using this feature to collect autosupports in one of our support mailboxes. If we'd want to move away from SMTP, how could we do that in the future? When we switch to the https transport method, the autosupports most likely will only be posted to NetApp, I suppose. Am I overlooking something or is there really no way to specify an additional URL or something like this so that we can also receive these alerts then? Ideally, I'd either like to run the autosupport receiver locally on our infrastructue and forward the requests to NetApp then. This way, I could parse the requests and (if necessary) create tickets, etc. and archive them internally. Anyone ever worked on something like this or knows where I can find more information about that? Thanks, Alexander Griesser Head of Systems Operations ANEXIA Internetdienstleistungs GmbH E-Mail: AGriesser(a)anexia-it.com<mailto:AGriesser@anexia-it.com> Web: http://www.anexia-it.com<http://www.anexia-it.com/> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

2 5

Find Chassis PSU Part Number
by Alexander Griesser 16 Jul '19

16 Jul '19

Hey there, on one of my lab systems, a chassis PSU broke (no maintenance anymore). I'm trying to find out what part number I need to replace here, but didn't have any luck so far. ::> system controller fru show-manufacturing-info -instance Node: XXX System Serial Number: XXX Model Name: FAS8020 System ID: XXX Kernel Version: NetApp Release 9.1P12: Mon Mar 5 05:01:09 PST 2018 Firmware Release: 9.5 FRU Description: PSU2 FRU Sub-type: - FRU Serial Number: 1350ABA-1349-XXXX FRU Part Number: 114-00040 FRU Revision of Part Number: +A5 FRU Manufacturer: - FRU Manufacturing Date: - FRU Product Identifier: - When I use part finder, it lists three different compatible models, as it seems: SP-763-R5 SP-763-R6 X763-R6 And I'm not sure which one is the right one here or is any 1300W PSU working in this situation? Thanks, Alexander Griesser Head of Systems Operations ANEXIA Internetdienstleistungs GmbH E-Mail: AGriesser(a)anexia-it.com<mailto:AGriesser@anexia-it.com> Web: http://www.anexia-it.com<http://www.anexia-it.com/> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

2 2

Need to quickly downgrade from 9.5 to 8.2.4
by Carolyn Chambers 07 Jul '19

07 Jul '19

Hello, We are the middle of move planning and need to snapmirror some 7 Mode data. The gear we have for the destination is from the factory with 9.5. The usual netboot is throwing errors. Any suggestions? Thanks, Carolyn 972.578.2708

7 13

Migrating ONTAP 8.3 to 9.5
by Edward Rolison 01 Jul '19

01 Jul '19

I've got a new cluster in, running the latest and greatest ONTAP version. For reasons, the predecessor cluster is running a 'stable' platform, and hasn't been tracking the most recent updates. It's a snapmirrored cluster. I'm trying to figure out migration routes now. Is there any equivalent of 7-mode -> CDOT TDP replication, or am I going to have to bite the bullet and do an update on the source cluster to a newer version? And if so, because the snapmirror relationship that already exists, does that mean a 'stepped' approach of 8.3->9.1->9.4 (to 9.5 potentially) because that's what I'll need to do to preserve the snapmirror relationship with the replication partner? I'm not overly keen on pushing up a major version number on both our prod/DR environment but if the choice is that or 'rsync/xcp' then I'll probably go with that. I am just hoping there's a migration-assist option that means I don't have to do that, analogous to TDP from 7 mode.

4 4

Providing someone access to shut down storage
by cs 20 Jun '19

20 Jun '19

Hi, Has anyone out there set up a foolproof tool for admins to use to shut down storage clusters during/for maintenance? Or do you simply let them go down / come up with the power like a network switch? I’m trying to figure out what it would take to create an “easy button” admins could use to shut down a storage cluster, basically so I don’t have to get up in the middle of the night to run one command. Some kind of web-based interface I could enable/disable as needed where an admin could type the name of the cluster in a text box and click the shutdown button. I suppose they should authenticate with the interface so their credentials could be captured and logged too. I suppose I could cron-job it, but that relies on others doing their part to get VMware shut down before the storage goes away. -- scott

1 0

server-ca certs expiring
by cheese＠nosuchhost.net 18 Jun '19

18 Jun '19

hi i have several systems with ontap 9.3P10 and have messages like: 6/12/2019 00:00:01 L1Q-A1 ERROR mgmtgwd.certificate.expiring: A digital certificate with Fully Qualified Domain Name (FQDN) Class2PrimaryCA, Serial Number 85BD4BF3D8DAE369F694D75FC3A54423, Certificate Authority 'Class 2 Primary CA' and type server-ca for Vserver L1Q will expire in the next 25 day(s). what should i do here? my netapp partner told me to renew them via deleteing them and creating new certs. i should create a new server-ca, which is not even an option in ontap (even with advanced privileges) ? i think this must be wrong. i hope others have the same problem and a solution. yours josef

5 7

Is there a best practice for adjust RAID "scrub" options?
by Sylvain Robitaille 05 Jun '19

05 Jun '19

Hello NetApp Gurus. I'm hoping mostly to get some guidance on RAID group scrubbing options and with some luck, perhaps pointers to documentation that would help me determine appropriate values in our environment. We've been seeing what feels like a large number of scrubbing "timeouts" on our filers. Log entries similar to this one: May 28 05:00:02 fc1-ev-n1.console.private [kern.notice] [fc1-ev-n1:raid.scrub.suspended.timer:notice]: Disk scrub suspended because the scrub time limit 240 was exceeded. It will resume at the next weekly/scheduled scrub. What we'd like to know is how concerned we should be about this. Ideally we'd be seeing "scrubs" complete reasonably frequently, but I'm honestly not sure how I could determine how frequently that happens, or how frequently it *should* happen for that matter. The scrub options on the filer have not been changed from the Ontap defaults (NetApp Release 9.5P2, but we've been seeing this with earlier versions as well): Node Option Value Constraint ------- ----------------------- ------ ---------- fc1-n1 raid.media_scrub.rate 600 only_one fc1-n1 raid.scrub.perf_impact low only_one fc1-n1 raid.scrub.schedule none (and the same for the partner node, of course) The "storage raid-options" manual page indicates that the default schedule of daily at 1am for 4 hours, except Sundays when it runs for 12 hours, applies if no explicit schedule is defined. If I examine the scrub status of our aggregates: fc1-ev::> storage aggregate scrub -aggregate * -action status Raid Group:/e1n2_tssd/plex0/rg0, Is Suspended:false, Last Scrub:Thu May 30 02:39:10 2019 Raid Group:/e1n2_t01/plex0/rg0, Is Suspended:true, Last Scrub:Sun May 26 02:55:15 2019, Percentage Completed:65% Raid Group:/e1n2_t02/plex0/rg0, Is Suspended:false, Last Scrub:Thu May 30 02:28:37 2019 Raid Group:/e1n2_root/plex0/rg0, Is Suspended:false, Last Scrub:Thu May 30 03:39:03 2019 Raid Group:/e1n1_root/plex0/rg0, Is Suspended:false, Last Scrub:Wed May 29 02:03:43 2019 Raid Group:/e1n1_d01/plex0/rg0, Is Suspended:true, Last Scrub:Tue May 28 03:22:52 2019, Percentage Completed:7% Raid Group:/e1n1_d01/plex0/rg1, Is Suspended:true, Last Scrub:Wed May 29 02:00:56 2019, Percentage Completed:4% Raid Group:/e1n1_d01/plex0/rg2, Is Suspended:false, Last Scrub:Wed May 29 04:02:50 2019 Raid Group:/e1n1_d01/plex0/rg3, Is Suspended:false, Last Scrub:Wed May 29 04:08:45 2019 Raid Group:/e1n1_d00/plex0/rg0, Is Suspended:true, Last Scrub:Sun Apr 28 06:00:40 2019, Percentage Completed:81% Raid Group:/e1n1_d00/plex0/rg1, Is Suspended:true, Last Scrub:Sun Apr 28 07:38:30 2019, Percentage Completed:80% The truth is I'm not sure how to interpret this output: - Is it the case that each RAID group where "Is Suspended:false" *completed* its scrub at the "Last Scrub" time, while those that are suspended are those for which we're seeing log entries? - Given the default schedule that has the scrub run for 12 hours on Sunday mornings, does it seem odd that /e1n2_t01/plex0/rg0 was suspended last Sunday at 02:55:15, prior to completion? In fact, all those interrupted on a Sunday were interrupted well before 12 hours. Might there be other reasons for suspending scrub operations? The load on this filer is not excessive in any way: CPU utilization is typically comfortably below 50% - How do I determine why the two RAID groups containing e1n1_d00 haven't run scrubbing in over a month? Is there something I should do about that? I've found documentation that explains the options and how to change them, but none that explains how to decide whether I *should* change them, or how to determine what to change them to. I'm interpretting that raid.media_scrub.rate and raid.scrub.schedule could be used together to tune the scrubbing, but am quite unsure how to determine what the best values would be for our filers. Any pointers to documentation that would help here would be hugely appreciated. Thanks in advance ... -- ---------------------------------------------------------------------- Sylvain Robitaille syl(a)encs.concordia.ca Systems analyst / AITS Concordia University Faculty of Engineering and Computer Science Montreal, Quebec, Canada ----------------------------------------------------------------------

3 5

all.zip and all_shelf_fw.zip most current versions
by Alexander Griesser 28 May '19

28 May '19

Hey, I'm interested in the ways people keep their firmware updated on their filers. On the support website, you can download all.zip and all_shelf_fw.zip, but they are most of the time not recent enough, so f.ex. today I could download all.zip from 10-APR-19 and there is more recent firmware for quite some disks dated with 17-May-19. Does anyone know if there is a public/private URL where I can download a "nightly" build or something like this for all.zip? Or is there any URL/FTP/etc. (without having to parse the download website with some selenium scripts or something like that) that I could use to mirror all the firmware files to one of my servers and create the zip file there? Best, Alexander Griesser Head of Systems Operations ANEXIA Internetdienstleistungs GmbH E-Mail: AGriesser(a)anexia-it.com<mailto:AGriesser@anexia-it.com> Web: http://www.anexia-it.com<http://www.anexia-it.com/> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

5 11

OSX/Chrome Login to Netapp Support
by Douglas Siggins 24 May '19

24 May '19

Greetings, Throughout the transition to the new support site I was beginning to have SSO issues logging into the netapp support site (endless redirects). I was able to work around that. Now, I can no longer use chrome to login as of approx. 1-2 months ago maybe? I've disabled all extensions and started with new profile without luck. I have no issues logging in with Firefox. Nor using chrome from Windows 10 or just about any linux destop. Is anyone else with Chrome on OSX having similar issues? Regards, Douglas

3 2

DNS woes
by Scott Classen 25 Apr '19

25 Apr '19

Hello, Can anyone help me with this before I open a case with NetApp? dns check on one of my sververs fails (see below where I get an “Operation timed out” error), but I can ping and traceroute from the vserver to the gateway and the DNS servers. sibyls2::*> dns show -vserver als-enable-ds1 Vserver: als-enable-ds1 Domains: als.lbl.gov, lbl.gov Name Servers: 131.243.5.1, 131.243.5.2 Timeout (secs): 2 Maximum Attempts: 1 Is TLD Query Enabled?: true Require Source and Reply IPs to Match: true Require Packet Queries to Match: true sibyls2::*> dns check -vserver als-enable-ds1 Name Server Vserver Name Server Status Status Details ------------- --------------- ------------ -------------------------- als-enable-ds1 down Operation timed out. 131.243.5.1 als-enable-ds1 down Operation timed out. 131.243.5.2 2 entries were displayed. sibyls2::*> ping -node sibyls2-03 -destination 131.243.78.1 -vserver als-enable-ds1 -wait-response 2000 -count 3 131.243.78.1 is alive sibyls2::*> ping -node sibyls2-03 -destination 131.243.5.1 -vserver als-enable-ds1 -wait-response 2000 -count 3 131.243.5.1 is alive sibyls2::*> ping -node sibyls2-03 -destination 131.243.5.2 -vserver als-enable-ds1 -wait-response 2000 -count 3 131.243.5.2 is alive sibyls2::*> ping -node sibyls2-04 -destination 131.243.78.1 -vserver als-enable-ds1 -wait-response 2000 -count 3 131.243.78.1 is alive sibyls2::*> ping -node sibyls2-04 -destination 131.243.5.1 -vserver als-enable-ds1 -wait-response 2000 -count 3 131.243.5.1 is alive sibyls2::*> ping -node sibyls2-04 -destination 131.243.5.2 -vserver als-enable-ds1 -wait-response 2000 -count 3 131.243.5.2 is alive sibyls2::*> traceroute -node sibyls2-03 -vserver als-enable-ds1 -destination 131.243.78.1 traceroute to 131.243.78.1 (131.243.78.1), 64 hops max, 40 byte packets 1 vlan3078.irals.lbl.gov (131.243.78.1) 0.521 ms * 0.484 ms sibyls2::*> traceroute -node sibyls2-03 -vserver als-enable-ds1 -destination 131.243.5.1 traceroute to 131.243.5.1 (131.243.5.1), 64 hops max, 40 byte packets 1 vlan3078.irals.lbl.gov (131.243.78.1) 0.478 ms 0.369 ms 0.376 ms 2 xe-2-2-1.er1-n1.lbl.gov (131.243.244.140) 0.411 ms 0.391 ms 0.330 ms 3 t5-4.ir1-n1.lbl.gov (131.243.244.131) 0.796 ms 1.365 ms 0.524 ms 4 ns.lbl.gov (131.243.5.1) 0.402 ms 0.765 ms 0.936 ms sibyls2::*> traceroute -node sibyls2-03 -vserver als-enable-ds1 -destination 131.243.5.2 traceroute to 131.243.5.2 (131.243.5.2), 64 hops max, 40 byte packets 1 vlan3078.irals.lbl.gov (131.243.78.1) 0.446 ms 0.409 ms 0.375 ms 2 nsals.lbl.gov (131.243.5.2) 0.649 ms 1.047 ms 1.080 ms sibyls2::*> traceroute -node sibyls2-04 -vserver als-enable-ds1 -destination 131.243.78.1 traceroute to 131.243.78.1 (131.243.78.1), 64 hops max, 40 byte packets 1 vlan3078.irals.lbl.gov (131.243.78.1) 0.443 ms * 0.502 ms sibyls2::*> traceroute -node sibyls2-04 -vserver als-enable-ds1 -destination 131.243.5.1 traceroute to 131.243.5.1 (131.243.5.1), 64 hops max, 40 byte packets 1 vlan3078.irals.lbl.gov (131.243.78.1) 0.515 ms 0.402 ms 0.388 ms 2 xe-2-2-1.er1-n1.lbl.gov (131.243.244.140) 0.513 ms 0.344 ms 0.326 ms 3 t5-4.ir3-n2.lbl.gov (131.243.244.129) 1.737 ms 1.618 ms t5-4.ir4-n3.lbl.gov (131.243.244.133) 0.582 ms 4 ns.lbl.gov (131.243.5.1) 0.898 ms 1.213 ms 0.517 ms sibyls2::*> traceroute -node sibyls2-04 -vserver als-enable-ds1 -destination 131.243.5.2 traceroute to 131.243.5.2 (131.243.5.2), 64 hops max, 40 byte packets 1 vlan3078.irals.lbl.gov (131.243.78.1) 2.075 ms 1.451 ms 0.403 ms 2 nsals.lbl.gov (131.243.5.2) 1.198 ms 0.410 ms 0.911 ms

4 10

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