2016-01-12 13:08:43 +01:00
|
|
|
#!/usr/bin/env bash
|
2017-10-02 01:48:25 +02:00
|
|
|
set -e
|
|
|
|
|
|
|
|
usage() {
|
2017-11-15 21:09:53 +01:00
|
|
|
cat <<EOF
|
|
|
|
Usage:
|
2018-03-03 01:10:51 +01:00
|
|
|
install --hostname=zulip.example.com --email=admin@example.com [options...]
|
2017-11-15 21:09:53 +01:00
|
|
|
install --help
|
|
|
|
|
2018-01-23 00:12:00 +01:00
|
|
|
Other options:
|
2018-03-03 01:10:51 +01:00
|
|
|
--certbot
|
2018-01-24 02:03:18 +01:00
|
|
|
--self-signed-cert
|
2018-03-03 01:10:51 +01:00
|
|
|
--no-init-db
|
|
|
|
|
|
|
|
The --hostname and --email options are required,
|
|
|
|
unless --no-init-db is set and --certbot is not.
|
|
|
|
|
2017-11-15 21:09:53 +01:00
|
|
|
EOF
|
2017-10-02 01:48:25 +02:00
|
|
|
exit 0
|
|
|
|
};
|
|
|
|
|
|
|
|
# Shell option parsing. Over time, we'll want to move some of the
|
|
|
|
# environment variables below into this self-documenting system.
|
2018-03-03 01:10:51 +01:00
|
|
|
args="$(getopt -o '' --long help,no-init-db,self-signed-cert,certbot,hostname:,email: -n "$0" -- "$@")"
|
2017-10-02 01:48:25 +02:00
|
|
|
eval "set -- $args"
|
|
|
|
while true; do
|
|
|
|
case "$1" in
|
2018-02-09 02:12:36 +01:00
|
|
|
--help) usage;;
|
2018-02-09 02:05:13 +01:00
|
|
|
--self-signed-cert) SELF_SIGNED_CERT=1; shift;;
|
|
|
|
--certbot) USE_CERTBOT=1; shift;;
|
|
|
|
--hostname) EXTERNAL_HOST="$2"; shift; shift;;
|
|
|
|
--email) ZULIP_ADMINISTRATOR="$2"; shift; shift;;
|
2018-03-03 01:10:51 +01:00
|
|
|
--no-init-db) NO_INIT_DB=1; shift;;
|
2018-02-09 02:05:13 +01:00
|
|
|
--) shift; break;;
|
2017-10-02 01:48:25 +02:00
|
|
|
esac
|
|
|
|
done
|
|
|
|
|
2018-01-24 22:23:47 +01:00
|
|
|
if [ "$#" -gt 0 ]; then
|
|
|
|
usage
|
|
|
|
fi
|
|
|
|
|
2018-02-09 02:12:36 +01:00
|
|
|
## Options from environment variables.
|
|
|
|
#
|
|
|
|
# Specify options for apt.
|
|
|
|
APT_OPTIONS="${APT_OPTIONS:-}"
|
|
|
|
# Install additional packages using apt.
|
|
|
|
ADDITIONAL_PACKAGES=${ADDITIONAL_PACKAGES:-}
|
|
|
|
# Deployment type is almost always voyager.
|
|
|
|
DEPLOYMENT_TYPE="${DEPLOYMENT_TYPE:-voyager}"
|
|
|
|
# Comma-separated list of puppet manifests to install. default is
|
|
|
|
# zulip::voyager for an all-in-one system or zulip::dockervoyager for
|
|
|
|
# Docker. Use e.g. zulip::app_frontend for a Zulip frontend server.
|
|
|
|
PUPPET_CLASSES="${PUPPET_CLASSES:-zulip::voyager}"
|
|
|
|
VIRTUALENV_NEEDED="${VIRTUALENV_NEEDED:-yes}"
|
2013-11-14 06:32:49 +01:00
|
|
|
|
2018-01-24 02:13:09 +01:00
|
|
|
if [ -n "$SELF_SIGNED_CERT" ] && [ -n "$USE_CERTBOT" ]; then
|
|
|
|
echo "error: --self-signed-cert and --certbot are incompatible" >&2
|
|
|
|
echo >&2
|
|
|
|
usage
|
|
|
|
fi
|
|
|
|
|
2018-03-03 01:10:51 +01:00
|
|
|
if [ -z "$EXTERNAL_HOST" ] || [ -z "$ZULIP_ADMINISTRATOR" ]; then
|
|
|
|
if [ -n "$USE_CERTBOT" ] || [ -z "$NO_INIT_DB" ]; then
|
|
|
|
usage
|
|
|
|
fi
|
2018-02-09 01:33:53 +01:00
|
|
|
fi
|
|
|
|
|
2017-10-02 01:48:25 +02:00
|
|
|
# Do set -x after option parsing is complete
|
|
|
|
set -x
|
2013-11-14 06:32:49 +01:00
|
|
|
|
2018-02-09 02:19:40 +01:00
|
|
|
ZULIP_PATH="$(readlink -f $(dirname $0)/../..)"
|
|
|
|
|
2017-11-23 03:03:44 +01:00
|
|
|
# Force a known locale. Some packages on PyPI fail to install in some locales.
|
|
|
|
export LC_ALL="en_US.UTF-8"
|
|
|
|
|
2018-03-07 04:26:02 +01:00
|
|
|
# Check for a supported OS release.
|
|
|
|
apt-get install -y lsb-release
|
|
|
|
os_release="$(lsb_release -sc)"
|
|
|
|
case "$os_release" in
|
|
|
|
trusty|xenial) ;;
|
|
|
|
*)
|
|
|
|
set +x
|
|
|
|
cat <<EOF
|
|
|
|
|
|
|
|
Unsupported OS release: $os_release
|
|
|
|
|
|
|
|
Zulip in production is supported only on:
|
|
|
|
- Ubuntu 14.04 LTS "trusty"
|
|
|
|
- Ubuntu 16.04 LTS "xenial"
|
|
|
|
|
|
|
|
For more information, see:
|
|
|
|
https://zulip.readthedocs.io/en/latest/production/requirements.html
|
|
|
|
EOF
|
|
|
|
exit 1
|
|
|
|
esac
|
|
|
|
|
2016-12-01 00:29:14 +01:00
|
|
|
# Check for at least ~1.9GB of RAM before starting installation;
|
|
|
|
# otherwise users will find out about insufficient RAM via weird
|
|
|
|
# errors like a segfault running `pip install`.
|
|
|
|
mem_kb=$(cat /proc/meminfo | head -n1 | awk '{print $2}')
|
|
|
|
if [ "$mem_kb" -lt 1900000 ]; then
|
|
|
|
echo "Insufficient RAM. Zulip requires at least 2GB of RAM."
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
|
2016-10-16 09:56:58 +02:00
|
|
|
# setup-apt-repo does an `apt-get update`
|
2016-09-15 19:29:56 +02:00
|
|
|
"$ZULIP_PATH"/scripts/lib/setup-apt-repo
|
2016-08-05 22:27:03 +02:00
|
|
|
|
2016-11-23 15:49:15 +01:00
|
|
|
# Handle issues around upstart on Ubuntu Xenial
|
|
|
|
"$ZULIP_PATH"/scripts/lib/check-upstart
|
|
|
|
|
2018-01-23 00:12:00 +01:00
|
|
|
# Check early for missing SSL certificates
|
2018-01-24 02:03:18 +01:00
|
|
|
if [ "$PUPPET_CLASSES" = "zulip::voyager" ] && [ -z "$USE_CERTBOT""$SELF_SIGNED_CERT" ] && { ! [ -e "/etc/ssl/private/zulip.key" ] || ! [ -e "/etc/ssl/certs/zulip.combined-chain.crt" ]; }; then
|
2018-02-09 02:05:13 +01:00
|
|
|
set +x
|
|
|
|
echo
|
|
|
|
echo "Could not find SSL certificates!"
|
|
|
|
for f in "/etc/ssl/private/zulip.key" "/etc/ssl/certs/zulip.combined-chain.crt"; do
|
|
|
|
[ -e "$f" ] || echo " - $f is missing!"
|
|
|
|
done
|
|
|
|
cat <<EOF
|
|
|
|
|
|
|
|
See https://zulip.readthedocs.io/en/latest/production/ssl-certificates.html for help.
|
|
|
|
For non-production testing, try the --self-signed-cert option.
|
|
|
|
|
|
|
|
Once fixed, just rerun scripts/setup/install; it'll pick up from here!
|
|
|
|
|
|
|
|
EOF
|
2017-10-24 22:30:27 +02:00
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
|
2017-08-23 23:54:59 +02:00
|
|
|
apt-get -y dist-upgrade $APT_OPTIONS
|
2018-01-22 23:34:29 +01:00
|
|
|
apt-get install -y \
|
2018-03-30 01:02:50 +02:00
|
|
|
puppet git curl wget \
|
2018-01-22 23:34:29 +01:00
|
|
|
python python3 python-six python3-six crudini \
|
|
|
|
$ADDITIONAL_PACKAGES
|
2017-08-23 23:54:59 +02:00
|
|
|
|
2018-01-23 00:12:00 +01:00
|
|
|
if [ -n "$USE_CERTBOT" ]; then
|
|
|
|
"$ZULIP_PATH"/scripts/setup/setup-certbot \
|
|
|
|
--no-zulip-conf --method=standalone \
|
|
|
|
--hostname "$EXTERNAL_HOST" --email "$ZULIP_ADMINISTRATOR"
|
2018-02-09 01:27:13 +01:00
|
|
|
elif [ -n "$SELF_SIGNED_CERT" ]; then
|
|
|
|
"$ZULIP_PATH"/scripts/setup/generate-self-signed-cert \
|
|
|
|
--exists-ok "${EXTERNAL_HOST:-$(hostname)}"
|
2018-01-23 00:12:00 +01:00
|
|
|
fi
|
|
|
|
|
2016-06-22 21:00:50 +02:00
|
|
|
# Create and activate a virtualenv
|
2016-07-12 20:46:49 +02:00
|
|
|
if [ "$VIRTUALENV_NEEDED" = "yes" ]; then
|
2016-11-20 05:45:53 +01:00
|
|
|
"$ZULIP_PATH"/scripts/lib/create-production-venv "$ZULIP_PATH"
|
2016-07-12 20:46:49 +02:00
|
|
|
fi
|
2016-06-22 21:00:50 +02:00
|
|
|
|
2017-01-07 00:57:42 +01:00
|
|
|
"$ZULIP_PATH"/scripts/lib/install-node
|
|
|
|
|
2018-02-09 02:14:28 +01:00
|
|
|
# Generate /etc/zulip/zulip.conf .
|
2013-11-14 06:32:49 +01:00
|
|
|
mkdir -p /etc/zulip
|
travis: Remove rabbitmq nodename dependency on hostname.
Because rabbitmq doesn't support changing the nodename of a running
rabbitmq node, Zulip installations suffered a plague of issues where
e.g. a Zulip server would reboot, the hostname would change, and
suddenly the local rabbitmq instance being used by Zulip would stop
working.
We address this problem by using, by default, a fixed rabbitmq
nodename, but providing server administrators the option to set the
rabbitmq nodename used by Zulip however they choose.
To upgrade an existing server to use this new configuration, one will
need to add something like the following to /etc/zulip/zulip.conf:
[rabbitmq]
nodename = zulip@localhost
However, I don't believe we have the puppet code in place to make this
work correctly at initial installation without rabbitmq-server being
already installed (but off), as we can easily setup in Travis CI but I
haven't been willing to do for the installer. So for now, this just
fixes our Travis CI problems.
Fixes: #1579.
2016-08-10 03:40:07 +02:00
|
|
|
(
|
2018-02-09 02:05:13 +01:00
|
|
|
cat <<EOF
|
|
|
|
[machine]
|
|
|
|
puppet_classes = $PUPPET_CLASSES
|
|
|
|
deploy_type = $DEPLOYMENT_TYPE
|
|
|
|
EOF
|
2016-11-20 06:36:04 +01:00
|
|
|
|
|
|
|
# Note: there are four dpkg-query outputs to consider:
|
|
|
|
#
|
|
|
|
# root@host# dpkg-query --showformat '${Status}\n' -W rabbitmq-server 2>/dev/null
|
|
|
|
# root@host# apt install rabbitmq-server
|
|
|
|
# root@host# dpkg-query --showformat '${Status}\n' -W rabbitmq-server 2>/dev/null
|
|
|
|
# install ok installed
|
|
|
|
# root@host# apt remove rabbitmq-server
|
|
|
|
# root@host# dpkg-query --showformat '${Status}\n' -W rabbitmq-server 2>/dev/null
|
|
|
|
# deinstall ok config-files
|
|
|
|
# root@host# apt purge rabbitmq-server
|
|
|
|
# root@host# dpkg-query --showformat '${Status}\n' -W rabbitmq-server 2>/dev/null
|
|
|
|
# unknown ok not-installed
|
|
|
|
#
|
|
|
|
# (There are more possibilities in the case of dpkg errors.) Here
|
|
|
|
# we are checking for either empty or not-installed.
|
|
|
|
if [ -n "$TRAVIS" ] || ! dpkg-query --showformat '${Status}\n' -W rabbitmq-server 2>/dev/null | grep -vq ' not-installed$'; then
|
2018-02-09 02:05:13 +01:00
|
|
|
cat <<EOF
|
|
|
|
|
|
|
|
[rabbitmq]
|
|
|
|
nodename = zulip@localhost
|
|
|
|
EOF
|
travis: Remove rabbitmq nodename dependency on hostname.
Because rabbitmq doesn't support changing the nodename of a running
rabbitmq node, Zulip installations suffered a plague of issues where
e.g. a Zulip server would reboot, the hostname would change, and
suddenly the local rabbitmq instance being used by Zulip would stop
working.
We address this problem by using, by default, a fixed rabbitmq
nodename, but providing server administrators the option to set the
rabbitmq nodename used by Zulip however they choose.
To upgrade an existing server to use this new configuration, one will
need to add something like the following to /etc/zulip/zulip.conf:
[rabbitmq]
nodename = zulip@localhost
However, I don't believe we have the puppet code in place to make this
work correctly at initial installation without rabbitmq-server being
already installed (but off), as we can easily setup in Travis CI but I
haven't been willing to do for the installer. So for now, this just
fixes our Travis CI problems.
Fixes: #1579.
2016-08-10 03:40:07 +02:00
|
|
|
fi
|
2017-11-15 00:48:22 +01:00
|
|
|
|
|
|
|
if [ -n "$USE_CERTBOT" ]; then
|
2018-02-09 02:05:13 +01:00
|
|
|
cat <<EOF
|
|
|
|
|
|
|
|
[certbot]
|
|
|
|
auto_renew = yes
|
|
|
|
EOF
|
2017-11-15 00:48:22 +01:00
|
|
|
fi
|
travis: Remove rabbitmq nodename dependency on hostname.
Because rabbitmq doesn't support changing the nodename of a running
rabbitmq node, Zulip installations suffered a plague of issues where
e.g. a Zulip server would reboot, the hostname would change, and
suddenly the local rabbitmq instance being used by Zulip would stop
working.
We address this problem by using, by default, a fixed rabbitmq
nodename, but providing server administrators the option to set the
rabbitmq nodename used by Zulip however they choose.
To upgrade an existing server to use this new configuration, one will
need to add something like the following to /etc/zulip/zulip.conf:
[rabbitmq]
nodename = zulip@localhost
However, I don't believe we have the puppet code in place to make this
work correctly at initial installation without rabbitmq-server being
already installed (but off), as we can easily setup in Travis CI but I
haven't been willing to do for the installer. So for now, this just
fixes our Travis CI problems.
Fixes: #1579.
2016-08-10 03:40:07 +02:00
|
|
|
) > /etc/zulip/zulip.conf
|
2018-02-09 02:14:28 +01:00
|
|
|
|
2016-09-15 19:29:56 +02:00
|
|
|
"$ZULIP_PATH"/scripts/zulip-puppet-apply -f
|
2013-11-14 06:32:49 +01:00
|
|
|
|
2016-07-12 05:35:14 +02:00
|
|
|
# Detect which features were selected for the below
|
2016-07-20 04:05:02 +02:00
|
|
|
set +e
|
2016-07-12 05:35:14 +02:00
|
|
|
[ -e "/etc/init.d/camo" ]; has_camo=$?
|
|
|
|
[ -e "/etc/init.d/nginx" ]; has_nginx=$?
|
|
|
|
[ -e "/etc/supervisor/conf.d/zulip.conf" ]; has_appserver=$?
|
|
|
|
[ -e "/etc/cron.d/rabbitmq-numconsumers" ]; has_rabbit=$?
|
|
|
|
[ -e "/etc/init.d/postgresql" ]; has_postgres=$?
|
2016-07-20 04:05:02 +02:00
|
|
|
set -e
|
2016-07-12 05:35:14 +02:00
|
|
|
|
2016-07-20 11:55:45 +02:00
|
|
|
# Docker service setup is done in the docker config, not here
|
|
|
|
if [ "$DEPLOYMENT_TYPE" = "dockervoyager" ]; then
|
|
|
|
has_camo=1
|
|
|
|
has_nginx=1
|
|
|
|
has_appserver=1
|
|
|
|
has_rabbit=1
|
|
|
|
has_postgres=1
|
|
|
|
fi
|
|
|
|
|
2013-11-14 06:32:49 +01:00
|
|
|
# These server restarting bits should be moveable into puppet-land, ideally
|
|
|
|
apt-get -y upgrade
|
2016-07-12 05:35:14 +02:00
|
|
|
|
|
|
|
if [ "$has_nginx" = 0 ]; then
|
2015-10-21 08:23:24 +02:00
|
|
|
# Check nginx was configured properly now that we've installed it.
|
|
|
|
# Most common failure mode is certs not having been installed.
|
2017-10-24 22:30:27 +02:00
|
|
|
nginx -t || (
|
|
|
|
set +x
|
2018-02-09 02:05:13 +01:00
|
|
|
cat <<EOF
|
|
|
|
|
|
|
|
Verifying the Zulip nginx configuration failed!
|
|
|
|
|
|
|
|
This is almost always a problem with your SSL certificates. See:
|
|
|
|
https://zulip.readthedocs.io/en/latest/production/ssl-certificates.html
|
|
|
|
|
|
|
|
Once fixed, just rerun scripts/setup/install; it'll pick up from here!
|
|
|
|
|
|
|
|
EOF
|
2017-10-24 22:30:27 +02:00
|
|
|
exit 1
|
|
|
|
)
|
2013-11-14 06:32:49 +01:00
|
|
|
service nginx restart
|
|
|
|
fi
|
|
|
|
|
2016-07-12 05:35:14 +02:00
|
|
|
if [ "$has_appserver" = 0 ]; then
|
2016-09-15 19:29:56 +02:00
|
|
|
"$ZULIP_PATH"/scripts/setup/generate_secrets.py --production
|
|
|
|
cp -a "$ZULIP_PATH"/zproject/prod_settings_template.py /etc/zulip/settings.py
|
2017-10-02 01:48:25 +02:00
|
|
|
if [ -n "$EXTERNAL_HOST" ]; then
|
|
|
|
sed -i "s/^EXTERNAL_HOST =.*/EXTERNAL_HOST = '$EXTERNAL_HOST'/" /etc/zulip/settings.py
|
|
|
|
fi
|
|
|
|
if [ -n "ZULIP_ADMINISTRATOR" ]; then
|
|
|
|
sed -i "s/^ZULIP_ADMINISTRATOR =.*/ZULIP_ADMINISTRATOR = '$ZULIP_ADMINISTRATOR'/" /etc/zulip/settings.py
|
|
|
|
fi
|
2016-09-15 19:29:56 +02:00
|
|
|
ln -nsf /etc/zulip/settings.py "$ZULIP_PATH"/zproject/prod_settings.py
|
2016-07-12 05:35:14 +02:00
|
|
|
fi
|
2013-11-14 06:32:49 +01:00
|
|
|
|
2016-04-28 07:32:27 +02:00
|
|
|
# Restart camo since generate_secrets.py likely replaced its secret key
|
install: Work around a bug in the (our) Debian package for camo.
Before this fix, the installer has an extremely annoying bug where
when run inside a container with `lxc-attach`, when the installer
finishes, the `lxc-attach` just hangs and doesn't respond even to
C-c or C-z. The only way to get the terminal back is to root around
from some other terminal to find the PID and kill it; then run
something like `stty sane` to fix the messed-up terminal settings
left behind.
After bisecting pieces of the install script to locate which step
was causing the issue, it comes down to the `service camo restart`.
The comment here indicates that we knew about an annoying bug here
years ago, and just swept it under the rug by skipping this step
when in Travis. >_<
The issue can be reproduced by running simply `service camo restart`
under `lxc-attach` instead of the installer; or `service camo start`,
following a `service camo stop`. If `lxc-attach` is used to get an
interactive shell, these commands appear to work fine; but then when
that shell exits, the same hang appears. So, when we start camo
we're evidently leaving some kind of mess that entangles the daemon
with our shell.
Looking at the camo initscript where it starts the daemon, there's
not much code, and one flag jumps out as suspicious:
start-stop-daemon --start --quiet --pidfile $PIDFILE -bm \
--exec $DAEMON --no-close -c nobody --test > /dev/null 2>&1 \
|| return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE -bm \
--no-close -c nobody --exec $DAEMON -- \
$DAEMON_ARGS >> /var/log/camo/camo.log 2>&1 \
|| return 2
What does `--no-close` do?
-C, --no-close
Do not close any file descriptor when forcing the daemon
into the background (since version 1.16.5). Used for
debugging purposes to see the process output, or to
redirect file descriptors to log the process output.
And in fact, looking in /proc/PID/fd while a hang is happening finds
that fd 0 on the camo daemon process, aka stdin, is connected to our
terminal.
So, stop that by denying the initscript our stdin in the first place.
This fixes the problem.
The Debian maintainer turns out to be "Zulip Debian Packaging Team",
at debian@zulip.com; so this package and its bugs are basically ours.
2018-01-23 02:27:35 +01:00
|
|
|
if [ "$has_camo" = 0 ]; then
|
|
|
|
# Cut off stdin because a bug in the Debian packaging for camo
|
|
|
|
# causes our stdin to leak to the daemon, which can cause tools
|
|
|
|
# invoking the installer to hang.
|
|
|
|
# TODO: fix in Debian too.
|
|
|
|
service camo restart </dev/null
|
2016-04-28 07:32:27 +02:00
|
|
|
fi
|
|
|
|
|
2016-07-12 05:35:14 +02:00
|
|
|
if [ "$has_rabbit" = 0 ]; then
|
|
|
|
if ! rabbitmqctl status >/dev/null; then
|
|
|
|
set +x
|
2018-02-09 02:05:13 +01:00
|
|
|
cat <<EOF
|
|
|
|
|
|
|
|
RabbitMQ seems to not have started properly after the installation process.
|
|
|
|
Often this is caused by misconfigured /etc/hosts in virtualized environments.
|
|
|
|
For more information, see:
|
|
|
|
https://github.com/zulip/zulip/issues/53#issuecomment-143805121
|
|
|
|
|
|
|
|
EOF
|
2016-07-12 05:35:14 +02:00
|
|
|
exit 1
|
|
|
|
fi
|
2016-09-15 19:29:56 +02:00
|
|
|
"$ZULIP_PATH"/scripts/setup/configure-rabbitmq
|
2015-09-30 03:41:31 +02:00
|
|
|
fi
|
|
|
|
|
2016-07-12 05:35:14 +02:00
|
|
|
if [ "$has_postgres" = 0 ]; then
|
2016-09-15 19:29:56 +02:00
|
|
|
"$ZULIP_PATH"/scripts/setup/postgres-init-db
|
2016-07-12 05:35:14 +02:00
|
|
|
fi
|
2013-11-14 06:32:49 +01:00
|
|
|
|
2016-07-12 05:35:14 +02:00
|
|
|
if [ "$has_appserver" = 0 ]; then
|
2016-09-15 19:29:56 +02:00
|
|
|
deploy_path=$("$ZULIP_PATH"/scripts/lib/zulip_tools.py make_deploy_path)
|
|
|
|
mv "$ZULIP_PATH" "$deploy_path"
|
|
|
|
ln -nsf /home/zulip/deployments/next "$ZULIP_PATH"
|
2016-07-12 05:35:14 +02:00
|
|
|
ln -nsf "$deploy_path" /home/zulip/deployments/next
|
|
|
|
ln -nsf "$deploy_path" /home/zulip/deployments/current
|
2016-07-20 05:42:43 +02:00
|
|
|
ln -nsf /etc/zulip/settings.py "$deploy_path"/zproject/prod_settings.py
|
2016-07-12 05:35:14 +02:00
|
|
|
mkdir -p "$deploy_path"/prod-static/serve
|
|
|
|
cp -rT "$deploy_path"/prod-static/serve /home/zulip/prod-static
|
|
|
|
chown -R zulip:zulip /home/zulip /var/log/zulip /etc/zulip/settings.py
|
2017-09-23 00:40:35 +02:00
|
|
|
|
2017-09-23 04:52:33 +02:00
|
|
|
if ! [ -e "/home/zulip/prod-static/generated" ]; then
|
2017-09-23 00:40:35 +02:00
|
|
|
# If we're installing from a git checkout, we need to run
|
|
|
|
# `tools/update-prod-static` in order to build the static
|
|
|
|
# assets.
|
|
|
|
su zulip -c "/home/zulip/deployments/current/tools/update-prod-static --authors-not-required"
|
|
|
|
fi
|
2016-07-12 05:35:14 +02:00
|
|
|
fi
|
2013-11-14 06:32:49 +01:00
|
|
|
|
2016-04-27 00:20:06 +02:00
|
|
|
if [ -e "/var/run/supervisor.sock" ]; then
|
|
|
|
chown zulip:zulip /var/run/supervisor.sock
|
|
|
|
fi
|
2013-11-14 06:32:49 +01:00
|
|
|
|
2018-03-03 01:10:51 +01:00
|
|
|
if [ -n "$NO_INIT_DB" ]; then
|
2018-01-24 22:29:24 +01:00
|
|
|
set +x
|
|
|
|
cat <<EOF
|
2013-11-14 06:32:49 +01:00
|
|
|
|
2018-03-03 01:13:49 +01:00
|
|
|
Success!
|
2013-11-14 06:32:49 +01:00
|
|
|
|
2018-03-03 01:13:49 +01:00
|
|
|
Stopping because --no-init-db was passed. To complete the installation, run:
|
2013-11-14 06:32:49 +01:00
|
|
|
|
2018-03-03 01:13:49 +01:00
|
|
|
su zulip -c /home/zulip/deployments/current/scripts/setup/initialize-database
|
2013-11-14 06:32:49 +01:00
|
|
|
EOF
|
2018-01-24 22:29:24 +01:00
|
|
|
exit 0
|
|
|
|
fi
|
|
|
|
|
2018-03-03 01:17:52 +01:00
|
|
|
su zulip -c '/home/zulip/deployments/current/scripts/setup/initialize-database --quiet'
|
2018-01-24 22:29:24 +01:00
|
|
|
|
2018-03-03 01:17:52 +01:00
|
|
|
su zulip -c '/home/zulip/deployments/current/manage.py generate_realm_creation_link'
|