Open vPotusFlotus opened 3 years ago
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?
Hi vPotusFlotus,
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'
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/"}'
tail -F
docker exec -it ${FQDN} /usr/bin/tail -F /var/log/univention/config-registry.replog
--env DEBUG=TRUE
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 )
Hi @GinoHarlos ,
Thanks a lot for your response! If I understand it correctly:
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 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!
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! :)
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!
Hi,
I'm trying to deploy the Univention-Corporate-Server container behind a proxy and with custom DNS servers: FQDN=ucs.lab.local; \
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!