What I learned using Sensu and sudo

I’ve been working on project that would have a Sensu plugin check a directory, every 60 seconds, to see if any symlinks existed.  If there were none, the Sensu plugin was configured to generate a critical alert.  If any symlink was found (broken or not) then no alert was generated.

But I had some difficulty getting the plugin to work properly.  Even though symlinks would exited in the directory the plugin was configured to look at, Sensu would always throw a critical alert.  I spent some time troubleshooting the problem and learned quite a few things:

  • Sensu uses its own build of Ruby, located in /opt/sensu/embedded/bin/ruby.  When I first started troubleshooting, I wasn’t aware of this and assumed Sensu was using the version of Ruby that was already installed on the server.  The version of Ruby between what the server was using and what was Sensu was packaged with were different, so I made sure to use the /opt/sensu/embedded/bin/ruby path during the troubleshooting process.
  • My Sensu plugin script made use of Bash’s ‘find’ command to look for symlinks.  Due to how the permissions were set up for the directory I wanted the plugin to look at, Sensu would experience permission problems when the plugin was executed.  As Sensu runs the plugins under its own user (sensu), I found that the ‘find’ command would not work.  I was able to get around this by specifying the Ruby plugin script in a /etc/sudoers.d/sensu file and placing the following data in it (this is not a complete version of the file – it is only the data needed to ensure the plugin worked properly):

    Defaults:sensu !requiretty
    sensu   ALL = NOPASSWD: /path/to/sensu/plugins/my_plugin.rb
    sensu   ALL = NOPASSWD: /bin/find

    *You might be able to add these to /etc/sudoers for the sensu user but I haven’t personally tested that.

After finding the above, making the necessary changes and testing those changes, my plugin script began to work!