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

[Guido Günther]

Hi,
On Fri, Nov 17, 2017 at 08:29:35AM +0100, Carsten Schoenert wrote:
> 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.

Maybe I'm thinking too simple, I'm taking apache as an example:

* split the apache related kopano webapp configuration from the apache
  site
* make the site use SSL (snakeoil) and include the configuration
* put the configuration into /etc/kopano-webapp/apache.conf
* put the site into /etc/apache2/sites-available, make it include the
  configuration
* do an a2ensite _once_ on initial install (so if the user disables it
  never reenable it again)
* keep the config up to date with changes in upstream kopano

I think this is the way lots of other packages work. The user can user
the default site for simple tests and disable it. The configuration for
to include in more complex scenarios (like real certs, etc) can simply
be included (and since it's a conf file as well modified by the admin).
Cheers
 -- Guido

> 
> 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
> 
> _______________________________________________
> Pkg-giraffe-discuss mailing list
> Pkg-giraffe-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-giraffe-discuss
>