Http service on linux

Linux HTTP Server Configuration

This article describes the installation and configuration of a HTTP server on Linux, with specific reference to the information needed for the RHCE EX300 exam.

Remember, the exams are hands-on, so it doesn’t matter which method you use to achieve the result, so long as the end product is correct.

Installation

For a minimum HTTP server installation, issue the following command.

If you want a more complete installation, you can install the «Web Server» package group.

Make sure the «/etc/hosts» file contains references for the loopback address and the hostname.

Turn on the HTTP server and make sure it starts automatically on reboot.

The HTTP server is now installed and running. The HTTP configuration files are located under the «/etc/httpd» directory, with the main configuration file being the «/etc/httpd/conf/httpd.conf» file. The default document root is «/var/www/html». Any files or directories below this point will be visible using a browser once you configure the firewall.

Changes to the «/etc/httpd/conf/httpd.conf» file have to be followed by a reload or a restart of the httpd service.

Firewall

If you are using the Linux firewall, you need to punch a hole in the firewall for port 80 (and 443 for HTTPS) to make sure the HTTP server can be accessed from the network. There are several ways to do this:

• The «Firewall Configuration» dialog from the menu (System > Administration > Firewall) or initiated from the command line by running the system-config-firewall command. On the «Trusted Services» section, scroll down the list and check the «WWW (HTTP)» option, then click the «Apply» button.
• The text-based «Firewall Configuration» utility ( system-config-firewall-tui ). This is the text-based version of the above dialog.
• Using the iptables service directly, as described here. In this case we could need the following entry.

You can read more about the Linux firewall here.

SELinux

If you are using SELinux, you will need to consider the following points.

The SELinux booleans associated with the httpd service are displayed using the getsebool command.

The setsebool command is used to set a specific boolean value.

The httpd_sys_content_t context should be assigned to all content.

You can check the current context setting on files and directories using the «ls -alZ» command.

More information on SELinux can be found here.

Virtual Hosts

Virtual Hosts allow multiple websites to be hosts by a single physical machine, with each website being apparently independent of each other. The virtual hosts can be IP-based, but are typically name-based, meaning the domain name in the URL used to access the web server determines which virtual host the request is for.

Create the following directories as locations for two virtual hosts. I’ve also created a test file in both document roots.

If you are using SELinux, make sure the directories and their contents are assigned the correct context.

Virtual hosts are defined in the «/etc/httpd/conf/httpd.conf» file. The definition of the two virtual hosts are shown below.

Reload or restart the httpd service for the changes to take effect.

Provided the DNS, or hosts file, resolves the names «mysite1.com» and «mysite2.com» to the IP address of the web server, pages under the document roots will now display for each virtual host. To test this you can alter your hosts file with the following entries.

You should now see the correct test page under each of the following URLs on the web server.

Private Directories

Using the virtual hosts we created previous, create a new directory called «private» and place a file in it.

Create a «.htpasswd» file containing a username/password, then add a second entry.

Edit the «/etc/httpd/conf/httpd.conf» file with an entry such as the following.

Reload or restart the httpd service for the changes to take effect.

You should now be prompted for a username/password when trying to access the following file.

Group Managed Content

Create a group that the users will be part of.

Add the necessary users to the group.

Change the ownership and permissions of the directories holding the group managed content.

Log in a the two users and check they can add and amend content.

The file with both users content is visible using the following URL.

Notice the umask setting, which allows read/write permission for the group. This setting can be placed in the «

/.bash_profile» file for each user.

Deploy a Basic CGI Application

Create a directory called «cgi-bin» under an existing virtual host.

Create a simple CGI application in the directory, for example a file called «helloworld.pl» with the following contents.

Change the ownership and make sure the file is executable.

Edit the «/etc/httpd/conf/httpd.conf» file, adding the following entries to the virtual host definition.

So the complete definition looks like this.

Reload or restart the httpd service for the changes to take effect.

The CGI application can now be run will the following URL.

If you prefer the «cgi-bin» directory to be placed in a different location, simply alter the «ScriptAlias» entry to reflect the changed location.

SSL Configuration (HTTPS)

HTTPS configuration is not a requirement of the RHCE exam, but it is useful to know, so I included it.

If they are not already installed, install the mod_ssl , openssl and crypto-utils packages.

The installation of the mod_ssl package creates the «/etc/httpd/conf.d/ssl.conf» configuration file, which includes references to the default self-signed localhost certificate and key. This is sufficient for testing SSL configuration. The httpd service must be restarted for the module to be loaded, but we will do that later.

The genkey command can generate a certificate request or a new self-signed certificate. For this test I created a new self-signed certificate. Remember, if you encrypt the certificate with a passphrase, you will need to enter it every time you start the HTTP server.

Move the key and certificate to the relevant directories.

Add/modify the following lines in the «/etc/httpd/conf.d/ssl.conf» file.

Notice the «SSLCACertificateFile» entry is commented out. If you are using a real certificate, you will probably need to download the intermediate bundle from the CA and reference it using this tag.

Restart the HTTP server.

Provided you have the correct firewall settings, you should now be able to access your applications using HTTPS.

Источник

How to run ASP.NET Core Web Application as a service on Linux without reverse proxy, no NGINX or Apache

Niels Swimberghe — 2/10/2020 — .NET

This article walks us through running a ASP.NET Core web application on Linux (RHEL) using systemd. Here’s what we’ll cover:

1. Running ASP.NET Core using systemd
2. Adding Systemd integration package
3. Making ASP.NET Core accessible externally (Kestrel only, no reverse proxy)
4. Serving ASP.NET Core over port 80 & 443 (Kestrel only, no reverse proxy)

The end goal is to serve ASP.NET Core directly via the built-in Kestrel webserver over port 80/443.
No reverse proxy, no NGINX and no Apache. Reverse proxies are great and still recommended but there’s enough of documentation on that already.

To learn how to run .NET Core services (non web stuff) on Linux, check out «How to run a .NET Core as a service using Systemd on Linux»

• Red Hat Enterprise Linux (or a compatible Unix based OS)
• .NET Core 3.1 installed (Get started instructions from Red Hat)
• Sudo privileges

This walkthrough should work for most .NET Core supported Linux distributions, not just RHEL.

Run ASP.NET Core using Systemd #

Let’s start by creating a new ASP.NET Core application using the web-template:

We’ll be using this application throughout the walkthrough. Let’s verify that the web application works:

Open a separate shell (leave the other shell running) and use the curl HTTP-client to send an HTTP request to the application:

If the application works, we can publish it somewhere logical such as ‘/srv/AspNetSite’:

The published result contains an executable called ‘AspNetSite’ which will run the application. Let’s verify we can also run the published application:

Make sure to return to the original directory by running ` cd

/AspNetSite `. To run services on Linux, Systemd uses ‘service unit configuration‘ files to describe how to run services. Let’s create the file ‘AspNetSite.service‘ inside our project so we can store it in source control along with our code. Add the following content to ‘AspNetSite.service’:

Make sure to update the ‘User’ to your username. Refer to the comments for an explanation of the specified options. For more information on the service unit configuration file, read the freedesktop manual page or the Red Hat documentation.

Systemd expects all configuration files to be put under ‘/etc/systemd/system/’. Copy the service configuration file to ‘/etc/systemd/system/AspNetSite.service’ and tell systemd to reload the configuration files.

Now systemd is aware of the new ‘AspNetSite’ service. Using ` systemctl start AspNetSite ` we can start the service.
Using ` systemctl status AspNetSite ` we can query the status of the service. Let’s start the service and check its status:

Due to the ` Restart=always ` option, systemd will restart our service in case it crashed. But it will not automatically start the service when the machine reboots. To enable automatic startup, use the following command:

If everything is working correctly, we should be able to curl the application via localhost:5000:

The website is now running as a systemd service. There’s a systemd-package provided by Microsoft to improve the integration with systemd. Let’s set that up next.

Add Systemd integration package #

Microsoft recently added a package to better integrate with systemd. When the integration is installed, the application will notify systemd when it’s ready and when it’s stopping. Additionally, systemd will understand the different log levels that the application logs.

Using the dotnet CLI, add the ‘Microsoft.Extensions.Hosting.Systemd’ (nuget) package:

Next, we’ll need to add one line to the ‘Program.cs’, ` .UseSystemd() `:

For demonstration purposes of the logging integration, update the ‘Program.cs’ file with the following:

Lastly, we need to update the file ‘AspNetSite.service’ to specify ‘type=Notify’:

Let’s deploy all our changes. We’ll need to publish the .NET app and stop/reload/start the systemd service:

The application logs are being captured by systemd. We can query the logs using ‘journalctl’, here are some examples:

The unit-flag (-u) allows us to filter by ‘SyslogIdentifier’ which we specified in ‘AspNetSite.service’.
We can verify that the .NET Core logging integrates correctly by using the priority-flag (-p) on ‘journalctl’. This will filter the output according the log levels below:

LogLevel	Syslog level	systemd name
Trace/Debug	7	debug
Information	6	info
Warning	4	warning
Error	3	err
Critical	2	crit

For example, the following command will only print output with log level 4 and below meaning warning, error, and critical:

Let’s first make a couple of HTTP request to the application using curl and then run the ‘journalctl’ query:

The ‘journalctl’ command should now return the different log statements we wrote 3 times.

The ‘UseSystemd’ function will not do anything when run outside of a systemd service. The implementation checks if the OS is a Unix system and whether the parent process is systemd.
If not, the systemd integration is skipped.

We now have our systemd-integration ready, but the application is still not accessible outside of the machine. Let’s make the application accessible externally.

Make ASP.NET Core accessible externally #

As demonstrated below, the application is only accessible via localhost on the machine and not via the machine’s IP-address.

Out of the box, the application is configured to listen to http://localhost:5000 & https://localhost:5001. This works great for development, but we want to expose our application to other machines in the network or even to the internet. In ASP.NET Core there are many ways to configure the URL’s. We can configure it through code, appsettings.json, environment variables, or command line arguments.
Let’s go with environment variables. Add the ‘ASPNETCORE_URLS’ environment variable to the ‘AspNetSite.service’ file:

Instead of specifying localhost or an IP-address, the asterisk (*) will act as a wildcard. The application will now listen to localhost and all IP-addresses assigned to the machine.

Let’s copy the updated configuration file and reload/restart the systemd service:

Instead of http://localhost:5000, we can now see http://[::]:5000. Now that the application is bound to the machine’s IP-address, we should be able to curl it via IP from within the machine:

Does this mean the website is accessible from outside the machine now?
Almost, Red Hat comes with a built-in firewall which will block the traffic. Using the ‘firewall-cmd’ utility, we can update the firewall configuration to allow TCP traffic over port 5000 & 5001:

Now the website will be accessible from other machines within the network.
In case you’re running this RHEL machine in the cloud, you will also have to ensure whatever security is provided by the cloud also allow TCP over port 5000 & 5001.
Once that’s done, the website should be accessible to the internet.

Serve ASP.NET Core over port 80 & 443 #

By default, Linux machines won’t allow processes to use well known ports (ports lower than 1024).
If we try to run the application using port 80 and/or 443, we’ll get a permission error:

There are many ways to work around this restriction.

Use a Reverse Proxy #

We can setup a reverse proxy to listen to port 80 & 443 and have it forward traffic to the ASP.NET Core application. This process is well documented by Microsoft:

This is a great option for many reasons, but we’re not going to do this since our goal for this walkthrough is to stick to the built-in Kestrel server exclusively.

Grant CAP_NET_BIND_SERVICE capability #

Using the following command, we can give the AspNetSite executable the ‘CAP_NET_BIND_SERVICE’ capability. This capability will allow the process to bind to well known ports.

Every time the executable is updated the ‘CAP_NET_BIND_SERVICE’ capability will be lost. We could make this command as part of a deployment script, but the systemd service unit configuration files has an option called ‘AmbientCapabilities’.
When configuring this option to ‘CAP_NET_BIND_SERVICE’, systemd will grant the capability to the service for us. Let’s update the ‘AspNetSite.service’ file to update the ports and add the capability to bind to well known ports.

For the last time, copy the ‘AspNetSite.service’ file and reload/restart the AspNetSite service.

The web application is now listening to port 80 & 443, but the built-in firewall will still block traffic coming in over those ports. Update the built-in firewall and any other network security to allow traffic over port 80 & 443:

Visiting the website over port 80 using the browser should now return «Hello World!».

Summary #

We now have a public facing ASP.NET Core application served by the built-in Kestrel web server by taking the following steps:

• deploy ASP.NET Core to RHEL under /srv/AspNetSite
• configure systemd to run the application as a service
• add systemd .NET Core integration to the application
• configure the application to listen to all IP’s and different ports using environment variables
• update the built-in firewall to allow TCP traffic over 5000, 5001, 80, and 443
• grant ‘CAP_NET_BIND_SERVICE’ capability to the service to allow the application to bind to well known ports such as 80 & 443

Niels Swimberghe

Niels Swimberghe is a Belgian Full Stack Developer solving problems and delivering value to customers using .NET technologies for back-end systems, and modern JavaScript technologies for the front-end.

Found this article useful? Follow me on Twitter, buy me a coffee, add this blog to your feed reader!

Источник