Here is how I set NGINX to the development branch to get more frequent updates and features over the stable branch
Updating NGINX to the development branch (on Ubuntu) to get more frequent updates and features over the stable branch
I have a number of guides on moving away from CPanel, Setting up VM’s on UpCloud, AWS, Vultr or Digital Ocean along with installing and managing WordPress from the command line. View all recent posts here https://fearby.com/all/
Now on with the post
Backup your Nginx and Server before making any changes. The Nginx development branch is quite stable but anything can happen. If your site is mission critical then stay on the stable branch.
By default, you will most likely get the stable branch of Nginx when instaling and updating Nginx. I have been running the stable version for the last few years but was made aware of a DDoS vulnerability in Nginx.
Here is a good write-up on development merges into the stable branch.
Widely-used #Nginx server releases versions 1.15.6 and 1.14.1 to patch two HTTP/2 implementation vulnerabilities that might cause excessive memory consumption (CVE-2018-16843) & CPU usage (CVE-2018-16844), allowing a remote attacker to perform #DoS attackhttps://t.co/1Z3JoghoBr pic.twitter.com/qQ3pOFD1Lk
— The Hacker News (@TheHackersNews) November 9, 2018
I was aware recently of a DDoS bug affecting Nginx and the recommendation was to update ot Nginx 1.15.6 development branch (or 1.14.1 stable branch).
A few days ago no 1.14.1 update was available but a 1.15.6 was, should I switch to the development branch to get updates earlier?
Reminder to update your #nginx installations to the 1.14.1 stable or the 1.15.6 mainline versions for critical security patches released this week. #NGINXPlus customers, see instructions for updating based on the patch released 10/30 https://t.co/KitsOWIJkb
— NGINX, Inc. (@nginx) November 8, 2018
Recent Nginx Changes
Here are the recent changes to Nginx: http://nginx.org/en/CHANGES
Changes with nginx 1.15.6 06 Nov 2018 *) Security: when using HTTP/2 a client might cause excessive memory consumption (CVE-2018-16843) and CPU usage (CVE-2018-16844). *) Security: processing of a specially crafted mp4 file with the ngx_http_mp4_module might result in worker process memory disclosure (CVE-2018-16845). *) Feature: the "proxy_socket_keepalive", "fastcgi_socket_keepalive", "grpc_socket_keepalive", "memcached_socket_keepalive", "scgi_socket_keepalive", and "uwsgi_socket_keepalive" directives. *) Bugfix: if nginx was built with OpenSSL 1.1.0 and used with OpenSSL 1.1.1, the TLS 1.3 protocol was always enabled. *) Bugfix: working with gRPC backends might result in excessive memory consumption. Changes with nginx 1.15.5 02 Oct 2018 *) Bugfix: a segmentation fault might occur in a worker process when using OpenSSL 1.1.0h or newer; the bug had appeared in 1.15.4. *) Bugfix: of minor potential bugs. Changes with nginx 1.15.4 25 Sep 2018 *) Feature: now the "ssl_early_data" directive can be used with OpenSSL. *) Bugfix: in the ngx_http_uwsgi_module. Thanks to Chris Caputo. *) Bugfix: connections with some gRPC backends might not be cached when using the "keepalive" directive. *) Bugfix: a socket leak might occur when using the "error_page" directive to redirect early request processing errors, notably errors with code 400. *) Bugfix: the "return" directive did not change the response code when returning errors if the request was redirected by the "error_page" directive. *) Bugfix: standard error pages and responses of the ngx_http_autoindex_module module used the "bgcolor" attribute, and might be displayed incorrectly when using custom color settings in browsers. Thanks to Nova DasSarma. *) Change: the logging level of the "no suitable key share" and "no suitable signature algorithm" SSL errors has been lowered from "crit" to "info". Changes with nginx 1.15.3 28 Aug 2018 *) Feature: now TLSv1.3 can be used with BoringSSL. *) Feature: the "ssl_early_data" directive, currently available with BoringSSL. *) Feature: the "keepalive_timeout" and "keepalive_requests" directives in the "upstream" block. *) Bugfix: the ngx_http_dav_module did not truncate destination file when copying a file over an existing one with the COPY method. *) Bugfix: the ngx_http_dav_module used zero access rights on the destination file and did not preserve file modification time when moving a file between different file systems with the MOVE method. *) Bugfix: the ngx_http_dav_module used default access rights when copying a file with the COPY method. *) Workaround: some clients might not work when using HTTP/2; the bug had appeared in 1.13.5. *) Bugfix: nginx could not be built with LibreSSL 2.8.0. Changes with nginx 1.15.2 24 Jul 2018 *) Feature: the $ssl_preread_protocol variable in the ngx_stream_ssl_preread_module. *) Feature: now when using the "reset_timedout_connection" directive nginx will reset connections being closed with the 444 code. *) Change: a logging level of the "http request", "https proxy request", "unsupported protocol", and "version too low" SSL errors has been lowered from "crit" to "info". *) Bugfix: DNS requests were not resent if initial sending of a request failed. *) Bugfix: the "reuseport" parameter of the "listen" directive was ignored if the number of worker processes was specified after the "listen" directive. *) Bugfix: when using OpenSSL 1.1.0 or newer it was not possible to switch off "ssl_prefer_server_ciphers" in a virtual server if it was switched on in the default server. *) Bugfix: SSL session reuse with upstream servers did not work with the TLS 1.3 protocol. Changes with nginx 1.15.1 03 Jul 2018 *) Feature: the "random" directive inside the "upstream" block. *) Feature: improved performance when using the "hash" and "ip_hash" directives with the "zone" directive. *) Feature: the "reuseport" parameter of the "listen" directive now uses SO_REUSEPORT_LB on FreeBSD 12. *) Bugfix: HTTP/2 server push did not work if SSL was terminated by a proxy server in front of nginx. *) Bugfix: the "tcp_nopush" directive was always used on backend connections. *) Bugfix: sending a disk-buffered request body to a gRPC backend might fail. Changes with nginx 1.15.0 05 Jun 2018 *) Change: the "ssl" directive is deprecated; the "ssl" parameter of the "listen" directive should be used instead. *) Change: now nginx detects missing SSL certificates during configuration testing when using the "ssl" parameter of the "listen" directive. *) Feature: now the stream module can handle multiple incoming UDP datagrams from a client within a single session. *) Bugfix: it was possible to specify an incorrect response code in the "proxy_cache_valid" directive. *) Bugfix: nginx could not be built by gcc 8.1. *) Bugfix: logging to syslog stopped on local IP address changes. *) Bugfix: nginx could not be built by clang with CUDA SDK installed; the bug had appeared in 1.13.8. *) Bugfix: "getsockopt(TCP_FASTOPEN) ... failed" messages might appear in logs during binary upgrade when using unix domain listen sockets on FreeBSD. *) Bugfix: nginx could not be built on Fedora 28 Linux. *) Bugfix: request processing rate might exceed configured rate when using the "limit_req" directive. *) Bugfix: in handling of client addresses when using unix domain listen sockets to work with datagrams on Linux. *) Bugfix: in memory allocation error handling.
Development branch changes are made every few weeks and stable branch changes are made less often.
Normally you update Nginx bu running an update and upgrade
apt-get update && apt-get upgrade
Restart Nginx for good measure
Checking NGINX Version
nginx -v nginx version: nginx/1.14.1
Changing your repository to the development branch
I changed ot the development branch by running
sudo add-apt-repository ppa:nginx/development
Update and upgrade Nginx
apt-get update && apt-get upgrade
Restart Nginx for good measure
Checking NGINX Version
nginx -v nginx version: nginx/1.16.6
Removing the stable Nginx repository
Run this command to remove the stable branch of Nginx
sudo add-apt-repository -r ppa:nginx/stable
Check to see if the development branch is listed
grep -r --include '*.list' '^deb ' /etc/apt/sources.list* |grep nginx /etc/apt/sources.list.d/nginx-ubuntu-development-bionic.list:deb http://ppa.launchpad.net/nginx/development/ubuntu bionic main
Good luck and I hope this guide helps someone
Ask a question or recommend an article
v1.0 Initial post
fyi: Consider reading this first (newer blog post): How to buy a new domain and SSL cert from NameCheap, a Server from Digital Ocean and configure it.
Buying a Domain
Buy a domain name from Namecheap here.
Why do I need a free Development IDE/VM
- You already have heaps of sub domains/sites/blogs on one CPanel domain and you don’t want to slow down your server anymore.
- You need a new collaboration web server setup in minutes.
- You want a server where you have full control to install the latest widgets (NGNIX, NodeJS etc).
- You want a single interface where you can deploy, develop and test online.
- You want to save money
- You want to access and edit your sites from anywhere.
Now there is no need to spend valuable development time on setting up hardware/software platform. You can create, build and run almost any development stack in minutes. Cloud9 maintain the server and you have full control it.
Signing up for a C9 account.
Cloud 9 offer a number of hosting plans (one free) with a range of hardware resources for when you want to scale up. The free tier is great if you want to keep your development environment closed. Use this link and get $19 free credit https://c9.io/c/DLtakOtNcba
Before you connect to your digital ocean VM connect to the server via the console in the digital ocdan admin pane (you may need to reset your root password) and then install NodeJS (Required by c9.io IDE).
- curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash –
- sudo apt-get install -y nodejs
- node -v
Now you will have node v6.3.0
Create a development Workspace.
Once you create a Cloud 9 account you can create a VM workspace. You can choose some common software packages to installed by default. Don’t worry you can install anything you want later from the command line in the VM.
How simple is that, a new development environment in minutes.
You can edit new code, play with WordPress or NodeJS all from the one Cloud9 IDE. The Cloud 9 IDE allows you to open a “bash terminal” tab, folder list, web browser, code window and debug tools (all from the web).
Code on the left, WordPress on the right, terminal on the bottom 🙂
You can Install what you want
Because you have access to the Linux bash terminal you can for example type the following to install an NGNIX web server.
- sudo apt-get update
- sudo apt-get install nginx
- sudo service nginx start
Full Bash Terminal
As usual installing stuff in Linux requires loads of googling and editing config files so beware.
What are the downsides of a c9.io Ubuntu server?
Your development environment (public of private) is mostly off limits to the outside world unless you invite people in who have a Cloud 9 account. This is great if you want to develop a customers website off the grid and keep is secure or share the development with other developers. Cloud 9 don’t really have a “goto production plan” so you will need to find a host to deploy to when you are ready.
Luckily this is where http://www.digitalocean.com comes in, Digital Ocean allow you to create a real/public VM (just like Cloud 9) and best of all you can connect it to the Cloud 9 IDE..
The only downside is you will need to move on from the free Cloud 9 account and pay $9 a month to allow you to connect securely (via SSH) to your new (Real) Digital Ocean VM. On the up side the $19 month plan gives you twice the ram (1GB) and 10x the storage (10GB) and you can have 2 premium (private accounts).
Signing up for a Digital OceanAccount
The cheapest Digital Ocean Hosting plan is $5 a month. If you want $10 free credit at Digital Ocean (two months free) please use this link: https://www.digitalocean.com/?refcode=99a5082b6de5
Granting SSH Access (before you create a server (droplet))
Tip: Add your Cloud 9 SSH key to your account before creating a droplet (VM). I added my SSH key when the VM/Droplet was create and I could not connect to it from Cloud 9. I then deleted the droplet, added the SSH key to my Digital Ocean account here then created the Droplet (VM) and all was ok. You can find your SSH key on the front page of your cloud 9 desktop.
This is the magic option, if you skip this you will be emailed a password to your VM and you will be on your own connecting to it with a secure terminal window. If you add your Cloud 9 SSH key ( found in your Cloud 9 IDE https://cloud.digitalocean.com/settings/security ) you can connect to and control your new Digital Ocean VM from the Cloud 9 UI.
Now you can create a server (droplet)
A digital ocean server can be setup in minutes. If you only use it for 2 weeks you will only be charged for 2 weeks. If you use my link your first 2 months are free (if you select a $5 server).
Your server should be created in well under 5 minutes. Write down your VM’s IP.
Connecting your C9 account to Digital Ocean Droplet
Now go back to Cloud 9 and login. Go here ( https://c9.io/account/ssh ) and add your SSH key from Digital Ocean.
Cloud 9 guide on setting up SSH on your server: https://docs.c9.io/docs/running-your-own-ssh-workspace
fyi: Here is a more recent post of how to connect Cloud 9 with AWS.
Create a new workspace with these settings (but use your IP from digital ocean) to connect to your new Digital Ocean VM.
Now you can develop like a pro. Cloud 9 will allow you to login to your development environment from anywhere and resume where you left off.
Traps and Tips
- Consider buying this course: https://www.udemy.com/all-about-nodejs/?dtcode=9TQkocT33Eck
- Get your VM/Droplets right (if they don’t work as expected delete them and start again).
- Know how to safely shutdown a Linux VM.
- If you receive the error “Could not execute node.js on [email protected] bash: /usr/bin/nodejs:” in C9 when connecting to the server try installing node via the digital oceans manual console window.
Connecting your new Cloud IP to a CPanel sub domain
If you have CPanel domain elsewhere you can link your new Digital Ocean Cloud VM IP to a new sub domain.
- Login to your CPanel domain UI.
- Click Simple DNS Zone Editor
- Type the sub domain name (swap my domain.com to your domain).
- Enter the IP for your Digital Ocean domain (you get this from the Digital Ocean account page).
- Click Add a record.
- Now when someone types http://newcloud.mydomain.com they get redirected to your new cloud domain but the URL stays the same (how professional is that).
- You can add multiple A name records pointing to the same IP.
$19 a month gives me a kick arse www.c9.io development environment and a few VMs.
$5 a month gives me my own real VM that I can scale up.
You can easily deploy an SSD cloud server in 55 seconds for $5 a month. Sign up using my link and receive $10 in credit: https://www.digitalocean.com/?refcode=99a5082b6de5
After a few weeks, do check your website with https://www.shodan.io and see if it has open software or is known to hackers.
Donate and make this blog better
Ask a question or recommend an article