Reverse Proxy Proxmox VNC With Nginx

Reverse Proxy Proxmox VNC With Nginx

Get Social!

proxmox logo gradThe noVNC console in the Proxmox Web GUI transfers it’s data through a technology called Websockets. Websockets often work in tandem with normal HTTP traffic and therefore often use the same end point (IP and port). Proxmox uses port 8006 by default for all web traffic; this includes the Web GUI you see and a websockets stream for the VNC console.

If you don’t already have Nginx set up, see my other post on How to reverse proxy the Proxmox Web GUI.

You’ll also need one of the more recent versions of Nginx for this to work.

If you use Nginx to reverse proxy your Proxmox Web GUI already, making it websocket compatible is very easy. In fact, it’s as easy as adding three additional lines to your Nginx config file for the location tag that serves your Proxmox Web GUI.

Open up your sites-available config file for your Proxmox site with a text editor:

vi /etc/nginx/sites-available/proxmox.jamescoyle.net

Find the location tag for your site and add the following:

proxy_http_version 1.1;                                                           proxy_set_header Upgrade $http_upgrade;                                           proxy_set_header Connection "upgrade";

The resulting site should look similar to the below:

upstream proxmox {
    server 10.10.10.10;
}
 
server {
    listen 80 default_server;
    rewrite ^(.*) https://$host$1 permanent;
}
 
server {
    listen 443;
    server_name _;
    ssl on;
    ssl_certificate /etc/nginx/ssl/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/key.pem;
    proxy_redirect off;
    location / {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade"; 
        proxy_pass https://proxmox:8006;
    }
}

 


Enable Compression in Nginx

Category : How-to

Get Social!

nginx-logoEnabling web content compression is one of the simplest ways to save bandwidth and, for some users, speed up the time it takes to serve a page. All modern browsers support content compression and the CPU overhead for clients is a thing of the past.

Compressing content on your server however, can be CPU intensive and something you may have to plan for. Generally, compressing anything is a trade off between size of the content and the CPU cycles required in compressing it. With Nginx, content that has compression enabled has to be sent through a gzip algorithm to compress it before it’s sent to the client.

Some content does not lend itself to compression in this manner. such as images and zip archives. This is because this content has already been compressed and compressing further will have little or no result. In fact, certain types of content can even end up larger after compression. Due to this, we only tend to compress content such as HTML, CSS, JS, XML and other text based content.

The below steps will enable gzip compression for the entire Nginx server – that includes all server{} tags listed in the sites-enabled config.

Create a new file called compression.conf in the Nginx conf.d directory. If this directory doesn’t exist on your Nginx installation, you can add this to the bottom of nginx.conf.

vi /etc/nginx/conf.d/compression.conf

Add the below text and save and close the file.

gzip on;
gzip_http_version 1.1;
gzip_vary on;
gzip_comp_level 6;
gzip_proxied any;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xm
l+rss text/javascript application/javascript text/x-js;
gzip_buffers 16 32k;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";

I won’t detail each line in the file, but two of the interesting attributes are:

  • gzip_comp_level – this is the compression level that gzip will apply to the content, between 1 and 9 where 1 is the lowest compression and 9 is the highest. Again, this is a trade of between CPU (and therefore time to compress the content) and the resulting file size. 5 – 7 is usually considered a sensible range for this value.
  • gzip_types – this is the MIME type of content that may be compressed. As you can see, each entry here is text based with no images/ zip files listed.

Reload the Nginx config for the changes to take effect.

service nginx reload

 


Install Nginx on Debian/ Ubuntu

Category : How-to

Get Social!

nginx-logoInstalling Nginx on Debian or Ubuntu is as easy as a single apt-get command, however it does not install the latest version of Nginx. In fact, the latest stable Nginx version is 1.8 and the latest package in Debian’s standard repository is 1.2

To get the latest stable version we need to add a new source to our package manager. Before doing so, add the Nginx PGP key which is used to sign all packages. Run the below commands to download the key from Nginx.com, add it to our package manager and clean up the local downloaded file.

wget http://nginx.org/keys/nginx_signing.key
apt-key add nginx_signing.key
rm nginx_signing.key

We can now create the new source file with the Nginx repository location.

vi /etc/apt/sources.list.d/nginx.list

Add one of the following depending on your Linux distribution. You will need to change wheezy or trusty to the codename of your distribution version.

Debian

deb http://nginx.org/packages/debian/ wheezy nginx
deb-src http://nginx.org/packages/debian/ wheezy nginx

Ubuntu

deb http://nginx.org/packages/ubuntu/ trusty nginx
deb-src http://nginx.org/packages/ubuntu/ trusty nginx

 

Finally, update your local repository cache and install Nginx.

apt-get update
apt-get install nginx

Run -v on nginx and you should see something like version 1.8.0.

nginx -v
nginx version: nginx/1.8.0

 


Nginx Error “client intended to send too large body”

Category : How-to

Get Social!

nginx-logoYou may see the below error in your Nginx web server log files, and the good news is it’s easy to fix!

2014/10/26 11:35:15 [error] 15180#0: *12944 client intended to send too large body: 1049290 bytes, client: 185.1.1.14, server: example.jamescoyle.net, request: "POST upload?app,raw HTTP/1.1", host: "example.jamescoyle.net", referrer: "http://example.jamescoyle.net/"

The error is presented because a request being sent to the server contains more data than Nginx allows by default. You can increase the allowed maximum with the client_max_body_size attribute.

You can add the client_max_body_size attribute to your configuration files in multiple places to control what sites or locations the attribute affects.  For example, you can add it to your main config file to ensure than any site can upload the value you set. The below example sets a global value of 50MB for all sites.

vi /etc/nginx/nginx.conf
http {
    client_max_body_size 50M;
...
...
}

You could also add it inside the server { tags of an individual site, or even the location { tags of a specific location.

Once you have made your change remember to reload the configuration and the changes will take effect.

service nginx reload

Proxy the Proxmox Web GUI with Nginx Over HTTPS with Load Balancing

Get Social!

The Proxmox web GUI is served by Proxmox’s new event driven API server called PVE Proxy. The default settings for the Proxmox web GUI is to listen on port 8006 for incoming HTTPS connections.

The following tutorial will show you how to use Nginx to reverse proxy the PVE Proxy application to do the following:

  • Redirect HTTP requests to use the HTTPS protocol.
  • Add your own certificate to use for HTTPS.
  • Listen on the standard HTTPS port (port 443).

The following steps show how to use Nginx to reverse Proxy Proxmox’s web GUI. If you would prefer to use Apache, please see my other blog post.

The first step is to make sure you have Nginx installed on the machine, or virtual instance, that you are going to use. You can install Nginx directly on the Proxmox host however, I prefer to keep the host software as standard as possible and run all additional applications in OpenVZ containers.

Create a shell session on the machine you would like to use and use apt-get to install Nginx.

apt-get install nginx

Make sure you have an SSL certificate and key pair on your server. See my OpenSSL certificate cheat sheet for more information.

We now need to specify the configuration for Nginx. Remove the existing site configuration and create a new configuration file called proxmox-gui. You can call this file whatever you wish, but you will also need to use the same name in the below steps.

rm -f /etc/nginx/sites-enabled/default
vi /etc/nginx/sites-enabled/proxmox-gui

Add the below text to your proxmox-gui file. You will need to substitute some of the settings with your own values:

  • ssl_certificate – this should point to your SSL certificate to use for signing the SSL traffic.
  • ssl_certificate_key – is this key which matches the above certificate.
  • server – this is the IP and port of your Proxmox server. If you have installed Nginx on the same host as the Proxmox web GUI then you could use https://localhost:8006 here.
upstream proxmox {
    server 10.10.10.10:8006;
}

server {
    listen 80 default_server;
    rewrite ^(.*) https://$host$1 permanent;
}

server {
    listen 443;
    server_name _;
    ssl on;
    ssl_certificate /etc/nginx/ssl/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/key.pem;
    proxy_redirect off;
    location / {
        proxy_pass https://proxmox;
    }
}

If you have multiple Proxmox servers in a cluster, it would make sense to use load balancing in Nginx. We don’t really want to use this feature to spread the load, because usually the traffic will be very light – we want to use it so that if one node in the cluster is down, Nginx will automatically try a different node in the cluster.

To add load balancing, add your additional servers in the upstream proxmox code section. For example:

upstream proxmox {
    server 10.10.10.10:8006;
    server 10.10.10.11:8006;
    server 10.10.10.12:8006;

}

We need to link the newly created config file so that Nginx can load it.

ln -sf /etc/nginx/sites-available/proxmox-gui /etc/nginx/sites-enabled/

The last step is to restart Nginx web server to pick up the new settings.

service nginx restart

Your Proxmox web GUI should now be available on the IP address of your Nginx server on the HTTPS protocol.

 


Gitlab error “fatal: The remote end hung up unexpectedly” Again

Category : How-to

Get Social!

gitlabI previously wrote in this blog post about how to fix an error with Gitlab. The error was presented when using the  git push command with a remote repository that uses the Gitlabs HTTP protocol and not the SSH protocol.

The following error was presented in the Git client when using the git push command:

git push -u origin master
Counting objects: 556, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (539/539), done.
efrror: RPC failed; result=22, HTTP code = 413367.00 KiB/s
atal: The remote end hung up unexpectedly
Writing objects: 100% (556/556), 1.45 MiB | 367.00 KiB/s, done.
Total 556 (delta 282), reused 0 (delta 0)
fatal: The remote end hung up unexpectedly
Everything up-to-date

It seems that the issue is Nginx, Gitlab’s HTTP server, is not configured to receive large amounts of data. We need to specify the attribute client_max_body_size in Gitlab’s Nginx configuration file and specify the maximum amount of data Nginx will accept.

Open the configuration file and find the line location @gitlab.

vi /etc/nginx/sites-available/gitlab

Add the client_max_body_size attribute and specify the size value to use.

client_max_body_size 20M

The M stands for megabyte – you can also use G for gigabytes.

If the size of your git push ever exceeds the above value, you will have to either increase the size further or reduce your git commit sizes.

Your completed /etc/nginx/sites-available/gitlab file should look like the below example which has a 20MB upload limit.

upstream gitlab {
  server unix:/home/git/gitlab/tmp/sockets/gitlab.socket;
}

server {
  listen *:80 default_server;         # e.g., listen 192.168.1.1:80; In most cases *:80 is a good idea
  server_name YOUR_SERVER_FQDN;     # e.g., server_name source.example.com;
  server_tokens off;     # don't show the version number, a security best practice
  root /home/git/gitlab/public;

  # Increase this if you want to upload large attachments
  # Or if you want to accept large git objects over http
  client_max_body_size 20m;

  # individual nginx logs for this gitlab vhost
  access_log  /var/log/nginx/gitlab_access.log;
  error_log   /var/log/nginx/gitlab_error.log;

  location / {
    # serve static files from defined root folder;.
    # @gitlab is a named location for the upstream fallback, see below
    try_files $uri $uri/index.html $uri.html @gitlab;
  }

  # if a file, which is not found in the root folder is requested,
  # then the proxy pass the request to the upsteam (gitlab unicorn)
  location @gitlab {
    proxy_read_timeout 300; # Some requests take more than 30 seconds.
    proxy_connect_timeout 300; # Some requests take more than 30 seconds.
    proxy_redirect     off;

    proxy_set_header   X-Forwarded-Proto $scheme;
    proxy_set_header   Host              $http_host;
    proxy_set_header   X-Real-IP         $remote_addr;
    proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;

    proxy_pass http://gitlab;
  }

  error_page 502 /502.html;
}

 


Visit our advertisers

Search

Quick Poll

Which type of virtualisation do you use?
  • Add your answer

Visit our advertisers