Giter Club home page Giter Club logo

steampipe-plugin-exec's People

Contributors

cbruno10 avatar dependabot[bot] avatar e-gineer avatar luisffc avatar madhushreeray30 avatar misraved avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Forkers

gedw99

steampipe-plugin-exec's Issues

query.docker_socket_not_mounted_inside_containers fails on linux?

query.docker_socket_not_mounted_inside_containers, used in Docker complance, runs the command shown here.

On my linux host I can do this in beta.4 with the general-improvements branch of the exec plugin.

docker ps --quiet --all | xargs docker inspect --format '{{ .Id }}: Volumes={{ .Mounts }}' | grep docker.sock

but not this:

> select * from exec_command where command = 'docker ps --quiet --all | xargs docker inspect --format ''{{ .Id }}: Volumes={{ .Mounts }}'' | grep docker.sock'
+---------------+-------------------------------------------------------+-----------+------------------------------------------------------->
| stdout_output | stderr_output                                         | exit_code | command                                               >
+---------------+-------------------------------------------------------+-----------+------------------------------------------------------->
|               |                                                       | 1         | docker ps --quiet --all | xargs docker inspect --forma>
|               | "docker inspect" requires at least 1 argument.        | 1         | docker ps --quiet --all | xargs docker inspect --forma>
|               | See 'docker inspect --help'.                          |           |                                                       >
|               |                                                       |           |                                                       >
|               | Usage:  docker inspect [OPTIONS] NAME|ID [NAME|ID...] |           |                                                       >
|               |                                                       |           |                                                       >
|               | Return low-level information on Docker objects        |           |                                                       >
|               |                                                       |           |                                                       >
+---------------+-------------------------------------------------------+-----------+-----------------------------------------------------

Remote and local connections return different results for `exec_command` table

Describe the bug
When running this query on an Amazon Linux 2023 machine:

select
  *
from
  exec_command
where
  command = 'sudo auditctl -l | grep docker.service';

We get different results based on how the connection is configured (using remote vs. SSHing and using local):

SSHed in and using local connection:

+--------+-----------+---------+------+
| output | exit_code | command | _ctx |
+--------+-----------+---------+------+
+--------+-----------+---------+------+

Using remote connection:

+--------+-----------+----------------------------------------+----------------------------------+
| output | exit_code | command                                | _ctx                             |
+--------+-----------+----------------------------------------+----------------------------------+
|        | 1         | sudo auditctl -l | grep docker.service | {"connection_name":"exec_local"} |
+--------+-----------+----------------------------------------+----------------------------------+

Not sure if this issue also exists for exec_command_line too

Steampipe version (steampipe -v)
Example: v0.3.0

Plugin version (steampipe plugin list)
Example: v0.5.0

To reproduce
Steps to reproduce the behavior (please include relevant code and/or commands).

Expected behavior
A clear and concise description of what you expected to happen.

Additional context
Add any other context about the problem here.

remote-linux-connection-through-ssh fail and defaulted to connect as root instead of ec2-user

Describe the bug
A clear and concise description of what the bug is.

https://hub.steampipe.io/plugins/turbot/exec#remote-linux-connection-through-ssh

This is my config setting in .spc

connection "exec_remote_linux" {
  plugin = "exec"
  host = "ec2-13-233-111-222.ap-south-1.compute.amazonaws.com"
  user = "ec2-user"
  private_key = "/Users/xyz/rvvv/priv-key/docker-cis.pem"
}

Even though I provide the user as ec2-user, every time it tries to connect as root

> select output from exec_remote_linux.exec_command where command = 'ls -al'
Error: timeout - last error: SSH authentication failed ([email protected]:22): ssh: handshake failed: ssh: unable to authenticate, attempted methods [none], no supported methods remain (SQLSTATE HV000)

Steampipe version (steampipe -v)
Example: v0.3.0

Plugin version (steampipe plugin list)
Example: v0.5.0

To reproduce
Steps to reproduce the behavior (please include relevant code and/or commands).

Expected behavior
A clear and concise description of what you expected to happen.

Additional context
Add any other context about the problem here.

Using exec_command crashes steampipe in some cases

Describe the bug
I am trying to use the exec_command plugin to run a dig +short against load balancer domain names to build a list of IP addresses in Postgres. When I try this query, it crashes. I'm not sure if it's the plugin crashing, or steampipe itself, but it doesn't crash with other plugins, hence starting here.

Steampipe version (steampipe -v)
v0.20.11

Plugin version (steampipe plugin list)
v0.0.3

To reproduce
Run this query:

select
    lb.dns_name,
    (select output from exec_command where command = 'dig +short ' || lb.dns_name) as ip_addresses
from
   aws_ec2_classic_load_balancer as lb

I understand this query may not be perfect, but I can't iterate on it as it crashes.

Expected behavior
I expect the query to return the load balancer DNS names along with the output from the dig command.

Additional context
I've attached the relevant log with the error.
database-2023-09-11.log

Update docs with config arg information and which ones can be used in local/remote connection types

Is your feature request related to a problem? Please describe.
Some config args can be only be used in local or remote connection types, but it's difficult to tell which ones.

Describe the solution you'd like
Update the index doc with detailed config arg information.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Should the `exec_command` table for remote connections always return exit codes 0 or 1?

Describe the bug
In https://github.com/turbot/steampipe-plugin-exec/blob/main/exec/utils.go#L116-L119, we only return exit codes 0 or 1. This may be because we aren't able to get the exact error code, but if that's the case, we should decide which exit codes to return and document it.

Steampipe version (steampipe -v)
Example: v0.3.0

Plugin version (steampipe plugin list)
Example: v0.5.0

To reproduce
Steps to reproduce the behavior (please include relevant code and/or commands).

Expected behavior
A clear and concise description of what you expected to happen.

Additional context
Add any other context about the problem here.

Update `exec_command` and `exec_command_line` tables to handle stdout and stderr better

Is your feature request related to a problem? Please describe.
When querying these tables, I'd like to see stdout and stderr and be able to distinguish which outputs belong to which.

In the exec_command_line table, if we don't already, we can show both stdout and stderr lines in order. A new column may be helpful as well that indicates if it's stdout or stderr.

For exec_command, instead of just output (or in addition to), maybe two new columns stdout_output and stderr_output could provide specific information.

In both tables, if we're unable to distinguish stdout vs. stderr, we should return all of stdout and stderr.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.