chef / omnibus-ctl

Provides service control for omnibus packages

omnibus-ctl

omnibus-ctl provides service control and configuration for omnibus packages.

For an introduction, please see this blog post Omnibus-ctl: What is it and what can it do for you?.

Run the Tests!

There are tests in this repo that should be run before merging to master in the spec directory.

To run them, first install rspec via bundler:

bundle install

Then run the tests:

bundle exec rake

Command API

There are two main functions you will use in your *-ctl project to add commands.

add_command_under_category(string, string, string, int, ruby_block)

This method will add a new command to your ctl under a category, useful for grouping similar commands together logically in help output.

Input arguments:

1. Name of the command.
2. Category of the command. It should be string consisting of only characters and "-". If the category does not exist, it will be added. Default categories are "general" and "service-management" (if the latter is enabled).
3. Description. This will be outputted below the command name when the help command is run.
4. Arity. TODO: Due to current bug, this must be 2, I believe. We should fix this.
5. Ruby block. Ruby code to be executed when your command is run (arguments to that command will be passed into the block).

add_command(string, string, int, ruby_block)

This method will add a new command to your ctl without a category. It will be displayed above all categories when the help command is called.

Input arguments are the same as add_command_under_category except 2 doesn't exist.

Sample Output

# sample-ctl help
/opt/opscode/embedded/bin/sample-ctl: command (subcommand)
command-without-category
  Here is an insightful description for the above command, added via add_command.
another-command-without-category
  Yet another description.
Some Category Of Commands:
  command-with-category
    Exciting description of command added via add_command_under_category.
  better-command-with-category
    You get the idea.
Another Category:
  command-with-better-category
    I'm not just going to copy-pasta above example descriptions.
  better-command-with-better-category
    I'm running out of ideas.

If you only use add_command_under_category to add your custom commands, everything will be outputted under a category.

Pre-hook API

add_global_pre_hook(string, ruby_block)

This method will add a global pre-hook block that will be executed before any *-ctl command is run. If the pre-hook raises an exception it will cause an early exit before the command is run.

Input Arguments:

1. Name of the hook
2. Ruby block of the code to be executed.

Sample

add_global_pre_hook "ensure that the user is always root" do
  raise "You must run this command as root" unless Process.uid == 0
end

Releasing

NOTE: Versions prior to 0.3.6 do not use a "v" prefix for their tags. Current versions do.

• Update the version in lib/omnibus-ctl/version.rb.
• Update the Change log.
• Commit those changes.
• Make sure you are an owner of the omnibus-ctl gem on RubyGems.org. If you aren't, contact one of the owners to be added.
• rake release. This will tag the version, push it to GitHub and RubyGems.

License

See the LICENSE file for details.

Copyright: Copyright (c) Chef Software, Inc. License: Apache License, Version 2.0

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

omnibus-ctl's Issues

Exclude .xz files from "ctl tail" output

Currently, the following archived extension are excluded from ctl tail output:

• gzip
• gz
• tgz

It would be nice to also exclude xz.

See https://github.com/chef/omnibus-ctl/blob/master/lib/omnibus-ctl.rb#L51:

• Current: @log_exclude = '(config|lock|@|gzip|tgz|gz)'
• Suggestion: @log_exclude = '(config|lock|@|gzip|tgz|gz|xz)'

requires system-wide `runit` on Debian

Break-out from #52.

We use system-wide runit for various other daemons on our nodes. chef-server-ctl reconfigure works correctly, but to use chef-server-ctl restart or chef-server-ctl status we need to explicitly set SVDIR (which #52 will prevent).

$ sudo env -i chef-server-ctl status
fail: bookshelf: unable to change to service directory: file does not exist
fail: nginx: unable to change to service directory: file does not exist
fail: oc_bifrost: unable to change to service directory: file does not exist
fail: oc_id: unable to change to service directory: file does not exist
fail: opscode-erchef: unable to change to service directory: file does not exist
fail: opscode-expander: unable to change to service directory: file does not exist
fail: opscode-solr4: unable to change to service directory: file does not exist
fail: postgresql: unable to change to service directory: file does not exist
fail: rabbitmq: unable to change to service directory: file does not exist
fail: redis_lb: unable to change to service directory: file does not exist
$ sudo env -i SVDIR=/opt/opscode/service chef-server-ctl status
run: bookshelf: (pid 4816) 1724702s; run: log: (pid 4869) 1724702s
run: nginx: (pid 4723) 1724706s; run: log: (pid 4980) 1724698s
run: oc_bifrost: (pid 4656) 1724708s; run: log: (pid 4693) 1724707s
run: oc_id: (pid 4708) 1724706s; run: log: (pid 4713) 1724706s
run: opscode-erchef: (pid 4936) 1724700s; run: log: (pid 4917) 1724701s
run: opscode-expander: (pid 4777) 1724703s; run: log: (pid 4807) 1724703s
run: opscode-solr4: (pid 4737) 1724704s; run: log: (pid 4767) 1724704s
run: postgresql: (pid 4635) 1724708s; run: log: (pid 4647) 1724708s
run: rabbitmq: (pid 4538) 1724709s; run: log: (pid 4530) 1724710s
run: redis_lb: (pid 4473) 1724773s; run: log: (pid 4976) 1724698s

This is on Chef server 12.7 and 12.13 (same effect on both).

Digging into the code, the shell-out happens here. It does not call the embedded/bin/sv binary but wrapper scripts in init/, and these contain RUNIT=/usr/bin/sv which is the global binary, looking for the services in /etc/service.

I don't know why these wrapper scripts are necessary, how they are created, or whether they should be used at all?

0.6.0 not tagged

the version in use by chef-server is currently not tagged.

Describe the problem

To make dist updates at a later date this version needs to be pinned here in chef server: https://github.com/chef/chef-server/blob/master/src/chef-server-ctl/Gemfile#L6

otherwise it will pickup the latest master on each build.
https://github.com/chef/omnibus-ctl/blob/master/lib/omnibus-ctl/version.rb#L3

Software Version

0.6.0

Replication Case

N/A

Stacktrace

N/A

Possible Solution

Tag the current branch as v0.6.0 and 0.6.0, both standards are in use.

Logging Binary Data in -ctl tail

Please exclude all binary files including *.gz files.

/cc @ryancragun

Unset/reset SVDIR

This is where chef/chef-server#1075 should be solved. 😉

Disabled services do not show up in `status` ctl command

chef/supermarket#890

Please see the above link for an explanation of this issue. This was originally reported in the supermarket repo. However, we determined that this is an issue with the default commands included in omnibus-ctl, rather than a supermarket-ctl specific command.

Remove old node state before running install

Similar to this: 18dbbb8

'chef-server-ctl install ...' is storing state in '/opt/opscode/embedded/nodes/'

So, if I run:

[root@ap-local-chef-server-12 chef]# chef-server-ctl install opscode-manage --path /media/sf_mnt_kits/chef
---SNIP---
Recipe: private-chef::add_ons_local
  * yum_package[opscode-manage] action install
---SNIP---
Chef Client finished, 1/1 resources updated in 2.802826526 seconds

Subsequent runs will load the previous state as can be seen from the "node['private_chef']['addons']['packages']" and "node['private_chef']['addons']['path']" attributes:

[root@ap-local-chef-server-12 chef]# head -1 /opt/opscode/version-manifest.txt 
chef-server 12.0.7

[root@ap-local-chef-server-12 chef]# chef-server-ctl install opscode-manage
---SNIP---
[1] pry(#<Chef::Recipe>)> node['private_chef']['addons']['packages']
=> ["opscode-reporting", "opscode-manage"]
[2] pry(#<Chef::Recipe>)> node['private_chef']['addons']['path']
=> "/media/sf_mnt_kits/chef"

chef-zero binds to ::1 even if you disable IPv6

In regard to https://gitlab.com/gitlab-org/omnibus-gitlab/issues/576 .

Even if ipv6 is disabled in system, chef-zero binds to ::1, and makes omnibus-ctl take too much time. Fixed it with running chef-client with --chef-zero-host 127.0.0.1 option.

Is this a valid fix? What are the thoughts on a PR to omnibus-ctl's use of chef-client?

Paths in Omnibus.Ctl class

Hello,

I use Omnibus Ctl to install our product.
I need to install our product everything inside a path but it seems that Omnibus Ctl needs the software /opt/#name ... is it possible to configure all the paths of the application (including var and log) from the extern ?

Thanks

omnibus-ctl should cleanup systemd unit file

Systemd support was added to the enterprise-chef-common cookbook, see chef-cookbooks/enterprise-chef-common#25.

omnibus-ctl uninstall and omnibus-ctl cleanse should remove the unit file the same as it removes the upstart job or the line from inittab, see

omnibus-ctl/lib/omnibus-ctl.rb

Line 223 in 4db616f

FileUtils.rm_f("/etc/init/#{name}-runsvdir.conf") if File.exists?("/etc/init/#{name}-runsvdir.conf")

Adding a line like

FileUtils.rm_f("/usr/lib/systemd/system/#{package_name}-runsvdir-start.service") if File.exists?("/usr/lib/systemd/system/#{package_name}-runsvdir-start.service")

would work for opscode-manage.

For chef server a change in enterprise-chef-common/recipes/runit_systemd.rb
like in enterprise-chef-common/recipes/runit_upstart.rb is required:

project_name = node['enterprise']['name'].clone
project_name.gsub!(/_/, '-') if project_name == 'private_chef'

I can provide the PRs if you think this is the right way to solve this problem.

From looking at the code I think removing the upstart job file is currently broken as well.
It should be #{package_name} instead of #{name}.

Embedded Chef Server Cookbooks Depend on chef-solo's Statelessness

As a customer, I want the representation of the chef server's state to be stateless except for whatever files are found in /etc/opscode.

The omnibus-ctl >= 0.3.2 gem found in Chef Server >= 12.0.4 including 916d0c2#diff-125137e844ec1fef32b4d26f67618ee1 breaks this assumption.

We are running the recipe[private-chef::default] cookbook through chef-client -z with the run_list pointed at by -j #{base_path}/embedded/cookbooks/dna.json and remembering the results in /etc/opscode/embedded/nodes/CHEF_SERVER_FQDN.json.

To avoid that memory, we should instead do it like this #25 after doing rm -fr /opt/opscode/embedded/nodes on the chef server's filesystem.

Help always shows `omnibus-ctl` rather than the command you're using

root@private-chef:/home/vagrant# private-chef-ctl help
/opt/opscode/embedded/bin/omnibus-ctl: command (subcommand)

Because we're using $0 in the help method and most users of this script make their own script that wraps this one.

ctl commands always run chef zero on port 8999 which can cause port conflicts

If you run a *-ctl command, like opscode-reporting-ctl reconfigure it spins up Chef Zero on port 8999 to do the converge.

Unfortunately this causes conflicts with other Chef Zero processes that could be running (say if you wanted to create a Chef Server remotely and already had this port taken).

The fix for this is to simply provide a range of ports when running Chef Zero. Chef Zero can take a range of ports instead of just the default 8999: https://github.com/chef/chef-zero/blob/master/lib/chef_zero/server.rb#L260

As a workaround, you can try to override the chef_zero_port in your configuration so it doesn't conflict as so:

.kitchen.yml

  # Leave ports 8999-9000 open for Chef Zero processes running on the server.
  # Not setting this will cause conflicts with Chef Zero processes.
  # Chef processes running on the server are not aware of the provisioner and there
  # is no way to pass a chef zero port range to these processes.
  chef_zero_port: 9001-9999