Table of Contents
The Identity Server must have a minimal set of configurations to be able to start. If this is not present, it’s considered an error state, and the server will refuse to start.
In the distribution of the server a minimal configuration file is delivered that will be used if no other configuration is present.
In a case where the Administrator needs to completely reset the system to a factory default. The configuration database must be deleted to restore the minimal configuration.
The initial configuration can be reset without deleting all previous configuration changes. One way do do this is using the idsvr command. If the admin server is running, login to it, and reload the configuration like this:
$ idsvr --force-reload
Another way to restore the initial configuration is by deleting all the files in $IDSVR_HOME/var/cdb. After doing this, restart the admin node. (No restart of the runtime nodes is needed.) Specifically, execute the following steps to reset the system to factory default.
Force the admin node to a stopped state. This example shows how to do this with the init.d scripts:
Located the admin node, and run the following shell command:
Make sure that the file min-conf.xml and key-conf.xml still exist in the above directory.
It is possible to change values in these files. If doing so, this will be picked up when the system starts with a blank database.
The default procedure files are also located in etc/init in subdirectories corresponding to each type.
If these have been updated with more procedures these are optional to delete during a reset.
All procedures are loaded into the servers memory on a clean start.
As there is no default cryptographic material, ensure that etc/init/crypto is either empty, or contains the expected initial files.
Start the admin node again, if using the init.d scripts execute the following command:
The admin node is now started in a factory default state. All runtime nodes will detect that the configuration has been wiped, and will default to an inactive state.
It may take a while for the runtime nodes to detect that the admin node is back up. This time depends on how long the admin node has been down.