diff --git a/content/products/doltlab/administrator.md b/content/products/doltlab/administrator.md
index ea978877c..d51856f5e 100644
--- a/content/products/doltlab/administrator.md
+++ b/content/products/doltlab/administrator.md
@@ -300,6 +300,11 @@ Upgrading to newer versions of DoltLab requires downtime. This means that DoltLa
In addition, some early versions have different database schemas than newer ones. If the docker volumes of an old version of DoltLab contain non-precious or test-only data, then DoltLab Admins can simply remove these Docker volumes and run the `start-doltlab.sh` script from the newer DoltLab version. This script will simply create new Docker volumes with the appropriate schema for that DoltLab version.
If you want to upgrade your DoltLab version without losing any data, please follow the upgrade guidelines below.
+Upgrade from DoltLab v2.0.8 to v2.1.0+
+
+The upgrade process for DoltLab `v2.0.8` to `v2.1.0` has not changed, and only requires replacing DoltLab `v2.0.8` with DoltLab `v2.1.0`, the way previous upgrades did.
+
+However, DoltLab `v2.1.0` requires configuring DoltLab using the included `installer` binary. Please refer to the [Start DoltLab section of the Installation guide](./installation.md#start-doltlab) for instructions on configuring DoltLab with the `installer`.
Upgrade from DoltLab v1.1.1 to v2.0.0+
@@ -550,7 +555,9 @@ docker run -d --add-host host.docker.internal:host-gateway --name=prometheus -p
Connect to an SMTP Server with Implicit TLS
-Starting with DoltLab `v0.4.2`, connections to existing SMTP servers using implicit TLS (on port `465`, for example) are supported. To connect using implicit TLS, edit the `docker-compose.yaml` included in the DoltLab zip. Under the `doltlabapi` section, in the `command` block, add the following argument:
+For DoltLab `v2.1.0`, use `--smtp-implicit-tls=true` with the `installer` to use implicit TLS. Use `--smtp-insecure-tls=true` to skip TLS verification.
+
+For DoltLab >= `v0.4.2` and < `v2.1.0`, connections to existing SMTP servers using implicit TLS (on port `465`, for example) are supported. To connect using implicit TLS, edit the `docker-compose.yaml` included in the DoltLab zip. Under the `doltlabapi` section, in the `command` block, add the following argument:
```yaml
...
@@ -656,7 +663,9 @@ Successfully sent email!
DoltLab for non-enterprise use currently supports explicit email whitelisting to prevent account creation by unauthorized users.
-To enable DoltLab's email whitelisting feature, edit the `docker-compose.yaml` file included in DoltLab's zip.
+In DoltLab >= `v2.1.0`, the `installer` binary can be run with `--white-list-all-users=false` in order to disable automatically whitelisting all users.
+
+In DoltLab < `v2.1.0`, to enable DoltLab's email whitelisting feature, edit the `docker-compose.yaml` file included in DoltLab's zip.
Under the `doltlabapi` section, in the `command` block, remove the argument `-dolthubWhitelistAllowAll`. Restart your DoltLab instance for this to take effect.
@@ -765,6 +774,8 @@ By default, DoltLab collects first-party metrics for deployed instances. We use
As of `v0.7.0`, DoltLab does not collect third-party metrics, and additionally, DoltLab's first-party metrics can be disabled. To disable metrics, edit the `start-doltlab.sh` script and remove `run_with_metrics` from the `_main` function.
+In DoltLab >= `v2.1.0` the `installer` can be run with `--disable-usage-metrics=true` to disable metrics.
+
Migrate Old Format DoltLab Databases
Unlike [DoltHub](https://www.dolthub.com), DoltLab does not support automatic database migration for old format Dolt databases. Instead, old format database hosted on DoltLab need to be migrated manually. To migrate a DoltLab database:
@@ -790,13 +801,17 @@ Add the field `logo` to the `admin-config.yaml` file with the absolute path of c
Save the file, and restart your DoltLab instance using the `start-doltlab.sh` script. When DoltLab restarts, you will see the custom logo in place of the DoltLab logo.
+DoltLab >= `v2.1.0` does not use an `admin-config.yaml` file, but instead uses the `installer` with the argument `--custom-logo=/path/to/custom/logo.png` to configure DoltLab to use a custom logo.
+
Customize automated emails
Starting with DoltLab `v0.7.6`, and ending with `v1.1.1`, DoltLab allows administrators to customize the automated emails their DoltLab instance sends to its users.
As of DoltLab >= `v2.0.0`, this feature is now exclusive to DoltLab Enterprise.
-Included in the DoltLab zip is a directory called `templates` that stores the [golang text template files](https://pkg.go.dev/text/template) your DoltLab instance will use to generate emails. Each file is named according to use case and the names of the files should NOT be changed.
+For DoltLab >= `v2.1.0`, custom emails can be configured with the `installer` binary by supplying the argument `--custom-email-templates=true`. The installer will generate the email template files at `./doltlabapi/templates/email` which match the files described below. You can customize these files and they will be used by DoltLab.
+
+For DoltLab < `v2.1.0`, included in the DoltLab zip is a directory called `templates` that stores the [golang text template files](https://pkg.go.dev/text/template) your DoltLab instance will use to generate emails. Each file is named according to use case and the names of the files should NOT be changed.
- `email/collabInvite.txt` sent to invite user to be a database collaborator.
- `email/invite.txt` sent to invite a user to join an organization.
@@ -921,7 +936,19 @@ Starting with DoltLab `v0.8.1`, and ending with `v1.1.1`, DoltLab allows adminis
As of DoltLab >= `v2.0.0`, this feature is now exclusive to DoltLab Enterprise.
-You can specify custom RGB values for DoltLab's assets by defining them in an `admin-config.yaml` file. By default, DoltLab will look for this file in the unzipped `doltlab` directory that contains DoltLab's other assets. However, this path can be overridden by setting the environment variable `ADMIN_CONFIG`.
+For DoltLab >= `v2.1.0`, which does not use an `admin-config.yaml`, this feature can be configured using the `installer`. The installer accepts the following arguments corresponding to the custom color you want to override:
+```bash
+--custom-color-rgb-accent-1="252, 66, 201"
+--custom-color-rgb-background-accent-1="24, 33, 52"
+--custom-color-rgb-background-gradient-start="31, 41, 66"
+--custom-color-rgb-button-1="61, 145, 240"
+--custom-color-rgb-button-2="31, 109, 198"
+--custom-color-rgb-link-1="31, 109, 198"
+--custom-color-rgb-link-2="61, 145, 240"
+--custom-color-rgb-link-light="109, 176, 252"
+```
+
+For DoltLab < `v2.1.0`, you can specify custom RGB values for DoltLab's assets by defining them in an `admin-config.yaml` file. By default, DoltLab will look for this file in the unzipped `doltlab` directory that contains DoltLab's other assets. However, this path can be overridden by setting the environment variable `ADMIN_CONFIG`.
```yaml
# admin-config.yaml DoltLab >= v0.8.1, <= v1.1.1
@@ -980,7 +1007,15 @@ As of DoltLab >= `v2.0.0`, this feature is now exclusive to DoltLab Enterprise.
A DoltLab "super admin" is a user who can has unrestricted access and the highest possibly permission level on all organizations, teams, and databases on a DoltLab instance. This allows these users to write to any database, public or private, merge pull-requests, delete databases and add or remove organization/team members. By default there are no "super admins" registered on a DoltLab instance, including the default user `admin`.
-You can define super admins for a DoltLab instance by defining them in an `admin-config.yaml` file. By default, DoltLab will look for this file in the unzipped `doltlab` directory that contains DoltLab's other assets. However, this path can be overridden by setting the environment variable `ADMIN_CONFIG`.
+For DoltLab `v2.1.0`, which does not use an `admin-config.yaml` file, super admins can be configured using the `installer` binary with the argument `--super-admin-email`. This argument can be supplied multiple times, for example:
+
+```bash
+--super-admin-email=me@email.com
+--super-admin-email=you@email.com
+...
+```
+
+For DoltLab < `v2.1.0`, you can define super admins for a DoltLab instance by defining them in an `admin-config.yaml` file. By default, DoltLab will look for this file in the unzipped `doltlab` directory that contains DoltLab's other assets. However, this path can be overridden by setting the environment variable `ADMIN_CONFIG`.
```yaml
# admin-config.yaml DoltLab >= v1.0.1, <= v1.1.1
@@ -1135,7 +1170,9 @@ Starting with DoltLab `v1.0.5`, it is possible to serve a DoltLab instance behin
Before you begin you will need to create valid TLS certificates on the DoltLab host. You can provision these from a [Certificate Authority](https://en.wikipedia.org/wiki/Certificate_authority) or do so with a free tool like [certbot](https://certbot.eff.org/). For this example we have created valid certs with `certbot`, `/etc/letsencrypt/live/doltlab.dolthub.com/fullchain.pem` and `/etc/letsencrypt/live/doltlab.dolthub.com/privkey.pem`.
-To start, shut down your DoltLab instance if it is currently running, then open four new ports on your DoltLab host. These ports will be used to forward requests to DoltLab's existing `HTTP` ports.
+For DoltLab `v2.1.0`, the `installer` can be used to configure DoltLab to run behind a reverse proxy over HTTPS. To do this, Supply the `--https` argument to the `installer`. The `installer` will generate DoltLab assets with the arguments/values required to run it behind a reverse proxy with TLS. You can now continue to the nginx section below.
+
+For DoltLab < `v2.1.0`, to start, shut down your DoltLab instance if it is currently running, then open four new ports on your DoltLab host. These ports will be used to forward requests to DoltLab's existing `HTTP` ports.
In our example we will using the following new ports: `443`, `143`, `5443`, and `50043`. `443` will route requests to port `80` where DoltLab's UI is served. `143` will forward requests to port `100` where DoltLab serves database data from. `5443` will forward requests to `4321`, which DoltLab uses to enable user file uploads. And, finally, `50043` will map to `50051`, the port used by clients for cloning, pushing, pulling, and fetching data.
@@ -1338,12 +1375,20 @@ Once your DoltLab instance comes up, it will be served on `HTTPS` via the `nginx
Starting with DoltLab `v1.0.6`, it is possible to run DoltLab over `HTTPS` with TLS natively. To do so, make sure that port `443` is open on the host running DoltLab (as well as the other required ports `100`, `4321`, and `50051`) and that you have a valid TLS certificate that uses the `HOST_IP` of the DoltLab host. We recommend creating a TLS certificate using [certbot](https://certbot.eff.org/).
-To start DoltLab with TLS, you will run the `./start-doltlab.sh` script with the argument `https`, and will need to supply two additional environment variables:
+For DoltLab >= `v2.1.0`, to serve DoltLab over HTTPS, run the `installer` binary with:
+
+```
+-https=true
+--tls-cert-chain=/path/to/tls/certificate/chain
+--tls-private-key=/path/to/tls/private/key
+```
+
+For DoltLab < `v2.1.0`, to start DoltLab with TLS, you will run the `./start-doltlab.sh` script with the argument `https`, and will need to supply two additional environment variables:
```bash
...
-export TLS_CERT_CHAIN=
-export TLS_PRIVATE_KEY=
+export TLS_CERT_CHAIN=/path/to/tls/certificate/chain
+export TLS_PRIVATE_KEY=/path/to/tls/private/key
./start-doltlab.sh https
```
@@ -1357,7 +1402,15 @@ When user's upload files on a DoltLab instance, or merge a pull request, DoltLab
By default, DoltLab imposes no limit to the number of concurrent Jobs that can be spawned. As a result, a DoltLab host might experience resources exhaustion as the Docker engine uses all available host resources for managing it's containers.
-To prevent resource exhaustion, the following can be added in DoltLab >= `v1.1.0` to limit the number of concurrent Jobs, ensuring DoltLab will not run more jobs than the configured limit, at any one time:
+For DoltLab >= `v2.1.0`, the following arguments can be used with the installer to prevent job resource exhaustion:
+
+```bash
+--job-concurrency-limit="5"
+--job-concurrency-loop-seconds="10"
+--job-max-retries="5
+```
+
+For DoltLab < `v2.1.0` and >= `v1.1.0`, to prevent resource exhaustion, the following can be added to limit the number of concurrent Jobs, ensuring DoltLab will not run more jobs than the configured limit, at any one time:
```yaml
# docker-compose.yaml
@@ -1395,7 +1448,14 @@ Be sure to also set "Name ID Format" to "Persistent".
Then, download the metadata Okta provides for this application to your DoltLab host.
-Next, run the `./gen_saml_certs.sh` script included with DoltLab `v2.0.0` to generate a SAML signing key and certificate. This script will create two files, `./saml_key.pem` and `./saml_cert.pem` DoltLab will use for signing SAML requests.
+For DoltLab >= `v2.1.0`, SAML single-sign-on can be configured with the `installer` by using following arguments:
+
+```bash
+--sso-saml-metadata-descriptor=/path/to/downloaded/metadata/descriptor
+--sso-saml-cert-common-name="mydoltlabinstance"
+```
+
+For DoltLab < `v2.1.0`, run the `./gen_saml_certs.sh` script included with DoltLab `v2.0.0` to generate a SAML signing key and certificate. This script will create two files, `./saml_key.pem` and `./saml_cert.pem` DoltLab will use for signing SAML requests.
Finally, edit the `./docker-compose.yaml` file for DoltLab so that the following arguments are added to the `doltlabapi.command` block and `doltlabapi.volumes` block:
@@ -1492,7 +1552,17 @@ aws sts get-caller-identity
}
```
-Next, we shut down our running DoltLab instance to make changes to the `docker-compose.yaml` file. In the `doltlabdb` secion, uncomment the AWS environment variables in the `doltlabdb.environment` block, as well as the ones in the `doltlabdb.volumes` block.
+For DoltLab >= `v2.1.0`, the `installer` is used to configure the AWS backup with the following arguments:
+
+```bash
+--automated-dolt-backups-url="aws://[test-doltlab-backup-application-db-manifest:test-doltlab-application-db-backups]/my_doltlab_backup"
+--aws-shared-credentials-file="/absolute/path/to/aws/credentials"
+--aws-config-file="/absolute/path/to/aws/config"
+--aws-region="aws-region"
+--aws-profile="doltlab_backuper"
+```
+
+For DoltLab < `v2.1.0`, we shut down our running DoltLab instance to make changes to the `docker-compose.yaml` file. In the `doltlabdb` secion, uncomment the AWS environment variables in the `doltlabdb.environment` block, as well as the ones in the `doltlabdb.volumes` block.
```yaml
...
@@ -1664,7 +1734,14 @@ Next, add GCP JSON credentials to your DoltLab host. You can find information ab
Following the Dolt's url template for GCP remotes as outlined in [this blog](https://www.dolthub.com/blog/2021-07-19-remotes/#gcp-remotes), the remote url we will use for this bucket will be `gs://test-doltlab-application-db-backup/my_doltlab_backup`.
-Ensure you have stopped your running DoltLab instance, then, like we did for the AWS remote, we are going to uncomment the `GOOGLE_APPLICATION_CREDENTIALS` environment variables in the `doltlabdb.environment` and `doltlabdb.volumes` block of DoltLab's `./docker-compose.yaml` file.
+For DoltLab >= `v2.1.0`, the `installer` is used to configure the GCP backup with the following arguments:
+
+```bash
+--automated-dolt-backups-url="gs://test-doltlab-application-db-backup/my_doltlab_backup"
+--google-creds-file="/absolute/path/to/gcloud/credentials"
+```
+
+For DoltLab < `v2.1.0`, ensure you have stopped your running DoltLab instance, then, like we did for the AWS remote, we are going to uncomment the `GOOGLE_APPLICATION_CREDENTIALS` environment variables in the `doltlabdb.environment` and `doltlabdb.volumes` block of DoltLab's `./docker-compose.yaml` file.
```yaml
...
@@ -1750,6 +1827,14 @@ In the above example, we've changed `key_file` to point to `/oci_private_key.pem
Following the Dolt's url template for OCI remotes as outlined in [this blog](https://www.dolthub.com/blog/2021-07-19-remotes/#oci-remotes), the remote url we will use for this bucket will be `oci://test-doltlab-application-db-backup/my_doltlab_backup`.
+For DoltLab >= `v2.1.0`, the `installer` is used to configure the GCP backup with the following arguments:
+
+```bash
+--automated-dolt-backups-url="oci://test-doltlab-application-db-backup/my_doltlab_backup"
+--oci-config-file="/absolute/path/to/oci/config"
+--oci-key-file="/absolute/path/to/oci/private/key.pem"
+```
+
Ensure you have stopped your running DoltLab instance, then, like we did for the AWS and GCP remotes, we are going to uncomment the `OCI_CONFIG_FILE` and `OCI_KEY_FILE` environment variables in the `doltlabdb.environment` and `doltlabdb.volumes` block of DoltLab's `./docker-compose.yaml` file.
```yaml
diff --git a/content/products/doltlab/installation.md b/content/products/doltlab/installation.md
index c3595e71f..5faf1276b 100644
--- a/content/products/doltlab/installation.md
+++ b/content/products/doltlab/installation.md
@@ -2,7 +2,7 @@
title: "Installation"
---
-The latest version of DoltLab is `v2.0.8` and to get started running your own DoltLab instance, you can follow the steps below. To see release notes for [DoltLab's releases](https://github.com/dolthub/doltlab-issues/releases) or to report and track DoltLab issues, visit DoltLab's [issues repository](https://github.com/dolthub/doltlab-issues).
+The latest version of DoltLab is `v2.1.0` and to get started running your own DoltLab instance, you can follow the steps below. To see release notes for [DoltLab's releases](https://github.com/dolthub/doltlab-issues/releases) or to report and track DoltLab issues, visit DoltLab's [issues repository](https://github.com/dolthub/doltlab-issues).
Please note, that to upgrading to a newer version of DoltLab will require you to kill the older version of DoltLab and install the newer one, which may result in data loss.
@@ -39,7 +39,7 @@ If your host is running Ubuntu 18.04/20.04, the quickest way to install these de
To use them:
```bash
-export DOLTLAB_VERSION=v2.0.8
+export DOLTLAB_VERSION=v2.1.0
chmod +x ubuntu-bootstrap.sh
sudo ./ubuntu-bootstrap.sh with-sudo "$DOLTLAB_VERSION"
cd doltlab
@@ -47,7 +47,7 @@ sudo newgrp docker # login as root to run docker without sudo
```
```bash
-export DOLTLAB_VERSION=v2.0.8
+export DOLTLAB_VERSION=v2.1.0
chmod +x centos-bootstrap.sh
sudo ./centos-bootstrap.sh with-sudo "$DOLTLAB_VERSION"
cd doltlab
@@ -81,13 +81,19 @@ cd doltlab
To install a specific version, run:
```bash
-export DOLTLAB_VERSION=v2.0.8
+export DOLTLAB_VERSION=v2.1.0
curl -LO https://doltlab-releases.s3.amazonaws.com/linux/amd64/doltlab-${DOLTLAB_VERSION}.zip
unzip doltlab-${DOLTLAB_VERSION}.zip -d doltlab
cd doltlab
```
-Inside the unzipped `doltlab` directory, you'll find the following items:
+DoltLab >= `v2.1.0` no longer contains the most of the assets described below. Instead, it ships with an `installer` binary
+which is now the main interface for configuring a DoltLab instance. Inside DoltLab >= `v2.1.0` you'll find:
+
+* installer
+* smtp_connection_helper
+
+Inside DoltLab < `v2.1.0`, in the unzipped `doltlab` directory, you'll find the following items:
* templates
* envoy.tmpl
@@ -109,53 +115,104 @@ Inside the unzipped `doltlab` directory, you'll find the following items:
* prometheus.yaml
* prometheus-alert.rules
* alertmanager.yaml
-
+
+`installer`, introduced in DoltLab `v2.1.0` is used for configuring a DoltLab instance. This tool will create the appropriate assets for you to run DoltLab, based on the arguments you supply to the `installer`.
+
`templates` contains email templates used by `doltlabapi` to send automated emails to users of your DoltLab instance. You can customize emails by
-editing these files before starting your DoltLab instance. For more information on the contents of these files and how to change them, see the [Customize automated emails](./administrator.md#customize-automated-emails) section of the Administrator guide.
+editing these files before starting your DoltLab instance. For more information on the contents of these files and how to change them, see the [Customize automated emails](./administrator.md#customize-automated-emails) section of the Administrator guide. In DoltLab >= `v2.1.0` these files are no longer shipped with the DoltLab zip. Instead, `installer` will generate these files if `--custom-email-templates` is used (DoltLab Enterprise only).
-`envoy.tmpl` is an template file used to create the [Envoy](https://www.envoyproxy.io/) proxy configuration file called `envoy.yaml`.
+`envoy.tmpl` is an template file used to create the [Envoy](https://www.envoyproxy.io/) proxy configuration file called `envoy.yaml`. In DoltLab >= `v2.1.0` this file is not included, as a single `envoy.json` file will be generated by the `installer` instead.
-`envoy-tls.tmpl` is included in DoltLab >= `v1.0.6` and is used to create an `envoy.yaml` file that uses TLS.
+`envoy-tls.tmpl` is included in DoltLab >= `v1.0.6` and is used to create an `envoy.yaml` file that uses TLS. In DoltLab >= `v2.1.0` this file is not included, as a single `envoy.json` file will be generated by the `installer` instead.
-`gentokenenckey`, short for "generate token encryption key" is a binary used to generate token encryption keys used by DoltLab. The code is available [here](https://gist.github.com/coffeegoddd/9b1acb07baaa72c8173a2e7b11dacb80).
+`gentokenenckey`, short for "generate token encryption key" is a binary used to generate token encryption keys used by DoltLab. The code is available [here](https://gist.github.com/coffeegoddd/9b1acb07baaa72c8173a2e7b11dacb80). In DoltLab >= `v2.1.0` this tool is not included, as the `installer` will generate encryption keys for each service. They will be available in directories named for each service after the `installer` runs.
-`config_loader` is a binary used to process the `admin-config.yaml` file, if one exists.
+`config_loader` is a binary used to process the `admin-config.yaml` file, if one exists. In DoltLab >= `v2.1.0` this tool is not included, it is replaced by the `installer`.
-`send_doltlab_deployed_event` is a binary that sends a single request to our metrics server, letting us track how many DoltLab instances get deployed each day. This information helps us properly fund and staff our DoltLab team. The source for this binary is [here](https://gist.github.com/coffeegoddd/cc1c7c765af56f6523bc5faffbc19e7a).
+`send_doltlab_deployed_event` is a binary that sends a single request to our metrics server, letting us track how many DoltLab instances get deployed each day. This information helps us properly fund and staff our DoltLab team. The source for this binary is [here](https://gist.github.com/coffeegoddd/cc1c7c765af56f6523bc5faffbc19e7a). In DoltLab >= `v2.1.0` this tool is not included, it is replaced by the `installer`.
`smtp_connection_helper` is a binary used to help troubleshoot any issues your DoltLab instance might have when establishing a connection to your existing SMTP server. This tool uses similar code to DoltLab's email service and should successfully send a test email if the connection to the SMTP server was configured correctly. The source code for the tool is available [here](https://gist.github.com/coffeegoddd/66f5aeec98640ff8a22a1b6910826667) and basic instructions for using the tool are [here](./administrator.md#troubleshoot-smtp-connection).
-`get_machine_id` is a binary used to determine the hardware ID of the DoltLab host, used only for DoltLab Enterprise.
+`get_machine_id` is a binary used to determine the hardware ID of the DoltLab host, used only for DoltLab Enterprise. In DoltLab >= `v2.1.0` this tool is not included, it is replaced by the `installer`.
-`gen_saml_key` is a binary used to generate a private key for configuring SAML single-sign-on, used only for DoltLab Enterprise.
+`gen_saml_key` is a binary used to generate a private key for configuring SAML single-sign-on, used only for DoltLab Enterprise. In DoltLab >= `v2.1.0` this tool is not included, it is replaced by the `installer`.
-`gen_saml_cert` is a binary used to generate a signing certificate for SAML single-sign-on, used only for DoltLab Enterprise.
+`gen_saml_cert` is a binary used to generate a signing certificate for SAML single-sign-on, used only for DoltLab Enterprise. In DoltLab >= `v2.1.0` this tool is not included, it is replaced by the `installer`.
-`gen_saml_certs.sh` is a script that uses `gen_saml_key` and `gen_saml_cert` to create a signing certificate for SAML single-sign-on, used only for DoltLab Enterprise. The script requires a single argument, the `common name` to use for the certificate.
+`gen_saml_certs.sh` is a script that uses `gen_saml_key` and `gen_saml_cert` to create a signing certificate for SAML single-sign-on, used only for DoltLab Enterprise. The script requires a single argument, the `common name` to use for the certificate. In DoltLab >= `v2.1.0` this tool is not included, it is replaced by the `installer`.
`migrate_postgres_dolt.sh` is a script available in DoltLab `v1.0.0`+. Prior to DoltLab `v1.0.0`, DoltLab used PostgreSQL as its database. But now, starting with `v1.0.0`, DoltLab uses Dolt as its database. This script is used when upgrading from an older DoltLab instance to DoltLab `v1.0.0` and will copy the data from the existing, older DoltLab instance into the new Dolt database backing DoltLab `v1.0.0`. Please see [the guide](./administrator.md#upgrade-v080-v100) for using this script to copy existing data during upgrade.
-`dolt_db_cli.sh` is a script available in DoltLab `v1.0.0`+, useful for restoring DoltLab's Dolt server from a backup.
+`dolt_db_cli.sh` is a script available in DoltLab `v1.0.0`+, useful for restoring DoltLab's Dolt server from a backup. In DoltLab >= `v2.1.0` this script will be generated by the `installer` and located at `./doltlabdb/dolt_db_cli.sh`.
-`shell-db.sh` is a script that will open a shell to your running DoltLab's database server. For DoltLab versions lower than `v1.0.0`, this database server is PostgreSQL. To use this script with those versions, supply the `POSTGRES_PASSWORD` value you set when starting DoltLab as the environment variable `PGPASSWORD`. A successful connection will display a `dolthubapi=#` prompt.
+`shell-db.sh` is a script that will open a shell to your running DoltLab's database server. For DoltLab versions lower than `v1.0.0`, this database server is PostgreSQL. To use this script with those versions, supply the `POSTGRES_PASSWORD` value you set when starting DoltLab as the environment variable `PGPASSWORD`. A successful connection will display a `dolthubapi=#` prompt. In DoltLab >= `v2.1.0` this script will be generated by the `installer` and located at `./doltlabdb/shell-db.sh`.
For DoltLab `v1.0.0` and later, Dolt is the database server. To connect to it, supply the `DOLT_PASSWORD` environment variable value you set when starting DoltLab. A successful connection will display a `mysql>` prompt.
-`docker-compose.yaml` is a complete [Docker Compose](https://docs.docker.com/compose/) configuration file that will spin up all the services required to run DoltLab.
+`docker-compose.yaml` is a complete [Docker Compose](https://docs.docker.com/compose/) configuration file that will spin up all the services required to run DoltLab. In DoltLab >= `v2.1.0` this file is not included, but will be generated as a single `docker-compose.yaml` file by the `installer` instead.
+
+`docker-compose-tls.yaml` is included in DoltLab >= `v1.0.6` and will spin up DoltLab using TLS. In DoltLab >= `v2.1.0` this file is not included, but will be generated as a single `docker-compose.yaml` file by the `installer` instead.
-`docker-compose-tls.yaml` is included in DoltLab >= `v1.0.6` and will spin up DoltLab using TLS.
+`start-doltlab.sh` is a helper script designed to quickly and easily start DoltLab. See the following section for more information about how to use this script. In DoltLab >= `v2.1.0` this script is not included, but will be generated as a single `start.sh` file by the `installer` instead.
-`start-doltlab.sh` is a helper script designed to quickly and easily start DoltLab. See the following section for more information about how to use this script.
+`stop.sh` is a script used to stop running a DoltLab instance. Only available in In DoltLab >= `v2.1.0`, this script is generated by the `installer`.
-`prometheus.yaml` is a [Prometheus](https://prometheus.io/) configuration file that can be used for observing real-time DoltLab service metrics. Used for DoltLab Enterprise automated backups.
+`prometheus.yaml` is a [Prometheus](https://prometheus.io/) configuration file that can be used for observing real-time DoltLab service metrics. Used for DoltLab Enterprise automated backups. In DoltLab >= `v2.1.0` this file is not included, but will be generated by the `installer` when automated backups are configured. It will be located at `./prometheus/prometheus.yaml`.
-`prometheus-alert.rules` is an alert rules file used for sending emails to DoltLab admins in the event of a backup failure. Used for DoltLab Enterprise automated backups.
+`prometheus-alert.rules` is an alert rules file used for sending emails to DoltLab admins in the event of a backup failure. Used for DoltLab Enterprise automated backups. In DoltLab >= `v2.1.0` this file is not included, but will be generated by the `installer` when automated backups are configured. It will be located at `./prometheus/alert.rules`.
-`alertmanager.yaml` is a [AlertManager](https://prometheus.io/docs/alerting/latest/alertmanager/) configuration file for sending email alerts to DoltLab admins based on Prometheus metrics. Used for DoltLab Enterprise automated backups.
+`alertmanager.yaml` is a [AlertManager](https://prometheus.io/docs/alerting/latest/alertmanager/) configuration file for sending email alerts to DoltLab admins based on Prometheus metrics. Used for DoltLab Enterprise automated backups. In DoltLab >= `v2.1.0` this file is not included, but will be generated by the `installer` when automated backups are configured. It will be located at `./alertmanager/alertmanager.yaml`.
Step 3: Start DoltLab
-The recommended way to run DoltLab is with the `start-doltlab.sh` script included in DoltLab's zip folder. This script requires the following environment variables to be set in your DoltLab host environment/shell.
+DoltLab >= `v2.1.0` is configured with an `installer` binary that will generate the required assets to run DoltLab based on the arguments supplied.
+
+It the simplest case the `installer` will generate four assets, `docker-compose.yaml`, `envoy.json`, `start.sh`, and `stop.sh`.
+
+Use `start.sh` to start DoltLab and `stop.sh` to stop it. These scripts will reference the other generated files.
+
+```bash
+./installer \
+--host=doltlab.dolthub.com \
+--smtp-auth-method=plain \
+--smtp-host=doltlab.dolthub.com \
+--smtp-port=587 \
+--no-reply-email=me@email.com \
+--default-user-email=me@email.com
+
+2024-03-29T18:19:28.164Z INFO metrics/emitter.go:111 Successfully sent DoltLab usage metrics
+2024-03-29T18:19:28.164Z INFO cmd/main.go:345 Successfully configured DoltLab {"version": "v2.0.9"}
+2024-03-29T18:19:28.164Z INFO cmd/main.go:349 You can now start DoltLab using the generated script {"start_script": "/home/ubuntu/doltlab/start.sh"}
+2024-03-29T18:19:28.164Z INFO cmd/main.go:354 Use the generated stop script to stop DoltLab {"stop_script": "/home/ubuntu/doltlab/stop.sh"}
+```
+
+The installer requires the following minimum arguments:
+
+`--host`, the host name or IP address of the host running DoltLab.
+
+`--smtp-auth-method`, the smtp server's authentication method, one of `plain`, `login`, `external`, `anonymous`, `oauthbearer`, and `disable`.
+
+`--smtp-host`, the smtp server's host name.
+
+`--smtp-port`, the smtp port.
+
+`--no-reply-email`, the email address to use to send automated DoltLab emails.
+
+`--default-user-email`, the email address to use for DoltLab's default user `admin`.
+
+You can now run `./start.sh` to start DoltLab:
+
+```bash
+DOLT_PASSWORD=password \
+DOLTHUBAPI_PASSWORD=password \
+EMAIL_USERNAME=myusername \
+EMAIL_PASSWORD=mypassword \
+./start.sh
+```
+
+Note that the generated `start.sh` script might require additional environment variables. Please see the list of how the environment variables defined below have changed in `v2.1.0`.
+
+For DoltLab < `v2.1.0`, the recommended way to run DoltLab is with the `start-doltlab.sh` script included in DoltLab's zip folder. This script requires the following environment variables to be set in your DoltLab host environment/shell.
> Note, the `./start-doltlab.sh` script contains references to some of these environment variables, but not all, as some are referenced elsewhere.
@@ -184,20 +241,20 @@ export TLS_PRIVATE_KEY=
> For DoltLab version <= `v0.8.4` include `export POSTGRES_USER="dolthubapi"` and rename `DOLT_PASSWORD` to `POSTGRES_PASSWORD`.
-`HOST_IP` should be the IP address or DNS name of the Linux host running DoltLab.
-`DOLT_PASSWORD` and `DOLTHUBAPI_PASSWORD` may be set to any valid Dolt password.
-`EMAIL_USERNAME` should be a valid username authorized to use existing SMTP server.
-`EMAIL_PASSWORD` should be the password for the aforementioned username of the SMTP server.
-`EMAIL_PORT` a `STARTTLS` port to the existing SMTP server is assumed by default. To use an implicit TLS port, [please follow these steps](./administrator.md#smtp-implicit-tls).
-`EMAIL_HOST` should be the host of the existing SMTP server.
-`NO_REPLY_EMAIL` should be the email address that receives no-reply messages.
-`DOLTLAB_ENTERPRISE_ONLINE_PRODUCT_CODE`, provided by us to DoltLab Enterprise customers.
-`DOLTLAB_ENTERPRISE_ONLINE_SHARED_KEY`, provided by us to DoltLab Enterprise customers.
-`DOLTLAB_ENTERPRISE_ONLINE_API_KEY`, provided by us to DoltLab Enterprise customers.
-`DOLTLAB_ENTERPRISE_ONLINE_LICENSE_KEY`, provided by us to DoltLab Enterprise customers.
-`DOLTLAB_ENTERPRISE_HARDWARE_ID`, use `./get_machine_id` binary to get the hardware ID and use the output as this value (DoltLab Enterprise only).
-`TLS_CERT_CHAIN` required if running DoltLab >= `v1.0.6` with TLS, should be the the absolute path to a TLS certificate chain.
-`TLS_PRIVATE_KEY` required if running DoltLab >= `v1.0.6` with TLS, should be the the absolute path to a TLS private key.
+`HOST_IP` should be the IP address or DNS name of the Linux host running DoltLab. In DoltLab `v2.1.0` this is replaced by the `--host` argument used with the `installer`.
+`DOLT_PASSWORD` and `DOLTHUBAPI_PASSWORD` may be set to any valid Dolt password. In DoltLab `v2.1.0` these may be required by the generated `start.sh` script.
+`EMAIL_USERNAME` should be a valid username authorized to use existing SMTP server. In DoltLab `v2.1.0` this may be required by the generated `start.sh` script.
+`EMAIL_PASSWORD` should be the password for the aforementioned username of the SMTP server. In DoltLab `v2.1.0` this may be required by the generated `start.sh` script.
+`EMAIL_PORT` a `STARTTLS` port to the existing SMTP server is assumed by default. To use an implicit TLS port, [please follow these steps](./administrator.md#smtp-implicit-tls). In DoltLab `v2.1.0` this is replaced by the `--smtp-port` argument used with the `installer`.
+`EMAIL_HOST` should be the host of the existing SMTP server. In DoltLab `v2.1.0` this is replaced by the `--smtp-host` argument used with the `installer`.
+`NO_REPLY_EMAIL` should be the email address that receives no-reply messages. In DoltLab `v2.1.0` this is replaced by the `--no-reply-email` argument used with the `installer`.
+`DOLTLAB_ENTERPRISE_ONLINE_PRODUCT_CODE`, provided by us to DoltLab Enterprise customers. In DoltLab `v2.1.0` this is replaced by the `--enterprise-online-product-code` argument used with the `installer`.
+`DOLTLAB_ENTERPRISE_ONLINE_SHARED_KEY`, provided by us to DoltLab Enterprise customers. In DoltLab `v2.1.0` this is replaced by the `--enterprise-online-shared-key` argument used with the `installer`.
+`DOLTLAB_ENTERPRISE_ONLINE_API_KEY`, provided by us to DoltLab Enterprise customers. In DoltLab `v2.1.0` this is replaced by the `--enterprise-online-api-key` argument used with the `installer`.
+`DOLTLAB_ENTERPRISE_ONLINE_LICENSE_KEY`, provided by us to DoltLab Enterprise customers. In DoltLab `v2.1.0` this is replaced by the `--enterprise-online-license-key` argument used with the `installer`.
+`DOLTLAB_ENTERPRISE_HARDWARE_ID`, use `./get_machine_id` binary to get the hardware ID and use the output as this value (DoltLab Enterprise only). Not used in DoltLab `v2.1.0.`
+`TLS_CERT_CHAIN` required if running DoltLab >= `v1.0.6` with TLS, should be the the absolute path to a TLS certificate chain. In DoltLab `v2.1.0` this is replaced by the `--tls-cert-chain` argument used with the `installer`.
+`TLS_PRIVATE_KEY` required if running DoltLab >= `v1.0.6` with TLS, should be the the absolute path to a TLS private key. In DoltLab `v2.1.0` this is replaced by the `--tls-private-key` argument used with the `installer`.
To use DoltLab with TLS ensure the certificate is for the `HOST_IP` of your DoltLab host. We recommend creating a TLS certificate with [certbot](https://certbot.eff.org/).
@@ -206,7 +263,7 @@ To use DoltLab with TLS ensure the certificate is for the `HOST_IP` of your Dolt
Starting in DoltLab `v0.3.1`, admins can use different SMTP authentication protocols to connect to an existing
SMTP server. By default, `./start-doltlab.sh` sets the environment variable `EMAIL_AUTH_METHOD` to `plain`.
-Supported `EMAIL_AUTH_METHOD` options are `plain`, `login`, `anonymous`, `external`, `oauthbearer`, or `disable`.
+Supported `EMAIL_AUTH_METHOD` options are `plain`, `login`, `anonymous`, `external`, `oauthbearer`, or `disable`. Note that in DoltLab `v2.1.0`, this environment variable is now the `--smtp-auth-method` flag used with the `installer`.
`plain` requires the environment variables `EMAIL_USERNAME` and `EMAIL_PASSWORD` to be set and uses the optional environment variable `EMAIL_IDENTITY`.
`login` requires the environment variables `EMAIL_USERNAME` and `EMAIL_PASSWORD` to be set. This is used by Microsoft 365 (`smtp.office365.com`).
@@ -224,7 +281,10 @@ when [DoltLab's API server](https://www.dolthub.com/blog/2022-02-25-doltlab-101-
This default user allows DoltLab admins to immediately sign in to DoltLab and begin using the product, even if their DoltLab instance is not successfully connected to an SMTP server.
-By default, the `./start-doltlab.sh` script will create a default user `DEFAULT_USER=admin` with password `DEFAULT_USER_PASSWORD=DoltLab1234` and the email address `DEFAULT_USER_EMAIL=$NO_REPLY_EMAIL`, which gets its value from the supplied `NO_REPLY_EMAIL` environment variable.
+For DoltLab >= `v2.1.0`, the default user email is configured with the `installer` using the flag `--default-user-email` and the no-reply email is configured with `--no-reply-email`. The default user's password can be overridden by defining `DEFAULT_USER_PASSWORD` when running `start.sh`.
+
+For DoltLab < `v2.1.0`, by default, the `./start-doltlab.sh` script will create a default user `DEFAULT_USER=admin` with password `DEFAULT_USER_PASSWORD=DoltLab1234` and the email address `DEFAULT_USER_EMAIL=$NO_REPLY_EMAIL`, which gets its value from the supplied `NO_REPLY_EMAIL` environment variable.
+
To overwrite these default values, simply change the values of their corresponding environment variables.
Once these variables are set, simply run the `start-doltlab.sh` script: