[Pkg-giraffe-discuss] Update of z-push package to 2.4.0?

[Carsten Schoenert]

Hello Roel,

Am 21.03.2018 um 13:57 schrieb Roel van Meer:
> I've prepped 2.4.0 in unstable as per your suggestion. I have an n=1  
> comfirmation that upgrading from 2.3.9 works (with the IMAP backend, that  
> is).

that's the main point for uploading a updated package. We can not break
things with an update if we know this would happen. And that's the
problem with z-push for me. :) I don't use this for me and technically
packaging the stuff is just one thing. So thanks for care!

> However, before I push to salsa I'd like some discussion or guidance on the  
> webserver configs. Ideally Z-push would provide more or less the same  
> functionality as with kopano-webapp, but currently it doesn't..
> 
> I think in general we can do three things:
> 
> a) Provide config that can be included in an existing ssl-enabled vhost and  
>    works without further changes;
> b) provide a completely separate vhost config in which a few parameters  
>    (primarily server name and ssl certs) should be changed before it works;
> c) provide config with a lot of possible options and let the user decide for  
>    himself what is wanted.
> 
> The kopano-webapp package provides option B for Apache and Nginx and A for  
> lighttpd. Z-push provides A for Apache and lighttpd and nothing (yet) for  
> Nginx (and the lighttpd config isn't even working OOTB, so we need some extra  
> instructions there).

[offtopic to z-push]
I've seen a broken kopano-webapp-lighttpd update to 3.4.9 right
yesterday. I haven't digged into detail what's causing the issue here.
It's maybe related to the update of PHP to 7.2.

> The nice thing about the include-in-existing-vhost config is that it can  
> work without any additional actions by the user. That's what we have for  
> Apache now. Then again, it might not be what a user wants, and depends on  
> assumptions (such as php-fpm being available, for nginx) that might not be  
> true.

I think it's desirable from a users view that the k-w or z-push webui
will work out of the box after a installation into a fresh system. That
would be no problem as long we only take care for the http protocol
only. The whole thing becomes more sensible and problematic if we want
or need to support also https with a redirection of http -> https.
What ever we like to provide and configure while a package installation
or update, if the user or system admin has something configured we would
touch we need to handle this without deletion or overriding.

> So, what's your preference here? Config for a separate vhost, or config  
> that is ready to be included in an existing vhost? Or both (such as webapp  
> already has for apache), do nothing automatically and let the user decide?

I like the possibility at least for apache and nginx to work with
dedicated snippets what can be puzzled together into a working solution
in various ways. By this we could provide a out of the box working first
time installation even with https, but give also the users the option to
just adjust a small part like the certificates and after a webserver
reload all is working quick again with the new certificates.

And this for a vhost/subdomain configuration and a subfolder situation
too. Apache and nginx can be configured for booth scenarios. I'm not
sure for lighttpd, so far I remember it's not designed for multisite or
multiple subdomain use cases. But I'm not a specialist for web server
configuration.

> Personally I lean to the method that you're using in kopano-webapp for  
> apache. Provide both a vhost config and a main config, and give the user the  
> option to do either, but do nothing automatically.

Hmm, for k-w and apache I changed the installation behavior a bit some
weeks ago. If k-w-a is installed for the first time the package enables
the k-w-a configuration and by this the website for servername/webapp.
If the user is doing a package update and the apache server isn't
already running a site configuration for 'kopano-webapp' before the
update the postinst isn't doing a activation of the webapp config.

I wanted to adopt this behavior for k-w-n too, but due lack of time and
testing I haven't done anything further here yet.

So, if possible we can and should do provide a similar package behavior
for the webserver configuration. Means we try to give the users, which
installing the package(s) will get a first time, a usable configuration
after the installation has finished. This will naturally only working
for as a subfolder in the web server root.
We break down the needed configuration into smaller peaces which will be
included in the needed way. A usable vhost configuration is based also
on these peaces and ideally full usable with only modifications to the
servername, ca certificates etc.

This should be possibly for apache and nginx, lighttpd has some
limitation here due the idea behind this web server. Not only to this,
it's probably not worth to put more than needed energy into a
configuration setup for lighttpd.

Everything can, but nothing must. That's all just ideas from my POV,
Roel, if you haven't the time or enough energy to work on something like
described above that would be totally o.k.
I think I can configure my websites and needs with apache in a almost
quick way (for me). This is likely to the really broad usage and
available website around the apache web server.
I regularly struggle with nginx configuration, especially once
php-fastcgi or php-fpm is getting involved.

> And one other point. Z-push on Nginx works only if used with php-fpm. When I  
> started here, I thought having separate packages for webserver configs  
> wasn't such a good idea, because a package that's split up too much is a  
> reason for rejection, according to the FTP-masters Reject FAQ. But it does  
> mean z-push cannot depend on php-fpm for it's nginx config. So I'm having  
> second thoughts about it.
> 
> What do you think about re-introducing those packages for Z-push?

That would be o.k., and this isn't a 'over splitting' of the packages,
you will need such packages to get the functionality into the
{pre,pos}tinst scripts to get not some automatic conflicts between the
web server configuration in case of parallel installation of apache and
nginx e.g..

On the other hand this would be need if you would package all needed
snippets in /u/s/d/z-push/examples and provide a well written README
file so user know what to do with theses snippets. It's all a matter of
taste and usability in the end.

BTW: If you have time to come to the MiniDebConf in Hamburg we could
take some time to look at all these things really in detail would be great!
Normally we would hold our groupware meeting at the ened of the spring,
but this isn't possible right now, so the MiniDebConf in Hamburg can be
a good place to do some work on this?

https://wiki.debian.org/DebianEvents/de/2018/MiniDebConfHamburg

> I hope I'm not bikeshedding again, and sorry if I'm overthinking things.
> 
> The current plan is to push 2.4.0-1 to salsa with config as is, and then sort  
> out all the webserver config stuff in 2.4.0-2. Is that acceptable?

Of course, there is no need to rush and somewhere you need start always.

-- 
Regards
Carsten Schoenert