Set default PATH for cron or full path to backup executable?

[allaire]

Currently, the default command ran by the cron is root backup perform --trigger my_backup --config-file /etc/backup/config.rb --log-path=/var/log > /dev/nu$

Thing is, this fail miserably because the PATH in a cron is not the same as the PATH in our shell, and the backup command is not found.

I see two solutions here:

• Use the full backup path, i.e /usr/local/bin/backup
• Add a default PATH in the crond resource, i.e :path => '/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin'

My current solution is to set the path in the cron_options parameters, i.e

  cron_options({
    :path => '/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin',
    :mailto => '[email protected]'
  })

But this is not really straightforward, since without this, the backup-cookbook cron simply does not work :)

Thoughts?

[smith]

If the place where gems get installed isn't in the default path, then this is what's going to happen. Telling it to use #{node['languages']['ruby']['bin_dir']}/backup would probably work for most people.

[allaire]

All my stuff is in shell default paths:

org@front:~$ which ruby
/usr/bin/ruby
org@front:~$ which gem
/usr/bin/gem
org@front:~$ which backup
/usr/local/bin/backup
org@front:~$

Thing is, CRON does not have the same default PATH as an interactive shell, i.e /usr/locale/sbin:/usr/local/bin:,
etc.

From the CRON man, we can read: If the PATH is omitted, no default will be used and file locations will need to be absolute.

So only calling backup, no matter if my gem is in my default interactive shell PATH, it won't work.

[kliuchnikau]

I agree, the cron PATH should be updated for backup-cookbook's cron task, because currently cookbook does not work smoothly with clean setup (without changes to cron_options) and new cookbook users might have problems setting everything up. Default PATH for cron task is too restrictive: /usr/bin:/bin is not enough. Let's at least add /usr/local/bin to the cron path. I believe almost everybody set cron_options's path or command to make backup-cookbook work.

[epcim]

On my system there is not Ruby system wide instaled. So even adding /usr/local/bin helps. The gem_package installs backup gem under /opt/chef/embedded thus you do have to add at least /opt/chef/embedded/bin as well.

How ever I would rather install Backup to system wide ruby installation. So sth. like rbenv cookbook shold be dependency of this one.

[alepore]

+1 for this, i have to use:

cron_options({
  path: '/opt/chef/embedded/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
})

[chewi]

My colleague, @neilh23, has raised an issue where backup is failing to start because it cannot find builder 3.2.2. It has installed the backup gem under /opt/chef/embedded and we also had to adjust the PATH as suggested above. I have surmised that the older chef-client already came with 3.2.2 but this was removed in favour of 3.2.3 when chef-client was updated.

This made me wonder whether it's even supposed to install the gem there. This cookbook doesn't seem to suggest that. It uses gem_package rather than chef_gem, for example. On the other hand, it doesn't allow you to override the gem_binary property, which defaults to Chef's embedded version.

On top of that, we have the comments above suggesting that the behaviour of gem_package has changed. It's hard to tell just by looking at the source but it seems that Chef 10 defaulted to the system Ruby and this changed in later releases. Note this comment from rubygems.rb.

# Opscode Omnibus - The ruby that ships inside omnibus is only used for Chef
# Default to installing somewhere more functional

Given backup's insistence on very precise gem versions, I believe installing it alongside the Chef gems is a bad idea. We should at least make it possible to override gem_binary so that a system-wide alternative can be used.

[chewi]

I thought I'd try just installing a system-wide Ruby first and seeing whether it picks that instead. Indeed it does. I guess chef-client's behaviour did not change after all, but we should make it clearer that you should install Ruby before using this cookbook as it will not do it for you.

The issue with the PATH still stands.