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: /etc/apache2/sites-available/zammad.conf
Attention:
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.
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
ZAMMAD_MAIL_SIZE="10"
while [ ! $ZAMMAD_SRUN ]; do
sleep 2
ZAMMAD_MAIL_SIZE="$(docker exec -i "$ZAMMAD_CONTAINER" rails r "p Setting.get('postmaster_max_size')")"
ZAMMAD_MAIL_SIZE="$(echo $ZAMMAD_MAIL_SIZE| bc)"
echo "# ... Checking Zammad-Mail-Size: "$ZAMMAD_MAIL_SIZE" MB #"
if [ $ZAMMAD_MAIL_SIZE -eq "35" ]; then
ZAMMAD_SRUN=false
fi
done
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")
"35"
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.
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.
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.
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)