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

Thu Mar 29 11:07:41 UTC 2018

Carsten Schoenert writes:

> > 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!

I have the same with the Kopano backend though..

This is just to let you know that 2.4.0 was pushed to Salsa without further  
changes to the web server configs. I'll look at those soonish.

Thanks for your extensive reply about that, I'll come back to it!

Cheers,

Roel

> > 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
>
> _______________________________________________
> 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