CentOS 6.5 Troubles with cap setup

[seajoshc]

Hello and thanks for the gem. I'm trying to use it to get a CentOS 6.5 server setup with a Rails app and running into some troubles with the cap production setup step. It fails trying to symlink to /etc/nginx/sites-enabled with the following:

INFO[9469de65] Running /usr/bin/env sudo ln -fs /etc/nginx/sites-available/my_app_production /etc/nginx/sites-enabled/my_app_production on 192.168.33.10
DEBUG[9469de65] Command: /usr/bin/env sudo ln -fs /etc/nginx/sites-available/my_app_production /etc/nginx/sites-enabled/my_app_production
DEBUG[9469de65]     ln: 
DEBUG[9469de65]     accessing `/etc/nginx/sites-enabled/my_app_production'
DEBUG[9469de65]     : Not a directory
DEBUG[9469de65]     
cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing on host 192.168.33.10: sudo exit status: 1
sudo stdout: Nothing written
sudo stderr: ln: accessing `/etc/nginx/sites-enabled/my_app_production': Not a directory

If I manually create /etc/nginx/sites-enabled it then fails on running update-rc.d which does not exist on CentOS 6:

INFO[445efdaf] Running /usr/bin/env sudo update-rc.d -f unicorn_my_app_production defaults on 192.168.33.10
DEBUG[445efdaf] Command: /usr/bin/env sudo update-rc.d -f unicorn_my_app_production defaults
DEBUG[445efdaf]     sudo
DEBUG[445efdaf]     : 
DEBUG[445efdaf]     update-rc.d: command not found
DEBUG[445efdaf]     
cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing on host 192.168.33.10: sudo exit status: 1
sudo stdout: Nothing written
sudo stderr: sudo: update-rc.d: command not found

I'm using the following versions: capistrano (3.2.1) capistrano-unicorn-nginx (3.1.1)

[bruno-]

Hi thanks for the report and sorry for the wait.

That's interesting, so are you saying /etc/nginx/sites-enabled/ does not exist on CentOS, even when nginx package is installed? How was nginx installed?

About the second thing, any ideas what should we use instead of update-rc.d? I guess then update-rc.d works only on ubuntu/debian?

As you might have guessed, this plugin has been mostly tested on ubuntu. We should probably test on other distros too.

[seajoshc]

No worries thanks for the response!

Just spun up a brand new CentOS VM and I'm installing Nginx via yum (using the EPEL Repository). I think the sites-enabled/sites-active is some helper stuff the Ubuntu package does, not necessarily an Nginx default. Here's some output:

[vagrant@localhost ~]$ nginx -v
nginx version: nginx/1.0.15
[vagrant@localhost ~]$ cat /etc/redhat-release 
CentOS release 6.6 (Final)
[vagrant@localhost ~]$ ll /etc/nginx/
total 64
drwxr-xr-x. 2 root root 4096 Nov  3 17:11 conf.d
-rw-r--r--. 1 root root  979 Apr 26  2013 fastcgi.conf
-rw-r--r--. 1 root root  979 Apr 26  2013 fastcgi.conf.default
-rw-r--r--. 1 root root  909 Apr 26  2013 fastcgi_params
-rw-r--r--. 1 root root  909 Apr 26  2013 fastcgi_params.default
-rw-r--r--. 1 root root 2837 Apr 26  2013 koi-utf
-rw-r--r--. 1 root root 2223 Apr 26  2013 koi-win
-rw-r--r--. 1 root root 3463 Apr 26  2013 mime.types
-rw-r--r--. 1 root root 3463 Apr 26  2013 mime.types.default
-rw-r--r--. 1 root root 1059 Apr 26  2013 nginx.conf
-rw-r--r--. 1 root root 2685 Apr 26  2013 nginx.conf.default
-rw-r--r--. 1 root root  544 Apr 26  2013 scgi_params
-rw-r--r--. 1 root root  544 Apr 26  2013 scgi_params.default
-rw-r--r--. 1 root root  570 Apr 26  2013 uwsgi_params
-rw-r--r--. 1 root root  570 Apr 26  2013 uwsgi_params.default
-rw-r--r--. 1 root root 3610 Apr 26  2013 win-utf

Instead of update-rc.d, the chkconfig command would work for RedHat-like OS's. The below should work:

chkconfig --add unicorn_my_app_production
chkconfig unicorn_my_app_production on

[seajoshc]

I've been playing around and have a branch with a working version for CentOS. I'll try to clean it up a bit in the next few days and see if I can send a PR your way. If you're curious: https://github.com/irlrobot/capistrano-unicorn-nginx/compare/capistrano-plugins:master...master

Some OS detection or manual configuration are probably required here. Would you rather see automatic detection/configuration (which means making some assumptions), or would a YAML configuration file the user sets up be a better option?

[bruno-]

Hi, thanks for sharing the updates on this. I must say I feel a bit stumped. I didn't expect so many differences across various distributions.

The diff you sent is helpful. I'm not sure what is the best way to proceed. If the differences between ubuntu <-> centos are so big, we should first set the ground for handling those differences on other distros as well. And enable user to easily make overrides. When we solve the "meta" problem, implementing specifics for ubuntu, centos and others should then be easy.

Please don't spend a lot of time on making the pull request that enables work with centos. In my mind solving the "meta" problem of handling any distro comes first. And that is something I'd like to give some time, tackle on my own and hopefully solve properly.

I presume you can handle your day-to-day work with the changes in your fork now?

[seajoshc]

Yep! Agree on the meta problem. Sounds good, if you'd like any help let me know.

[jbcom]

Adding my two cents since I'm going to probably end up using your fine work for a deployment to our own CentOS 6.5 Rails infrastructure.

Correct, neither nginx or httpd use sites-enabled on CentOS. Conf.d is the standard and is more "Nixy" which is a stupid argument because synlinkibg into an enabled directory is a brilliant step forward. That's irrelevant though.

For people using Chef to deploy code the vendor cookbooks for httpd and nginx will create Debian style directories and scripts to help modernize the CebtOS structure to something a bit more useful.

So what you could do is if you wanted to abstract this to a meta problem is handle it like Chef and make the assumption that you should support no assumptions. There are multiple possible solutions for running a service such as runit, upstart, etc... Platform agnostisic development could be swung towards on a pivot by testing for the same set of service management strategies that Chef uses and then by abstraction, creating a singular directive whose underlying code translates to the correct manager (runit, upstart, etc...)

Same for directory structure. Test for include directives inside of nginx's global configuration and determine whether sites-enabled is in the directives. Or test for sites-enabled / sites-available in the filesystem. Support it as the preferred method for enabling and disabling Nginx and if it doesn't exist fall back to conf.d or whatever is in the Include.

Just my two cents. I look forward to forking this to see how much works with CentOS 6.5 once Chef has made the architecture more universal.

[ereichert]

Is there a timeline for fixing this?

[bruno-]

Hi, I'll be straight up honest and say that unfortunately there is not. I still want to handle this properly, but other things and real life get in the way. If anyone want's to help that would be appreciated.

[bruno-]

@jmbogaty sorry for never replying.. If you ever forked this plugin and made it work for centos, I'd be pretty interested to see the changes..

[ereichert]

@bruno-

Along the same lines as the idea @jmbogaty expressed, Facter is used by Puppet to determine OS level properties.

This (https://github.com/puppetlabs/facter/blob/master/lib/facter/operatingsystem/linux.rb#L238) is how Facter determines which distro is installed.

I've done a cursory search and haven't found an efficient way of duplicating this using ssh kit. I'm thinking that uploading a script and then running that script might be the best way of doing it.

Thoughts?

[roadt]

Met the issue on Centos 6.3, ignore error and manually config using centos chkconfig or ntsysv . to workaround it. it is great if there are ideas of fix!

[kaleemullah360]

I also got this error. as far as I know CentOS 7 didn't has sites-enabled directory instead it has /etc/nginx/conf.d/default.conf and server block can be enabled by /bin/systemctl enable nginx.service

rvm 1.29.1 (latest) by Michal Papis, Piotr Kuczynski, Wayne E. Seguin [https://rvm.io/]
ruby-2.4.0
ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux]
00:00 nginx:setup
      Uploading /tmp/expedite_core_production 100.0%
      01 sudo mv /tmp/expedite_core_production /etc/nginx/sites-available
    ✔ 01 dev@192.168.15.78 0.032s
      02 sudo ln -fs /etc/nginx/sites-available/expedite_core_production /etc/nginx/sites-enabled/expedite_core_production
      02 ln: failed to create symbolic link ‘/etc/nginx/sites-enabled/expedite_core_production’: No such file or directory
(Backtrace restricted to imported tasks)
cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing as dev@192.168.15.78: sudo exit status: 1
sudo stdout: ln: failed to create symbolic link ‘/etc/nginx/sites-enabled/expedite_core_production’: No such file or directory
sudo stderr: Nothing written

SSHKit::Command::Failed: sudo exit status: 1
sudo stdout: ln: failed to create symbolic link ‘/etc/nginx/sites-enabled/expedite_core_production’: No such file or directory
sudo stderr: Nothing written

Tasks: TOP => nginx:setup

please guide update how to resolve it.

[kaleemullah360]

I've solve the above said issue by just creating directories i.e sites-enabled and sites-available then did cap production setup not cap production deploy but encounter a new problem cause after symlinking site to enabled directory it try to do sudo update-rc.d -f unicorn_core_production defaults and in centOS update-rc.d not longer exist.

Error

03 sudo: update-rc.d: command not found
(Backtrace restricted to imported tasks)
cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing as dev@192.168.15.78: sudo exit status: 1
sudo stdout: sudo: update-rc.d: command not found
sudo stderr: Nothing written

SSHKit::Command::Failed: sudo exit status: 1
sudo stdout: sudo: update-rc.d: command not found
sudo stderr: Nothing written