Buno's questions

I am trying to make my nginx "status" page from machine A (Ubuntu 16.04) available from machine B (Ubuntu 20.04), but I am getting error port 80: No route to host when trying to access the page.

Both machines are connected through an internal network with addresses 10.3.1.1 and 10.3.2.201.

ping works in both directions and I have setup my nginx conf file as follows:

server {
    listen 127.0.0.1;
    listen 10.3.1.1:80;
    root /home/www/public_html;
    index index.html;

    location /basic_status {
      stub_status on;
      allow 127.0.0.1;
      allow 10.3.2.201;
      allow 10.3.1.1;
      deny all;
    }
}

For some reason I'm able to access the /basic_status page on machine A from machine A, but not from machine B:

ubuntu@machine-a:~$ curl http://10.3.1.1/basic_status
Active connections: 1
server accepts handled requests
 187325 187325 2010480
Reading: 0 Writing: 1 Waiting: 0

ubuntu@machine-a:~$ curl http://127.0.0.1/basic_status
Active connections: 1
server accepts handled requests
 187326 187326 2010481
Reading: 0 Writing: 1 Waiting: 0

ubuntu@machine-b:~$ curl http://10.3.1.1/basic_status
curl: (7) Failed to connect to 10.3.1.1 port 80: No route to host

ufw is configured on machine A to accept incoming connections to port 80 from anywhere:

ubuntu@machine-a:~$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
80                         ALLOW       Anywhere
443                        ALLOW       Anywhere
80 (v6)                    ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)

At this this point I don't know what other setting could be causing this...

I have read in several places that it's good practice to mount /, /home and /var on separate partitions for a server, as a way of mitigating the risk of an unwanted app/action filling-up the disk.

In all the cloud providers in which I have created instances, though (AWS, OVH and GCP), the default available image for Ubuntu normally comes with a single / partition.

Is the "good practice" mentionned above somehow irrelevant for cloud, or is it just being ignored? As the root partition is obviously mounted when I log into the server, is there a way for me to shrink it and re-allocate empty space?

I've been researching how to secure privaye keys for SSL certificats using nginx as a webserver, but have not been able to find many satisfactory answers.

Specifically, for a client who wants to me to deploy a website under their own sub-domain, they are afraid that someone could access their sub-domain's certificate private key, and hence setup a legitimate-looking unsafe website. They have asked me to use some kind of software vault solution to secure they private key.

This article from nginx's blog as well as this one describe some solutions, but in the end they both rely on the same principle: the private key is protected by a passphrase, that we will retrieve from either a local or remote location, and this "retrieval" procedure requires a password/token.. that is stored locally.

Hence I fail to understand how the private key really gets more secure - it looks a bit like locking your frontdoor key in a keybox instead of leaving it under the mat... and then leaving the keybox key under the mat.

Am I missing something? Is there a better way to secure a private key with nginx?

I am changing the domain name of my app from old.com to new.com

My app is connected to external APIs that send data through webhooks, and I would like to redirect the webhooks sent to the old url, so that they hit the new url and get processed.

I have a tried a plain rewrite

server {
  server_name old.com;
  listen 443 ssl;
  rewrite ^       https://new.com$request_uri;

I can see this triggers a 302 redirection, but that doesn't seem to do the trick..

I tried with a proxy_pass

server {
  server_name old.com;
  listen 443 ssl;

  location /webHook {
    proxy_pass https://new.com/webHook;
  }

  rewrite ^       https://new.com$request_uri;

Same result.. I can see a 302 redirect in the logs, but the webhook never seem to hit the new URL and doesn't get processed..

Any idea on how to achieve that?

I need to scale my infrastructure and do not really understand why on my provider (OVH), dedicated server seems to be a better value than a cloud VPS instance.

For ~55€ you can get a dedicated server with 4 cores and 32 GB ram

For ~42€ you only get 4 cores and 15 GB ram on cloud instances

This makes me want to switch to dedicated rather than cloud instances, so I'm wondering if I'm missing out on something.. Are there some obvious pros for Cloud vs Dedicated? For instance, in terms of availability, would Cloud be "safer", as it doesn't rely on a single machine?

I'm running a server under Ubuntu 16.04 and am trying to find a way to manually launch all the available security upgrades when I want to. I found numerous posts about unattended-upgrades, however it doesn't seem to give me any upgrades available..

When I try to get the upgrades, I get:

ubuntu@server:~$ sudo unattended-upgrades --download-only -v -d
Allowed origins are: ['o=Ubuntu,a=xenial', 'o=Ubuntu,a=xenial-security', 'o=Ubuntu,a=xenial-security', 'o=UbuntuESM,a=xenial']
pkgs that look like they should be upgraded:
Fetched 0 B in 0s (0 B/s)
fetch.run() result: 0

Yet, if do seem to have pending security upgrades :

ubuntu@server:~$ apt-show-versions | grep upgradeable | grep security
isc-dhcp-client:amd64/xenial-security 4.3.3-5ubuntu12.9 upgradeable to 4.3.3-5ubuntu12.10
isc-dhcp-common:amd64/xenial-security 4.3.3-5ubuntu12.9 upgradeable to 4.3.3-5ubuntu12.10
libgcrypt20:amd64/xenial-security 1.6.5-2ubuntu0.3 upgradeable to 1.6.5-2ubuntu0.4
libgd3:amd64/xenial-security 2.1.1-4ubuntu0.16.04.8 upgradeable to 2.2.5-4+ubuntu16.04.1+deb.sury.org+2

etc...

The allowed origins include "xenial-security" so I don't understand why U-U finds nothing..

If you have a clue I'd be grateful...