
Security News
Follow-up and Clarification on Recent Malicious Ruby Gems Campaign
A clarification on our recent research investigating 60 malicious Ruby gems.
Monitors and controls running workflow robots off of priority queues and within a cluster.
In your Gemfile
, add:
gem 'robot-controller'
In your Rakefile
, add the following (if you don't want to include the environment unconditionally):
require 'robot-controller/tasks'
Create the following configuration files based on the examples in example/config
:
config/environments/robots_development.yml
Then to use the controller to boot the robots:
bundle exec controller boot
If you want to override the eye configuration but still use the controller (though NOT recommended), then add:
config/eye.rb
Usage: controller ( boot | quit )
controller ( start | status | stop | restart | log ) [worker]
controller verify [--verbose]
controller [--help]
Example:
controller boot # start eyed and jobs
controller status # check on status of jobs
controller verify # verify robots are running as configured
controller log robot01_01_dor_accessionWF_descriptive-metadata # view log for worker
controller stop # stop jobs
controller quit # stop eyed
Environment:
EYE_BASEDIR - where eye stores its state (default: run/eye)
EYE_LOGFILE - output log (default: log/eye.log)
ROBOT_ENVIRONMENT - (default: development)
v1.0.0
: Initial versionv1.0.1
: Add 'rake' as dependencyv2.0.0
: Added 'verify' commandv2.0.1
: Added rake robots:verify and support for whenever gemv2.0.2
: Updated rake dependencyv2.0.3
: Fixed problem with multiple robot queues in specificationverify
commandYou can run the verify
command with an optional --verbose
to print out
details about whether the robots processes are running as configured.
To install create a config/robots.yml
that lists all of the robots in your suite.
When no errors are detected, the output looks like so:
% bundle exec controller verify
OK
% bundle exec controller verify --verbose
OK robot1 is up (1 running)
OK robot2 is up (1 running)
OK robot3 is not enabled (0 running)
OK robot4 is not enabled (0 running)
If robot2
were down and robot3
were up, the output would look something like:
% bundle exec controller verify
ERROR robot2 is down (1 of 3 running)
ERROR robot3 is not enabled (but 1 running)
% bundle exec controller verify --verbose
OK robot1 is up (1 running)
ERROR robot2 is down (1 of 3 running)
ERROR robot3 is not enabled (but 1 running)
OK robot4 is not enabled (0 running)
The various states are determined as follows:
OK
: all N processes are runningERROR
: not all N processes are runningOK
: no processes are runningERROR
: 1 or more processes are runningERROR
: alwaysNOTE: The queues on which the robots are running are NOT verified.
verify
command via crontabIn Capfile
add:
require 'whenever/capistrano'
In config/deploy.rb
add:
set :whenever_identifier, ->{ "#{fetch(:application)}_#{fetch(:stage)}" }
In config/schedule.rb
add:
every 5.minutes do
# cannot use :output with Hash/String because we don't want append behavior
set :output, proc { '> log/verify.log 2> log/cron.log' }
set :environment_variable, 'ROBOT_ENVIRONMENT'
rake 'robots:verify'
end
FAQs
Unknown package
We found that robot-controller demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
A clarification on our recent research investigating 60 malicious Ruby gems.
Security News
ESLint now supports parallel linting with a new --concurrency flag, delivering major speed gains and closing a 10-year-old feature request.
Research
/Security News
A malicious Go module posing as an SSH brute forcer exfiltrates stolen credentials to a Telegram bot controlled by a Russian-speaking threat actor.