merged navid-dev -r r350:r364 into trunk/rhel-5-startr1.7-8

git-svn-id: svn+ssh://svn.fedorahosted.org/svn/sos/trunk@368 ef72aa8b-4018-0410-8976-d6e080ef94d8

1 files changed, 54 insertions, 0 deletions

diff --git a/src/README.rh-upload-core b/src/README.rh-upload-core
new file mode 100644
index 00000000..c03f5d56
--- /dev/null
+++ b/src/README.rh-upload-core
@@ -0,0 +1,54 @@
+
+rh-upload-core
+
+This is a script provided with the SOS RPM which provides some automation for RHEL kernel vmcore file
+handling.  The script is capable of compressing, encrypting, checksumming, splitting and uploading a
+vmcore file by passing a few options and answering two questions.
+
+The script requires that the system (it is run on) has lftp, openssl, and gzip installed otherwise it
+will die.
+
+#### Recommendations ####
+  
+Red Hat absolutely recommends that you perform an md5checksum and provide the result file to your
+technician.  This only takes a few extra minutes and can save a lot of headaches if the file somehow
+is corrupted during transfer.
+
+It is not recommended to split the core file unless you are on an unreliable or low throughput
+connection.  Lftp will automatically resume uploads if there are connection interruptions but in
+some cases splitting the core file into smaller hunks may be desirable.
+
+Because your core could potentially contain data sensitive to your company it is recommended that
+core file encryption is at least considered.  While it's not very likely that someone could sniff
+that sensitive information while in transit it is possible.  Even with very large core files it takes
+less time to encrypt a compressed core file than it does to actually compress it the core file.  
+The 10 or so extra minutes it takes may be worth it.
+
+It's likely that you will be running the script remotely so it is recommended that you launch a
+screen session _before_ kicking off this script.  That way if your connection is dropped for some
+reason the script will continue until it's ready to prompt for destination input.
+
+#### Questions ####
+
+A couple of comments regarding choices made in the design of the script.
+
+Why use gzip instead of bzip2?
+While bzip2 /does/ compress tighter than gzip it is significantly slower on large files like
+vmcore files.  When compressing a core file speed is more of the essence rather than overall 
+compression ratio.
+
+Why not have a switch to provide the ticket number and/or upload destination?
+Good question.  While there isn't really a technical reason it seemed more logical to prompt
+for this information at the beginning and end of the script run.
+
+Do I have to use this script to upload kernel vmcore files?
+No you don't have to use it; however, we would prefer you did. It standardizes the core file
+naming convention on the dropbox for one thing.  Secondly it allows you to run this script
+and then go work on something else while all of the file operations run; however, if you wish to
+stare blankly at a screen waiting for compression to complete so you can upload that's entirely
+your perogative. ;-)
+
+I have a suggestion for this script who do I give it to?
+Open a ticket with Red Hat support with your request. It will certainly be considered.  That said,
+this was written in a shell script with the idea being that anyone could alter it in any way
+they see fit.