Not all Environment Variables (nameserver, proxy/http) are set

[vPotusFlotus]

Hi,

I'm trying to deploy the Univention-Corporate-Server container behind a proxy and with custom DNS servers:
FQDN=ucs.lab.local; \

docker run
--detach
--network hostlocal
--ip 192.168.124.20
--cap-add SYS_ADMIN
--cap-add MKNOD
--volume /sys/fs/cgroup:/sys/fs/cgroup:ro
--tmpfs /run
--tmpfs /tmp
--restart unless-stopped
--hostname ${FQDN}
--name ucs-univention
--env nameserver='192.168.124.200 192.168.124.201'
--env timezone=Europe/Berlin
--env proxy_http='http://192.168.124.202:3128/' \

For some reason the 'nameservers' are not set in the container. When I run 'ucr get nameserver1' it returns empty. The same for the proxy/http regitstry key: even though it is being passed as env varaible, it is not set.
Passing the forwarders as env variables does seem to work however (ucr get dns/forwarder1 returns the forwarder that I've passed).

This causes the container to hang / not start up correctly because I believe UCS container needs internet access and without a proxy and proper nameservers the container won't get it.

Are we missing something? Can you help us out?

Thanks a lot in advance for your time!

[vPotusFlotus]

UPDATE
The logs look like this and it keeps on repeating these logs (waited 1h):

When I run the container and immediately log into it and set the proxy manually (ucr set proxy/http='proxy_url') ucs seems to be much happier and even sets my nameserver & forwarders automatically & correctly as well as my timezone etc. So after setting the proxy manually in the container, the other variables are passed correctly and ucs container starts immediately unpacking files and setting up the environment. The logs then look like this:

Are we passing the proxy/http env variable (proxy_http) wrong? Or does ucs container start immediatly with trying to reach the online repos before setting the proxy/http registry key or something?

[GinoHarlos]

Hi vPotusFlotus,

1. Check your network, maybe like this

docker run \
  --rm -it \
  --network hostlocal \
  --ip 192.168.124.20 \
    univention/univention-corporate-server \
      /bin/bash -c 'cat /etc/resolv.conf && apt-get update && apt-get --assume-yes install iputils-ping && ping -c 3 -W 3 192.168.124.200 && ping -c 3 -W 3 192.168.124.201 && ping -c 3 -W 3 updates.software-univention.de'

2. You don't have set a system role ... This is not a problem, but you will get a master ( primary directory node ) and for a master you will get a forced localhost configured name server. ( name server environment )
3. To set the univention config registry, you find two options ... ( from ENV or JSON )

• --env key=value (ucr set key=value) OR

• --env registry='{"key":"value"[,"key":"value",...]}'

• --env registry='{"proxy/http":"http://192.168.124.202:3128/"}'

4. Follow the config registry with tail -F

docker exec -it ${FQDN} /usr/bin/tail -F /var/log/univention/config-registry.replog

5. If you would like, you can go into debugging mode ( DEBUG )

• --env DEBUG=TRUE
• Now you can look after run-parts: exicuting join/00-domain-name-service for name server settings and run-parts: exicuting join/00-ucr-environment-import / run-parts: exicuting join/00-ucr-json-import for ucr imports during the container start/boot.

Are we passing the proxy/http env variable (proxy_http) wrong?

No, but proxy/http will set after the first update/dist-upgrade ...

Or does ucs container start immediatly with trying to reach the online repos before setting the proxy/http registry key or something?

Yes, it needs time to set the ucr entries ... ( Maybe the section extended usage can help to understand the deploying process )

[vPotusFlotus]

Hi @GinoHarlos ,

Thanks a lot for your response! If I understand it correctly:

• Yes, we can reach our DNS Servers. The UCS is just behind a proxy, and for outside world access everything needs to pass via that proxy. With only DNS Servers working (yes they are working/reachable) we're not able to reach the internet.
• We're passing the Proxy Variable correctly for UCS
• The Proxy Variable will set the UCS Proxy Registry and afterwards OS Env Variable $http_proxy via /etc/profile
• But before the UCS Registry gets set, an apt-get update is performed and packages are installed
• During this apt-get update & package installation, the OS is not yet aware of a Proxy because the UCS Registry is set afterwards (and so the /etc/profile or $http_proxy)

Hence if I pass the Environment Variable 'http_proxy' as an "OS Environment Variable" to the UCS Container (in addition to my initial variables mentioned in my initial post) like so:

--env http_proxy=http://192.168.124.202:3128/
--env https_proxy=http://192.168.124.202:3128/ \

It seems to work (99% correct ;-) )! Because it will set the OS Variables ($http_proxy & $https_proxy) and the apt-get update & package installation succeeds. Afterwards the UCS Registry gets set.

Why is it 99% working? (I tested this now 3 times, always same results)

• The '92univention-management-console-web-server' service could not be started because it was not joined. After executing the join in the 'Domain Join' section of the UCS Portal, it seemed to be happy and running.
• The status reported by the 'docker ps' command is still 'health: starting'; probably because of the failed univention-management-console-web-server service. But after joining and the system not complaining in the UI, the status is still the same. Even after reboot of the container

The issues mentioned above are not present when I set the environment variables $http_proxy manually by logging in to the container immediately after the container has started. As explained in my 2nd post in this Github Issue (the one with the screenshots).

The only downside is that it's lower case so it also gets processed as a UCS Registry Key if I'm not mistaking. This means that I now have the working ucr key set (proxy/http) and also the non-existant 'http/proxy' ucr key because it's passed lowercase. If I pass it in uppercase ($HTTP_PROXY vs $http_proxy), the issue is still the same and UCS cannot reach your repo.

I'm not aware of any side-effects of setting a ucr key that actually does not exist or should not be used (http/proxy) because I'm passing the lowercase http_proxy variable in order to let the OS have a proxy setup before it does the apt-get update.

I don't know if this is behaving as expected for Univention? Or if you have a guide somewhere to deploy UCS Containers behind a proxy? But this is at least how I seem to get it working, with the above mentioned small issues.

Thanks again for your time!

[GinoHarlos]

Hi vPotusFlotus,

I have tested with some public HTTP(S) proxies. And the same result for me, it looks not so nicely behind a proxy ...
I don't know if this is a Bug, but i think it's the limit of starting systemd inside the container. All environment variables from docker run ... ${FQDN} ... you can find, are only available under PID 1/systemd. Therefore you find the service unit univention-container-mode-environment.service. And for sure, if you use docker exec ... ${FQDN} ... you will find this variables again.

--env http_proxy=http://192.168.124.202:3128/
--env https_proxy=http://192.168.124.202:3128/

Nice! But I think you need this too.

--env proxy_http=http://192.168.124.202:3128/
--env proxy_https=http://192.168.124.202:3128/

It will change the file /etc/apt/apt.conf.d/80proxy permanent, because http(s)_proxy are only available under PID 1.
For now I don't see any side-effects ( ucr search proxy ), but you're right. So maybe we have to block these variables ...

@reqa << EOF: Should one expand the excluded keys? ( http_proxy and https_proxy )

• ( root/usr/lib/univention-container-mode/join/00-ucr-environment-import )

UniventionConfigRegistryExcludeKeyFilter="^(rootpw|sshkey|dcname|dcuser|dcpass|language|encoding|timezone|role|license|nameserver|forwarder|domainname|hostname|registry|install|container|certificates|credentials|http_proxy|https_proxy)$"

• ( docs/README.ENVIRONMENT.md )

... ( Excluded keys are: rootpw, sshkey, dcname, dcuser, dcpass, language, encoding, timezone, role, license, nameserver, forwarder, domainname, hostname, registry, install, container, certificates, credentials, http_proxy, https_proxy )

@reqa EOF

If you in trouble with APACHE and the Docker HEALTHCHECK like this ( exit status 226/NAMESPACE ):

Jun 25 10:34:22 sh[39]: ● apache2.service - The Apache HTTP Server
Jun 25 10:34:22 sh[39]:    Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
Jun 25 10:34:22 sh[39]:    Active: failed (Result: exit-code) since Fri 2021-06-25 12:34:18 CEST; 14ms ago
Jun 25 10:34:22 sh[39]:      Docs: https://httpd.apache.org/docs/2.4/
Jun 25 10:34:22 sh[39]:   Process: 14144 ExecStart=/usr/sbin/apachectl start (code=exited, status=226/NAMESPACE)

you can have a look here advanced example ... basic example for apparmor security option. This will fix for now the systemd private tmp inside the container.

Thanks for your time too! :)

[vPotusFlotus]

Hi @GinoHarlos ,

Thanks for the profound explanation! Indeed it does not look so nicely behind a proxy.
Yes indeed, I've mentioned those ENV Variables in addition to the ones for the ucr.

Have a nice day!