Search results

summon-chefapi-0.1.1-0.2.git88fdef1.lbn25.x86_64

For many, Chef encrypted data bags are difficult to work with. This Summon provider allows you to use Summon + secrets.yml to improve your development workflow with encrypted data bags. Example Create an encrypted data bag with a PostgreSQL password. $ knife data bag create passwords postgres --secret-file encrypted_data_bag_secret { "id": "postgres", "value": "mysecretpassword" } Install Summon and this provider. Create a secrets.yml file. POSTGRES_PASSWORD: !var passwords/postgres/value Now you can inject the password into any process as an environment variable. Instead of dealing with the Data Bag API in your Chef recipe, you can just use ENV['POSTGRES_PASSWORD']. $ summon chef-client --once Once chef-client finishes, the password is gone, not left on your system. Configure Configuration of this provider is through environment variables: CHEF_NODE_NAME: The name of the node. (node_name in knife.rb) CHEF_CLIENT_KEY_PATH: The location of the file that contains the client key. (client_key in knife.rb) CHEF_SERVER_URL: The URL for the Chef server. (chef_server_url in knife.rb) CHEF_DECRYPTION_KEY_PATH: The location of the file that contains the decryption key. CHEF_SKIP_SSL: Skip SSL verification (for self-signed certs). Set to "1" to activate.

summon-conjur-0.6.0-0.1.gitf48c46b.lbn25.x86_64

CyberArk Conjur provider for Summon

summon-keyring-0.2.1-2.lbn25.noarch

Cross-platform provider for Summon that talks to keyrings. Wraps the Python keyring library to allow summon to fetch credentials from: OSX Keychain Linux Secret Service Windows Credential Vault gnome-keyring kwallet This provider requires that you have Python and pip installed. By default, this provider fetches secrets from the service "summon". Change this by setting the SUMMON_KEYRING_SERVICE environment variable.

summon-s3-0.2.0-0.2.git42b6d99.lbn25.x86_64

AWS S3 provider for Summon. Provides access to secrets stored in Amazon S3.

summon-vault4summon-0.4-0.1.gitcd31ff2.lbn25.x86_64

Providers for Summon are easy to write. Given the identifier of a secret, they either return its value or an error. There is the contract: They take one and only one argument, the identifier of a secret (a string). The argument can also be a flag with value -v or --version. The provider must return his version on stdout. If retrieval is successful, they return the value on stdout with exit code 0. If an error occurs, they return an error message on stderr with a non-0 exit code. The default path for providers is /usr/local/lib/summon/. If one provider is in that path, summon will use it. If multiple providers are in the path, you can specify which one to use with the --provider flag, or the environment variable SUMMON_PROVIDER. If your providers are placed outside the default path, give summon the full path to them. Variable IDs are used as identifiers for fetching Secrets. These are made up of a secret name (required) and secret key path (optional). The Vault CLI to retrieve a secret is vault kv get -field=mysecretkeypath secret/name This provider are 2 implemented formats for Variable ID: secret/name#mysecretkeypath as used by AWS Secrets Manager provider secret/name/mysecretkeypath as used by Keepass kdbx database file provider So the two commands below return the same value summon --provider vault4summon --yaml 'hello: !var secret/name#mysecretkeypath' printenv hello summon --provider vault4summon --yaml 'hello: !var secret/name/mysecretkeypath' printenv hello

sumo-livetail-2.0-0.1.lbn25.x86_64

The Live Tail Command Line Interface (CLI) is a standalone application that allows you to start and use a Live Tail session from the command line, similar to tail -f The output is directed to stdout - so you can pipe the output to commands (grep, awk etc)

sumo-shell-0.5.0-0.1.git03f0a8d.lbn25.x86_64

Sumoshell is collection of utilities to improve analyzing log files written in Go. grep can't tell that some log lines span multiple individual lines. Parsing out fields is cumbersome. Aggregating is basically impossible, and there is no good way to view the results. In Sumoshell, each individual command acts as a phase in a pipeline to get the answer you want. Sumoshell brings a lot of the functionality of Sumo Logic to the command line. Commands should start with sumo search [filter] which will transform logs into the json format sumoshell uses. Commands should end with render or graph which render the output to the terminal. Each operator is a stand-alone binary allowing them to be easily composed. Usage Like SumoLogic, sumoshell enables you pass log data through a series of transformations to get your final result. Pipelines start with a source (tail, cat, etc.) followed by the sumo operator. An example pipeline might be: tail -f logfile | sumo search "ERROR" | sumo parse "thread=*]" | sumo count thread | render This would produce a count of log messages matching ERROR by thead. In the basic renderer, the output would look like: _Id _count thread 0 4 C 1 4 A 2 1 B The sumo search operator sumo search takes an optional filter parameter to allow for basic searching. The sumo operator performs 3 steps: Break a text file into logical log messages. This merges things like stack traces into a single message for easy searching. Allow basic searching. Transforms the log message into the sumoshell internal json format. The sumo json operator For JSON logging, the sumo json operator will automatically parse JSON from your logs and extract key value pairs. Displaying results After using the sumo operator, the output will be in JSON. To re-render the output in a human-readable form, | the results of your query into one of the three render operators. render: Capable of rendering aggregate and non-aggregate data. Add nowraw to drop the raw data when an aggregate isn't present. Aggregates are updated in place using terminal escape sequences, with a limit of 20 shown. Add all to remove the limit. Aggregates will be rendered when the stream ends (ctrl+c) graph: Curses based renderer for rendering tabular data as a bar chart. Parsing Data sumoshell supports a basic parse operator similar to the parse operator in SumoLogic. Queries take the form: ... | sumo parse "[pattern=*] pattern2:'*' morePatterns=(*)" as pattern, pattern2, more | ... Filtering Data sumoshell supports a filter operator similar to the where operator in SumoLogic. Queries take the form: ... | sumo parse "[host=*]" as host | sumo filter host = server1 This will drop any log lines that don't have server1 as the host. Aggregating Data sumoshell currently supports 3 aggregate operators: count Example queries: ... | sumo count # number of rows ... | sumo count key # number of rows per key ... | sumo count key value # number of rows per the cartesian product of (key, value) sum Example queries: ... | sumo sum k # sum of all k's ... | sumo sum v by k # sum of all v's by k average Example queries: ... | sumo average k # average of all k's ... | sumo average v by k # average of all v's by k

SuperLU-4.3-12.lbn19.x86_64

SuperLU contains a set of subroutines to solve a sparse linear system A*X=B. It uses Gaussian elimination with partial pivoting (GEPP). The columns of A may be preordered before factorization; the preordering for sparsity is completely separate from the factorization.

SuperLU-5.3.0-1.lbn25.x86_64

SuperLU contains a set of subroutines to solve a sparse linear system A*X=B. It uses Gaussian elimination with partial pivoting (GEPP). The columns of A may be preordered before factorization; the preordering for sparsity is completely separate from the factorization.

SuperLU-6.0.0-1.lbn36.x86_64

SuperLU contains a set of subroutines to solve a sparse linear system A*X=B. It uses Gaussian elimination with partial pivoting (GEPP). The columns of A may be preordered before factorization; the preordering for sparsity is completely separate from the factorization.