Running Wire backend independently

[ychost]

i am in China,because of the GFW, the speed is very slow, i want change the server to local. how can i do this thanks.

[kelvinji2009]

@ychost Please do not ask the question which is unmeaning.

[umpc]

@ychost They do not have a version that you can download. This was answered a few days ago in issue #16 by someone who used different phrasing for their question.

[marcoconti83]

Hi @ychost ,
Thanks for getting in touch.

Wire doesn't currently have a stand-alone server version that can be deployed on your own infrastructure. We have plans to make it available at some point, so please stay tuned.

As usual when we introduce new features and updates, we will make announcements on our channels:
https://medium.com/@wireapp and https://medium.com/@wireupdates.

[shahzaib414]

hey can you provide me documentation. How can i setup my own Wire Server

[rhzs]

@marcoconti83 i am so curious how can I run this repo in my local MacOS. seems like a lot of dependencies are needed.

[teller]

An update on this https://blog.wire.com/blog/server-code-open-source/

[umpc]

Thank you! That is great!

[Nemra1]

medium.com is down guys..im lost here

[teller]

Just checked, Medium works just fine. Blocked in your country?

Short story: You can't self host yet.

[Nemra1]

@teller so ..if i cant setup wire server on my vps server ) what is the point from wire server source code if we cant used him???

[andrewgdunn]

@Nemra1 quit being abusive. Wait and watch the repository for the developers to actually release this work.

[Nemra1]

@storrgie no abusive in my words..just looking for some missing elements here and frist and important thing ...we need documentation bcs not All people Experts ..we need road map and learning

[andrewgdunn]

Set your status for this repo to watch.

This is an internal project that is being re-written by the originated organization. We are beholden to their timetable.

[teller]

@Nemra1 The initial goal with releasing the code is transparency - so that people can verify that our privacy claims in fact hold true.

The next step is working on making the server self-hostable. As said in the blog post this is a significant project and will take time. @storrgie 's recommendation is a good one - just watch the repo and/or this thread.

[rhzs]

@teller yes I watched this repoo 💯
Buttt even better if you can give us schedule pleaseee? It shows real commitment from wire.

Having said that, thanks a lot for making it open source!! You guys amazing 👍

[umpc]

It takes a lot of effort to clean up a project that wasn’t destined to be open source to begin with.

I doubt they have a solid schedule, and even so, it is not going to be their top priority.

I appreciate their effort to allow self-hosting. I hope that they take as long as they need to make it correct to their standards.

[andrewgdunn]

I'll echo that I'd like to see them do it at a pace that is comfortable for the team in terms of getting the features they've already developed in the open. There are others playing in this space now, wire has a place, but it's best gained by attaining a state where people can use it comfortably... which means this repository needs to mature comfortably.

[setekhid]

@teller Any progress? Even deploying on AWS with all dependencies of external servers listed at README.md, can I run my own wire-server now?

And is there any deadline you can give out?!

[neongreen]

Even deploying on AWS with all dependencies of external servers listed at README.md, can I run my own wire-server now?

You can – for instance, some Chinese guys did just that (and forgot that our code is GPL-ed ). It's not particularly easy though.

Instead of writing a long manual about how to deploy wire-server in its current state, we have decided to spend the effort on making the from-scratch setup easy, since this way we kill two birds with one stone – our own infrastructure becomes nicer, and other people get a way to deploy their own wire-server painlessly. It requires significant effort and we have other priorities too (as @umpc rightly guessed), but I absolutely assure you that we're not slacking on it 🙂

[andrewgdunn]

@neongreen this might be a bit reductionist in view, sorry, but would it be possible to consider non AWS dependencies for self deployment as this project progresses?

I'll elaborate, there are some that can purchase bulk services (e.g. a server in a rack in a datacenter) but cannot purchase rate based services (e.g. elastic compute) due to how organizational purchasing is "handled".

[neongreen]

@storrgie the plan is to get the AWS version out first, then we will look into making it fully or partly AWS-independent (replacing EC2 is easy, replacing SES is harder). The demo (https://github.com/wireapp/wire-server/blob/develop/deploy/services-demo/README.md) works already, but the AWS replacements that it uses are not quite suitable for production.

[neongreen]

NB. In an ideal world I would just tell you exactly what is the progress on this and what are our best estimates, but if I do it, a hundred people will misinterpret "this is our best estimate" as "this is our ironclad commitment" and then throw stones at us if our plans change 😒

[andrewgdunn]

The open efforts are appreciated. I think there are many watching the project in anticipation of self hosting.

[samuelantonioli]

Here is a script to install the development version of wire-server. Please run on Ubuntu 16.04, Debian won't work for unknown reasons.

It just aggregates all the commands found in the installation docs (and those that I had to search for).

[thepill]

@samuelantonioli or anyone: AWS is a must have dependency to run this, am i right?

[samuelantonioli]

No, this uses replacements. But for production use, you should definitely use AWS services currently.

[thepill]

@samuelantonioli thanks - another question:

from your script [!] only for testing! this is not stable or secure. What exactly does/doesnt make it secure?

[samuelantonioli]

See e.g. https://github.com/wireapp/wire-server/blob/develop/deploy/services-demo/README.md

The way that the data stores used are set up is done in a simple way that is not advisable for a production environment (e.g., cassandra uses a single node and Docker will manage the storage of your database data by writing the database files to disk on the host system using its own internal volume management). Also, some other dependencies (such as the "fake" AWS services) do not provide the full functionality of the real AWS services (for instance, large resumable uploads are not supported) nor do they have the same reliability and availability.

It runs on HTTP in default mode and exposes all the other services. It isn't meant for production use, therefore I added this comment.

[neongreen]

In terms of security though, it's not significantly less secure than production backend -- the whole point of end-to-end encryption is that you retain security regardless of what the backend does. Nonetheless, some metadata like conversation titles will leak to anyone who has the ability to intercept the traffic (since, as @samuelantonioli mentioned, it doesn't use HTTPS). I'm not familiar with the state of the art in intercepting unencrypted traffic going over, say, Wi-Fi networks – but I'd be wary 🙂

[jschaul]

@neongreen @thepill - in terms of security, the demo setup (all services running on the same machine and/or in docker containers, exposing ports over plain http, without any firewall rules) is significantly less secure than the production backend, simply because there are no network restrictions built-in in this setup. Let me elaborate:

If your laptop or server is reachable from the outside, it means not only is nginz reachable on port 8080, but other services and databases are also directly reachable from outside on other ports. This allows anyone on the internet to

• query any user's information,
• make use of internal endpoints not requiring additional authorization,
• impersonate other users by making HTTP requests directly to services (such as brig) using a Z-User: <other user's uuid> header,
• talk directly to the databases and modifying information there, giving arbitrary control over accounts, conversation membership, allows deleting messages for recipients that are offline, etc.

While it is correct that the user-impersonation upon message sending can be detected by clients if fingerprint verification was performed beforehand, and in any case message content cannot be read by the server or those with access to it (assuming well-behaved clients), the demo setup can due to the above not be called "secure" by any means.

Additionally, the demo setup exposes nginz on plain http, so if you don't have your own ssl termination server in front, that allows all kinds of metadata (who, with which device/browser accessed which endpoint with which content at what time) to be read by all routers and people in the networks in between a user and the server. This is the opposite of secure.

Finally, running different services on the same physical or virtual machine is NOT recommended for security. Example: Even in a modified demo setup (in which only nginz is reachable from outside; and SSL/HTTPS in enforced), a temporary bug in nginz could allow an attacker to gain access to that machine, therefore also to the disk and RAM in use by other services (allowing to steal e.g. the private key used by the brig service to sign access tokens; allowing user impersonation even after the nginx bug is fixed (if keys are not rotated)).

So, to repeat:

⚠️ The demo setup is not secure by default. ⚠️

[fisx]

There is now also https://github.com/wireapp/wire-server-deploy. it is still an involved task to put it to work, but we are using it in production, so you should definitely take a look. If you encounter any problems or have any questions, please open an issue there.

[jschaul]

(Minor correction: we are planning to use https://github.com/wireapp/wire-server-deploy in production - migrating to it for us will still take some time - but if you're starting with a fresh installation, definitely take a look there)