Hi There

I realize some of you may know this, but just in case...

Asup to NetApp, as of around 6.4 or 6.5, has the option of sending to NetApp via HTTP or HTTPS. This was implemented because of issues Mike Sphar mentioned (SMTP relays not being configured to allow the filer to send to netapp.com or the config changing). Unless you block HTTP out of your datacenter, you should really use this transport. If you block direct HTTP, but have a proxy, there's an option for that too.

autosupport.support.enable on autosupport.support.proxy autosupport.support.to autosupport@netapp.com <<<< Only used for SMTP autosupport.support.transport https autosupport.support.url support.netapp.com/asupprod/post/1.0/postAsup (url is hard-coded)

HTTPS is the default for new installs. Systems that have been installed since before this option existed, or have been upgraded from an install that predates this may still be set to their original SMTP settings. I don't know off top of my head if any ONTAP upgrades change this at all.

HTTP does not have the same message size limits that SMTP usually does.

These options must be set from the CLI (console or telnet/SSH), since they're not exposed in FilerView.

If you want to check if asup is working at all, when you might not be getting messages, ask support or your SE to check for asups at our end. The filer also syslogs errors encountered by asup, by default in /etc/messages and on the console, if connected when the problem occurs.

The other reason I bring this up is that even if your filer is not under support, NetApp will still receive the asup messages. We just won't open or act on cases automatically if there is no support in place. The messages are still useful in many ways, including if you ever decide to reactivate support, we have history we can use to help you. Also, if you want to upgrade (add-on or head swap), your NetApp SE can give you advice based on the asup info.

Share and enjoy!

Peter

-----Original Message----- From: Bender, Marilee [mailto:Marilee.Bender@delta.com] Sent: Wednesday, February 28, 2007 9:26 AM To: toasters@mathworks.com Subject: FW: autosupport stops functioning

We had this issue too. I agree with the post below that it could be message size. However, if it's just past asups that were too large because of the messages file (or one of the other attachments), you can set the autosupport.content size to minimal to delete all the queued asups, then "doit" to generate one without the attachments to see if you receive it, then put the content back to complete. It cleared the issue on one of our NearStores....the other one appears to have a "corrupt" character in the data chunk as viewed from the smtp server logs.

-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Sphar, Mike Sent: Tuesday, February 27, 2007 2:19 PM To: toasters@mathworks.com Subject: RE: autosupport stops functioning

I don't think this is the same problem as the one originally posted, but we once had a similar problem here where autosupport messages stopped being received by netapp because our mail gateway was rejecting all messages larger than a certain size. We didn't even know they were bouncing (we weren't getting the bounces) until one of the mail admins finally said something about it.

-- Michael W. Sphar - IS&T - Lead Systems Administrator SMBU Engineering Support Services, BMC Software

-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Stephen C. Losen Sent: Tuesday, February 27, 2007 6:55 AM To: Leeds, Daniel Cc: toasters@mathworks.com Subject: Re: autosupport stops functioning

anyone else have this happen?

suddenly one of our filers stops generating autosupport messages.

both autosupport.enable and autosupport.support.enable are on. if i generate a test email with the autosupport.doit option nothing happens. not even a failed message, the console just sits there as if i never generated one.

needless to say neither netapp or our email server gets anything from

this filer and nothing hits the console about generating any autosupport emails.

One of our filers stopped sending weekly autosupports because the /etc/messages file was huge (170MB). It gets sent to netapp as part of the autosupport. I got an automatic email from Netapp support telling me that they hadn't received an autosupport for two weeks. Buried in my huge /etc/messages file was an error indicating that autosupport had failed, but no reason why.

This particular filer holds our home directories and gets a lot of CIFS logins, which we want to log. We have enabled CIFS login tracing, which is very verbose.

I used /etc/syslog.conf to divert the CIFS auth messages to another file:

*.warning;auth.none /dev/console *.info;auth.none /etc/messages auth.info /etc/cifs_auth_log

I rotate the cifs_auth_log with a cron job because I think ONTAP will only rotate /etc/messages.

Now /etc/messages only grows to about 200K and autosupport is working again.

Steve Losen scl@virginia.edu phone: 434-924-0640

University of Virginia ITC Unix Support