How to check configuration changes in WildFly

This article will teach you an Admin Tip to check the configuration changes that you have applied to the WildFly Model using the Command Line Interface.

Firstly, in line of principle, there are several strategies for hardening WildFly, such as enabling auditing the CLI commands. The following article will discuss this topic more in detail: How to audit WildFly commands

Then, let’s see how to check the list of configuration changes for your WildFly Server. This is a two-step procedure:

1. Firstly, you can set the history of configuration changes to track
2. Then, you will list the actual changes in your configuration in the history track

Let’s see it in practice!

Fetching configuration changes

We will track the last 10 configuration changes to our Model with the following CLI command:

/subsystem=core-management/service=configuration-changes:add(max-history=10) 

Then, let’s apply a sample change to our configuration. For example:

/subsystem=datasources/data-source=PostgrePool:write-attribute(name=user-name,value=postgres)

Now let’s fetch the list of changes:

/core-service=management/service=configuration-changes:list-changes

As you can see from the output, we can check the last configuration change in JSON format:

Using the history to check the latest commands

By using the

list-changes you can track all configuration changes from any users. On the other hand, if you just want to check your latest changes there’s a simplest option, which is the CLI history.

By default, the command line interface enables history for both commands and operation requests. This history is stored in two places: in memory and in a file on disk named “

.jboss-cli-history“. This file is automatically created in the user’s home directory and is read each time the interface launches, initializing the in-memory history with its content. This ensures that the history persists between command line sessions.

To manage your CLI history you can use the

history command. If you execute it without any arguments, it will print all the commands and operations (up to the configured maximum, which defaults to 500) from the in-memory history.

Besides, history supports three optional arguments:

• disable – will disable history expansion (but will not clear the previously recorded history);
• enabled – will re-enable history expansion (starting from the last recorded command before the history expansion was disabled);
• clear – will clear the in-memory history (but not the file one).

Finally, you can also pipe the history command with the grep command to filter through the history:

[standalone@localhost:9990 /] history | grep "postgre"
/subsystem=datasources/data-source=PostgrePool:write-attribute(name=user-name,value=postgres)

Conclusion

This article discussed some options to track configuration changes using different strategies. The the

list-changes allows you to track all configuration changes from any users. If you want to check only your local changes, then you can use the

history command for the same purpose. Found the article helpful? if so please follow us on Socials