weixin_39775577
2020-12-05 10:36 阅读 1

Update pretix via WebGUI

Update the pretix via WebGUI so you don't need shell access.

该提问来源于开源项目:pretix/pretix

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

4条回答 默认 最新

  • weixin_39604685 weixin_39604685 2020-12-05 10:36

    First of all, thanks for the suggestion. I'd also like to have this feature, not only to get updates rolled out more quickly, but even more to be able to easily install plugins. However, there is quite a number of concerns that I have and while I'm always open to discussion, I'm only that much away from closing this as "wontfix".

    Consistency

    Currently, there are two official ways to install pretix: Using docker and manual installation via pip or from git. For both of them, we provide tutorials to help beginners, but with both ways, you can greatly deviate from the tutorials and there are good reasons to do so. For example, in both the docker and the manual case you could run the pretix processes (web process and worker process) across multiple machines. You could use one of the multitude of orchestration tools for docker, e.g. docker-compose or something more complex like kubernetes. You could automate your manual installation using a tool like Ansible, Salt or Puppet. You could use your distribution's package manager to install the dependencies or use pip. You could use your distribution's python version or roll your own. You could run the processes using systemd or supervisord or upstart or whatever floats your boat on Debian, CentOS, FreeBSD or maybe even Windows (haven't tried yet, but should work). There are good reasons for most of those decisions and I've seen most of them in practice. I'm a sysadmin for currently three installations of pretix that are vastly different from each other.

    pretix doesn't know about most of these differences, because it doesn't care. That's a good thing, it proves that the system is flexible and it makes sysadmins of very different taste happy.

    Auto-updating could only support very very few of those cases and would require us to introduce a lot of new assumptions. The docker installation couldn't use it, because it's good practice to keep docker containers immutable and our container shouldn't be able to talk to the docker host and recreate/restart itself for a number of reasons. Using a provisioning tool like Ansible would require very special care in combination with such a system. Self-updating the software in-place across multiple machines also sounds quite ambitious.

    Frankly, any straightforward implementation of this couldn't properly support any of the three installations I maintain. I see this as a very bad smell, not only because that means I wouldn't even notice if it breaks, but also because it suggests that it might pose large problems to other admins. Furthermore, other people don't know the system as well as I do and might not even see that and why they shouldn't do it. I don't really like the idea of pretix installations becoming even more different than they are now.

    Compatibility

    We won't break anything between patch-level releases (except if required to fix vulnerabilities or critical bugs), but between feature releases (like 1.x.y to 1.z.0), we currently make very limited promises about compatibility to external systems. Of course, we try to make it backwards-compatible and easy most of the time, but in general, new versions of pretix might for example

    • require new system-level (non-python) dependencies
    • require a newer version of python
    • introduce code changes that break all plugins
    • require new external components (maybe redis doesn't stay optional forever?)
    • require you to adjust your webserver or database configuration
    • require you to adjust your pretix.cfg config file
    • require you to run a special upgrade command

    Some of those cases could be automated, at least for some setups, but most of them couldn't (see also: security concerns). In all those cases, self-updating could break and you wouldn't want a non-technical person or a person without access to the operating system to (accidentally) update the system. You'd want your sysadmin to be there 😉

    Security

    Updating means automatically downloading and executing code, which would require great care to avoid introducing vulnerabilities here. This would be even worse with plugin installations. Additionally, even though it might be possible in most current installations, there is no reason why a running pretix process should be able to alter its own source code and it might be a good idea from a security standpoint to disable it.

    For all those reasons and maybe more, I believe the automatic update check and notifications that we introduced in 1.2.x are the closest we get here. If someone wants to go through the trouble of packaging this in a standardized and isolated way like the GitLab Omnibus package and would commit to maintaining that in the long run, that could help with some of the problems above, but still not with all of them.

    Cheers Raphael

    P.S.: You suggested on twitter to talk this through on e.g. IRC, we can totally do that, but if we keep the discussion here, people can read up on it later and it can be helpful both for me to point people to if they ask for this feature again and for other projects to learn from, so if it's no trouble for you, lets stay here.

    点赞 评论 复制链接分享
  • weixin_39604685 weixin_39604685 2020-12-05 10:36

    Also, for other folks reading this: If you don't want to go through the trouble of updating your own installation, there is always the possibility of using the hosted version running on pretix.eu 😉

    点赞 评论 复制链接分享
  • weixin_39775577 weixin_39775577 2020-12-05 10:36

    Following points are not in the right order.

    non-technical persons

    In all those cases, self-updating could break and you wouldn't want a non-technical person or a person without access to the operating system to (accidentally) update the system. In 1.4.0 you've released a Team Management with IMHO better rights management, so maybe you could create a "updater" role which has the "Update" Button.

    Compatibility As pointed out on Twitter, it also could be a alternative to provide web-updater feature only for 1 Version (p.e. only pip installed Versions on Linux hosts), I see that it's not the best way & you kinda push people without /that/ much SysAdmin Skills towards that solution, but it could be an option.

    Security I see your points concerning the security, and I much appreciate that it's clear that you don't do something giddily with pretix. I must admit I'm not a dev and I don't totally understand the way of a Update via pip, but isn't it possible to create a 3rd process (pretix-updater) running as user "pretix" and connected to the pretix-worker, so when a new release comes out the user can trigger the update, so the "pretix-updater" can launch the venv and do the Update.

    P.S.: Yeah, i forgot that there is a github issue page to comment on... ;D So no problem for me discussing this here. :)

    点赞 评论 复制链接分享
  • weixin_39604685 weixin_39604685 2020-12-05 10:36

    I'm gonna close this for now as I don't see that my opinion on this will likely change ;)

    点赞 评论 复制链接分享

相关推荐