[openstack-ansible] Environment variable overflow on Ubuntu 20,04
Hello,
The 'lxc_container_create' role appends the content of the 'global_environment_variables' OSA variable to '/etc/environment', which is used by the library 'libpam'.
On Ubuntu 20.04 and 'libpam-runtime' library version 1.3.1, this works fine unless one of the environment variables content size exceeds 1024 char. In this case, the variable content is truncated. In our OpenStack deployment, this is the variable 'no_proxy' that overflows.
This limit has been raised to 8192 with 'libpam-runtime' version 1.4 but there is no backport available in Ubuntu 20.04 repositories.
So what would you think of the following workaround: instead of using '/etc/environment' to store the global variables, the role would create a shell script in '/etc/profile.d' thus avoiding the variable truncation issue related to the 'libpam' library ?
This works on Ubuntu, Debian and CentOS hosts and containers.
Cheers, JF
Hi JF,
We have some clear documentation for this case here https://docs.openstack.org/openstack-ansible/latest/user/limited-connectivit... and a discussion of the pros and cons of making system-wide proxy configuration.
Once the deployment reaches a certain size it is necessary to use transient "deployment_environment_variables" instead of persistent "global_environment_variables" to manage no_proxy, both in terms of the length of the no_proxy environment variable but also the need to manage the contents of that variable across all hosts / containers and running services for any changes made to the control plane.
From experience I can say that it is much much easier to selectively enable the use of a proxy during ansible tasks with deployment_environment_variables than it is to prevent the use of global proxy configuration through no_proxy in the very large number of cases that you do not want it (basically the whole runtime of your openstack services, loadbalancer, .....).
Regarding the addition of an extra script in /etc/profile.d, I would not be in favor of adding this as we already have a very reliable way to deploy behind an http proxy using deployment_environment_variables. There is great benefit in not leaving any "residual" proxy configuration on the hosts or containers.
Hopefully this is helpful, Jonathan.
On 07/12/2022 11:44, Taltavull Jean-François wrote:
Hello,
The 'lxc_container_create' role appends the content of the 'global_environment_variables' OSA variable to '/etc/environment', which is used by the library 'libpam'.
On Ubuntu 20.04 and 'libpam-runtime' library version 1.3.1, this works fine unless one of the environment variables content size exceeds 1024 char. In this case, the variable content is truncated. In our OpenStack deployment, this is the variable 'no_proxy' that overflows.
This limit has been raised to 8192 with 'libpam-runtime' version 1.4 but there is no backport available in Ubuntu 20.04 repositories.
So what would you think of the following workaround: instead of using '/etc/environment' to store the global variables, the role would create a shell script in '/etc/profile.d' thus avoiding the variable truncation issue related to the 'libpam' library ?
This works on Ubuntu, Debian and CentOS hosts and containers.
Cheers, JF
Hi Jonathan,
I understand your opinion about /etc/profile.d. I will test "deployment_environment_variables".
Thanks for helping !
JF
-----Original Message----- From: Jonathan Rosser jonathan.rosser@rd.bbc.co.uk Sent: mercredi, 7 décembre 2022 13:44 To: openstack-discuss@lists.openstack.org Subject: Re: [openstack-ansible] Environment variable overflow on Ubuntu 20, 04
EXTERNAL MESSAGE - This email comes from outside ELCA companies.
Hi JF,
We have some clear documentation for this case here https://docs.openstack.org/openstack-ansible/latest/user/limited- connectivity/index.html and a discussion of the pros and cons of making system-wide proxy configuration.
Once the deployment reaches a certain size it is necessary to use transient "deployment_environment_variables" instead of persistent "global_environment_variables" to manage no_proxy, both in terms of the length of the no_proxy environment variable but also the need to manage the contents of that variable across all hosts / containers and running services for any changes made to the control plane.
From experience I can say that it is much much easier to selectively enable the use of a proxy during ansible tasks with deployment_environment_variables than it is to prevent the use of global proxy configuration through no_proxy in the very large number of cases that you do not want it (basically the whole runtime of your openstack services, loadbalancer, .....).
Regarding the addition of an extra script in /etc/profile.d, I would not be in favor of adding this as we already have a very reliable way to deploy behind an http proxy using deployment_environment_variables. There is great benefit in not leaving any "residual" proxy configuration on the hosts or containers.
Hopefully this is helpful, Jonathan.
On 07/12/2022 11:44, Taltavull Jean-François wrote:
Hello,
The 'lxc_container_create' role appends the content of the
'global_environment_variables' OSA variable to '/etc/environment', which is used by the library 'libpam'.
On Ubuntu 20.04 and 'libpam-runtime' library version 1.3.1, this works fine
unless one of the environment variables content size exceeds 1024 char. In this case, the variable content is truncated. In our OpenStack deployment, this is the variable 'no_proxy' that overflows.
This limit has been raised to 8192 with 'libpam-runtime' version 1.4 but there
is no backport available in Ubuntu 20.04 repositories.
So what would you think of the following workaround: instead of using
'/etc/environment' to store the global variables, the role would create a shell script in '/etc/profile.d' thus avoiding the variable truncation issue related to the 'libpam' library ?
This works on Ubuntu, Debian and CentOS hosts and containers.
Cheers, JF
participants (2)
-
Jonathan Rosser
-
Taltavull Jean-François