[Pkg-giraffe-discuss] default behavior of kopano-webapp-$(webservers)?
Simon Eisenmann
s.eisenmann at kopano.com
Fri Nov 17 10:36:08 UTC 2017
Hey Carsten,
-----Original message-----
> From:Carsten Schoenert <c.schoenert at t-online.de>
> Sent: Friday 17th November 2017 8:27
> To: pkg-giraffe-discuss at lists.alioth.debian.org
> Subject: [Pkg-giraffe-discuss] default behavior of kopano-webapp-$(webservers)?
> 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.
>
This is complicated and i doubt it is possible to find a solution which always works and/or is suitable for a large percentage of possible installations. A package i have been using in the past which tries to do something automatically (but without TLS) is "smokeping". It tries to do 3. for Apacha and if thats fails or is not possible, always ships 2.
In their README.Debian is
```
The web server configuration is done automatically on new installations
when possible. If that doesn't happen, the recommended way to get theI
CGI script working is
ln -s /etc/smokeping/apache2.conf /etc/apache2/conf.d/smokeping
invoke-rc.d apache2 restart
See NEWS.Debian for information on upgrades from older versions of
the package.
```
>From my point of view and from an administrators perspective i would do and expect it like that.
In Kopano case, where it would be good to be activated only in the TLS case, i suggest to do that only if there is already a working TLS vhost available in Apache. Else just use 2. and let the admin decide how to actually expose Kopano in the environment, providing working configuration files for Apache which just can be included in the right vhost configuration.
Best regards
Simon
More information about the Pkg-giraffe-discuss
mailing list