> On Dec. 4, 2012, 7:29 p.m., Prasanna Santhanam wrote: > > I like the idea that this script can be provided as a convenience to > > collect various logs. One problem however is that the script assumes root > > access on the management server and executes a bunch of commands (ip > > routes, hostnames, top, df, dmesg) etc that someone might not be okay with. > > May be it should be made interactive and warn the user of the actions it > > will/has performed. When as a commercial support provider you have > > permission to access and troubleshoot a system it would be okay to run > > this. But IMO it could be provided by that company which is looking to > > provide support to the operator of the said cloud to simplify their process > > of support. So I'm slightly wary of accepting something like this unless > > someone else convinces me that this would absolutely be beneficial. Also > > admins operating large clouds might be using a syslog server to already do > > some (or more) of these actions for them. If the logs are moved away from > > where one expects them to be then this script fails. > > Radoslaw Smigielski wrote: > > So I'm slightly wary of accepting something like this unless someone > else convinces > > me that this would absolutely be beneficial. > Prasanna, let me try then. > > The main reasons why I created this tools: > 1. CloudStack is a project which targets cloud enthusiasts but also > "enterprises" and if you have a look on all the big products, vendors on the > marker they offer utilities which do exactly what cs-bugtool does. Collect > logs, basic system and configuration information. Examples: NetApp > autosupport, XenServer xs-bugtool, VMware vSphere Client does this, . . ., > and many others which I don't know. So IMHO CloudStack should also include > this type of utility. > 2. CloudStack becomes more and more complex, having this log bundle we > can share it with other trusted persons or some support representative and > this really can speed up analysis, avoid tens of questions, sending emails > and files back and forth. > 3. I fully understand your concern about sharing sensitive information > and to address this: > a.) I am going to implement some switches which let user decided what to > include in output archive > b.) It's clearly written in README but we can repeat this information > what exactly is collected > c.) We can add warning, the output archive can contain information which > you can consider as a sensitive please be aware of this and be careful with > who you sharing this(!!!) > d.) The main use case of this utility is to share output archive with > trusted people or some sort of support representative not to make public > users' configurations. We do not send any information automatically, we just > give a user a blob and user decides what to do with this. > > > script assumes root access on the management server and executes a > bunch of commands > This is a good point, I need to add logic which detect non-root execution > situation. > We this also should be in README. > > I hope above change your mind :) > > Radek. >
> The collated logs may contain private information, and if you are at all > worried about that, you should not use this tool, or you should explicitly > exclude those logs from the archive. Prasanna, this is fragment of README.xen-bugtool taken from xen.org project. We can add similar disclaimer in our README and in cs-bugtool output. Radek. - Radoslaw ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8248/#review14023 ----------------------------------------------------------- On Dec. 4, 2012, 6:49 p.m., Radoslaw Smigielski wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/8248/ > ----------------------------------------------------------- > > (Updated Dec. 4, 2012, 6:49 p.m.) > > > Review request for cloudstack, Prasanna Santhanam and Rohit Yadav. > > > Description > ------- > > The main purpose behind cs-bugtool is to make easier collecting > logs required for CloudStack/CloudPlatform troubleshooting > and it mainly comes from Support. cs-bugtool collects logs, system > information and cloud database dump, compress everything and creates > .zip archive file ready to share with others. > For those familiar with Xen/XenServer cs-bugtool name may sound similar > to xen-bugtool, this similarity is intentional. > > Current version of cs-bugtool collects: > - basic system and environment information > - CP/CS management service logs > - basic system logs > - cloud database > > Current version does not accept any arguments but this may > changed in next iterations of cs-bugtool. > > We DO NOT collect and do not want to collect any sensitive information. > If there is still any sensitive pice of information please let us know > and we will try to remove it or replace by meaningless data. > > > Diffs > ----- > > tools/support/README PRE-CREATION > tools/support/cs-bugtool PRE-CREATION > > Diff: https://reviews.apache.org/r/8248/diff/ > > > Testing > ------- > > I tested this on CS 3.0.4 and 3.0.5. > > > Thanks, > > Radoslaw Smigielski > >
