Recently I’ve setup a Ruby web application service with the instructions from Digital Ocean. The instructions are great, however they do not mention how to start the Nginix process up on startup.
The command to start the service on boot [under Centos] is:
sudo chkconfig –levels 235 nginx on
However their start script would prevent you from doing that as that it is not a service script that is compatible with chkconfig. The error message that will be given is: service nginx does not support chkconfig.
To fix it, add the following comments to the top of the script (/etc/init.d/nginix) right after the first line (#!/bin/sh)
### BEGIN INIT INFO
# Provides: nginx
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: S 0 1 6
# Short-Description: nginx initscript
# Description: nginx
### END INIT INFO
One of the things that has been bothering me quite a bit as of late is debugging setup issues with OpenStack. Usually this consists of tracking down errors amongst 12 different log files when something goes wrong. There are multiple issues going on here. Firstly, the guides for setting up OpenStack, Folsom, are not so great, or situated for different environments (multinode vs single-node). [That being said, DevStack is pretty cool and easy to use] Secondly, debugging a new setup and learning at the same time can be a pain.
The major issue of installing OpenStack could be solved through a dedicated install process. However, the larger issue is that the user is allowed to fail so quickly. It’s similar to refusing to validate an email address prior to submission and processing on a website. My suggestion is that many of these issues can be solved by doing step by step confirmations of the process. For example, if you were to install a web framework, the installation process/script should confirm:
- That a server is installed
- The installing user has permissions, or can be elevated to the permission level, to install the web application
- Copy the files over to the web server and start the web application
- The web application prompts for a configuration on the first run (I.e. Checking for writable permissions at the get go, setting up users, etc.)
Asking a system administrator to do all of these manual confirmations causes quite a few issues. For example, Some web applications have an issue with the database configuration after the web site has been put in use. Lastly, if a script fails it should fail in a sandbox rather than the live environment. Gentoo sandboxes ebuilds prior to installing the executables on the system.
Another thing to note, if a user is configuring a database on install ask for the host, confirm that the host is enabled, and then allow for a database selection.