Code, InfoSec and Server Stuff
Views are my own and not my employer's
Here is how I set NGINX to the development branch to get more frequent updates and features over the stable branch
Read the full article here: https://fearby.com/article/updating-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
Advertisement:
Aside
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
Warning
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.
Nginx Branches
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.
Nginx Updates
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
Advertisement:
Recent Nginx Changes
Here are the recent changes to Nginx: http://nginx.org/en/CHANGES
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 | 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.
Advertisement:
Updating Nginx
Normally you update Nginx bu running an update and upgrade
1 | apt-get update && apt-get upgrade |
Restart Nginx for good measure
1 | /etc/init.d/nginx restart |
Checking NGINX Version
1 2 | nginx -v nginx version: nginx/1.14.1 |
Changing your repository to the development branch
I changed ot the development branch by running
1 | sudo add-apt-repository ppa:nginx/development |
Update and upgrade Nginx
1 | apt-get update && apt-get upgrade |
Restart Nginx for good measure
1 | /etc/init.d/nginx restart |
Checking NGINX Version
1 2 | nginx -v nginx version: nginx/1.16.6 |
Removing the stable Nginx repository
Run this command to remove the stable branch of Nginx
1 | sudo add-apt-repository -r ppa:nginx/stable |
Check to see if the development branch is listed
1 2 | 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
Revision History
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.
Advertisement:
Buying a Domain
Buy a domain name from Namecheap here.
Why do I need a free Development IDE/VM
The Solution
Cloud9 ( http://www.c9.io ) combines a powerful online code editor with a full Ubuntu server in the cloud. Simply pick your configuration, develop an app, invite others in to preview and help code.
Update 2018: For the best performing VM host (UpCloud) read my guide on the awesome UpCloud VM hosts (get $25 free credit by signing up here).
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).
Installing NodeJS
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.
Development Workspace
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.
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
Tip:
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
Advertisement:
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
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.
Summary
$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.
Coupon
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
Security
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
