How to provide files to Red Hat Support (vmcore, rhev logcollector, sosreports, heap dumps, log files, etc.)

Solution Verified - Updated -

Environment

  • Files that needs to be sent to Red Hat Support
  • Red Hat Secure FTP - sftp.access.redhat.com
  • Note: Do not send files via email attachment to a support case:
    • While the text body of an email reply to a case is captured as a comment within the case, any and all email attachments are stripped and discarded. Instead of email attachments, use one of the methods outlined within the 'Resolutions' section below.

Issue

  • How to provide files to Red Hat Support

    • Production server crashed, how to attach document, screenshot, crashdump(kdump)?
    • After hard reboot, collected data like tcpdump, strace, top, ps, vmstat, iostat and reports for analysis. Whom can I send ?
    • System hang and would like to know the reason behind it, where can I provide data for analysis ?
    • How can I attach a file to a Red Hat support case?
    • Need to upload a file to the support team.
    • Need to attach a file to a Red Hat support case.
  • How to provide large files to Red Hat Support (vmcore, rhev logcollector, large sosreports, heap dumps, large log files, etc.)

    • Customer portal uploader supports uploading of attachments of 250GB each.
    • The redhat-support-tool supports uploading files 1GB or less only, how to upload large files to Red Hat Technical Support?
  • How to upload files to Red Hat's Secure FTP (sftp.access.redhat.com)?

Resolution

Contents

  1. Upload files via Customer Portal
  2. Red Hat Support Tool
  3. Secure FTP
  4. Splitting files into parts for upload
  5. Computing file digests

Upload files via Customer Portal

You can now upload files up to 250GB in size directly to the Customer Portal. There is no longer any need to use a separate mechanism for uploading large files. Refer to Attaching files via Portal UI for attaching files via the Red Hat Customer Portal.

There is a known issue with the IE browser timing out with uploads that take longer than 15 minutes. This should only happen with extremely large uploads. If you need to provide very large files, please use Chrome/Firefox or FTP until a fix is available.

Red Hat Support Tool

Note: currently there is a size restriction of 1GB for each single file uploaded. That size restriction is being addressed via RHBZ Bug 1653573.

  • To Case: To upload files directly from your system, you can also use Red Hat Support Tool (redhat-support-tool). It gives you flexibility and also scripting capabilities. The simplest way to upload files, e.g.: sosreport, is this:

    $ redhat-support-tool addattachment -c CASE_NUMBER /path/to/sosreport
    

Note: See Red Hat Access: Red Hat Support Tool for more complete information on redhat-support-tool, including installation instructions.

  • To Dropbox FTP:

    • This will upload your file directly to the Customer Portal. If you want to upload to the FTP site, use the "-f" option:

      $ redhat-support-tool addattachment -c CASE_NUMBER -f /path/to/sosreport
      
    • Split Files and upload to FTP: If you have a very big vmcore file and you don't have access to the Dropbox FTP site, you can split your file with the "-s" option of newer versions of the support tool to upload the file to the Customer Portal:

      $ redhat-support-tool addattachment -c CASE_NUMBER -s 1024 -f /path/to/vmcore
      
    • The facility has also been tested using the multi-platform GUI FTP client from http://filezilla-project.org/.

NOTE Dropbox FTP has been deprecated, and Red Hat Support Tool will be updated soon to point to the new Secure FTP . We request you to use Secure FTP directly for uploading files until we ship a new update to Red Hat Support Tool.

Secure FTP

Red Hat’s new Secure FTP platform has been made available: sftp.access.redhat.com

The new platform replaces our legacy dropbox.redhat.com file sharing platform and aims to provide a sustainable, cross-platform, command-line accessible endpoint for customers to upload files to Red Hat. The new Secure FTP can be used to attach files to support cases, as well as simply share files with Red Hat outside of support cases. You can learn more about how to use the new Secure FTP platform in this user guide.

Splitting files into parts for upload

While some customers have no problem uploading 50GB vmcore files to Red Hat, others have problems with anything over 1-2GB in size. Sometimes large uploads do not complete reliably either due to file size or network congestion or other issues resulting in failure to complete the upload successfully. Failed uploads often must be resumed from the beginning of the file.

If you have had trouble uploading a file in the past to either the portal or via redhat-support-tool (or FTP) due to size, network stability, or other issues, then the file can be split into parts and each smaller part uploaded. The current recommendation when splitting a large file, such as a vmcore, into parts is to break the file into 1GB chunks as a starting point. If that still fails, fallback to 512m size and try again.

  • The splitcommand can be used to break a large file into smaller chunks for upload to dropbox.redhat.com or to the support case within the Red Hat Customer Portal. If a single chunk upload fails, only the upload of that chunk needs to be retried.

    • For example, the following splits a large 8.5GiB vmcore file into 9 smaller files for upload. The -b 1024m command line option limits the split file size to a maximum of 1024MB (1GiB) each.

      # ls -ltrh largefile.tar.xz
      -rw-rw-r--. 1 root    root    8.5G Feb 20 13:54 largefile.tar.xz
      # split -b 1024m -a 2 -d largefile.tar.xz largefile.tar.xz.part
      # ls -ltrh largefile.tar.xz.*
      -rw-rw-r--. 1 root root 1.0G Feb 21 10:01 largefile.tar.xz.part00
      -rw-rw-r--. 1 root root 1.0G Feb 21 10:01 largefile.tar.xz.part01
      -rw-rw-r--. 1 root root 1.0G Feb 21 10:01 largefile.tar.xz.part02
      -rw-rw-r--. 1 root root 1.0G Feb 21 10:01 largefile.tar.xz.part03
      -rw-rw-r--. 1 root root 1.0G Feb 21 10:01 largefile.tar.xz.part04
      -rw-rw-r--. 1 root root 1.0G Feb 21 10:01 largefile.tar.xz.part05
      -rw-rw-r--. 1 root root 1.0G Feb 21 10:01 largefile.tar.xz.part06
      -rw-rw-r--. 1 root root 1.0G Feb 21 10:02 largefile.tar.xz.part07
      -rw-rw-r--. 1 root root 508M Feb 21 10:02 largefile.tar.xz.part08
      
    • The parts can be reassembled using cat command.

      # ls -1c -v largefile.tar.xz.part* | xargs -I {} cat {} >> largefile.tar.xz
      
    • See man split for further information and command options.

Computing file digests

  • To compute the MD5 message digest of the files you uploaded, run

     $ md5sum [filename]
    
  • Or, alternatively, to compute the SHA1 message digest of the files you uploaded, run

     $ sha1sum [filename]
    

Footnotes

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

35 Comments

when i try to register my linux server (It is a physical box) to the redhat network it gives fatel error

Problem registering system

error message

Insufficient software channel

that means you have no entitlements of that version of os

sosreport-Amiller.00644930-20120518105719-5c00.tar.xz

Sorry please ignore this comment, attached to incorrect location.

Is there a way to use WinSCP? When I set it up, it lets me in Okay, but you are in the root, not incoming. I can't seem to change to the incoming directory, and I can't figure out a way to specify going to "incoming" directly.

Can I have the ftp server available http which can be accessible office network (proxy enabled networks where we dont have direct public internet access)

server xpvlap0143 was in unresponsive state, no crash generated while manual power off and on. Please check and analyse for the root cause. uploading sas report to the case

[root@Hardedn5 rhn]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.5 (Tikanga)

the full versíon is:
[root@descreta ~]# uname -a
Linux descreta 2.6.18-164.el5 #1 SMP Thu Sep 3 04:15:13 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
[root@descreta ~]# cat /proc/version
Linux version 2.6.18-164.el5 (mockbuild@ca-build10.us.oracle.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Thu Sep 3 04:15:13 EDT 2009
[root@descreta ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.4 (Tikanga)

FileZila gets 550 permission denied after login.

A Permissioned Denied error on login is normal, both in / or in /incoming. As stated it is a "blind" anonymous ftp server, which means you have no rights to list the content in the directories. However uploading files in /incoming should work fine.

I get 550 permission denied too using FireFTP. do you have a solution for this?

Jagadish, if you're having difficulty uploading files to the FTP server, you should mention this in your support case emails.

A Permissioned Denied error on login is normal, both in / or in /incoming. As stated it is a "blind" anonymous ftp server, which means you have no rights to list the content in the directories. However uploading files in /incoming should work fine.

I cant upload files if i connected clients servers through VPN becaise of firefile block

So copied it to my laptop and tried to upload but it giving below eeror. Please let us know if anu other site for upload files.

Govind

User (origin-dropbox.redhat.com:(none)): anonymous
331 Please specify the password.
Password:
230 Login successful.
ftp> cd incoming
250 Directory successfully changed.
ftp> bin
200 Switching to Binary mode.
ftp> ha
Hash mark printing On ftp: (2048 bytes/hash mark) .
ftp> mput vm*
mput vmcore.24102013_22_54.gz? y
200 PORT command successful. Consider using PASV.
425 Failed to establish connection.
ftp> literal pasv
227 Entering Passive Mode (209,132,183,100,22,67)
ftp> put vm*
200 PORT command successful. Consider using PASV.
425 Failed to establish connection.
ftp>

Since downloading files from dropbox.redhat.com is forbidden, how can get the file, that someone uploaded there when I know the filename?

Thanks

Various customers (banking, telco, ...) do not allow uploading via FTP or SFTP. Servers (and infrastructure) simply don't have Internet access and desktops are behind proxies that block most protocols other than HTTP(S).

So uploading to the customer portal is the only viable alternative in this case. Fortunately, despite what is claimed, one can upload files larger than 1GB. We have send vmcore files up to almost 2GB via the customer portal without a problem. But it is likely slower than FTP or SFTP.

Sadly, no longer the case. Since the latest update of the portal, a hard limit of 250Mb is set on uploads. Anything more than that and the "Upload" button is greyed out.

Nenhum comentário

dump será anexado

I have upload this file case01309377.vmcore.gz tp dropbox/incoming folder

lftp -v -c 'open -e "set ftps:initial-prot "

set ftp:ssl-force true;
set ftp:ssl-protect-data true;
set ssl:verify-certificate true;
open anonymous:ftp@dropbox.redhat.com ;
cd incoming;
put vmcore.tar.gz
'
cd: Login failed: ftp:ssl-force is set and server does not support or allow SSL
put: Access failed: 553 Could not create file. (vmcore.tar.gz)

I just verified the full cycle of storing a file with the command stated above in the document, upload and verification of the uploaded content: works as expected here.
I suspect you have interfering networkequipment in the way. For an indepth analysis (running the client with debug options, sniffing packets etc.) you could open a case with the Red Hat support.

You should also use a better filename, i.e. include your credentials and a case number.

We are using curl to automate the upload, but we still have to manually update the case notes to indicate what files were dropped in the dropbox. Is there a way to automate updating the case notes with the file names to eliminate that manual step?

The support-tool might help here: https://access.redhat.com/articles/445443

The example commands given should contain CASE_NUMBER not CASE_NUMER!

Thanks for catching that, corrected it.

The curl method posted at the bottom is very, very helpful to those of us operating behind a BlueCoat proxy (those don't seem to handle FTP all that well). Huge thanks for the KB update!

In a rescue mode can we follow this procedure once sosreport is generated from /tm/sosreport-XYZ, to send the report to RHT support?

$ redhat-support-tool addattachment -c CASE_NUMBER -s -f /path/to/sosreport

So the ftp says this is obsolete but tells me to come here for details -- maybe this article could be updated:

220-+---------------------------------------------------------------+
220-|        Welcome to Red Hat Global Support Services FTP!        |
220-|                                                               |
220-|      Now you can upload files up to 250GB in size directly    |
220-|   to the Customer Portal. With this new capability, you can   |
220-|     manage everything in one place. You can start taking      |
220-|        advantage of this improved functionality now.          |
220-|                                                               |
220-|    Access to dropbox.redhat.com and dropbox-ssl.redhat.com    |
220-|   will no longer be available on March 1, 2019. Please visit  |
220-|     https://access.redhat.com/solutions/2112 for details.     |
220-+---------------------------------------------------------------+

https://github.com/redhataccess/redhat-support-lib-python/blob/bf2d9a5ee92c0d7635dd3f305b334242c72abebf/src/redhat_support_lib/utils/confighelper.py#L65 (not sure if that's the right upstream code though, but it is still present in latest rhel 7 package)

should reflect the new limit of 250GB and in general dropbox.redhat.com support should be dropped according to welcome message of that ftp

Hello @Klaas,

I will update the KCS to reflect the appropriate changes in upload capabilities.

Regarding the update to the redhat-support-tool, https://bugzilla.redhat.com/show_bug.cgi?id=1679259 has been created.

Thank you!

Hello,

My RHE self-signed SSL certificate has been expired. How can I renew it without installing a new one?

Thanks

I have been using this new way of downloading sosreports and it is taking too much time to download from the device and upload it to the page.

strace -fttTvyys 4096 -o sosreport.strace sosreport --batch -vvv --threads=1 |& tee sos.log

an anyone suplly a better way to gather the reports. I have done it in the past sosreport -n networking but now i am being asked to created it with the networking during business hours. please advised if there is a better way because taking all day to upload items is getting ridiculous.