Zammad: Don't drop zammad.conf into /etc/nginx/sites-enabled/

Created on 21 Jun 2017 · 10Comments · Source: zammad/zammad

Infos:

Used Zammad version: 1.6.0-1497971761.97eca99.jessie
Used Zammad installation source: package
Operating system: Debian 8
Browser + version: n/a

Expected behavior:

Zammad package drops example nginx configuration to /etc/nginx/sites-available

Actual behavior:

Zammad package installs nginx configuration to /etc/nginx/sites-enabled
This actively changes the configuration of the webserver which is not a good practice.
In our case this conflicts names with existing vhosts and nginx will not reload/restart anymore:

Jun 21 16:28:22 tickets.darmstadt.freifunk.net systemd[1]: Starting A high performance web server and a reverse proxy server...
Jun 21 16:28:22 tickets.darmstadt.freifunk.net nginx[14822]: nginx: [emerg] duplicate upstream "zammad" in /etc/nginx/sites-enabled/zammad.conf:5
Jun 21 16:28:22 tickets.darmstadt.freifunk.net nginx[14822]: nginx: configuration file /etc/nginx/nginx.conf test failed
Jun 21 16:28:22 tickets.darmstadt.freifunk.net systemd[1]: nginx.service: control process exited, code=exited status=1
Jun 21 16:28:22 tickets.darmstadt.freifunk.net systemd[1]: Failed to start A high performance web server and a reverse proxy server.

Steps to reproduce the behavior:

Move /etc/nginx/sites-enabled/zammad.conf to /etc/nginx/sites-enabled/tickets.example.com.conf
Update package
Boom.

Source

mweinelt

Most helpful comment

Its fixed now in: https://github.com/zammad/zammad/commit/52baed55f80e73a5f12c07e561fb23d858734ba9

monotek on 24 Jun 2017

👍4

All 10 comments

Whats your point?
You want to install Zammad by hand and by package and expect to have no conflicts?

Eidt: Now i see what you've done. You renamed our config file so Zammad installed a new one, when updating. Can't work . Don't rename our config file.

monotek on 21 Jun 2017

It is usually best practice to install new configuration files into /etc/apache2/sites-available or /etc/nginx/sites-available/ and symlink them to /etc/$webserver/sites-enabled. This allows the admin to easily en- & disable sites.

Especially since the configuration file (per default) only contains HTTP you (as an admin) will probably end up writing your own or adjusting them anyway being able to disable the vendor configuration & using it as reference (for the proxy setup etc) is probably a sane idea.

My recommendation would be to only drop a configuration file in /etc/$webserver/sites-available and symlink to /etc/$webserver/sites-enabled ONLY during package installation - not upgrades. If the symlink still exists the webserver configuration will be updated - if someone wants to run it's own configuration he'll have to adjust.

andir on 21 Jun 2017

👍1

I sincerely hope you'll reconsider this. Installing example contrib configuration into a production setup should not be done.

mweinelt on 22 Jun 2017

Fully agree to @andir

rkaldung on 23 Jun 2017

The configuration script is run after the package installation so there is no save way to check if it's the first installation or not and therefore it makes no difference if you use a symlink or not.

monotek on 23 Jun 2017

Well in the simplest scenario you would this a test -f in there to detect
an upgrade. Packages are clearly able to perform different behaviours
depending on (first) install and upgrade. Think about databases migrating
you existing files etc...

On Jun 23, 2017 6:39 PM, "André Bauer" notifications@github.com wrote:

The configuration script is run after the package installation so there is
no save way to check if it's the first installation or not and therefore it
makes no difference if you use a symlink or not.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zammad/zammad/issues/1196#issuecomment-310714440, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAm_dK9PdJdzrZCyfvuYpmJknzdZ778Rks5sG-oigaJpZM4OBDiJ
.

andir on 23 Jun 2017

If you already have an idea: https://github.com/zammad/zammad/tree/develop/contrib/packager.io

Pullrequest welcome.

monotek on 23 Jun 2017

Ok, I had testing for the symlink in mind, what would of course not work, but checking for the file itself in sites-available could be a solution, at least for Debian family systems. As far as I remember centos & suse had no available / enabled dirs...

I'll do it for Debian as soon as I have some spare time.

monotek on 23 Jun 2017

👍1

Its fixed now in: https://github.com/zammad/zammad/commit/52baed55f80e73a5f12c07e561fb23d858734ba9

monotek on 24 Jun 2017

👍4

Thank you! 👍

andir on 24 Jun 2017

👍2

Was this page helpful?

0 / 5 - 0 ratings