4 ms·

> Point in time backups isn't trivial either Have you tried our built-in backups tool? See https://zulip.readthedocs.io/en/latest/production/export-and-import

> Point in time backups isn't trivial either Have you tried our built-in backups tool? See https://zulip.readthedocs.io/en/latest/production/export-and-import.html#backups https://zulip.readthedocs.io/en/latest/production/export-and... > How do I connect to existing databases? It's straightforward in the inline configuration file, see https://github.com/zulip/zulip/blob/master/zproject/prod_settings_template.py#L434 https://github.com/zulip/zulip/blob/master/zproject/prod_set... There's more detailed documentation available here: https://zulip.readthedocs.io/en/latest/production/deployment.html#running-zulip-s-service-dependencies-on-different-machines https://zulip.readthedocs.io/en/latest/production/deployment... We only store transient cache-type state in memcached/redis/rabbitmq, but they have similar configuration options. > How do I store this in an existing configuration management system? Our intent is that you configure /etc/zulip using your configuration management system and then use the Zulip installer to install the Zulip software (and it'll configure the services you've configured it to manage accordingly). Our puppet rules are intentionally written to allow only running the application frontend role on a system (as we do in our own production systems). > You'd better run in on the recommended Ubuntu version, any deviations will cause the above procedure to explode into a ball of mud. We support all Debian releases and Ubuntu LTS releases in production (which are the only ones worth supporting given that their-non LTS releases are only supported by Ubuntu itself for a few months and thus are structurally long-lived betas). And we're working on CentOS/RHEL support. I'd love to collaborate on how we can improve Zulip's documentation around your use case. Would you be up for stopping by chat.zulip.org to discuss specific changes?

xorcist 6y ago
The backstory here is that I pitched Zulip for an organization which I suspect would be an ideal customer fit. They told me later they had evaluated it but since it wasn't operationally sound, they didn't take it further. Being surprised by this I spend a number of hours on my own with the product, so I did not write the above lightly. The installation example is just an example. If script doesn't run or doesn't do what you want, it doesn't help. Perhaps the basic problem here is that you are expected to run a script to set up a complex system, with a number of dependencies on the platform repos, where you'd expect to just unpack a tarball and modify an example config to get running. This is not completely unheard of, it used to be common with proprietary unices, but most were just a basic shar script whereas this is a series chained scripts where if the version of Puppet on your platform isn't what the script expect it's really hard to even get started. And, no, Debian is (sadly) not as big with enterprises as Red Hat and SuSE is. It might however be a mistake to tie software to a specific Linux distribution at all. Those are moving targets and work is probably better spent on other things. I could elaborate further on software procurement if this anecdoctal evidence is of any use. Generally, there are boxes to be ticked, and things like four interlocking databases and a dump script in cron makes it hard for a DBA to answer if point in time recovery will be possible.

xorcist 6y ago

The backstory here is that I pitched Zulip for an organization which I suspect would be an ideal customer fit. They told me later they had evaluated it but since it wasn't operationally sound, they didn't take it further. Being surprised by this I spend a number of hours on my own with the product, so I did not write the above lightly. The installation example is just an example. If script doesn't run or doesn't do what you want, it doesn't help. Perhaps the basic problem here is that you are expected to run a script to set up a complex system, with a number of dependencies on the platform repos, where you'd expect to just unpack a tarball and modify an example config to get running. This is not completely unheard of, it used to be common with proprietary unices, but most were just a basic shar script whereas this is a series chained scripts where if the version of Puppet on your platform isn't what the script expect it's really hard to even get started. And, no, Debian is (sadly) not as big with enterprises as Red Hat and SuSE is. It might however be a mistake to tie software to a specific Linux distribution at all. Those are moving targets and work is probably better spent on other things. I could elaborate further on software procurement if this anecdoctal evidence is of any use. Generally, there are boxes to be ticked, and things like four interlocking databases and a dump script in cron makes it hard for a DBA to answer if point in time recovery will be possible.