If you want to use this formula, please pay attention to the FORMULA file and/or git tag, which contains the currently released version. This formula is versioned according to Semantic Versioning.

See Formula Versioning Section for more details.

If you need (non-default) configuration, please refer to:

how to configure the formula with map.jinja
the pillar.example file
the Special notes section

Contributing to this repo

Commit messages

Commit message formatting is significant!!

Please see How to contribute for more details.

pre-commit

pre-commit is configured for this formula, which you may optionally use to ease the steps involved in submitting your changes. First install the pre-commit package manager using the appropriate method, then run bin/install-hooks and now pre-commit will run automatically on each git commit.

$ bin/install-hooks
pre-commit installed at .git/hooks/pre-commit
pre-commit installed at .git/hooks/commit-msg

Special notes

None.

`snmp`

Installs the snmp daemon, starts, and enables the associated snmp service.

`snmp.conf`

Configures the snmp daemon.

`snmp.trap`

Starts and enables the trap service.

`snmp.conftrap`

Configures the trap service.

`snmp.options`

Sets snmp runtime options.

Layered configuration

Since SNMP can be integrated with many services, it may be handy to split configuration between several files, each belonging to different packages and teams. For example, you may setup generic SNMP configuration in common pillar file, and it will include:

snmp:
  conf:
    settings:
      logconnects: false
      sysServices: 72

Whereas team, that wants to monitor GPFS with SNMP on the same cluster will add this pillar file to their package:

snmp:
  conf:
    settings:
      master: ['agentx']
      AgentXSocket: tcp:localhost:705
    rocommunities:
      - gpfs
    mibs:
      GPFS: salt://gpfs/files/GPFS-mib.txt

To utilize this ability of layered configuration, you can modify snmp/conf.jinja file in following manner:

# Generic configuration:
{% set conf = salt['pillar.get']('snmp:conf', {}) %}

# Imagine you have team_names list which consist of packages provided
# by set of independent teams inside your company:
{% for team in team_names %}
{% set conf = salt['pillar.get'](
    team + ":snmp",
    default=conf,
    merge=True)
%}
{% endfor %}

# Afterall there might configuration specific to current deployment in separate pillar file:
{% set conf = salt['pillar.get'](
    "user:snmp",
    default=conf,
    merge=True)
%}

Testing

Linux testing is done with kitchen-salt.

Requirements

Ruby
Docker

$ gem install bundler
$ bundle install
$ bin/kitchen test [platform]

Where [platform] is the platform name defined in kitchen.yml, e.g. debian-9-2019-2-py3.

`bin/kitchen converge`

Creates the docker instance and runs the TEMPLATE main state, ready for testing.

`bin/kitchen verify`

Runs the inspec tests on the actual instance.

`bin/kitchen destroy`

Removes the docker instance.

`bin/kitchen test`

Runs all of the stages above in one go: i.e. destroy + converge + verify + destroy.

`bin/kitchen login`

Gives you SSH access to the instance for manual testing.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].

Cheap and reliable Node.js hosting starts at $3/month, and $1/month static HTML hosting

saltstack-formulas / snmp-formula

Programming Languages

Labels

Projects that are alternatives of or similar to snmp-formula

snmp-formula

General notes