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:
- Firstly, you can set the history of configuration changes to track
- 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.
