deb - Listen to DISABLE_INSTALL_DEMO_CONFIG

[indykoning]

Description

This PR allows users installing the package on debian to request no demo config. Taken from the docker install

Issues Resolved

• Request: Make RPM Installation of Demo Configuration Optional  security#4199

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[peterzhuamazon]

Adding @DarshitChanpura @derek-ho I remember we discussed this before but at the time response it we need to have it installed by default.

Thanks.

[inflatador]

Hello, this is Brian with the Wikimedia Foundation. I was wondering if anyone had a chance to look at this yet? Our organization requires us to build our own Docker images using Debian packages.

Since the package requires a password, we're currently hard-coding it in our Docker build files.

While this is safe enough (the datadir never gets copied to the image), it looks bad enough that I've had to explain myself a few times. If we could get this merged, I think it would simplify a lot of similar workflows (such as installing via config management).

[krisfreedain]

@peterzhuamazon @gaiksaya @rishabh6788 @zelinh @prudhvigodithi @Divyaasm @tianleh -- can you look at @inflatador 's input? thanks

[peterzhuamazon]

As previously stated, the request to mandate demo installation with specific password was requested by the security team back in 2.12.0.
This change required the inputs from @DarshitChanpura @derek-ho who was working on the password requirement back then.

Thanks.

[bugfood]

Additional bugs about this which I have found are:
opensearch-project/security#4199 (already mentioned above)
opensearch-project/security#4344
opensearch-project/security#4965

My position on this is that either the demo configuration should not be created by default, or it should default to a random password (generated on demand).

For example, the Debian package for bacula generates random passwords:
https://salsa.debian.org/bacula-team/bacula/-/blob/master/debian/additions/common-functions.dpkg#L6-L46

Either way, package installation should succeed without requiring the user to specify any environment variables.

Imagine if using an environment variable this way were standard--installing packages would be utter chaos. For example:

sudo env MARIADB_PASSWD=baz apt install mariadb-server
sudo env BACULA_DIRPASSWD=foo BACULA_DIRMPASSWD=bar ... apt install bacula-director
sudo env POSTGRES_PASSWD=qux apt install postgres

Admins and configuration management systems would need to know and support all that, and installation would still be doomed if another package pulled in any such package as a dependency.

The opensearch situation is worse on Debian than it is on RHEL (at least as I tested on AlmaLinux 8).

• Debian considers post-install failure fatal, so the package ends up with a half-configured status, and the failure results the package manager returning a non-zero exit status (failure).
• RHEL reports post-install failures as a warning; the post-install script exits early, leaving later steps unfinished, but the package manager returns a zero exit status (ok).

At least with RHEL, for better or for worse, tolerating the failure lets configuration management (or an admin) proceed onward and properly configure opensearch.

[zaeemarshad]

Chiming in with my own 2 cents here - we use Puppet to setup Debian based Opensearch clusters. The hardcoded demo configuration means that the puppet manifest is littered with execs like remove_demo_users, remove_demo_configs etc. The original proposal is a decent one which will allow the users to control how their packages should be installed.