Node.js 17.0.1 Gatsby error - "digital envelope routines::unsupported ... ERR_OSSL_EVP_UNSUPPORTED"

I am building a Gatsby site. I upgraded Node.js to v17.0.1, and when I run a build, there is an error:

Error: digital envelope routines::unsupported

opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
library: 'digital envelope routines',
reason: 'unsupported',
code: 'ERR_OSSL_EVP_UNSUPPORTED'

If I downgrade it to v16, it works fine, and the build will be successful. How can I fix this?


This might help. Add these scripts in the package.json file.

React:

"scripts": {
    "start": "export SET NODE_OPTIONS=--openssl-legacy-provider && react-scripts start",
    "build": "export SET NODE_OPTIONS=--openssl-legacy-provider && react-scripts build"
}

or

"scripts": {
    "start": "react-scripts --openssl-legacy-provider start",
    "build": "react-scripts --openssl-legacy-provider build",
}

Vue.js:

"scripts": {
    "serve": "export NODE_OPTIONS=--openssl-legacy-provider && vue-cli-service serve",
    "build": "export NODE_OPTIONS=--openssl-legacy-provider && vue-cli-service build",
    "lint": "export NODE_OPTIONS=--openssl-legacy-provider && vue-cli-service lint"
},

or

"scripts": {
    "serve": "vue-cli-service --openssl-legacy-provider serve",
    "build": "vue-cli-service --openssl-legacy-provider build",
    "lint": "vue-cli-service --openssl-legacy-provider lint"
},


this work for me:

"scripts": {

"serve": "SET NODE_OPTIONS=--openssl-legacy-provider && vue-cli-service serve",

"build": "SET NODE_OPTIONS=--openssl-legacy-provider && vue-cli-service build",

"lint": "SET NODE_OPTIONS=--openssl-legacy-provider && vue-cli-service lint"

},

How to Create Custom Meta Boxes & Custom Fields in WordPress?

The default custom fields functionality in WordPress is to help end-users customize their websites fast and easily. However, it is limited to only text fields and thus, is not enough in most cases. In this post, we will learn how to take control of custom fields by creating our own new field types.

this

OpenSSL SSL_connect: Connection was reset in connection to github.com:443 while try to git push

fatal: unable to access 'https://github.com/XXX/XXXXX.git/': OpenSSL SSL_connect: Connection was reset in connection to github.com:443

Suddenly I'm getting above error while I try to git pull, git push, or clone the repo.


solution:

As Iranian Govenment has recently blocked OpenSSL protocol in most ISPs, we have to switch from HTTPS to SSH or use Github Desktop (This solution is just for Iranian people like me!).

I recommend installing GitHub Desktop if you can. I couldn't install it since I want to use GIT in the terminal. So, I switched from HTTPS mode to SSH mode using this command (Reference):

git config --global url."git@github.com:".insteadOf "https://github.com/"

Then I created an SSH key and added it to ssh agent using this tutorial on github.

Also, to test your ssh key, you can use (Reference):

ssh -T git@github.com

Cannot open the disk on Powering on a virtual machine

I finally found a solution for this. Stop the VM, and check the drive images…

vmkfstools -x check "hassos_ova-3.10.vmdk"

If it says “Disk needs repaired” (which mine did), then repair it.

I dont think repair implies the disk image is damagaed, it just implies that some disk config is not as it should be

> vmkfstools -x repair "hassos_ova-3.10.vmdk"
Disk was successfully repaired

Now we need to convert the disk image to VMFS, since it was created from a desktop version of VMWare and the disk image does not support snapshots…

> vmkfstools -i "hassos_ova-3.10.vmdk" "hassos_new-3.10.vmdk"

Destination disk format: VMFS zeroedthick
Cloning disk 'hassos_ova-3.10.vmdk'...
Clone: 100% done.

Now unregister the hassos_ova-3.10.vmdk disk from your hassos VM Image (do not delete the files just yet)

Attach the newly converted hassos_new-3.10.vmdk image leaving the settings as default

Fire up your VM. You may find the vm refuses to boot, but skip past this with F1

You may get a 2nd warning suggesting the disk may need partioning. Ignore this and hit ‘m’ to boot into the menu like it suggests

At this point it boots you into the ha shell prompt and after a little while home assistant should be up and running

Once you have checked everything is working, you can delete the old disk image hassos_ova-3.10.vmdk (there may be secondary images such as hassos_ova-3.10-s001.vmdk which can be deleted also)

You can now use snapshots on your HA VM, aswell as use any VM backup tools which rely on snapshot feature (such as Synology Backup For Business)

If you find it’s not working, just delete the new drive from the VM config and reattach the old vmdk, and you are back to where you started.

https://community.home-assistant.io/t/failure-to-start-hassos-on-vmware-esxi-with-object-type-requires-hosted-i-o-error/274469/3

https://kb.vmware.com/s/article/1038189

How To Set Up Password Authentication with Nginx on Ubuntu

Introduction

When setting up a web server, there are often sections of the site that you wish to restrict access to. Web applications often provide their own authentication and authorization methods, but the web server itself can be used to restrict access if these are inadequate or unavailable.

In this guide, we’ll demonstrate how to password protect assets on an Nginx web server running on Ubuntu 14.04.

Prerequisites

To get started, you will need access to an Ubuntu 14.04 server environment. You will need a non-root user with sudo privileges in order to perform administrative tasks. To learn how to create such a user, follow our Ubuntu 14.04 initial server setup guide.

If you haven’t done so already, install Nginx on your machine by typing:

 
  1. sudo apt-get update
  2. sudo apt-get install nginx

Copy

Create the Password File

To start out, we need to create the file that will hold our username and password combinations. You can do this by using the OpenSSL utilities that may already be available on your server. Alternatively, you can use the purpose-made htpasswd utility included in the apache2-utils package (Nginx password files use the same format as Apache). Choose the method below that you like best.

Create the Password File Using the OpenSSL Utilities

If you have OpenSSL installed on your server, you can create a password file with no additional packages. We will create a hidden file called .htpasswd in the /etc/nginx configuration directory to store our username and password combinations.

You can add a username to the file using this command. We are using sammy as our username, but you can use whatever name you’d like:

 
  1. sudo sh -c "echo -n 'sammy:' >> /etc/nginx/.htpasswd"

Copy

Next, add an encrypted password entry for the username by typing:

 
  1. sudo sh -c "openssl passwd -apr1 >> /etc/nginx/.htpasswd"

Copy

You can repeat this process for additional usernames. You can see how the usernames and encrypted passwords are stored within the file by typing:

 
  1. cat /etc/nginx/.htpasswd

Copy

 

Output

sammy:$apr1$wI1/T0nB$jEKuTJHkTOOWkopnXqC1d1

Create the Password File Using Apache Utilities

While OpenSSL can encrypt passwords for Nginx authentication, many users find it easier to use a purpose-built utility. The htpasswd utility, found in the apache2-utils package, serves this function well.

Install the apache2-utils package on your server by typing:

 
  1. sudo apt-get update
  2. sudo apt-get install apache2-utils

Copy

Now, you have access to the htpasswd command. We can use this to create a password file that Nginx can use to authenticate users. We will create a hidden file for this purpose called .htpasswd within our /etc/nginx configuration directory.

The first time we use this utility, we need to add the -c option to create the specified file. We specify a username (sammy in this example) at the end of the command to create a new entry within the file:

 
  1. sudo htpasswd -c /etc/nginx/.htpasswd sammy

Copy

You will be asked to supply and confirm a password for the user.

Leave out the -c argument for any additional users you wish to add:

 
  1. sudo htpasswd /etc/nginx/.htpasswd another_user

Copy

If we view the contents of the file, we can see the username and the encrypted password for each record:

 
  1. cat /etc/nginx/.htpasswd

Copy

 

Output

sammy:$apr1$lzxsIfXG$tmCvCfb49vpPFwKGVsuYz. another_user:$apr1$p1E9MeAf$kiAhneUwr.MhAE2kKGYHK.

Configure Nginx Password Authentication

Now that we have a file with our users and passwords in a format that Nginx can read, we need to configure Nginx to check this file before serving our protected content.

Begin by opening up the server block configuration file that you wish to add a restriction to. For our example, we’ll be using the default server block file installed through Ubuntu’s Nginx package:

 
  1. sudo nano /etc/nginx/sites-enabled/default

Copy

Inside, with the comments stripped, the file should look similar to this:

/etc/nginx/sites-enabled/default

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;

    root /usr/share/nginx/html;
    index index.html index.htm;

    server_name localhost;

    location / {
        try_files $uri $uri/ =404;
    }
}

To set up authentication, you need to decide on the context to restrict. Among other choices, Nginx allows you to set restrictions on the server level or inside a specific location. In our example, we’ll restrict the entire document root with a location block, but you can modify this listing to only target a specific directory within the web space:

Within this location block, use the auth_basic directive to turn on authentication and to choose a realm name to be displayed to the user when prompting for credentials. We will use the auth_basic_user_file directive to point Nginx to the password file we created:

/etc/nginx/sites-enabled/default

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;

    root /usr/share/nginx/html;
    index index.html index.htm;

    server_name localhost;

    location / {
        try_files $uri $uri/ =404;
        auth_basic "Restricted Content";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
}

Save and close the file when you are finished. Restart Nginx to implement your password policy:

 
  1. sudo service nginx restart

Copy

The directory you specified should now be password protected.

Confirm the Password Authentication

To confirm that your content is protected, try to access your restricted content in a web browser. You should be presented with a username and password prompt that looks like this:

Nginx password prompt

If you enter the correct credentials, you will be allowed to access the content. If you enter the wrong credentials or hit “Cancel”, you will see the “Authorization Required” error page:

Nginx unauthorized error

 

link

آموزش افزایش سایز دیسک اوبونتو سرور نصب شده روی VM

زمان مطالعه: 3 دقیقه

با سلام و درود، همیشه سعی کنید همون ابتدا که میخواید به ماشین برای سرور خودتون بسازید حجم رو به درستی پیش بینی کنید که در اواسط مجبور به افزایش دادن فضای دیسک اوبونتوی نصب شده روی VMنشوید، در هر صورت امکان داره مجبور به افزایش حجم دیسک بشید که در ادامه آموزشش رو براتون دادم.

ابتدا باید فضای دیسک را از سمت VmWare افزایش دهید، فقط توجه داشته باشید در صورت افزایش فضای دیسک در VM، دیسک شما به شکل زیر خواهد شد:

۱- افزایش حجم دیسک در VM

۱- برای این کار ابتدا ماشین خود را که قصد افزایش حجم دیسک آن را دارید، خاموش کنید.

۲- حال وارد setting ماشین خود شده و دیسک آن را به مقدار مورد نظر خودتان افزایش دهید.

نکته: اگر قسمت هارد دیسک غیر فعال (خاکستری بود)، مطمین شوید هیچ snapshot روی ماشین مورد نظر نداشته باشید و IDE روی ماشین فعال نباشد.

۳- مجدد ماشین خود را start کنید.

۴- به ماشین خودتان از طریق کنسول و root لاگین کنید.

۲- افزایش فضای دیسک سمت اوبونتو سرور

۱- ابتدا با دستور زیر فضای دیسک را بررسی کنید:

 

 

1

fdisk -l

با توجه به تصویر فوق مشاهده می کنید که ماشین من ۳۰ گیگ داشت که ۲۲۰ گیگ جدید رو قصد دارم بهش اضافه کنم. که در کل میشه ۲۵۰ گیگ

۲- حال دستور زیر را اجرا کنید:

 

 

1

fdisk /dev/sda

حال n را برای ساخت پارتیشن جدید بزنید و سپس شماره ی پارتیشن که برای من ۴ می شد (sda4) و در انتها w برای write کردن تغییرات (امکان داره از شما چند تا گزینه دیگه مانند start blockو غیره هم بپرسته که حالت پیشفرض را انتخاب کنید)

نکته : اگر Hex code (type L to list codes): را پرسید، 8e را وارد کنید.

 

1

Hex code (type L to list codes): 8e

۳- سیستم را ریبوت کنید.

۴- حال دستور pvcreate را بزنید (با این دستور فیزیکال وولیوم را می سازید):

 

 

1

 sudo pvcreate /dev/sda4

2

3

  output:

4

    Physical volume "/dev/sda4" successfully created.

۵- برای بدست آوردن نام volume group فعلی، دستور زیر را بزنید:

 

 

1

vgdisplay

۶- برای توسعه دادن volume groupاز دستور زیر استفاده کنید (sda4 را به آن اضافه کنید):

 

 

1

sudo vgextend ubuntu-vg /dev/sda4

۷- حال برای بدست آوردن مسیر lv از دستور زیر استفاده کنید (Logical Volume path):

 

 

1

sudo lvdisplay

۸- حال برای توسعه دادن Logical Volume و افوزدن sda4 به آن، از دستور زیر استفاده کنید:

 

 

1

sudo lvextend /dev/ubuntu-vg/ubuntu-lv /dev/sda4

2

3

output:

4

    Size of logical volume ubuntu-vg/ubuntu-lv changed from 20.00 GiB (5120 extents) to <240.00 GiB (61439 extents).

5

  Logical volume ubuntu-vg/ubuntu-lv successfully resized.

6

۹- از دستور زیر برای بروزرسانی Logical Volumeاستفاده کنید:

 

 

1

sudo resize2fs /dev/ubuntu-vg/ubuntu-lv

۱۰ – در انتهای از دستور df -hبرای مشاهده تغییرات اعمال شده استفاده کنید:

همانطور که مشاهده می کنید، از ۳۰ گیگ به ۲۵۰ گیگ رسیدیم و پایان آموزش.

مرجع ۱ – مرجع۲ – مرجع ۳

 

مرجع اصلی

Google Chrome — How to Inspect Websites on Mobile Devices

https://medium.com/nerd-for-tech/google-chrome-how-to-inspect-websites-on-mobile-devices-804677f863ce

How to Get Let's Encrypt SSL on Ubuntu 20.04

https://serverspace.io/support/help/how-to-get-lets-encrypt-ssl-on-ubuntu/


 

SSL/TLS encryption is an integral part of the network infrastructure. Any web and mail server allows you to enable data encryption. In this article, we will look at the process of obtaining a free SSL certificate Let's Encrypt.

Cloud ServersIntel Xeon Gold 6254 3.1 GHz CPU, SLA 99,9%, 100 Mbps channelfrom4 EUR/monthTRY

As initial conditions, you must have a domain name. Its DNS A-record must contain the public address of your server. If the firewall is enabled, open access for HTTP and HTTPS traffic.

sudo ufw allow 80
sudo ufw allow 443

Step 1 – Installing the "Let's Encrypt" package

The process of installing the "Let's Encrypt" package with all its dependencies is extremely simple. To do this, enter the command:

sudo apt install letsencrypt

Along with the "Let's Encrypt" package, this command also installs the "certbot.timer" utility for automatic certificate renewal. It checks the validity of SSL certificates in the system twice a day and extends those that expire in the next 30 days. To make sure that it is running, enter:

sudo systemctl status certbot.timer
There are different configurations and conditions for obtaining a certificate. Let's look at some of them.

Step 2 – Standalone server for getting the "Let's Encrypt" SSL certificate

The easiest way to get an ssl certificate is to use a standalone option in Certbot. Replace domain-name.com with your domain name, run the command, and follow the instructions:

sudo certbot certonly --standalone --agree-tos --preferred-challenges http -d domain-name.com

The certonly option means that the certificate will only be obtained without installation on any web server, standalone allows you to start your own web server for authentication, agree-tos means acceptance of the ACME server subscription agreement, which is a prerequisite, and preferred-challenges http means performing authorization using HTTP.

Step 3 – Automatic installation of the SSL certificate on nginx and Apache web servers

Certbot can automatically install the certificate on nginx and Apache web servers. To do this, you need to install an additional package and choose the appropriate one for your web server.

apt install python3-certbot-nginx
apt install python3-certbot-apache

Run this command for nginx:

sudo certbot --nginx --agree-tos --preferred-challenges http -d domain-name.com

Or this for Apache:

sudo certbot --apache --agree-tos --preferred-challenges http -d domain-name.com

Follow the instructions and Certbot will install an SSL certificate for you.

Step 4 – "Let's Encrypt" Wildcard SSL certificate

To create a wildcard certificate, the only possible challenge method is DNS. In the d parameter, you must specify both the bare domain and wildcard.

sudo certbot certonly --manual --agree-tos --preferred-challenges dns -d domain-name.com -d *.domain-name.com

After that, place the specified TXT record on your DNS server and click continue.

If everything is well, you will see the path where your new wildcard certificate is stored and some other information.

Update: Using Free Let’s Encrypt SSL/TLS Certificates with NGINX

Editor – The blog post detailing the original procedure for using Let’s Encrypt with NGINX (from February 2016) redirects here. The instructions in that post are deprecated.

This post has been updated to eliminate reliance on certbot‑auto, which the Electronic Frontier Federation (EFF) deprecated in Certbot 1.10.0 for Debian and Ubuntu and in Cerbot 1.11.0 for all other operating systems. For additional details and alternate installation methods, see this post from the EFF.

Also see our blog post from nginx.conf 2015, in which Peter Eckersley and Yan Zhu of the Electronic Frontier Foundation introduce the then‑new Let’s Encrypt certificate authority.

It’s well known that SSL/TLS encryption of your website leads to higher search rankings and better security for your users. However, there are a number of barriers that have prevented website owners from adopting SSL.

Two of the biggest barriers have been the cost and the manual processes involved in getting a certificate. But now, with Let’s Encrypt, they are no longer a concern. Let’s Encrypt makes SSL/TLS encryption freely available to everyone.

Let’s Encrypt is a free, automated, and open certificate authority (CA). Yes, that’s right: SSL/TLS certificates for free. Certificates issued by Let’s Encrypt are trusted by most browsers today, including older browsers such as Internet Explorer on Windows XP SP3. In addition, Let’s Encrypt fully automates both issuing and renewing of certificates.

In this blog post, we cover how to use the Let’s Encrypt client to generate certificates and how to automatically configure NGINX Open Source and NGINX Plus to use them.

How Let’s Encrypt Works

Before issuing a certificate, Let’s Encrypt validates ownership of your domain. The Let’s Encrypt client, running on your host, creates a temporary file (a token) with the required information in it. The Let’s Encrypt validation server then makes an HTTP request to retrieve the file and validates the token, which verifies that the DNS record for your domain resolves to the server running the Let’s Encrypt client.

Prerequisites

Before starting with Let’s Encrypt, you need to:

  • Have NGINX or NGINX Plus installed.
  • Own or control the registered domain name for the certificate. If you don’t have a registered domain name, you can use a domain name registrar, such as GoDaddy or dnsexit.
  • Create a DNS record that associates your domain name and your server’s public IP address.

Now you can easily set up Let’s Encrypt with NGINX Open Source or NGINX Plus (for ease of reading, from now on we’ll refer simply to NGINX).

Note: We tested the procedure outlined in this blog post on Ubuntu 16.04 (Xenial).

1. Download the Let’s Encrypt Client

First, download the Let’s Encrypt client, certbot.

As mentioned just above, we tested the instructions on Ubuntu 16.04, and these are the appropriate commands on that platform:

$ apt-get update
$ sudo apt-get install certbot
$ apt-get install python-certbot-nginx

With Ubuntu 18.04 and later, substitute the Python 3 version:

$ apt-get update
$ sudo apt-get install certbot
$ apt-get install python3-certbot-nginx

 

2. Set Up NGINX

certbot can automatically configure NGINX for SSL/TLS. It looks for and modifies the server block in your NGINX configuration that contains a server_name directive with the domain name you’re requesting a certificate for. In our example, the domain is www.example.com.

  1. Assuming you’re starting with a fresh NGINX install, use a text editor to create a file in the /etc/nginx/conf.d directory named domain‑name.conf (so in our example, www.example.com.conf).

  2. Specify your domain name (and variants, if any) with the server_name directive:

    server {
        listen 80 default_server;
        listen [::]:80 default_server;
        root /var/www/html;
        server_name example.com www.example.com;
    }
  3. Save the file, then run this command to verify the syntax of your configuration and restart NGINX:

    $ nginx -t && nginx -s reload

3. Obtain the SSL/TLS Certificate

The NGINX plug‑in for certbot takes care of reconfiguring NGINX and reloading its configuration whenever necessary.

When certificate generation completes, NGINX reloads with the new settings. certbot generates a message indicating that certificate generation was successful and specifying the location of the certificate on your server.

Congratulations! You have successfully enabled https://example.com and https://www.example.com 

-------------------------------------------------------------------------------------
IMPORTANT NOTES: 

Congratulations! Your certificate and chain have been saved at: 
/etc/letsencrypt/live/example.com/fullchain.pem 
Your key file has been saved at: 
/etc/letsencrypt/live/example.com//privkey.pem
Your cert will expire on 2017-12-12.

Note: Let’s Encrypt certificates expire after 90 days (on 2017-12-12 in the example). For information about automatically renenwing certificates, see Automatic Renewal of Let’s Encrypt Certificates below.

  1. Run the following command to generate certificates with the NGINX plug‑in:

    $ sudo certbot --nginx -d example.com -d www.example.com
  2. Respond to prompts from certbot to configure your HTTPS settings, which involves entering your email address and agreeing to the Let’s Encrypt terms of service.

If you look at domain‑name.conf, you see that certbot has modified it:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    root /var/www/html;
    server_name  example.com www.example.com;

    listen 443 ssl; # managed by Certbot

    # RSA certificate
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot

    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot

    # Redirect non-https traffic to https
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    } # managed by Certbot
}

4. Automatically Renew Let’s Encrypt Certificates

Let’s Encrypt certificates expire after 90 days. We encourage you to renew your certificates automatically. Here we add a cron job to an existing crontab file to do this.

Summary

We’ve installed the Let’s Encrypt agent to generate SSL/TLS certificates for a registered domain name. We’ve configured NGINX to use the certificates and set up automatic certificate renewals. With Let’s Encrypt certificates for NGINX and NGINX Plus, you can have a simple, secure website up and running within minutes.

To try out Let’s Encrypt with NGINX Plus yourself, start your free 30-day trial today or contact us to discuss your use cases.

  1. Open the crontab file.

    $ crontab -e
  2. Add the certbot command to run daily. In this example, we run the command every day at noon. The command checks to see if the certificate on the server will expire within the next 30 days, and renews it if so. The --quiet directive tells certbot not to generate output.

    0 12 * * * /usr/bin/certbot renew --quiet
  3. Save and close the file. All installed certificates will be automatically renewed and reloaded.

How to Configure Nginx to serve Multiple Websites on a Single VPS

Introduction

This article details how to configure Virtual Hosting for Nginx. If you are looking for a guide for Apache, click here.

There are several reasons you may want to host multiple websites on a single server. If you are using a dedicated server / VPS and want to host multiple applications on a separate domain and a single server then you will need to host multiple websites on a single server. You can achieve this with Apache / Nginx virtual hosting. Virtual hosting allows you to use a single VPS to host all your domains. So hosting multiple websites on a single VPS server using Virtual hosting is the best solution for you to reduce the hosting cost.

There is, in theory, no limit to the number of sites that you can host on your VPS with Apache or Nginx. But, make sure that your server has enough disk space, CPU and RAM.

In this tutorial, we will learn how to set up multiple websites on an Ubuntu VPS with Nginx.

Webdock does not recommend you use our servers for shared hosting as it can cause a range of issues and stops you from using some of our management tools, namely our easy Let's Encrypt / Certbot management for SSL Certificates and Wordpress management. Click here to read why we think you should really use a single VPS for each website / app.

Please note: Doing these actions may bring down your server. Do not do this on a live site without knowing the potential consequences.

Prerequisites

  • A fresh Webdock cloud Ubuntu instance with LEMP installed.
  • Two valid domain names are pointed with your VPS IP address. In this tutorial, we will use web1.webdock.io and web2.webdock.io.
  • You have shell (SSH) access to your VPS.

Note : You can refer the Webdock DNS Guide to manage the DNS records.

Configure Nginx to Host Multiple Websites

In this section, we will show you how to host two websites named web1.webdock.io and web2.webdock.io on a single Ubuntu VPS with Nginx webserver.

Create Directory Structure

Before starting, make sure LEMP stack is installed on your VPS. You can check the Nginx server status with the following command:

systemctl status nginx

Best method to host multiple websites is to create a separate document root directory and configuration file for each website. So, you will need to create a directory structure for both websites inside Nginx web root:

To do so, run the following command for each website:

mkdir /var/www/html/web1.webdock.io
mkdir /var/www/html/web2.webdock.io

Next, you will need to create sample website content for each website:

First, create a index.html file for web1.webdock.io website:

nano /var/www/html/web1.webdock.io/index.html

Add the following html markup which will be served when you connect to the site:

web1.webdock.io

Welcome to the web1.webdock.io with Nginx webserver.

Save and close the file.

Next, create a index.html file for web2.webdock.io website:

nano /var/www/html/web2.webdock.io/index.html

Add the following html markup which will be served when you connect to the site:

web2.webdock.io

Welcome to the web2.webdock.io with Nginx webserver.

Save and close the file. Then, change the ownership of both website directories to www-data:

chown -R www-data:www-data /var/www/html/web1.webdock.io
chown -R www-data:www-data /var/www/html/web2.webdock.io

Create Virtual Configuration

Next, you will need to create a virtual host configuration file for each website that indicate how the Nginx web server will respond to various domain requests.

First, create a virtual host configuration file for the web1.webdock.io website:

nano /etc/nginx/sites-available/web1.webdock.io.conf

Add the following lines:

server {
        listen 80;
        listen [::]:80;
        root /var/www/html/web1.webdock.io;
        index index.html index.htm;
        server_name web1.webdock.io;

   location / {
       try_files $uri $uri/ =404;
   }

}

Save and close the file. Then, create a virtual host configuration file for the web2.webdock.io website:

nano /etc/nginx/sites-available/web2.webdock.io.conf

Add the following lines:

server {
        listen 80;
        listen [::]:80;
        root /var/www/html/web2.webdock.io;
        index index.html index.htm;
        server_name web2.webdock.io;

   location / {
       try_files $uri $uri/ =404;
   }

}

Save and close the file. Then, enable each virtual host with the following command:

ln -s /etc/nginx/sites-available/web1.webdock.io.conf /etc/nginx/sites-enabled/
ln -s /etc/nginx/sites-available/web2.webdock.io.conf /etc/nginx/sites-enabled/

Next, check Nginx for any syntax error with the following command:

nginx -t

If everything goes fine, you should get the following output:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Finally, restart the Nginx service to apply the configuration changes:

systemctl restart nginx

Test Your Websites

Now, open your web browser and type the URL http://web1.webdock.io and http://web2.webdock.io. You should see both websites with the content we have created earlier:

web1.webdock.io

page1.png

web2.webdock.io

page2.png