Linux: Spring Boot as a service on port 80

Well, that’s a mouth full. This blog shows how to run your Spring Boot application on port 80 when your linux server starts. We are going to use Ubuntu or Linux Mint for this, and we’re going to assume that Java is installed.

Setup Spring Boot

The first thing we need to do is tell Maven to make our Spring Boot application runnable. We’ll configure the spring-boot-maven-plugin to make the jar that’s going to be built executable.

	<build>
		<plugins>
			<plugin>
				<groupId>org.springframework.boot</groupId>
				<artifactId>spring-boot-maven-plugin</artifactId>
				<configuration>
					<executable>
						true
					</executable>
				</configuration>
			</plugin>
		</plugins>
	</build>

By default Spring Boot runs on port 8080. There’s no need to change that here, we’ll deal with that later. But if you want, you could start the application on a different port by configuring it in application.properties

server.port=8079

Run Application as a Service

Set permissions

The first thing we need to do is to copy the application to its final destination, and create a user to run the app. By creating a separate user for this application, we limit the damage that can be done in case there is a security breach. I’m going to call the application “website” and I’m going to place it under /var/website, to make things easy. Once the application is in its place, change directory to /var/website, create a new user and transfer ownership to the new user. We’re going to allow the newly created user to read and execute the file, but not to write to the file. This, again, limits the damage that can be done when there’s a security breach.

sudo useradd website
sudo passwd website
sudo chown website:website website.jar
sudo chmod 500 website.jar

Setup systemd service

To manage starting and stopping our application, we’re going to turn it into a service maintained by systemd. We need to tell systemd how to run our service by creating a configuration file.

create /etc/systemd/system/website.service

[Unit]
Description=My spring-boot application

Wants=network.target
After=syslog.target

[Service]
User=website
Type=simple
ExecStart=/var/website/website.jar
Restart=on-failure
RestartSec=60
KillMode=mixed

[Install]
WantedBy=multi-user.target

This is what the options mean:
Description: A text description of what the service is for.
Wants: The services that should, but are not required to, be started before this service.
After: The services that should be started (if they are not already running) after this service has been started.
User: The user that should be used to start this service.
Type: This indicates the way the service is started. We’ll set it to simple.
ExecStart: The command with parameters that needs to be executed to start this service.
Restart: When the service should be restarted.
RestartSec: If the service needs to be restarted, how many seconds systemd should wait.
KillMode: How the process will be stopped by systemd. We’ll set it to mixed, which sends a SIGTERM signal to our service which allows the service to shut down itself.
WantedBy: We want our service to be started when the system is up and running, and accepting connections from users.

For a list of options, look here.
KillMode is described here.
For more info on WantedBy, see this.

For the security reasons mentioned above, we’ll change the permissions of this file:

sudo chmod 640 /etc/systemd/system/website.service

Enable service to start on boot

The next thing we want to do is to indicate that this service should be started when the server is starting.

sudo systemctl enable website

Setup nginx

Now we have our application installed as a service, and it’s started when the server starts up. But the application is running on port 8079, which is not what we want. Linux only allows the root user to open TCP ports below 1000. To fix this, we’re going to use nginx to forward port 80 to our application.

create /etc/nginx/sites-enabled/website.conf with the following content:

server {
        listen  80;
        server_name     _;
        location /  {
            proxy_pass          http://localhost:8079/;
            proxy_redirect      off;

            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        }
}

This tells nginx to listen to port 80, for incoming connections on any hostname, and forward it to our application.

Distributed Websearch

When it comes to searching the web, the first thing that comes to mind is Google. Or Bing. Or Yahoo. Sure, it’s easy, fast, and sort of reliable. However, there are a few problems with these kinds of services.

First of all, there’s the filter bubble. These search engines (and social networks) will present results that are specifically tailored for you. On the one hand, this is a good thing, because you’ll probably find what you’re looking for faster. However, you’ll never find information that COULD be relevant, but is filtered out for you. Your world view is being limited by this filter bubble.

You can work around this by using “anonymous” search engines, such as DuckDuckGo or Startpage. These search engines don’t store your personal data, and therefore can not create a filter bubble for you. As for Startpage, that search engine will act as a proxy between you and Google. You will usually get high quality results to your search query.

Another problem is “The Right To Be Forgotten”. The European court ruled that Google needs to provide the option to delete certain search results from its index. When you’ve had problems, which have been resolved, you shouldn’t be judged on the basis of those past problems. However, once information is on the Internet, it’s very hard to remove. The toothpaste is out of the tube, the genie out of the bottle. You’ll never get it back in. Google provides links to this information, it does not provide the information itself. Removing the links is not the same as removing the information. We have seen the same misunderstanding in the case of The Pirate Bay.

YaCy

Since a couple of years, there is YaCy. YaCy is a distributed search engine, that ensures TRUE anonimity, and is impossible to take down. You need to install a piece of software on your computer, browse to the local webserver (probably http://localhost:8090/), and start searching. At this moment, there are 1.7 billion documents in the public network. In contrast, the web is estimated to contain 15 to 55 billion documents.

There are a couple of other interesting features in YaCy, such as creating a search engine for one specific topic, or a search engine for your local intranet. Give it a try.