How to configure Nginx VirtualHost on OpenBSD

To configure Nginx Virtualhost in OpenBSD

Virtual hosting is a technique used for hosting multiple sites on a single or a set of servers. It also lets the server to share its resources such as memory and process cycles. This article will help you understand the configuration of Nginx VirtualHost on OpenBSD.

If you want to know about VirtualHost configuration on FreeBSD refer the following link:

https://www.linuxhelp.com/configure-apache-virtual-host-freebsd/


To Configure Nginx VirtualHost

Before you initiate the Nginx VirtualHost configuration, check for the availability of FEMP(nginx) on your system. If not, use the following command to install it.

# /etc/rc.d/nginx check
Nginx(ok)


Once it is installed, create a directory for the VirtualHost domains as follows.

 # mkdir -p /var/www/vhost1.com
 # mkdir -p /var/www/vhost2.com 

After the directories are created, use the following command to create an index.html file for the VirtualHost domains.

# nano /var/www/vhost1.com/index.html

< html> 
< head> VIRTUAL HOST1< /head> 
< title> VHOST< /title> 
< body> This is My first virtual host....!< /body> 
< /html> 

# nano /var/www/vhost2.com/index.html

< html> 
< head> VIRTUAL HOST1< /head> 
< title>  VHOST2< /title> 
< body> This is My Second virtualhost....!!< /body> 
< /html> 

Once the files are created, configure the .conf files as follows.

Make sure you configure VirtualHost within the “ http” tag

# nano /etc/nginx/nginx.conf
.
.
.
http { 
.
.
.
#first virtualhost
server {
        listen       80 
       server_name  test.vhost1.com 
        location / {
        root /var/www/vhost1.com 
        index  index.html index.htm 
        }
           }

#second virtualhost
server {
        listen       80 
       server_name  test.vhost2.com 
        location / {
        root /var/www/vhost2.com 
        index  index.html index.htm 
        }
           }

}

Once the files are configured, add the VirtualHost domains in hosts file as follows.

# nano /etc/hosts

192.168.7.243   test.vhost1.com
192.168.7.243   test.vhost2.com

The VirtualHost is configured, restart the Nginx service for the configuration to be effective. Use the following command for the same purpose.

# /etc/rc.d/nginx restart
Nginx(ok)
Nginx(ok)

All is done now, access your VirtualHost domains through your web browser. Open it and call http://192.168.7.243 to check the Nginx service.

The Nginx service is effective. Check virtualhost1 by calling http://test.vhost1.com on the URL tab.

Also, check virtualhost2 by calling http://test.vhost2.com on the URL tab.

FAQ
Q
Does NGINX Plus include caching? Is it for static content only?
A
NGINX Plus does indeed include an extremely scalable caching engine for both static and dynamic content. Caching is supported for all proxy-modes/protocols, such as HTTP/FastCGI/uwsgi/SCGI.
Cached content is stored in a hybrid cache – hot content is stored in memory, and all content is stored on an on-disk cache that persists across software restarts and reboots.
Q
For which general use cases is NGINX more appropriate than Squid?
A
NGINX is generally deployed as a reverse proxy, not as a caching proxy (like Squid). The key advantage of NGINX is its nominal RAM and CPU usage under heavy load. Squid is best applied to cache dynamic content for applications that cannot do it themselves.
Q
How to run both apache and nginx web servers in linux?
A
Its possible to run both the Web servers. If apache is running in port 80 then configure nginx in any other port. But its highly not recommended to do so, since it may give some conflict erro
Q
How does on-the-fly reconfiguration in NGINX Plus work?
A
On-the-fly reconfiguration is used to modify load balancing parameters, and to add or remove servers from an upstream group.
Q
What kind of advanced load balancing does NGINX Plus provide on top of NGINX OSS?
A
Load balancing algorithms function better in NGINX Plus due to cross-core synchronization, multiple session persistence methods to fine-tune load balancing decisions, health checks to better identify failed servers and slow-start to reintroduce them.