Request for comments on the new pynag CLI

[Palli]

In an informal interim version pynag-0.4.2. It gives the ability to list / create / update / delete objects directly from the command line

It would be very nice before we release next version if someone could download it, play with it. and give feedback on command-line syntax which currently is quite immature.

Here are some output examples to show capabilities:

### Run it without arguments to get help

$ pynag

Usage: pynag <sub-command> [arguments]

Examples:

 pynag list host_name service_description where object_type=service and host_name=examplehost.com

 pynag update service set check_period=24x7 where host_name=examplehost.com and object_type=host

Available subcommands:

  list          List host/services, etc.

  update        Update host/service etc.

  add           Create a new object definition

  copy          Copy a current object definition to a new one

  delete        Delete a specific object definition

  config-set    set a specific value for nagios.cfg

  config-append append a specific value to nagios.cfg

### List some objects:

$ pynag list host_name service_description where object_type=service and host_name=localhost

host_name                                service_description                     

--------------------------------------------------------------------------------

localhost                                Disk Space                              

localhost                                Current Users                           

localhost                                Total Processes                         

localhost                                Current Load                            

--------------------------------------------------------------------------------

### Rename a host and all its services

$ pynag update set  host_name=new_host_name where host_name=oldhostname

object_type                              shortname                                filename                                

--------------------------------------------------------------------------------

host                                     oldhostname                              /etc/nagios3/conf.d/oldhostname-host.cfg

service                                  oldhostname/HP EVA Systems               /etc/nagios3/conf.d/oldhostname-eva.cfg 

service                                  oldhostname/HP EVA Diskgroups            /etc/nagios3/conf.d/oldhostname-eva.cfg 

service                                  oldhostname/HP EVA Disks                 /etc/nagios3/conf.d/oldhostname-eva.cfg 

service                                  oldhostname/HP EVA Controllers           /etc/nagios3/conf.d/oldhostname-eva.cfg 

service                                  oldhostname/HP EVA Diskshelves           /etc/nagios3/conf.d/oldhostname-eva.cfg 

service                                  oldhostname/None                         /etc/nagios3/conf.d/oldhostname-host.cfg

service                                  oldhostname/Ping                         /etc/nagios3/conf.d/oldhostname-host.cfg

--------------------------------------------------------------------------------

Update these 8 objects ? (y/N) y

/etc/nagios3/conf.d/oldhostname-host.cfg (new_host_name): changed host_name to new_host_name

/etc/nagios3/conf.d/oldhostname-eva.cfg (new_host_name/HP EVA Systems): changed host_name to new_host_name

/etc/nagios3/conf.d/oldhostname-eva.cfg (new_host_name/HP EVA Diskgroups): changed host_name to new_host_name

/etc/nagios3/conf.d/oldhostname-eva.cfg (new_host_name/HP EVA Disks): changed host_name to new_host_name

/etc/nagios3/conf.d/oldhostname-eva.cfg (new_host_name/HP EVA Controllers): changed host_name to new_host_name

/etc/nagios3/conf.d/oldhostname-eva.cfg (new_host_name/HP EVA Diskshelves): changed host_name to new_host_name

/etc/nagios3/conf.d/oldhostname-host.cfg (new_host_name/None): changed host_name to new_host_name

/etc/nagios3/conf.d/oldhostname-host.cfg (new_host_name/Ping): changed host_name to new_host_name

Updated 8 objects

[J. Snyder]

I've enjoyed using this CLI in addition to scripting against the install modules. There are some nice features, like "filename" and "object_type" being searchable attributes. Even though this post is several versions old, I would like to suggest a some features.

1.

Please change the '--filename' option to be available for all sub-commands, not just config-set and config-append. I'm finding that I need to perform a post-install update to the Parsers/__init__.py for my custom nagios install to get the other sub-commands to work.

2.

For the "list" sub-command, please allow the specified <attribute> to be optional, and show all attributes if one is not specified. At the moment, it seems to accept the syntax of an omitted attribute, even though the syntax help text seems to indicate it is required. When no attribute is present, it only displays a sub-set of attributes.

3.

A definition in the help text of the valid values of the [WHERE <search>] may be useful

Feel free to direct me elsewhere if feature requests are inappropriate for this forum. I may able to contribute to the project, but am unfamiliar with the process.

[Tommi]

On Thursday, September 13, 2012 4:47:43 AM UTC, J. Snyder wrote:

I've enjoyed using this CLI in addition to scripting against the install modules. There are some nice features, like "filename" and "object_type" being searchable attributes. Even though this post is several versions old, I would like to suggest a some features.

1.

Please change the '--filename' option to be available for all sub-commands, not just config-set and config-append. I'm finding that I need to perform a post-install update to the Parsers/__init__.py for my custom nagios install to get the other sub-commands to work.

This is interesting, could you post what exactly you are doing? I find that --filename makes sense for updating keys in config files but other actions?

2.

For the "list" sub-command, please allow the specified <attribute> to be optional, and show all attributes if one is not specified. At the moment, it seems to accept the syntax of an omitted attribute, even though the syntax help text seems to indicate it is required. When no attribute is present, it only displays a sub-set of attributes.

I think there is an option in there, at least it was planned. Palli?

3.

A definition in the help text of the valid values of the [WHERE <search>] may be useful

This needs to be added and I have created a ticket, https://github.com/pynag/pynag/issues/12

Feel free to direct me elsewhere if feature requests are inappropriate for this forum. I may able to contribute to the project, but am unfamiliar with the process.

Feature request are good here or on the issue tracker on github.

Contributing via patches should be easy enough if you have a github account. Just go to https://github.com/pynag/pynag, there you can create a fork, post pull request (patch submittal) and many other options.

---
Tommi

 

[J. Snyder]

On Thursday, September 13, 2012 3:16:00 AM UTC-5, Tommi wrote:

On Thursday, September 13, 2012 4:47:43 AM UTC, J. Snyder wrote:

I've enjoyed using this CLI in addition to scripting against the install modules. There are some nice features, like "filename" and "object_type" being searchable attributes. Even though this post is several versions old, I would like to suggest a some features.

1.

Please change the '--filename' option to be available for all sub-commands, not just config-set and config-append. I'm finding that I need to perform a post-install update to the Parsers/__init__.py for my custom nagios install to get the other sub-commands to work.

This is interesting, could you post what exactly you are doing? I find that --filename makes sense for updating keys in config files but other actions?

Looking at "config-set" and "config-append", it appears that although they worked, I agree that the context would not make sense. I'm using Shinken, a Nagios fork. I used the default install paths, so my primary configuration file is:

/usr/local/shinken/etc/nagios.cfg

I had a choice of creating either creating a symlink to an existing default "guess" at the "nagios.cfg" file, or to edit the file: "pynag-0.4.5-1/pynag/Parsers/__init__.py". Otherwise I get the ParseError, "Could not find nagios.cfg" when running pynag. Here's my diff:

48c48,49

<         possible_files = ('/etc/nagios/nagios.cfg',

---

>         possible_files = ('/usr/local/shinken/nagios.cfg',

>                           '/etc/nagios/nagios.cfg',

2.

For the "list" sub-command, please allow the specified <attribute> to be optional, and show all attributes if one is not specified. At the moment, it seems to accept the syntax of an omitted attribute, even though the syntax help text seems to indicate it is required. When no attribute is present, it only displays a sub-set of attributes.

I think there is an option in there, at least it was planned. Palli?

) My use case:

pynag list where hostgroups=dev

# Yields attributes: object_name, shortname, filename

) However, I can run the following to get more fields:

pynag list host_name hostgroups alias address check_command max_check_attempts check_period check_interval contact_groups object_type filename where hostgroups=dev

# Yields all of the listed attributes

[J. Snyder]

Self correction inline:

On Thursday, September 13, 2012 10:07:53 PM UTC-5, J. Snyder wrote:

On Thursday, September 13, 2012 3:16:00 AM UTC-5, Tommi wrote:

On Thursday, September 13, 2012 4:47:43 AM UTC, J. Snyder wrote:

I've enjoyed using this CLI in addition to scripting against the install modules. There are some nice features, like "filename" and "object_type" being searchable attributes. Even though this post is several versions old, I would like to suggest a some features.

1.

Please change the '--filename' option to be available for all sub-commands, not just config-set and config-append. I'm finding that I need to perform a post-install update to the Parsers/__init__.py for my custom nagios install to get the other sub-commands to work.

This is interesting, could you post what exactly you are doing? I find that --filename makes sense for updating keys in config files but other actions?

Looking at "config-set" and "config-append", it appears that although they worked, I agree that the context would not make sense. I'm using Shinken, a Nagios fork. I used the default install paths, so my primary configuration file is:

/usr/local/shinken/etc/nagios.cfg

 

I had a choice of creating either creating a symlink to an existing default "guess" at the "nagios.cfg" file, or to edit the file: "pynag-0.4.5-1/pynag/Parsers/__init__.py". Otherwise I get the ParseError, "Could not find nagios.cfg" when running pynag. Here's my diff:

Pasting the correct diff: 

48c48,49

<         possible_files = ('/etc/nagios/nagios.cfg',

---

>         possible_files = ('/usr/local/shinken/etc/nagios.cfg',

>                           '/etc/nagios/nagios.cfg',

[Páll Sigurðsson]

I know it has been a long time, i just found this in my drafts folder. Sending anyway for the list.

Hi Snyder,

I like your ideas, and made some changes in git master yesterday. We are planning on releasing a new version in the next few days and these changes will be included. In the meantime you can try them out by pulling from github.com/pynag/pynag.git

* All sub-commands now take --cfg_file option (--filename was ambigious between subcommands so that will be deprecated in a later version)

* config-set and config-append have been combined into one "config" subcommand. 

------------------

$ pynag config --examples

config Examples:

  # /usr/local/bin/pynag config --set process_perfdata=1

  # /usr/local/bin/pynag config --append cfg_dir=/etc/nagios/conf.d

  # /usr/local/bin/pynag config --remove cfg_dir --old_value=/etc/nagios/conf.d

  # /usr/local/bin/pynag config --get object_cache_file

------------------

* The usage for pynag list currently looks like this:

$ pynag list --help | head -n 1

Usage:  pynag list [attribute1] [attribute2] [WHERE <...>] 

* Somewhere around version 0.4.4 WHERE syntax has been described in the man page. I updated the --help to point this out. Also every subcommand should now accept both --help and --examples for context specific help. I think this is a huge improvement.