Book Image

WildFly: New Features

By : Filippe C Spolti
Book Image

WildFly: New Features

By: Filippe C Spolti

Overview of this book

Table of Contents (13 chapters)
WildFly: New Features
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Index

Other basic configurations


It is quite common in tests and production environments that we need to start more than one instance on the same server. WildFly has a very simple way to quickly set it. It is possible to start up an instance with all the doors changed very fast using a very convenient way. This configuration has a set of ports defined in the standalone xml / domain.xml configuration file; these define how many doors we want to add from the default ports. For example, if you want the next HTTP port to be 8081, just assign the value 1 instead of 0. If you want the port be 8090, simply assign the value 10, and so on. Here's how to make this setup simple. As an example, I will use the standalone.xml file.

Change the following line of code to turn the configuration permanent:

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">

Or just start the WildFly server passing these configurations as a parameter, as shown in the following command:

[root@wfly_book bin]# ./standalone.sh -Djboss.socket.binding.port-offset=10

The part that should be changed is highlighted; instead of 0, we can insert any desired value that will be added to the default port. We will see the default ports shown in the following lines of command:

<socket-binding name="management-native" interface="management" port="${jboss.management.native.port:9999}"/>
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
<socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
<socket-binding name="http" port="${jboss.http.port:8080}"/>
<socket-binding name="https" port="${jboss.https.port:8443}"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>

Once you perform the following change, including setting the value 10 instead of 0. It is as if we did all the changes manually, and it would look similar to the following code:

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:10}">
<socket-binding name="management-native" interface="management" port="${jboss.management.native.port:10009}"/>
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:10000}"/>
<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:10002}"/>
<socket-binding name="ajp" port="${jboss.ajp.port:8019}"/>
<socket-binding name="http" port="${jboss.http.port:8090}"/>
<socket-binding name="https" port="${jboss.https.port:8453}"/>
<socket-binding name="txn-recovery-environment" port="4802"/>
<socket-binding name="txn-status-manager" port="4803"/>

If we want to change only a port or more than a port through parameters during startup, it is very simple. We will change the default port to 9190 for the HTTP parameter passed when starting up the instance:

[root@wfly_book bin]# ./standalone.sh -Djboss.http.port=9190

The result is as shown in the following command:

JBAS017519: Undertow HTTP listener default listening on /192.168.11.109:9190

This can also be done using the netstat command:

[root@wfly_book ~]# netstat -anp | grep java
tcp        0      0 192.168.11.109:9190         0.0.0.0:*                   LISTEN      3713/Java

We now have the HTTP protocol listening on port 9190. You can change all the ports that WildFly uses, but each port has its own specific parameter and if you want to change them, you should assign the port for the parameter. The following is a list of all ports that can be changed using parameters:

  • -Djboss.management.native.port=<desired_port>

  • -Djboss.management.http.port=<desired_port>

  • -Djboss.management.https.port=<desired_port>

  • -Djboss.ajp.port=<desired_port>

  • -Djboss.http.port=<desired_port>

  • -Djboss.https.port=<desired_port>

Thus we can use the port we want in a very practical way.

In a new installation in Linux environments, it is quite common to use the root user. And often just leaving WildFly running with the root user is a security loophole, where WildFly has the root permissions on a server that is running and therefore can perform any operation that requires root permissions, such as shutting down the computer. An example of this was Versions 4 and 5 of JBoss where it is possible to perform a number of tasks that could compromise the functioning of the server, perform deployment of malicious applications, shutdown the server, obtain physical server information, and more. Since Version 7 of JBoss, it has became more complex, because now, management consoles in the new installation are protected in two ways., The first is with the address at which the interface is listening; by default, it is always the loopback address. The second protection is that, if a user needs to access a server that is not created, the web management console is inaccessible until the user is created and user passwords are protected by encryption. As a continuation of this chapter, we will learn how to run WildFly with a user, but without many privileges in our newly-configured environment.

The first step is to define a username and create it. In this case, to facilitate the identification of the user, I decided to create a user called wildfly because we can identify which applications this user owns.

The first step is to create the runtime user on the OS:

[root@wfly_book bin]# useradd wildfly -c "WildFly Server Runtime user"

The parameter-c is a comment that helps auditors and administrators to identify the user. If you do not want to change the password of the created user, it is not strictly necessary. However, if the password is not set for the user, he/she cannot log in unless you are already logged in as the rootuser. If you want to alter this, perform the following steps:

  1. The first step is to change the password for the user using the following commands:

    [root@wfly_book bin]# passwd wildfly
    Changing password for user wildfly.
    New password: Exampl3@test
    Retype new password:
    passwd: all authentication tokens updated successfully. 
    
  2. The next step is to grant read/write permissions in the WildFly server directory installation.

It is necessary that the created user can run WildFly so that the user becomes the owner of the installation directory and its subdirectories. He/she will need to perform read/write operations in these directories. If we do not do this, the server will throw an exception during startup. as shown in the following command:

[wildfly@wfly_book bin]$ ./standalone.sh
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /opt/server/wildfly-8.0.0.CR1

  JAVA: /usr/java/jdk1.7.0_45/bin/java

  JAVA_OPTS:  -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

java.lang.IllegalArgumentException: Failed to instantiate class "org.jboss.logmanager.handlers.PeriodicRotatingFileHandler" for handler "FILE"
...
Caused by: java.io.FileNotFoundException: /opt/server/wildfly-8.0.0.CR1/standalone/log/server.log (Permission denied)
...

You can see that we have a permission error in the log file. This is because it is the first file that WildFly tries to write during startup. To solve this problem, we need to change the owner of the files as shown in the following command:

[root@wfly_book ~]# chown -R wildfly.wildfly /opt/server/wildfly-8.0.0.CR1/

As you can see in the following commands, all the files currently belong to the root file:

[wildfly@wfly_book wildfly-8.0.0.CR1]$ ls -l
total 408
drwxr-xr-x. 3 root root   4096 Dec 22 04:12 appclient
drwxr-xr-x. 5 root root   4096 Jan  7 19:12 bin
-rw-r--r--. 1 root root   2451 Dec 22 04:12 copyright.txt
drwxr-xr-x. 4 root root   4096 Dec 22 04:12 docs
drwxr-xr-x. 7 root root   4096 Jan  7 17:24 domain
-rw-r--r--. 1 root root 351490 Dec 22 04:12 jboss-modules.jar
-rw-r--r--. 1 root root  26530 Dec 22 04:12 LICENSE.txt
drwxr-xr-x. 3 root root   4096 Dec 22 04:12 modules
-rw-r--r--. 1 root root   2356 Dec 22 04:12 README.txt
drwxr-xr-x. 8 root root   4096 Jan  7 16:35 standalone
drwxr-xr-x. 2 root root   4096 Jan  3 11:59 welcome-content

After running the previous command, note that the user wildfly is now the owner of all the files, as shown in the following commands:

[wildfly@wfly_book wildfly-8.0.0.CR1]$ ls -l
total 408

At this point, we can start the server with the user wildfly with no startup problems. Let's see what happens when we issue the following command:

JBAS015874: WildFly 8.0.0.CR1 "WildFly" started in 14358ms

The server starts successfully. Note that, when we see the process, the runtime user is wildfly, as shown in the following commands:

[root@wfly_book ~]# ps aux | grep java
wildfly   4033 13.4 56.0 1594376 136876 pts/0  Sl+  01:07   0:08 /usr/java/jdk1.7.0_45/bin/java -D[Standalone] -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.head
less=true -Dorg.jboss.boot.log.file=/opt/server/wildfly-8.0.0.CR1/standalone/log/server.log -Dlogging.configuration=file:/opt/server/wildfly-8.0.0.CR1/standalone/configuration/logging.properties -jar /opt/server/wildfly-8.0.0.CR1/jboss-modules.jar -mp /opt/server/wildfly-8.0.0.CR1/modules org.jboss.as.standalone -Djboss.home.dir=/opt/server/wildfly-8.0.0.CR1 -Djboss.server.base.dir=/opt/server/wildfly-8.0.0.CR1/standalone

Nowadays, we, mainly system administrators, have certain requirements to standardize our environments for easy understanding of how they are configured and consequently maintain a default on new installations.

One way to keep everything in order is to organize the applications by the services. The installation of WildFly comes with a pre-configured script for executing the server as a service. It is within the following directory:

$JBOSS_HOME/bin/init.d

To start, you must copy the configuration file wildfly.conf, present in the same directory, to /etc/default or simply make a symbolic link. In this case, I will make a symbolic link to the file wildlfy.conf as shown in the following commands:

 [root@wfly_book init.d]# ln -s /opt/server/wildfly-8.0.0.CR1/bin/init.d/wildfly.conf /etc/default/
[root@wfly_book init.d]# ls /etc/default/
nss  useradd  wildfly.conf

I am using CentOS, which is a RedHat-like operating system, and it will also make a symlink script wildfly-init.redhat.sh for /etc/init.d as shown in the following command:

[root@wfly_book init.d]# ln -s /opt/server/wildfly-8.0.0.CR1/bin/init.d/wildfly-init-redhat.sh /etc/init.d/wildfly

Before starting the service WildFly, we must change the wildfly.conf file uncommenting the most important configurations; these configurations are shown in the following code:

JAVA_HOME=/usr/java/jdk1.7.0_45
JBOSS_USER=wildfly
JBOSS_MODE=standalone
JBOSS_CONFIG=standalone.xml

Let's try to start it now with the service command:

[root@wfly_book init.d]# service wildfly start
Starting wildfly:                                          [  OK  ]

And check the log using the following command:

JBAS015874: WildFly 8.0.0.CR1 "WildFly" started in 16362ms

And to stop the WildFly server, just run the following command:

[root@wfly_book init.d]# service wildfly stop
Stopping wildfly:                                          [  OK  ]