Extracting install_demo_configuration script to a standalone Java Tool

[DarshitChanpura]

Description:
This issue is created to track the process of extracting all the logic from the install_demo_configuration script and transferring it to a standalone Java tool.

What's Happening with the Script?
The script will serve as a wrapper to call the Java tool. This approach will ensure minimal changes to the current behavior when running the demo script. Additionally, it will allow the script to use the bundled JDK (similar to the OpenSearch process) if no JAVA_HOME is set, thereby preventing script failures. Without this wrapper, the newly created Java tool would require JAVA_HOME to be set, potentially causing issues in certain distributions (such as rpm/deb).

What Will the New Tool Look Like?
The behavior of new tool would be consistent with the script. The new tool will contain all of the current individual components, including generating certificates, updating the opensearch.yml file, and modifying the admin password in internal_users.yml, among others. These components will serve as the foundation for future enhancements, particularly focusing on addressing static secrets.

Why a Standalone Java Tool?

1. Reusability: The requirement to generate a new random password can be fulfilled using tools like passay, which is currently employed for the service-account capability. This tool can be leveraged to generate a new password for the admin user. Similarly, the existing WeakPasswordValidation framework can be used to validate the provided password to ensure it is not weak.
2. Avoiding Duplication: Currently, the logic for installing the demo configuration exists in both .sh and .bat files, leading to redundancy. Creating a Java tool will serve as a single source of truth for the demo config setup, eliminating this redundancy.

Acceptance Criteria:

• A new password is generated if not provided, and the generated password is logged in the executing terminal (stdout).
• The script should accept a new parameter environment -t to reflect that this script is going to be used in test environment. Default value is set to demo
• When the environment is set to demo (default), and a custom password is provided:
  • It must be validated to ensure it is not a weak password:
    • The password should be at least 8 characters long.
    • The password should not contain the username.
• When the environment is set to test, the password validation should be skipped.

[stephen-crawford]

[Triage] Hi @DarshitChanpura, thank you for filing this issue. This issue has all the right info to be marked triaged :)