mirror of https://github.com/go-gitea/gitea
Git with a cup of tea, painless self-hosted git service
Mirror for internal git.with.parts use
https://git.with.parts
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
304 lines
12 KiB
304 lines
12 KiB
5 years ago
|
---
|
||
|
date: "2020-01-16"
|
||
|
title: "Database Preparation"
|
||
|
slug: "database-prep"
|
||
1 year ago
|
sidebar_position: 10
|
||
4 years ago
|
toc: false
|
||
5 years ago
|
draft: false
|
||
2 years ago
|
aliases:
|
||
|
- /en-us/database-prep
|
||
5 years ago
|
menu:
|
||
|
sidebar:
|
||
|
parent: "installation"
|
||
|
name: "Database preparation"
|
||
1 year ago
|
sidebar_position: 10
|
||
5 years ago
|
identifier: "database-prep"
|
||
|
---
|
||
|
|
||
4 years ago
|
# Database Preparation
|
||
|
|
||
2 years ago
|
You need a database to use Gitea. Gitea supports PostgreSQL (>=10), MySQL (>=5.7), SQLite, and MSSQL (>=2008R2 SP3). This page will guide into preparing database. Only PostgreSQL and MySQL will be covered here since those database engines are widely-used in production. If you plan to use SQLite, you can ignore this chapter.
|
||
5 years ago
|
|
||
|
Database instance can be on same machine as Gitea (local database setup), or on different machine (remote database).
|
||
|
|
||
4 years ago
|
Note: All steps below requires that the database engine of your choice is installed on your system. For remote database setup, install the server application on database instance and client program on your Gitea server. The client program is used to test connection to the database from Gitea server, while Gitea itself use database driver provided by Go to accomplish the same thing. In addition, make sure you use same engine version for both server and client for some engine features to work. For security reason, protect `root` (MySQL) or `postgres` (PostgreSQL) database superuser with secure password. The steps assumes that you run Linux for both database and Gitea servers.
|
||
4 years ago
|
|
||
5 years ago
|
## MySQL
|
||
|
|
||
2 years ago
|
1. For remote database setup, you will need to make MySQL listen to your IP address. Edit `bind-address` option on `/etc/mysql/my.cnf` on database instance to:
|
||
4 years ago
|
|
||
|
```ini
|
||
|
bind-address = 203.0.113.3
|
||
|
```
|
||
4 years ago
|
|
||
2 years ago
|
2. On database instance, login to database console as root:
|
||
5 years ago
|
|
||
|
```
|
||
|
mysql -u root -p
|
||
|
```
|
||
|
|
||
|
Enter the password as prompted.
|
||
|
|
||
2 years ago
|
3. Create database user which will be used by Gitea, authenticated by password. This example uses `'gitea'` as password. Please use a secure password for your instance.
|
||
5 years ago
|
|
||
|
For local database:
|
||
|
|
||
|
```sql
|
||
|
SET old_passwords=0;
|
||
|
CREATE USER 'gitea' IDENTIFIED BY 'gitea';
|
||
|
```
|
||
|
|
||
|
For remote database:
|
||
|
|
||
|
```sql
|
||
|
SET old_passwords=0;
|
||
5 years ago
|
CREATE USER 'gitea'@'192.0.2.10' IDENTIFIED BY 'gitea';
|
||
5 years ago
|
```
|
||
|
|
||
5 years ago
|
where `192.0.2.10` is the IP address of your Gitea instance.
|
||
5 years ago
|
|
||
|
Replace username and password above as appropriate.
|
||
|
|
||
2 years ago
|
4. Create database with UTF-8 charset and collation. Make sure to use `utf8mb4` charset instead of `utf8` as the former supports all Unicode characters (including emojis) beyond _Basic Multilingual Plane_. Also, collation chosen depending on your expected content. When in doubt, use either `unicode_ci` or `general_ci`.
|
||
5 years ago
|
|
||
|
```sql
|
||
5 years ago
|
CREATE DATABASE giteadb CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_unicode_ci';
|
||
5 years ago
|
```
|
||
|
|
||
|
Replace database name as appropriate.
|
||
|
|
||
2 years ago
|
5. Grant all privileges on the database to database user created above.
|
||
5 years ago
|
|
||
|
For local database:
|
||
|
|
||
|
```sql
|
||
|
GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea';
|
||
|
FLUSH PRIVILEGES;
|
||
|
```
|
||
|
|
||
|
For remote database:
|
||
|
|
||
|
```sql
|
||
5 years ago
|
GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea'@'192.0.2.10';
|
||
5 years ago
|
FLUSH PRIVILEGES;
|
||
|
```
|
||
|
|
||
2 years ago
|
6. Quit from database console by `exit`.
|
||
5 years ago
|
|
||
2 years ago
|
7. On your Gitea server, test connection to the database:
|
||
5 years ago
|
|
||
|
```
|
||
5 years ago
|
mysql -u gitea -h 203.0.113.3 -p giteadb
|
||
5 years ago
|
```
|
||
|
|
||
5 years ago
|
where `gitea` is database username, `giteadb` is database name, and `203.0.113.3` is IP address of database instance. Omit `-h` option for local database.
|
||
5 years ago
|
|
||
|
You should be connected to the database.
|
||
|
|
||
|
## PostgreSQL
|
||
|
|
||
2 years ago
|
1. For remote database setup, configure PostgreSQL on database instance to listen to your IP address by editing `listen_addresses` on `postgresql.conf` to:
|
||
4 years ago
|
|
||
|
```ini
|
||
|
listen_addresses = 'localhost, 203.0.113.3'
|
||
|
```
|
||
|
|
||
2 years ago
|
2. PostgreSQL uses `md5` challenge-response encryption scheme for password authentication by default. Nowadays this scheme is not considered secure anymore. Use SCRAM-SHA-256 scheme instead by editing the `postgresql.conf` configuration file on the database server to:
|
||
5 years ago
|
|
||
|
```ini
|
||
|
password_encryption = scram-sha-256
|
||
|
```
|
||
|
|
||
|
Restart PostgreSQL to apply the setting.
|
||
|
|
||
2 years ago
|
3. On the database server, login to the database console as superuser:
|
||
5 years ago
|
|
||
|
```
|
||
|
su -c "psql" - postgres
|
||
|
```
|
||
|
|
||
2 years ago
|
4. Create database user (role in PostgreSQL terms) with login privilege and password. Please use a secure, strong password instead of `'gitea'` below:
|
||
5 years ago
|
|
||
|
```sql
|
||
|
CREATE ROLE gitea WITH LOGIN PASSWORD 'gitea';
|
||
|
```
|
||
|
|
||
|
Replace username and password as appropriate.
|
||
|
|
||
2 years ago
|
5. Create database with UTF-8 charset and owned by the database user created earlier. Any `libc` collations can be specified with `LC_COLLATE` and `LC_CTYPE` parameter, depending on expected content:
|
||
5 years ago
|
|
||
|
```sql
|
||
|
CREATE DATABASE giteadb WITH OWNER gitea TEMPLATE template0 ENCODING UTF8 LC_COLLATE 'en_US.UTF-8' LC_CTYPE 'en_US.UTF-8';
|
||
|
```
|
||
|
|
||
|
Replace database name as appropriate.
|
||
|
|
||
2 years ago
|
6. Allow the database user to access the database created above by adding the following authentication rule to `pg_hba.conf`.
|
||
5 years ago
|
|
||
|
For local database:
|
||
|
|
||
|
```ini
|
||
|
local giteadb gitea scram-sha-256
|
||
|
```
|
||
|
|
||
|
For remote database:
|
||
|
|
||
|
```ini
|
||
5 years ago
|
host giteadb gitea 192.0.2.10/32 scram-sha-256
|
||
5 years ago
|
```
|
||
|
|
||
|
Replace database name, user, and IP address of Gitea instance with your own.
|
||
|
|
||
|
Note: rules on `pg_hba.conf` are evaluated sequentially, that is the first matching rule will be used for authentication. Your PostgreSQL installation may come with generic authentication rules that match all users and databases. You may need to place the rules presented here above such generic rules if it is the case.
|
||
|
|
||
|
Restart PostgreSQL to apply new authentication rules.
|
||
4 years ago
|
|
||
2 years ago
|
7. On your Gitea server, test connection to the database.
|
||
5 years ago
|
|
||
|
For local database:
|
||
|
|
||
|
```
|
||
|
psql -U gitea -d giteadb
|
||
|
```
|
||
|
|
||
|
For remote database:
|
||
|
|
||
|
```
|
||
5 years ago
|
psql "postgres://gitea@203.0.113.3/giteadb"
|
||
5 years ago
|
```
|
||
|
|
||
5 years ago
|
where `gitea` is database user, `giteadb` is database name, and `203.0.113.3` is IP address of your database instance.
|
||
5 years ago
|
|
||
|
You should be prompted to enter password for the database user, and connected to the database.
|
||
5 years ago
|
|
||
|
## Database Connection over TLS
|
||
|
|
||
|
If the communication between Gitea and your database instance is performed through a private network, or if Gitea and the database are running on the same server, this section can be omitted since the security between Gitea and the database instance is not critically exposed. If instead the database instance is on a public network, use TLS to encrypt the connection to the database, as it is possible for third-parties to intercept the traffic data.
|
||
|
|
||
|
### Prerequisites
|
||
|
|
||
|
- You need two valid TLS certificates, one for the database instance (database server) and one for the Gitea instance (database client). Both certificates must be signed by a trusted CA.
|
||
|
- The database certificate must contain `TLS Web Server Authentication` in the `X509v3 Extended Key Usage` extension attribute, while the client certificate needs `TLS Web Client Authentication` in the corresponding attribute.
|
||
|
- On the database server certificate, one of `Subject Alternative Name` or `Common Name` entries must be the fully-qualified domain name (FQDN) of the database instance (e.g. `db.example.com`). On the database client certificate, one of the entries mentioned above must contain the database username that Gitea will be using to connect.
|
||
|
- You need domain name mappings of both Gitea and database servers to their respective IP addresses. Either set up DNS records for them or add local mappings to `/etc/hosts` (`%WINDIR%\System32\drivers\etc\hosts` in Windows) on each system. This allows the database connections to be performed by domain name instead of IP address. See documentation of your system for details.
|
||
|
|
||
|
### PostgreSQL
|
||
|
|
||
|
The PostgreSQL driver used by Gitea supports two-way TLS. In two-way TLS, both database client and server authenticate each other by sending their respective certificates to their respective opposite for validation. In other words, the server verifies client certificate, and the client verifies server certificate.
|
||
|
|
||
2 years ago
|
1. On the server with the database instance, place the following credentials:
|
||
5 years ago
|
|
||
4 years ago
|
- `/path/to/postgresql.crt`: Database instance certificate
|
||
|
- `/path/to/postgresql.key`: Database instance private key
|
||
|
- `/path/to/root.crt`: CA certificate chain to validate client certificates
|
||
5 years ago
|
|
||
2 years ago
|
2. Add following options to `postgresql.conf`:
|
||
5 years ago
|
|
||
|
```ini
|
||
|
ssl = on
|
||
|
ssl_ca_file = '/path/to/root.crt'
|
||
|
ssl_cert_file = '/path/to/postgresql.crt'
|
||
|
ssl_key_file = '/path/to/postgresql.key'
|
||
|
ssl_min_protocol_version = 'TLSv1.2'
|
||
|
```
|
||
|
|
||
2 years ago
|
3. Adjust credentials ownership and permission, as required by PostgreSQL:
|
||
5 years ago
|
|
||
|
```
|
||
|
chown postgres:postgres /path/to/root.crt /path/to/postgresql.crt /path/to/postgresql.key
|
||
|
chmod 0600 /path/to/root.crt /path/to/postgresql.crt /path/to/postgresql.key
|
||
|
```
|
||
|
|
||
2 years ago
|
4. Edit `pg_hba.conf` rule to only allow Gitea database user to connect over SSL, and to require client certificate verification.
|
||
5 years ago
|
|
||
|
For PostgreSQL 12:
|
||
|
|
||
|
```ini
|
||
|
hostssl giteadb gitea 192.0.2.10/32 scram-sha-256 clientcert=verify-full
|
||
|
```
|
||
|
|
||
|
For PostgreSQL 11 and earlier:
|
||
|
|
||
|
```ini
|
||
|
hostssl giteadb gitea 192.0.2.10/32 scram-sha-256 clientcert=1
|
||
|
```
|
||
|
|
||
|
Replace database name, user, and IP address of Gitea instance as appropriate.
|
||
|
|
||
2 years ago
|
5. Restart PostgreSQL to apply configurations above.
|
||
5 years ago
|
|
||
2 years ago
|
6. On the server running the Gitea instance, place the following credentials under the home directory of the user who runs Gitea (e.g. `git`):
|
||
5 years ago
|
|
||
4 years ago
|
- `~/.postgresql/postgresql.crt`: Database client certificate
|
||
|
- `~/.postgresql/postgresql.key`: Database client private key
|
||
|
- `~/.postgresql/root.crt`: CA certificate chain to validate server certificate
|
||
5 years ago
|
|
||
|
Note: Those file names above are hardcoded in PostgreSQL and it is not possible to change them.
|
||
|
|
||
2 years ago
|
7. Adjust credentials, ownership and permission as required:
|
||
5 years ago
|
|
||
|
```
|
||
|
chown git:git ~/.postgresql/postgresql.crt ~/.postgresql/postgresql.key ~/.postgresql/root.crt
|
||
|
chown 0600 ~/.postgresql/postgresql.crt ~/.postgresql/postgresql.key ~/.postgresql/root.crt
|
||
|
```
|
||
|
|
||
2 years ago
|
8. Test the connection to the database:
|
||
5 years ago
|
|
||
|
```
|
||
|
psql "postgres://gitea@example.db/giteadb?sslmode=verify-full"
|
||
|
```
|
||
|
|
||
|
You should be prompted to enter password for the database user, and then be connected to the database.
|
||
|
|
||
|
### MySQL
|
||
|
|
||
|
While the MySQL driver used by Gitea also supports two-way TLS, Gitea currently supports only one-way TLS. See issue #10828 for details.
|
||
|
|
||
|
In one-way TLS, the database client verifies the certificate sent from server during the connection handshake, and the server assumes that the connected client is legitimate, since client certificate verification doesn't take place.
|
||
|
|
||
2 years ago
|
1. On the database instance, place the following credentials:
|
||
5 years ago
|
|
||
4 years ago
|
- `/path/to/mysql.crt`: Database instance certificate
|
||
|
- `/path/to/mysql.key`: Database instance key
|
||
|
- `/path/to/ca.crt`: CA certificate chain. This file isn't used on one-way TLS, but is used to validate client certificates on two-way TLS.
|
||
5 years ago
|
|
||
2 years ago
|
2. Add following options to `my.cnf`:
|
||
5 years ago
|
|
||
|
```ini
|
||
|
[mysqld]
|
||
|
ssl-ca = /path/to/ca.crt
|
||
|
ssl-cert = /path/to/mysql.crt
|
||
|
ssl-key = /path/to/mysql.key
|
||
|
tls-version = TLSv1.2,TLSv1.3
|
||
|
```
|
||
|
|
||
2 years ago
|
3. Adjust credentials ownership and permission:
|
||
5 years ago
|
|
||
|
```
|
||
|
chown mysql:mysql /path/to/ca.crt /path/to/mysql.crt /path/to/mysql.key
|
||
|
chmod 0600 /path/to/ca.crt /path/to/mysql.crt /path/to/mysql.key
|
||
|
```
|
||
|
|
||
2 years ago
|
4. Restart MySQL to apply the setting.
|
||
5 years ago
|
|
||
2 years ago
|
5. The database user for Gitea may have been created earlier, but it would authenticate only against the IP addresses of the server running Gitea. To authenticate against its domain name, recreate the user, and this time also set it to require TLS for connecting to the database:
|
||
5 years ago
|
|
||
|
```sql
|
||
|
DROP USER 'gitea'@'192.0.2.10';
|
||
|
CREATE USER 'gitea'@'example.gitea' IDENTIFIED BY 'gitea' REQUIRE SSL;
|
||
|
GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea'@'example.gitea';
|
||
|
FLUSH PRIVILEGES;
|
||
|
```
|
||
|
|
||
|
Replace database user name, password, and Gitea instance domain as appropriate.
|
||
|
|
||
2 years ago
|
6. Make sure that the CA certificate chain required to validate the database server certificate is on the system certificate store of both the database and Gitea servers. Consult your system documentation for instructions on adding a CA certificate to the certificate store.
|
||
5 years ago
|
|
||
2 years ago
|
7. On the server running Gitea, test connection to the database:
|
||
5 years ago
|
|
||
|
```
|
||
|
mysql -u gitea -h example.db -p --ssl
|
||
|
```
|
||
|
|
||
|
You should be connected to the database.
|