[Pkg-giraffe-discuss] default behavior of kopano-webapp-$(webservers)?

[Carsten Schoenert]

Hi,

the kopano-webapp source package was getting accepted yesterday to enter
the main archive. Yeah!

And I had never realized before I've taking a look at the newly created
tracker site [1] Guido already created a first bug report against
kopano-webapp-apache2 [2] due some not straight forward behavior of the
installation.
And yes, I must admit the current way of running the postinst script
isn't a good and fully logic solution. But all three webserver specific
package do more or less the same, they doesn't enable the https access
fully.

To short summarize what happen while installing on (or more)
kopano-webapp-$(webserver) package.
All these package have a dependency on kopano-webapp-common which
provides the PHP content and which itself depends also on package
ssl-certs which is used in the postinst of -common to create some
intermediate certificate and key if not available so we could use these
to bring up and start a web server configuration later in the postinst
script of the various web server packages.

https://anonscm.debian.org/cgit/pkg-giraffe/kopano-webapp.git/tree/debian/kopano-webapp-apache2.postinst#n33
https://anonscm.debian.org/cgit/pkg-giraffe/kopano-webapp.git/tree/debian/kopano-webapp-lighttpd.postinst#n37
https://anonscm.debian.org/cgit/pkg-giraffe/kopano-webapp.git/tree/debian/kopano-webapp-nginx.postinst#n32

Until now I have modified all three webserver specific packages to not
enable any https configuration by default. Note there are specific
README:Debian files in the packages too.
That brings us than back to the bug report #876668.

What should we do in the webserver packages?

1. I guess we are agree we don't want default a http configuration due
   the usage of sensitive password data.
   We can provide a webserver specific configuration for that too but
   I'd just put this into the /u/s/d/kopano-webapp-$(webserver) so a
   user could pick up the file(s) from there.

2. We just create some basic https configuration snippet for each
   webserver package and place them into /u/s/d/.. with additional
   information in the README.Debian file?

3. We create a working configuration based on a cert and key by the
   ssl-serts package and enable this configuration if possible. I don't
   know if this is full possible as administrators mostly want use
   different webserver at the same time on servers with a bit more
   complexity.

4. We create a working configuration like in 3 but don't enable anything
   at all and provide a deeper explanation on how to use the provided
   configuration files. This would questioning the usage of the
   ssl-certs package in *-common.

>From my current POV as a user/admin I'd vote for 3. But, I never had to
administrate such possible complex structures.
If someone can help here out how to make the best of a user experience
for the webserver configuration I happily would take offered help! If
this is all not possible we need to document the steps that are needed
to get webserver running in the various use cases.

BTW: I've worked the last two days while sitting in the train on the
fresh released kopano-webapp 3.4.0. I've got a working build with some
additional patches on top of the i18n files. But I haven't tested the
new packaging yet. If this is done I'd prepare a next upload to
experimental again so I could take a look again on a first upload of
kopano-webapp-files to NEW.

[1] https://tracker.debian.org/pkg/kopano-webapp
[2] https://bugs.debian.org/876668

-- 
Regards
Carsten Schoenert