Open Stack

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 at rd.bbc.co.uk>
> Sent: mercredi, 7 décembre 2022 13:44
> To: openstack-discuss at 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
> >
> >