Install and Configure Monit web interface

Install Monit

Monit is easiest to install through apt-get:

$ sudo apt-get install monit

Once monit downloads, you can add programs and processes to the configuration file:

$ sudo nano /etc/monit/monitrc

Monit can be started up with a command that then keeps it running in the background

$ monit

Typing monit status displays monit’s details:

The Monit daemon 5.3.2 uptime: 1h 25m 

System 'myhost.mydomain.tld'
  status                            Running
  monitoring status                 Monitored
  load average                      [0.03] [0.14] [0.20]
  cpu                               3.5%us 5.9%sy 0.0%wa
  memory usage                      26100 kB [10.4%]
  swap usage                        0 kB [0.0%]
  data collected                    Thu, 30 Aug 2012 18:35:00

Configure Monit

Monit is very easy to use nearly out of the box. By default, it is set up to check that services are running every 2 minutes and stores its log file in “/var/log/monit.log”.

These settings can be altered at the beginning of the configuration file in the set daemon and set logfile lines respectively.

Web Service

Monit comes with it’s own web server running on port 2812. To configure the web interface, find and uncomment the section that begins with set httpd port 2812. Once the section is uncommented, write in your server’s IP or domain name as the address, allow anyone to connect, and then create a monit user and password

    set httpd port 2812
    use address 12.34.56.789  # only accept connection from localhost
    allow 0.0.0.0/0.0.0.0     # allow localhost to connect to the server and
    allow admin:monit         # require user 'admin' with password 'monit'

Once this is configured, monit should reload and reread the configuration file, and the web interface will be available:

$ monit reload

When you are done, try

http://12.34.56.789:2812

You will see a dialog box appear in the browser.

General Monit Scripts

Sidekiq

  # /etc/monit/conf-available/sidekiq
  check process sidekiq_thepact_staging0 with pidfile "/home/deployer/www/staging/shared/tmp/pids/sidekiq.pid"  
  start program = "/bin/su - deployer -c 'cd /home/deployer/www/staging/current && /usr/local/rvm/bin/rvm default do bundle exec sidekiq --config /home/deployer/www/staging/current/config/sidekiq.yml --index 0 -e staging -d'" with timeout 30 seconds  
  stop program  = "/bin/su - deployer -c 'cd /home/deployer/www/staging/current && /usr/local/rvm/bin/rvm default do bundle exec sidekiqctl stop /home/deployer/www/staging/shared/tmp/pids/sidekiq.pid'" with timeout 110 seconds  group thepact-sidekiq-0

PostGreSQL

 # /etc/monit/conf-available/pg
 check process postgres with pidfile /var/run/postgresql/9.5-main.pid
 group database
 start program = "/etc/init.d/postgresql start"
 stop program  = "/etc/init.d/postgresql stop"
 if failed unixsocket /var/run/postgresql/.s.PGSQL.5432 protocol pgsql
 then restart

Puma

 # /etc/monit/conf-available/puma
 check process puma with pidfile /var/www/myapp/production/shared/tmp/pids/puma.pid
 group www

 start program   = "/bin/su - john -c '~/.rvm/bin/rvm default do bundle exec puma -C /var/www/myapp/production/shared/puma.rb --daemon'"
 stop program    = "/bin/su - john -c 'pumactl stop -P /var/www/myapp/production/shared/tmp/pids/puma.pid'"
 restart program = "/bin/su - john -c 'pumactl restart -P /var/www/myapp/production/shared/tmp/pids/puma.pid'"

or

 # /etc/monit/conf-available/puma
 check process puma with pidfile /var/www/myapp/production/shared/tmp/pids/puma.pid
 group www
 start program   = "/bin/su - john -c '~/.rvm/bin/rvm default do bundle exec puma -C /var/www/myapp/production/shared/puma.rb --daemon'"
 stop program    = "/bin/su - john -c '~/.rvm/bin/rvm default do bundle exec pumactl -S /var/www/myapp/production/shared/tmp/pids/puma.state stop'"
 restart program = "/bin/su - john -c '~/.rvm/bin/rvm default do bundle exec pumactl -S /var/www/myapp/production/shared/tmp/pids/puma.state restart'"

Using the scripts

By default Monit does not load conf-scripts in conf-available. You have to copy the scripts to conf-enabled to have them executed by Monit. So, we are going to link those files that folder instead of copying/duplicating them. Its a good practice.

$ sudo ln /etc/monit/conf-available/puma /etc/monit/conf-enabled/puma

This will link the file there, same file will act as if it is there too.

Sources

https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-monit

Advertisements

SSL Certification and Linux / Nginx

Create the SSL Certificate

We can start off by creating a directory that will be used to hold all of our SSL information. We should create this under the Nginx configuration directory:

sudo mkdir /etc/nginx/ssl

Now that we have a location to place our files, we can create the SSL key and certificate files in one motion by typing:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.crt

You will be asked a series of questions. Before we go over that, let’s take a look at what is happening in the command we are issuing:

  • openssl: This is the basic command line tool for creating and managing OpenSSL certificates, keys, and other files.
  • req: This subcommand specifies that we want to use X.509 certificate signing request (CSR) management. The “X.509” is a public key infrastructure standard that SSL and TLS adheres to for its key and certificate management. We want to create a new X.509 cert, so we are using this subcommand.
  • -x509: This further modifies the previous subcommand by telling the utility that we want to make a self-signed certificate instead of generating a certificate signing request, as would normally happen.
  • -nodes: This tells OpenSSL to skip the option to secure our certificate with a passphrase. We need Nginx to be able to read the file, without user intervention, when the server starts up. A passphrase would prevent this from happening because we would have to enter it after every restart.
  • -days 365: This option sets the length of time that the certificate will be considered valid. We set it for one year here.
  • -newkey rsa:2048: This specifies that we want to generate a new certificate and a new key at the same time. We did not create the key that is required to sign the certificate in a previous step, so we need to create it along with the certificate. The rsa:2048 portion tells it to make an RSA key that is 2048 bits long.
  • -keyout: This line tells OpenSSL where to place the generated private key file that we are creating.
  • -out: This tells OpenSSL where to place the certificate that we are creating.

As we stated above, these options will create both a key file and a certificate. We will be asked a few questions about our server in order to embed the information correctly in the certificate.

Fill out the prompts appropriately. The most important line is the one that requests the Common Name (e.g. server FQDN or YOUR name). You need to enter the domain name that you want to be associated with your server. You can enter the public IP address instead if you do not have a domain name.

The entirety of the prompts will look something like this:

Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Bouncy Castles, Inc.
Organizational Unit Name (eg, section) []:Ministry of Water Slides
Common Name (e.g. server FQDN or YOUR name) []:your_domain.com
Email Address []:admin@your_domain.com

Both of the files you created will be placed in the /etc/nginx/ssl directory.

Wildcard certificate

In computer networking, a wildcard certificate is a public key certificate which can be used with multiple subdomains of a domain. The principal use is for securing web sites with HTTPS, but there are also applications in many other fields.

Common Name (e.g. server FQDN or YOUR name) []:*.your_domain.com
# This make the certificate also applicable to sub-domains.

Step Two — Configure Nginx to Use SSL

We have created our key and certificate files under the Nginx configuration directory. Now we just need to modify our Nginx configuration to take advantage of these by adjusting our server block files. You can learn more about Nginx server blocks in this article.

Nginx versions 0.7.14 and above (Ubuntu 14.04 ships with version 1.4.6) can enable SSL within the same server block as regular HTTP traffic. This allows us to configure access to the same site in a much more succinct manner.

Your server block may look something like this:

server {
        listen 80 default_server;
        listen [::]:80 default_server ipv6only=on;

        root /usr/share/nginx/html;
        index index.html index.htm;

        server_name your_domain.com;

        location / {
                try_files $uri $uri/ =404;
        }
}

The only thing we would need to do to get SSL working on this same server block, while still allowing regular HTTP connections, is add a these lines:

server {
        listen 80 default_server;
        listen [::]:80 default_server ipv6only=on;

        listen 443 ssl;

        root /usr/share/nginx/html;
        index index.html index.htm;

        server_name your_domain.com;
        ssl_certificate /etc/nginx/ssl/nginx.crt;
        ssl_certificate_key /etc/nginx/ssl/nginx.key;

        location / {
                try_files $uri $uri/ =404;
        }
}

When you are finished, save and close the file.

Now, all you have to do is restart Nginx to use your new settings:

sudo service nginx restart

This should reload your site configuration, now allowing it to respond to both HTTP and HTTPS (SSL) requests.

Step Three — Test your Setup

Your site should now have SSL functionality, but we should test it to make sure.

First, let’s test to make sure we can still access the site with using normal HTTP. In your web browser, go to your server’s domain name or IP address:

http://server_domain_or_IP

 

Sources

https://www.digitalocean.com/community/tutorials/how-to-create-an-ssl-certificate-on-nginx-for-ubuntu-14-04 for references

https://en.wikipedia.org/wiki/Wildcard_certificate

https://support.comodo.com/index.php?/Knowledgebase/Article/View/1/38/csr-generation-using-openssl-apache-wmod_ssl-nginx-os-x

https://sg.godaddy.com/help/what-is-a-wildcard-ssl-certificate-567

Linux Distributions : Nginx : Configuration Basics

Nginx is a light weight high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server. Nginx is known for its high performance, stability, rich feature set, simple configuration, and low resource consumption.

This guide describes how to start and stop Nginx, and reload its configuration, explains the structure of the configuration file and describes how to set up Nginx to serve out static content and how to configure Nginx as a proxy server.

Continue reading

Amazon S3 : Carrier Wave : Error : The difference between the request time and the current time is too large.

Error:  Excon::Errors::Forbidden

You have sometime faced this error which you can see in the server log in development or any environment. This mainly concerns with Amazon S3 server or any other servers you rely upon for APIs.

Main Reason:

  • You have changed your system Date – Time by any means
  • You use Virtual Machine to run your operating system in which your development environment run and you have resumed the system from suspension after a while.
  • Your server Date – Time is not configured properly if you have your own server locally (Physically)

Continue reading

Forcefully kill WEBrick instance in Ubuntu and Windows

For Linux/Ubuntu Users, ubuntu has kill command. While running webrick server, in project directory within location APP_DIR/tmp/pids/server.pid there will be all Process Ids saved.
You just need to open the file, you will find the Process Id of currently running server. Now you can use the following command to kill the process

$ kill [pid] # Example kill 8123

For Windows user, you can use the following command

taskkill /PID 8436

Rails detects changes in Models, Views and Controllers aut

When does server restart?

Server restarts if browser requests for fresh content. In normal request the Application is not reloaded in fact the older version of app is rendered  and sent to client.

To get latest version you need to reload removing cache. You need to Hard-Reload the Browser.

In development mode (which is what you're working in by default), Rails reloads your application with every browser request, so there's no need to stop and restart the web server when a change is made.

asd