Create Zulip installation process for CentOS about zulip HOT 47 OPEN

I agree. CentOS/Red Hat is most commonly used in enterprise and if Zulip wants to replace Skype in enterprise (and it should, it has a potential after all of the Skype's privacy issues) it needs to support CentOS/Red Hat 7.

from zulip.

Just an update on this, we recently completed support for installing a Zulip development environment on CentOS/Fedora/etc. Work is ongoing on production installer support.

from zulip.

All this tickets for distribution-specific installation processes would be superfluous if I just had a document that explains which components and libraries to install and how to configure them IMHO.

I don't want to run a setup/install script that magically does all the work anyway because I want to be in control of what is installed/touched on my system.

Are there any plans for distribution-agnostic installation instructions?

from zulip.

Full ack!
Especially if people want to install it with special environments like shared hosting (hxxp://uberspace.de) and cannot use the default settings.

On October 2, 2015 8:41:19 AM CEST, kostich [email protected] wrote:

I agree that making Zulip easier for installation should be the goal.
But I must disagree with a way of making it easier. :)

I know that it must be harder now but you guys need to create a
detailed guide for building and configuring Zulip from scratch. You do
not want for Zulip to become Hadoop in terms of packaging and
configuring.

Also, by doing a detailed guide, it will be eaiser for community to
understand and maybe even simplify Zulip and it's dependencies.

---

Reply to this email directly or view it on GitHub:
#41 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

from zulip.

That's why we need a well documented installation from the scratch. Then people can modify the setup for their environment. A good example is gitlab and it's installation documentation. It's possible (and not hard at all) to setup a gitlab server on a shared host like uberspace.de.

On October 2, 2015 6:21:08 PM CEST, Luke Faraone [email protected] wrote:

While possible, it would depend heavily on the particulars of each
environment.

I think we'll probably take a similar approach to Phabricator:
"this may work, but is not recommended […] we do not support shared
hosts."

---

Reply to this email directly or view it on GitHub:
#41 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

from zulip.

Now that Zulip uses a virtualenv for its dependencies, CentOS support is probably a lot easier to make happen.

from zulip.

This would be great, thanks 👍

from zulip.

👍

from zulip.

The main challenge is that Zulip uses a few dozen dependencies, several of which are newer than the latest available in most distributions. While the python dependencies are easily documented via the requirements.txt file, the installations instructions without a script would be painfully long and likely somewhat error prone unless someone builds the appropriate packages for the appropriate distributions.

For the moment, there's of course the workaround of installing an Ubuntu Trusty VM on top of your favorite distribution.

from zulip.

We just have to make scripts/setup/install call out to different install scripts based on what OS you're on. I think it's assumed that the package manager's versions will be new enough, server deployments really suck with source-built deps. (and there are always PPAs)

from zulip.

good idear

from zulip.

I agree that making Zulip easier for installation should be the goal. But I must disagree with a way of making it easier. :)

I know that it must be harder now but you guys need to create a detailed guide for building and configuring Zulip from scratch. You do not want for Zulip to become Hadoop in terms of packaging and configuring.

Also, by doing a detailed guide, it will be eaiser for community to understand and maybe even simplify Zulip and it's dependencies.

from zulip.

shared hosting

Since Zulip requires persistent workers, running in shared hosting would be incredibly difficult.

from zulip.

Why should persistent workers not be possible on a shared host?

On October 2, 2015 6:12:00 PM CEST, Luke Faraone [email protected] wrote:

shared hosting

Since Zulip requires persistent workers, running in shared hosting
would be incredibly difficult.

---

Reply to this email directly or view it on GitHub:
#41 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

from zulip.

While possible, it would depend heavily on the particulars of each environment.

I think we'll probably take a similar approach to Phabricator: "this may work, but is not recommended […] we do not support shared hosts."

from zulip.

We are a RedHat/Fedora shop, and would absolutely love to run Zulip in house! We need a secure, in-house Skype replacement in order to maintain productivity while meeting legal requirements. (increasing regulations prohibiting disclosure of client information via 3rd parties)

We'll probably try the VM route to get started, but this is in no way a preferred option since it significantly increases administration overhead.

My suggestion would be to enable this via the EPEL repositories, which satisfies RHEL, CentOS, and Fedora distributions alike, as well as access to newer packages.

Has work officially begun on this, or is this still in the discussion phase?

from zulip.

There's no official work on CentOS, but that's more due to a lack of someone having signed up to start doing the work -- I don't think more discussion is needed. I share Luke's concerns about supporting a shared hosting environment being difficult, but that's basically off-topic for this thread.

FWIW I just helped someone install a Zulip development environment on Fedora yesterday, which should at least be part of the instructions needed to do CentOS; I'll make sure to post the link to the writeup here once he puts it together.

from zulip.

@timabbott, that's great! If you managed to install Zulip on latest Fedora, it won't take a lot of work to get it working on CentOS 7.

from zulip.

@timabbott ，You want to install and are simple to install in centos environment , this is a good idea

from zulip.

So here's the PR adding instructions for installing the development environment on Fedora: #149 (needs a few fixes but basically works). I should emphasize it sets up the Zulip development environment -- so it doesn't do things like setup nginx, configure SSL certs, etc. But, it's definitely a start.

Probably the next step here would be to get the development environment running on CentOS 7, and once we have that working, we can try to get the production environment working there (that'll be harder since we'll need to come up with a plan for how to manage the configuration side of things).

from zulip.

So, @timabbott, while I am probably not qualified to lead any of this work, I am willing to throw my hat into the ring if anybody wants to get a CentOS 7 port of Zulip up and running. It's the only Linux flavor that I am any kind of familiar with and the one I run almost anywhere. What I may lack in Linux skills, I think I can make up in Python ones. So if this gets going, somebody, please let me know; I'll help :)

from zulip.

@kvorak Sweet! First you can check out: #161 for installing the development environment on CentOS which I'm hoping to merge soon once @kostich has a chance to fix a few more small things.

There are a few challenges that will need to be resolved to go from the development environment to something one can run in production. The main issues are going to be installing the dependencies:
(1) Currently scripts/setup/install expects to get the initial pre-puppet dependencies via apt (and sets up apt stuff); we could patch it to check if the system is CentOS/Fedora and do the right thing for those platforms instead (potentially just using pip with the requirements.txt like we do in development to save work packaging properly for Fedora/CentOS the right versions of Python dependencies).
(2) Currently the puppet configuration which sets up a bunch of configuration and installs a bunch of dependencies expects the Debian packages.

We could address this second issue in a few possible ways:
(A) Try to build an RPM that just installs the puppet configuration files where they go, ignoring the puppet stuff. This is annoying in that it results in another place one needs to update whenever we add a new dependency, but it might be a nicer installation mechanism in the longer term.
(B) Create some sort of sane forked puppet configuration depending on platform. Probably requires doing a bit of research into the right way to do this with puppet, and might be super annoying such that we end up either (1) ending up with 5 duplicate copies of the puppet config once we support every platform or (2) having the code get super ugly and unreadable.

If I were doing this, I would probably try investigating (B) first for a bit to check out how hard it is to make it work; it may be that the issues are all around dependency names and little things like postgres version (which we need to solve anyway to support more Ubuntu versions anyway, for example).

from zulip.

@timabbott, I think that I will have time tommorow afternoon (UTC+2) to test out and refine dev server installation instructions for Fedora 22 and CentOS 7. :)

from zulip.

How come puppet is needed at all? What about folks that user other config management systems?

from zulip.

@kostich great re: the CentOS 7 instructions :)

@fletchowns there's no fundamental need for puppet over a different configuration management system. However, we do need a way to install a decent amount of configuration for a half dozen different services, and currently the configuration to do it is stored using puppet, so even for the case where we build an RPM from the Zulip source distribution as in option "A" I described above, we'll still likely want to reuse e.g. the required nginx configuration for Zulip from where that configuration is checked into version control under the puppet/zulip/files/ tree. I don't think that we would use the actual puppet manifests for the RPM solution, but they'd still be an invaluable source for anyone looking to see exactly what one needs to do when building an RPM.

from zulip.

i'm looking to try and set this up on CentOS. Does anyone have a good reference on steps outlined to complete installation? I'm looking to get this up on a CentOS 6.7, of if there is a preference for CentOS 7 i can just do a new clean install

from zulip.

checkout
#161

from zulip.

i got stuck with the following error when trying to install requirements.txt

Complete output from command python setup.py egg_info:
Traceback (most recent call last):
File "", line 20, in
File "/tmp/pip-HYVeSu-build/setup.py", line 32, in
version = import('django').get_version()
File "django/init.py", line 1, in
from django.utils.version import get_version
File "django/utils/version.py", line 7, in
from django.utils.lru_cache import lru_cache
File "django/utils/lru_cache.py", line 28
fasttypes = {int, str, frozenset, type(None)},
^
SyntaxError: invalid syntax

from zulip.

@balwaniPrem which version of Python are you using? Zulip requires Python 2.7.x

from zulip.

Gotcha, thx @lfaraone - i'd 2.6 on it. I'll try updating it to 2.7 and running the install again.

from zulip.

Hello @zulip/server-production members, this issue was labeled with the "area: production installer" label, so you may want to check it out!

from zulip.

Ongoing PR: #11091.

from zulip.

Hi!
Is there any updates on this? Is there a procedure to instal Zulip in CentOS?

Thank you
Kind regards

from zulip.

See https://chat.zulip.org/#narrow/stream/3-backend/topic/prod.20env.20on.20CentOS.207 for current discussion.

from zulip.

I am running Fedora 34. Can anyone help me install the development server on Fedora 34.

On running ./tools/provision I get this error:

`CRITICAL:root:Unsupported platform: fedora 34

Provisioning failed (exit code 1)!

• Look at the traceback(s) above to find more about the errors.
• Resolve the errors or get help on chat.
• If you can fix this yourself, you can re-run tools/provision at any time.
• Logs are here: zulip/var/log/provision.log
  `

from zulip.

Yeah, Fedora 34 hasn't been tested, and so the dev setup fails. If you want to test if it works, you can replace the 33 https://github.com/zulip/zulip/blob/master/tools/lib/provision.py#L108 with 34. If it works, do report the fact in chat.zulip.org and so the installer will be updated to include Fedora 34.

from zulip.

I got the following error on doing so:

Error: Transaction test error:
file /usr/share/doc/libxml2-devel/examples/Makefile conflicts between attempted installs of libxml2-devel-2.9.12-2.fc34.i686 and libxml2-devel-2.9.12-2.fc34.x86_64

Error running a subcommand of ./lib/provision.py: sudo -- ./scripts/lib/setup-yum-repo
Actual error output for the subcommand is just above this.

Traceback (most recent call last):
File "/home/manavdesai/zulip/tools/./lib/provision.py", line 481, in
main(options)
File "/home/manavdesai/zulip/tools/./lib/provision.py", line 377, in main
raise e from None
File "/home/manavdesai/zulip/tools/./lib/provision.py", line 374, in main
install_system_deps()
File "/home/manavdesai/zulip/tools/./lib/provision.py", line 236, in install_system_deps
install_yum_deps(deps_to_install)
File "/home/manavdesai/zulip/tools/./lib/provision.py", line 272, in install_yum_deps
run_as_root(["./scripts/lib/setup-yum-repo"])
File "/home/manavdesai/zulip/scripts/lib/zulip_tools.py", line 518, in run_as_root
run(args, **kwargs)
File "/home/manavdesai/zulip/scripts/lib/zulip_tools.py", line 228, in run
subprocess.check_call(args, **kwargs)
File "/usr/lib64/python3.9/subprocess.py", line 373, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '--', './scripts/lib/setup-yum-repo']' returned non-zero exit status 1.

Provisioning failed (exit code 1)!

• Look at the traceback(s) above to find more about the errors.
• Resolve the errors or get help on chat.
• If you can fix this yourself, you can re-run tools/provision at any time.
• Logs are here: zulip/var/log/provision.log

from zulip.

Alright I fixed that error. Now I am getting the following error:

[MIRROR] pgdg-fedora10-10-4.noarch.rpm: Status code: 404 for https://download.postgresql.org/pub/repos/yum/10/fedora/fedora-34-x86_64/pgdg-fedora10-10-4.noarch.rpm (IP: 2604:1380:2000:7501::69)

[MIRROR] pgdg-fedora10-10-4.noarch.rpm: Status code: 404 for https://download.postgresql.org/pub/repos/yum/10/fedora/fedora-34-x86_64/pgdg-fedora10-10-4.noarch.rpm (IP: 2604:1380:2000:7501::69)

[MIRROR] pgdg-fedora10-10-4.noarch.rpm: Status code: 404 for https://download.postgresql.org/pub/repos/yum/10/fedora/fedora-34-x86_64/pgdg-fedora10-10-4.noarch.rpm (IP: 2604:1380:2000:7501::69)

[MIRROR] pgdg-fedora10-10-4.noarch.rpm: Status code: 404 for https://download.postgresql.org/pub/repos/yum/10/fedora/fedora-34-x86_64/pgdg-fedora10-10-4.noarch.rpm (IP: 2604:1380:2000:7501::69)

[FAILED] pgdg-fedora10-10-4.noarch.rpm: Status code: 404 for https://download.postgresql.org/pub/repos/yum/10/fedora/fedora-34-x86_64/pgdg-fedora10-10-4.noarch.rpm (IP: 2604:1380:2000:7501::69)

Status code: 404 for https://download.postgresql.org/pub/repos/yum/10/fedora/fedora-34-x86_64/pgdg-fedora10-10-4.noarch.rpm (IP: 2604:1380:2000:7501::69)

from zulip.

Since PGroonga hasn't built that package for Fedora, you need to set the flag to build it from source in provision.py. Search for pgroonga in that file and you'll find it.

from zulip.

That's strange, since in

from zulip.

It's an old issue - is it still under consideration? Because I've managed to install zulip on Rockylinux9 and I'm not sure if my work will be beneficial for anyone?

from zulip.

@moonwolf-github , IMHO I do not see the value in this anymore. Instead of having distribution-specific steps, it's better to use container images and run services inside containers.

Of course, this is just my opinion.

from zulip.

OK, but zulip-docker is still in Alpha. Is it ready for use in production?

from zulip.

We don't run docker-zulip in production ourselves, but that's purely because our production environment is not Docker-based. We're aware of folks who do run it in production. "beta" is probably a better label for it at this point.

I'm also of the opinion that the stunted and decaying vestiges of CentOS support would be better off removed.

from zulip.

@moonwolf-github Can you share how you installed Zulip on Rocky Linux?

from zulip.

I'm also of the opinion that the stunted and decaying vestiges of CentOS support would be better off removed.

I agree, I think the prod install should have very few select similar OSes (Debians and Ubuntus) supported, with the rest being supported via Docker, so that the code is more concise (can fit in one's head RAM), and easier to maintain.

This is the current solution, but having everything being declarative in Nix would be nice, so it works on even Darwin out of the box / with minimal extra setup, and that there are no need for Vagrant for dev and Puppet for prod.

from zulip.

@moonwolf-github Can you share how you installed Zulip on Rocky Linux?

It's in my fork: https://github.com/moonwolf-github/zulip

Unfortunately, it is a mess so I don't guarantee it will work.

from zulip.