-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
System timezone can't be changed? #17
Comments
Hello nichthinterfragen,
I have no idea how Docker maps that file to actual timezone of the system. Maybe your host system in UTC? |
Hi Rafael, the Ubuntu base image you are using for the Diladele Docker image has Etc/UTC set by default (visible in /etc/timezone via container shell). There are many ways to overwrite it I guess in Linux generally. However Docker is always a little special as far as I found out during my research. In fact there are issues open regarding that or were open for the base Ubuntu image you are using about timezone and sadly the only replies are like "build your own with commands to set timezone in Dockerfile to get an image with your own timezone" (bit sad... to get such replies). Anyway. You can as my example in attempt 2 to get the right timezone simply mount the necessary files as readonly from your host system into the container. The files even read the right timezone that is set on the host system. I have the timezone I need set on my host system (Europe/Berlin). Sadly seems like it is being ignored somehow. I don't blame Diladele. I think this possibly somehow related to the base Ubuntu base image given the support threads there about changing timezone being handled rather with lackluster and moving the responsibility to the reporter to fix it themselves. I just discovered yesterday that the Docker image in the docs is not approved for productional use. I think I'm going to see how far I can go with it and might end up installing brand new Ubuntu 20.04 LTS VMs with latest Diladele versions. Regards |
Indeed deploying a fully configured vm is the production supported scenario. |
Experienced with Diladele 8.3 & 8.4 Docker image.
With the "TIME_ZONE=Europe/Berlin" var for env we provide the timezone for Diladele (or rather said Django). This works so far as can be seen well in Diladele webinterface.
What about the system timezone? It is set to etc/utc by default. I tried a bunch of stuff to change it but it won't change inside what the Diladele Webinterface is showing me. "tzdata" seems to be already installed in the base Ubuntu image that is used inside the Diladele Dockerfile.
What I tried so far:
Compose snippet from my Stack:
environment:
command: >
sh -c "ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone && exec /sbin/my_init"
Result: The container boots up normally and so does Diladele. $TZ equals Europe/Berlin. /etc/timezone for some reason is empty. Diladele still shows etc/utc as the system timezone. I guess this way is not working well. The one below does better from the looks of the respective timezone and other files.
Compose snippet from my Stack:
environment:
volumes:
Result: $TZ equals the set value. Content of timezone and localtime equal what is set on the Docker host. Docker Host timezone is set to Europe/Berlin btw. Diladele still says that the system timezone is etc/utc.
Can this issue be even ignored? I plan on using Diladele with AD integration. Kerberos and such stuff can be very problematic with stuff like time being accurate. Do I have to build my own Image that implements fixes to this issue?
Mainly because I have a few Diladele servers running on Ubuntu 18.04 LTS with different Diladele versions. Ubuntu 18.04 LTS as you may know is EOL after May 2023 (unless you get a subscription for the Pro version which provides support until somewhere in 2027). So I discovered the Diladele Docker image.
Actually I have a list of issues with the image. I'm trying to fix issues on the way myself and write down the issue + fix at the moment to submit more issues.
The text was updated successfully, but these errors were encountered: