Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to build images with Microsoft SQL client packages - cannot pass environment variables or respond to prompts #3940

Open
richm opened this issue Feb 9, 2024 · 4 comments

Comments

@richm
Copy link

richm commented Feb 9, 2024

Describe the bug
Some of the Microsoft SQL client packages require the user to accept the EULA before or during installation, either by setting an environment variable (ACCEPT_EULA=y), or by the package interactively prompting the user on the terminal. For example:

https://packages.microsoft.com/rhel/9/prod/Packages/m/mssql-tools-17.10.1.1-1.x86_64.rpm

rpm -qp --scripts mssql-tools-17.10.1.1-1.x86_64.rpm

preinstall scriptlet (using /bin/sh):
check_eula_acceptance()
{
	if [ "$ACCEPT_EULA" != "y" ] && [ "$ACCEPT_EULA" != "Y" ]; then
    	exec 2>/dev/tty 1>&2 </dev/tty
…

The problem is that the image builder does not have a way to pass such environment variables through to the package manager, or deal with such interactive prompts.

Environment

  • OS version (/etc/os-release and /etc/redhat-release): any
  • osbuild-composer version (rpm -qi osbuild-composer): any

To Reproduce
Steps to reproduce the behavior:

  • for example starting osbuild-composer.service or running composer-cli command, don't forget to include all configuration files you created

Configure the Microsoft SQL server repositories (however repositories are configured):

[mssql_server_2022]
name=Microsoft SQL Server 2022
baseurl=https://packages.microsoft.com/rhel/9/mssql-server-2022
enabled=1
gpgcheck=1

[mssql_client]
name=Microsoft SQL Client
baseurl=https://packages.microsoft.com/rhel/9/prod
enabled=1
gpgcheck=1

Configure the list of packages to be installed:

[[packages]]
name = "mssql-server"
version = "*"
[[packages]]
name = "mssql-server-fts"
version = "*"
[[packages]]
name = "mssql-server-ha"
version = "*"
[[packages]]
name = "mssql-server-selinux"
version = "*"
[[packages]]
name = "mssql-tools"
version = "*"
[[packages]]
name = "powershell"
version = "*"
[[packages]]
name = "unixODBC-devel"
version = "*"

The image build will fail

Expected behavior
Image building will succeed

Additional context

@richm richm changed the title Unable to build images with Microsoft SQL packages - cannot pass environment variables or respond to prompts Unable to build images with Microsoft SQL client packages - cannot pass environment variables or respond to prompts Feb 9, 2024
@bcl
Copy link
Contributor

bcl commented Feb 9, 2024

@achilleas-k and @richm and I discussed this on slack a bit today.

One idea is to add the ability to include environmental variables with the packages. eg.

[[packages]]
name = "mssql-tools"
version = "*"
environment = ["ACCEPT_EULA=y"]

It's not a great idea, it requires plumbing this down through all the layers to the rpm stage in osbuild. But I don't really see any better way. Limiting it to the specific package would prevent the environment accidentally leaking into other packages and possibly causing problems.

Another alternative is that mssql adds the ability to check for a known file to indicate acceptance of the EULA, and then you can use customizations.files to create it. Currently that is limited to /etc so we may need to talk about allowing files elsewhere.

@richm
Copy link
Author

richm commented Feb 10, 2024

Another alternative is that mssql adds the ability to check for a known file to indicate acceptance of the EULA, and then you can use customizations.files to create it.

We've asked MS about this idea. No reply yet.

Currently that is limited to /etc so we may need to talk about allowing files elsewhere.

Just for my info, why not /opt or /var?

@ondrejbudai
Copy link
Member

Just for my info, why not /opt or /var?

Just a policy thing. Happy to revisit it if needed.

@richm
Copy link
Author

richm commented Feb 12, 2024

Just for my info, why not /opt or /var?

Just a policy thing. Happy to revisit it if needed.

No, I'm sure you have your reasons. I was just curious.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants