Setting of environment variables

[Klaas-]

Hi,
please document how to set environment variables during the update run, the most prominent example of a package that needs env vars set in our environment is microsofts own odbc rpms:
ACCEPT_EULA=Y is needed in the environment variables for an update to succeed.

Old update management also loads /etc/environment but that does not seem to be documented anywhere.

Greetings
Klaas

[kjohn-msft]

Hi Klaas,

Thanks for the feedback on this.

We do not currently plan to set variables like ACCEPT_EULA on our own because the EULA is a legal agreement between the end customer and the package author.

For any generic set of environment variables to set, customers are encouraged to set them on Azure VMs using mechanisms like Run command:
https://docs.microsoft.com/en-us/azure/virtual-machines/linux/run-command

For specific ones like ACCEPT_EULA, we will review that as a product request in our backlog, and get back to you.

Thanks,
Koshy

[Klaas-]

if there is no way to set environment variables you can not update Microsoft packages like msodbcsql17 with update management (https://packages.microsoft.com/rhel/8/prod/msodbcsql17-17.9.1.1-1.x86_64.rpm). That is also why update management v1 sets ACCEPT_EULA=Y inside it's runbook. I would much prefer a generic way via configfile or something similar :)

[shaneholder]

This seems to have been addressed with #215 but I am not finding any documentation on how to use the functionality. I see a reference to documentation on how to use it.

[shaneholder]

Based on the code it seems that a JSON file needs to exist
/var/lib/azure/linuxpatchextension/patch.eula.settings with contents of:

{
            "AcceptEULAForAllPatches": "True",
            "AcceptedBy": "TestSetup",
            "LastModified": "2023-08-29"
}

It would be great if someone on the team could confirm and document this.

[kjohn-msft]

We're unable to fulfill this request as Legal has advised that we cannot accept license agreements on behalf of customers. As such, for those reasons, we're unable to declare or provide any support for such scenarios. Customers are encouraged to install these updates as one-offs, or request alternate machine-wide independent pre-acceptance capabilities from specific package vendors.

[Klaas-]

So essentially you're offering a service that does not work for microsofts own software packages like msodbcsql ? :)

I'll be honest, I now do all my updates via ansible because I did not have time to wait for a solution for two years.

if anyone else wants to switch, updating all packages with set environment variables is easy there:

- name: Install all pending updates
   become: true
   ansible.builtin.package:
     name: "*"
     state: latest
   # Workaround for broken msodbcsql package
   environment:
     ACCEPT_EULA: 'y'

[kjohn-msft]

I understand where you're coming from, and appreciate all the feedback and notes here. This is a function of the restrictions we're operating inside. There's still a lot of goodness still happening with the limited number of people on this spread between this and other large-scale related internal projects. If you do decide to try us out again, especially considering everything on offer is free, we're keen to continue to incorporate feedback.