I could use some help with NGINX .conf files

Development Web Development
1

I’m trying to get WordPress up and working on my personal dedicated server, and I’m having some trouble with NGINX.

I used this installation script GitHub - arakasi72/rtinst: seedbox installation script for Ubuntu and Debian systems in order to install everything I needed / wanted for hosting ruTorrent, and it works swimmingly.

I had no trouble buying a domain name from Namecheap. I had no trouble buying, configuring, and installing an SSL certificate from Comodo. When I type my-domain-name.tld into any web browser, everything works. It shows me the NGINX landing page. I have a nice padlock icon by my domain name.

I figured, okay… let me install WordPress next, because I’d like to make a gallery for my art and perhaps some day even sell it, and as I understand, extending WordPress with a webshop plug-in is fairly easy.

I’ve read enough to know that there’s a lot of hate for WordPress around here (and after reading a huge thread with Wendell’s explanations, it sounds like reasonable hate), however whether I decide to use WordPress, or Hugo, or whatever CMS, I think I still need to figure out / understand this issue I’m having with NGINX.

EDIT: My dedicated server is an Ubuntu 20.04.5 LTS installation. That probably shouldn’t matter, but I thought I’d mention it.

So right now, in my /etc/nginx/sites-available/ directory, I have a file called “default”.

It looks like this:

server {
        listen 80;
        listen [::]:80;
        server_name my-domain-name.tld www.my-domain-name.tld;
        root /var/www;
        index index.html index.php index.htm;

        error_page 403 = @denied;

        #Below enter IP address or block to allow, eg LAN and/or VPN blocks
        allow 10.0.0.0/8;
        allow 172.16.0.0/12;
        allow 192.168.0.0/16;
        deny all;

        location @denied {
               return 301 https://$host$request_uri;
        }
        
	location / {
		try_files $uri $uri/ =404;
	}

        location /rutorrent {
               auth_basic "Restricted";
               auth_basic_user_file /etc/nginx/.htpasswd;
               include /etc/nginx/conf.d/php;
               include /etc/nginx/conf.d/cache;
        }

        #include /etc/nginx/sites-available/dload-loc;

	location ~ /\.ht {
                deny all;
        }
}

server {
        listen 443 ssl http2 default_server;
        listen [::]:443 ssl http2 default_server;

        server_name my-domain-name.tld www.my-domain-name.tld;

        root /var/www;
        index index.html index.php index.htm;

        client_max_body_size 40m;
        
        ssl_certificate /etc/ssl/www_my_domain_name_tld_chain.crt;
        ssl_certificate_key /etc/ssl/private/www_my_domain_name_tld.key;
        ssl_session_timeout 5m;
        
        location / {
               try_files $uri $uri/ =404;
        }

        location /rutorrent {
               client_max_body_size 40m;
               auth_basic "Restricted";
               auth_basic_user_file /etc/nginx/.htpasswd;
               include /etc/nginx/conf.d/php;
               include /etc/nginx/conf.d/cache;
        }

        #include /etc/nginx/sites-available/dload-loc;

        include /etc/nginx/sites-available/webmin-loc;

        location ~ /\.ht {
                deny all;
        }
}

I decided to follow what I thought would be a simple tutorial for this: Install WordPress on Ubuntu 20.04 with Nginx, MariaDB, PHP7.4 (LEMP)

Everything was smooth sailing. Right up until Step 4.

Step 4 says make a .conf file at /etc/nginx/conf.d/example.com.conf. Okay. No problem. I did sudo nano /etc/nginx/conf.d/my-domain-name.tld.conf and then pasted this in:

server {
  listen 80;
  listen [::]:80;
  server_name www.example.com example.com;
  root /usr/share/nginx/example.com/;
  index index.php index.html index.htm index.nginx-debian.html;

  location / {
    try_files $uri $uri/ /index.php;
  }

   location ~ ^/wp-json/ {
     rewrite ^/wp-json/(.*?)$ /?rest_route=/$1 last;
   }

  location ~* /wp-sitemap.*\.xml {
    try_files $uri $uri/ /index.php$is_args$args;
  }

  error_page 404 /404.html;
  error_page 500 502 503 504 /50x.html;

  client_max_body_size 20M;

  location = /50x.html {
    root /usr/share/nginx/html;
  }

  location ~ \.php$ {
    fastcgi_pass unix:/run/php/php7.4-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
    include snippets/fastcgi-php.conf;

    # Add headers to serve security related headers
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Permitted-Cross-Domain-Policies none;
    add_header X-Frame-Options "SAMEORIGIN";
  }

  #enable gzip compression
  gzip on;
  gzip_vary on;
  gzip_min_length 1000;
  gzip_comp_level 5;
  gzip_types application/json text/css application/x-javascript application/javascript image/svg+xml;
  gzip_proxied any;

  # A long browser cache lifetime can speed up repeat visits to your page
  location ~* \.(jpg|jpeg|gif|png|webp|svg|woff|woff2|ttf|css|js|ico|xml)$ {
       access_log        off;
       log_not_found     off;
       expires           360d;
  }

  # disable access to hidden files
  location ~ /\.ht {
      access_log off;
      log_not_found off;
      deny all;
  }

}

Once I saved the .conf file, that’s when all Hell broke loose.

sudo nginx -t returned errors along the lines of:

nginx: [warn] conflicting server name "www.<domain_name.tld>" on 0.0.0.0:80, ignored
nginx: [warn] conflicting server name "<domain_name.tld>" on 0.0.0.0:80, ignored
nginx: [warn] conflicting server name "www.<domain_name.tld>" on [::]:80, ignored
nginx: [warn] conflicting server name "<domain_name.tld>" on [::]:80, ignored
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Okay, so I was able to figure out on my own that apparently NGINX sees this as configuration files for two separate servers and not for a single web server running two services - WordPress and ruTorrent.

Quick note: I changed the location of the wordpress directory from /usr/share/nginx/example.com in the /etc/nginx/conf.d/my-domain-name.tld.conf/ to /var/www/my-domain-name.tld.conf. I did change the appropriate lines in the .conf file above as well, of course.

I did remember to do the things I need to do, like sudo chown www-data:www-data /var/www/my-domain-name.tld/ -R

My questions are the following:

  1. Which file do I edit to actually make NGINX serve up WordPress such that when a user types in www.my-domain-name.tld in their web browser and presses the Enter key, they’ll be graced with my WordPress installation (after I myself can actually access it and go through the installation process)?

  2. What do I actually type, and in which file do I actually type it? Clearly I’m doing something wrong, and I’ve tried a lot of “workarounds”.

I tried putting parts of the .conf file from the LinuxBabe tutorial in the default file in /etc/nginx/sites-available/. That actually did work, eventually… I think I added a bunch of the fastcgi/php related crap from the LinuxBabe file and changed the root in the default file to var/www/wordpress. And when I typed www.my-domain-name.tld into the web browser, I was in fact greeted with the WordPress install page… however this broke ruTorrent. Which isn’t going to work.

So I need some real help understanding these NGINX conf files, I probably need help understanding the location directive, because I’m pretty sure I don’t get it, either.

Finally, if you read all this… God, Allah, Buddha, whatever you believe in, bless you. If you read all this and actually want to help, a thousand blessings upon you.

1 Like
2

Before you proceed, Wordpress is less than ideal when it comes to security so I would either look at an alternative and/or actually use a provider instead.
There’s most likely not a complete list of its history regarding security, Wordpress Wordpress : List of security vulnerabilities so it’s more or less a dayjob making sure everything is up to date and monitoring it.

If you can use Hugo or Jekyll you’re doing yourself a huge favor even if the learning curve can be a bit steep.

You might’ve also broken your package system somewhat since that “script” appears to pull in third party repos to install applications or completely disregard packaging having a quick look at the repo.

3

I appreciate that advice, and as I said in the post… I want to eventually move to something like Hugo or Jekyll, but right now, I’m trying to figure out what’s wrong with the .conf file in /etc/nginx/conf.d and the default file in /etc/nginx/sites-available.

I would be very grateful if you could provide some insight into what I’m doing wrong here, since I know I will have to configure these files for Hugo or Jekyll as well.

EDIT: Using a provider is not in the cards. I pay around $33 a month for this dedicated server. It’s a quad-core / 8-thread machine with 32GB of RAM and 24 TB of storage with 50 TB of monthly transfer. I’m not going to pay more money when I have plenty of power available to me right here.

Plus I would have to buy another domain name and another SSL certificate.

I believe I did mention this in the post; if I didn’t, my mistake.

4

Is that correctable, I wonder…?

5

I would use this guide instead. Obviously update to what is current in your repositories:

Always be weary of scripts on the internet. If you want to learn and understand how to do these things, use the scripts as a guide but don’t trust them blindly. Installing third party repositories is a big security risk and is one reason why Wordpress gets a bad reputation; people who don’t know what they are doing are following “tutorials” on the internet that have them install stuff out of tree and leaves security and caution to the wind.

Any modern distribution will have everything that you need in the official repository lists. Once you understand what you are doing, only then should you go off the beaten path.

6

I doubt that guide will help me at this point.

Through some good old-fashioned documentation reading and monkeying around, I think I’ve “figured out” NGINX location blocks, or at least I’ve figured them out to a point where I can now write one and get the functionality I want.

For instance, I discovered that in the following block:

location /rutorrent {
		auth_basic "Restricted";
		auth_basic_user_file /etc/nginx/.htpasswd;
		include /etc/nginx/conf.d/php;
		include /etc/nginx/conf.d/cache;
        }

if I add the line root /var/www;, that’s telling NGINX, "Hey, the directory /rutorrent is located there, so go look there for it.

That fixed the whole, “It breaks my ruTorrent install” issue.

But now I have a whole new fun problem.

Whenever I navigate to <my-domain-name.tld> to start the WordPress installation, WordPress downloads a file, either download in Chromium-based browsers, or <random_characters> in Firefox.

This tells me that NGINX is not executing PHP files, or rather that it isn’t passing them along to be executed, but is just serving them up instead, so now I’m trying to figure that out.

And I’ve noticed a disturbing trend that I thought was just limited to Reddit, but I see is apparently part of the Internet-at-large now…

The last time I was working heavily with these technologies - HTML, CSS, JavaScript, PHP, web servers, etc., was 20 years ago. Back when you had a problem then, you’d post your problem on a forum, people would actually look at / read what you’d posted and then dissect it and say, “Okay, here’s where it all went haywire… line 121… <blah blah blah, reason reason reason>…”

Now everyone points to a tutorial or the documentation, as if that’s actually helpful… as if someone who can figure out how to write A, AAAA, MX, TXT, etc. records, who can configure an installation script for a Linux server delivered in a rescue / recovery mode, etc., needs to be told to go read the docs.

I would say something along the lines of, “It pains me to say it…” but it doesn’t pain me one bit. I’m not seeing a whole lot of actual help these days online. I’m seeing a whole lot of, “Hey go look at these resources that you’ve probably already looked out.”

Usually when I see something like this, it stems from people replying who don’t have a full understanding of the underlying tech either. I don’t know if that’s you and diizzy or not, but so far I’m under the impression that you’ve scanned the thread, but haven’t really read the thread for understanding.

I’m not asking for people’s theories on best practices or which content management system they believe is superior to another. I’m not asking for another guide. I’m asking for detailed information on why these configurations didn’t / aren’t working. So I’ll just be blunt: so far all I’ve gotten is a bunch of useless platitudes, non-useful links, and unsolicited commentary. One of the problems I had, I fixed on my own. It looks like I’ll be fixing the second problem on my own too.

The TL;DR: If you’re not going to post information that will solve the problem, save yourself the effort of posting and me the effort of reading it. I’d rather read, “You’ll just have to figure it out on your own.”

7

I guess something like this might be helpful?

8

It was not.

As I said earlier, I don’t need a guide. I needed someone with extensive knowledge of NGINX. Turns out that person was me.

I bought and read: https://www.amazon.com/Nginx-HTTP-Server-Harness-infrastructure/dp/178862355X/

By the time I finished it, I was able to find the errors in my configuration files.

1 Like
9

Sometimes you have to brute force it. I am glad you were able to resolve it. Don’t sleep on reading guide from trusted names that deal with these things as their bread and butter though. It is good to get information from multiple sources to ensure you are on the right track. You may also learn information that the other sources gloss over or omit.

1 Like