Open Stack

IMHO, removal of sensitive information is done by services when they (do
not) log relative data to logs, such as tokens. Current set of commands
only collects specific config folders and files and logs, but if an admin
decided to store keys in one of these folders - the tool will collect them
too. It's up to the end user to only provide data collected via this tool
to a trusted party. Same goes for our current snapshot mechanism.
As of sanitization for hostnames, IPs, etc - this will make the diagnostic
snapshot pretty useless because it's important for navigation within logs
and configs, for RCA compilation, etc.

I cannot say much about running under a non-root account, I guess that
would be pretty easy to implement, let's wait for Alexander's reply. I am
not sure it is useful though because a non-root user will not have
necessary access unless there is a passwordless non-interactive sudo config.

On Tue, Apr 19, 2016 at 1:39 PM, Dmitry Nikishov <dnikishov at mirantis.com>
wrote:

> Hello,
>
> I've got a couple of questions:
> - What about this tool using non-root accounts to connect to OpenStack
> nodes? Currently, it seems to assume that it always is going to use "root"
> for SSH.
> - Shouldn't it sanitize all sensitive information (user names, host names,
> passwords, tokens, keys etc)?
>
> Thanks.
>
> On Tue, Apr 19, 2016 at 4:52 AM, Aleksandr Dobdin <adobdin at mirantis.com>
> wrote:
>
>> Hello team,
>>
>> I want to discuss the tool <https://github.com/adobdin/timmy> that we
>> have created for MOS as a replacement/alternative of shotgun.
>>
>>
>>
>>    -
>>
>>    The tool is based on
>>    https://etherpad.openstack.org/p/openstack-diagnostics
>>    -
>>
>>    Should work fine on the following environments that were tested: 4.x,
>>    5.x, 6.x, 7.0, 8.0
>>    -
>>
>>    Operates non-destructively.
>>    -
>>
>>    Can be launched on any host within admin network, provided the fuel
>>    node IP is specified and access is possible to Fuel and other nodes via ssh
>>    from local system.
>>    -
>>
>>    Parallel launch, only on the nodes that are 'online'. Some filters
>>    for nodes are also available.
>>    -
>>
>>    Commands (from ./cmds directory) are separated according to roles
>>    (detected automatically) by the symlinks. Thus, the command list may depend
>>    on release, roles and OS. In addition, there can be some commands that run
>>    everywhere. There are also commands that are executed only on one node
>>    according to its role, using the first node of this type they
>>    encounter.
>>    -
>>
>>    Modular: possible to create a special package that contains only
>>    certain required commands.
>>    -
>>
>>    Collects log files from the nodes using filters
>>    -
>>
>>    Some archives are created - general.tar.bz2 and logs-*
>>    -
>>
>>    checks are implemented to prevent filesystem filling due to log
>>    collection, appropriate error shown.
>>    -
>>
>>    can be imported in other python scripts (ex.
>>    https://github.com/f3flight/timmy-customtest) and used as a transport
>>    and structure to access node parameters known to Fuel, run commands on
>>    nodes, collect outputs, etc. with ease.
>>
>> ​
>>
>> Sincerely yours,
>> Aleksandr Dobdin
>> Senior Operations Engineer
>> Mirantis
>> ​Inc.​
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Dmitry Nikishov,
> Deployment Engineer,
> Mirantis, Inc.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Yours sincerely,
Dmitry Sutyagin
OpenStack Escalations Engineer
Mirantis, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160419/5c4d8ea7/attachment.html>