Zammad on UCS with Letsencrypt

Hello, I want to free my Zammad von Zentyal as a server and relocate to a UCS Univention server.

Have made a recent backup and the UCS schonmal installed and also Zammad runs.

Since the instance should be accessible from the outside, I have everything set up so far.

But now my problem, the letsencrypt of UCS does not grab the docker or?

How do I get it out that Zammad can be reached under “service.domain.example” and also encrypted with Letsencrypt?

The port 10412 I could indeed redirect over the firewall.


the docker is the wrong path here.
You can find a custom vHost for the apache on the UCS system that does all the magic.

You proberbly want to start there:


Currently our joinscripts on UCS don’t check if the file has been edited and will remove and “reset” the files content on every update. Your changes there are not update safe at the moment.

Hopefully that helps.

1 Like

is this planned to be integrated, any way to contribute?

This is not a public repo, so no way to contribute at the moment, sorry!

I put it on my list, no ETA though.

Just a small follow up, currently I’m finish the app update which will raise Zammad to 3.1.x.
It will also introduce app settings and an alternative port to the highport (now 8443). HTTPs (443) itself is not possible because of how Zammad works.

The Zammad-App for UCS will support Let’s Encrypt (by Univention GmbH) and custom certificates if they are in the right location.


Hi, we need to use Zammad forms and therefore we need Zammad to use the Let’s Encrypt certificate. Can you estimate when the app update will be ready? Thank you!

We’re currently awaiting verification by Univention. It seems during their tests the upgrade fails and never finishes. I can’t reproduce this on our systems, but this is a show stopper.

Maybe this is related to a problem we had with the joinscript (/usr/lib/univention-install/50zammad.inst). Zammad never becomes ready because this loop does not end:

# Check readiness of Zammad-Docker
while [ ! $ZAMMAD_SRUN ]; do
  sleep 2
  ZAMMAD_MAIL_SIZE="$(docker exec -i "$ZAMMAD_CONTAINER" rails r "p Setting.get('postmaster_max_size')")"
  echo "# ... Checking Zammad-Mail-Size: "$ZAMMAD_MAIL_SIZE" MB                         #"

  if [ $ZAMMAD_MAIL_SIZE -eq "35" ]; then

When running

docker exec -i zammad_zammad-railsserver_1 rails r "p Setting.get('postmaster_max_size')"                                                                                        

it returns more than just the 35:

I, [2019-09-26T12:24:58.288014 #25-47115586047840]  INFO -- : Setting.set('product_logo', "6d5d035a808e2d90c76822c304ea6d23.png")

So did you do a fresh install or was this an upgrade installation?
What did it return?

Normally this check only should happen on a fresh install, because we’re setting it from 10 to 35 (default).
If you had a previous installation, as we don’t remove data at some points, it might be that old settings strike you here.

Can you verify that?

This was a fresh installation. If the joinscript is not run again for the upgrade, it can not be causing the problem, of course.

There’s a second check running (before), that waits for the docker construct to boot completely.
We’re checking for code 200 as HTTP response here, because from that moment on, the containers are ready to receive and handle data.

This by the way was the breaking point on the Univention tests. Right now I’m however unable to reproduce the steps these tests do.


could you solve the problem? I got the same loop with my zammad installation. This it where it stocks:

“# … Checking Zammad-Mail-Size: MB #
/usr/lib/univention-install/50zammad.inst: line 211: [: -eq: unary operator expected”

after a reinstallation of zammad.

PS : This is line 211 “if [ $ZAMMAD_MAIL_SIZE -eq “35” ]; then”

If you adjust the affected line to
if [ "$ZAMMAD_MAIL_SIZE" -eq "35" ]; then
you should be fine. Sorry about that, I messed up there.

This will be solved by the 3.1 update that Univention and we are working on, ETA unknown.

For us the problem was solved by setting

config.log_level = :warn

This way ZAMMAD_MAIL_SIZE="$(docker exec -i "$ZAMMAD_CONTAINER" rails r "p Setting.get('postmaster_max_size')")" returns only “35” and not two lines.

For us the missing " was not a problem, I verified it using the following code:

if [ $Foo -eq "35" ]; then
  echo "Foo"

Interesting, could you let me know what those two lines contain?
I mean I don’t want to hide behind “it works on my machine” :stuck_out_tongue:

1 Like

OK Thanks , I need to wait after 4 a clock then I confirm, as this is a productive machine. Any restart or reload after this?

I, [2019-09-26T12:24:58.288014 #25-47115586047840]  INFO -- : Setting.set('product_logo', "6d5d035a808e2d90c76822c304ea6d23.png")

See post above :wink:

ah! My bad sorry, didn’t recognize it as relevant for me (in that case haha).
Okay, the above seems to be somewhat of a race condition where your host is not fast enough.

I’m aware that this doesn’t help you too much here.
Normally the above should not appear at this state. Looks like your container still was initializing. :frowning:

Anyway, the current update does not hold any option to change the logging.
However, I’ll add this as an enhancement issue on our private repo to address this during the next update.

Thanks for the heads up!

Edit: Couldn’t let me go…
I’ve double checked, yes, the if might fail once or twice, but should normally continue to function, because it’s living in a while that shouldn’t break because if issues with checking for a value (normally) :smiley:

if [ “$ZAMMAD_MAIL_SIZE” -eq “35” ]; then

Solved my problem. Thanks

1 Like