feat: adicionadas configuracoes de rede Wireguard e ssh keys da vps1, vps3 e vps4
This commit is contained in:
Rui
@@ -0,0 +1,26 @@
|
|||||||
|
# 🖥️ Configuração de Rede Segura (VPN WireGuard) - VPS 1 (Hub Central / Gateway)
|
||||||
|
|
||||||
|
Este diretório contém a configuração e o backup de referência do WireGuard para a **VPS 1** (`10.99.0.1`), que atua como o Hub Central (servidor principal) da rede privada criptografada do **Clube67**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 📁 Arquivos de Configuração Disponíveis
|
||||||
|
|
||||||
|
1. **[wg0.conf](file:///home/deploy/instrucoes/VPS-0.1/wg0.conf)**: Arquivo completo de configuração do WireGuard para ser colocado em `/etc/wireguard/wg0.conf` na **VPS 1**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🛠️ Detalhes do Roteamento (NAT Forwarding)
|
||||||
|
|
||||||
|
Como a **VPS 1** é o ponto de convergência de toda a rede VPN, o encaminhamento de pacotes IPv4 (*IP Forwarding*) precisa estar ativado no Kernel do Linux.
|
||||||
|
|
||||||
|
1. **Ativar o Forwarding no Kernel**:
|
||||||
|
```bash
|
||||||
|
sudo sysctl -w net.ipv4.ip_forward=1
|
||||||
|
```
|
||||||
|
2. **Persistir a configuração**:
|
||||||
|
Certifique-se de descomentar ou adicionar a linha abaixo em `/etc/sysctl.conf`:
|
||||||
|
```text
|
||||||
|
net.ipv4.ip_forward=1
|
||||||
|
```
|
||||||
|
*Comando para aplicar imediatamente:* `sudo sysctl -p`
|
||||||
@@ -0,0 +1,36 @@
|
|||||||
|
# /etc/wireguard/wg0.conf - VPS 1 (Hub Central / Gateway)
|
||||||
|
# IP Privado VPN: 10.99.0.1
|
||||||
|
|
||||||
|
[Interface]
|
||||||
|
Address = 10.99.0.1/24
|
||||||
|
PrivateKey = <Chave_Privada_VPS1_Omitida_Por_Seguranca>
|
||||||
|
ListenPort = 51820
|
||||||
|
|
||||||
|
# Habilitar forwarding de pacotes para comunicação entre peers (Estrela/Hub)
|
||||||
|
# Certifique-se de que net.ipv4.ip_forward = 1 está ativado no sysctl.conf
|
||||||
|
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
|
||||||
|
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
|
||||||
|
|
||||||
|
# ----------------------------------------------------
|
||||||
|
# PEERS AUTORIZADOS NA VPN (10.99.0.0/24)
|
||||||
|
# ----------------------------------------------------
|
||||||
|
|
||||||
|
# Peer 1: Notebook do Rui (Administrador)
|
||||||
|
[Peer]
|
||||||
|
PublicKey = <Chave_Publica_do_Notebook_do_Rui>
|
||||||
|
AllowedIPs = 10.99.0.10/32
|
||||||
|
|
||||||
|
# Peer 2: VPS 3 (Banco de Dados Dedicado)
|
||||||
|
[Peer]
|
||||||
|
PublicKey = S40JqovA4F8oH8aieWsDvNEv1yw5Juwu1wb4zHjQ8Ww=
|
||||||
|
AllowedIPs = 10.99.0.3/32
|
||||||
|
|
||||||
|
# Peer 3: VPS 4 (Desenvolvimento / Staging)
|
||||||
|
[Peer]
|
||||||
|
PublicKey = ln7phEfm4w//jZJqqlkGAjsXKWQnOw2kYc64ni5PXX0=
|
||||||
|
AllowedIPs = 10.99.0.4/32
|
||||||
|
|
||||||
|
# Peer 4: VPS 5 (CRM WhatsApp / newwhats)
|
||||||
|
[Peer]
|
||||||
|
PublicKey = <Chave_Publica_da_VPS_5_Omitida>
|
||||||
|
AllowedIPs = 10.99.0.5/32
|
||||||
@@ -0,0 +1,15 @@
|
|||||||
|
# 🗄️ Configuração de Rede Segura (VPN WireGuard) - VPS 3 (Banco de Dados Dedicado)
|
||||||
|
|
||||||
|
Este diretório contém a configuração e o backup de referência do WireGuard para a **VPS 3** (`10.99.0.3`).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 📁 Arquivos de Configuração Disponíveis
|
||||||
|
|
||||||
|
1. **[wg0.conf](file:///home/deploy/instrucoes/VPS-0.3/wg0.conf)**: Arquivo completo de configuração do WireGuard para ser colocado em `/etc/wireguard/wg0.conf` na **VPS 3**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🛠️ Detalhes da Conexão
|
||||||
|
|
||||||
|
Como a rede adota uma topologia **Hub-and-Spoke**, a **VPS 3** conecta-se diretamente ao servidor central (**VPS 1**) através da interface virtual `wg0`. O tráfego para qualquer outro peer na sub-rede `10.99.0.0/24` (incluindo a **VPS 4** de desenvolvimento) é automaticamente encaminhado e roteado pelo Hub.
|
||||||
@@ -0,0 +1,14 @@
|
|||||||
|
# /etc/wireguard/wg0.conf - VPS 3 (Banco de Dados Dedicado)
|
||||||
|
# IP Privado VPN: 10.99.0.3
|
||||||
|
|
||||||
|
[Interface]
|
||||||
|
Address = 10.99.0.3/24
|
||||||
|
PrivateKey = <Chave_Privada_VPS3_Omitida_Por_Seguranca>
|
||||||
|
ListenPort = 52830
|
||||||
|
|
||||||
|
[Peer]
|
||||||
|
# VPS 1 (Hub Central / Gateway de Entrada)
|
||||||
|
PublicKey = jUWnuc+82vQ6kLMSI7W1i7hBRBgQKcaSZ8yJy56QSUw=
|
||||||
|
AllowedIPs = 10.99.0.0/24
|
||||||
|
Endpoint = 158.220.109.237:51820
|
||||||
|
PersistentKeepalive = 25
|
||||||
@@ -0,0 +1,105 @@
|
|||||||
|
# 🧪 Configuração de Rede Segura (VPN WireGuard) - VPS 4 (Desenvolvimento / Staging)
|
||||||
|
|
||||||
|
Este diretório contém os arquivos de configuração necessários para que a **VPS 4** (`10.99.0.4`) entre na rede privada criptografada do **Clube67** de forma totalmente segura.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🗺️ Visão de Conexão da VPS 4
|
||||||
|
```mermaid
|
||||||
|
graph LR
|
||||||
|
VPS4["🧪 VPS 4 (Staging) <br> IP: 10.99.0.4"]
|
||||||
|
VPS1["🖥️ VPS 1 (Hub Central) <br> IP: 10.99.0.1"]
|
||||||
|
VPS3["🗄️ VPS 3 (Banco de Dados) <br> IP: 10.99.0.3"]
|
||||||
|
|
||||||
|
VPS4 <== Canal Seguro VPN (Porta UDP 51820) ==> VPS1
|
||||||
|
VPS4 -- Replicação PostgreSQL (Porta 5432) --> VPS3
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 📁 Arquivos de Configuração Disponíveis
|
||||||
|
|
||||||
|
1. **[wg0.conf](file:///home/deploy/instrucoes/VPS-0.4/wg0.conf)**: Arquivo completo de configuração do WireGuard para ser colocado em `/etc/wireguard/wg0.conf` na **VPS 4**.
|
||||||
|
2. **[hub_peer_vps4.conf](file:///home/deploy/instrucoes/VPS-0.4/hub_peer_vps4.conf)**: Snippet de peer para ser adicionado à configuração do Hub (**VPS 1**).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🛠️ Passo a Passo para Configuração
|
||||||
|
|
||||||
|
### Passo 1: Configurar o Peer no Hub Central (VPS 1)
|
||||||
|
Antes de ativar a conexão na VPS 4, o servidor central (**VPS 1**) precisa autorizar a sua chave pública.
|
||||||
|
|
||||||
|
1. Acesse o terminal da **VPS 1**.
|
||||||
|
2. Abra o arquivo `/etc/wireguard/wg0.conf` para edição:
|
||||||
|
```bash
|
||||||
|
sudo nano /etc/wireguard/wg0.conf
|
||||||
|
```
|
||||||
|
3. Adicione o seguinte bloco de peer ao final do arquivo:
|
||||||
|
```ini
|
||||||
|
[Peer]
|
||||||
|
# VPS 4 (Desenvolvimento / Staging)
|
||||||
|
PublicKey = ln7phEfm4w//jZJqqlkGAjsXKWQnOw2kYc64ni5PXX0=
|
||||||
|
AllowedIPs = 10.99.0.4/32
|
||||||
|
PersistentKeepalive = 25
|
||||||
|
```
|
||||||
|
4. Salve e recarregue as configurações do WireGuard na VPS 1 de forma viva (sem derrubar as conexões existentes):
|
||||||
|
```bash
|
||||||
|
sudo wg syncconf wg0 <(wg-quick strip wg0)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Passo 2: Configurar o Cliente WireGuard na VPS 4
|
||||||
|
1. Acesse o terminal da **VPS 4**.
|
||||||
|
2. Instale o WireGuard caso ainda não esteja instalado:
|
||||||
|
```bash
|
||||||
|
sudo apt-get update && sudo apt-get install -y wireguard
|
||||||
|
```
|
||||||
|
3. Crie o arquivo `/etc/wireguard/wg0.conf` e cole o seguinte conteúdo:
|
||||||
|
```ini
|
||||||
|
[Interface]
|
||||||
|
Address = 10.99.0.4/24
|
||||||
|
PrivateKey = 4PAIHMPhK0RSs878Lc275hCu2lluzm0QTY9x7T25XEQ=
|
||||||
|
DNS = 1.1.1.1, 8.8.8.8
|
||||||
|
|
||||||
|
[Peer]
|
||||||
|
# VPS 1 (Hub Central / Gateway de Entrada)
|
||||||
|
PublicKey = jUWnuc+82vQ6kLMSI7W1i7hBRBgQKcaSZ8yJy56QSUw=
|
||||||
|
AllowedIPs = 10.99.0.0/24
|
||||||
|
Endpoint = 158.220.109.237:51820
|
||||||
|
PersistentKeepalive = 25
|
||||||
|
```
|
||||||
|
4. Ajuste as permissões do arquivo para segurança máxima (somente leitura para o root):
|
||||||
|
```bash
|
||||||
|
sudo chmod 600 /etc/wireguard/wg0.conf
|
||||||
|
```
|
||||||
|
5. Inicie a interface VPN e configure para iniciar automaticamente no reboot:
|
||||||
|
```bash
|
||||||
|
sudo systemctl enable wg-quick@wg0.service
|
||||||
|
sudo systemctl start wg-quick@wg0.service
|
||||||
|
```
|
||||||
|
|
||||||
|
### Passo 3: Testar e Validar a Conexão
|
||||||
|
Para verificar se a VPS 4 está inserida na rede com sucesso:
|
||||||
|
1. Veja o status do link:
|
||||||
|
```bash
|
||||||
|
sudo wg show
|
||||||
|
```
|
||||||
|
2. Realize um ping teste para o Hub central e para a VPS 3 (banco de dados):
|
||||||
|
```bash
|
||||||
|
ping -c 3 10.99.0.1
|
||||||
|
ping -c 3 10.99.0.3
|
||||||
|
```
|
||||||
|
3. Teste a conexão segura de replicação com o PostgreSQL da VPS 3:
|
||||||
|
```bash
|
||||||
|
pg_isready -h 10.99.0.3 -p 5432
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🔒 Diretrizes de Segurança (Hardening) para a VPS 4
|
||||||
|
|
||||||
|
* **Firewall UFW**: Mantenha o UFW ativo na VPS 4, liberando a porta SSH pública apenas para a VPN ou desativando o SSH público inteiramente caso queira operá-la 100% Zero-Trust (acessível apenas pelo link WireGuard `10.99.0.4` do notebook do Rui).
|
||||||
|
* **Non-local Bind**: Ative o nonlocal bind para que serviços dependentes da VPN possam iniciar no boot sem falhar se a interface wg0 demorar alguns milissegundos para subir:
|
||||||
|
```bash
|
||||||
|
echo "net.ipv4.ip_nonlocal_bind=1" | sudo tee -a /etc/sysctl.conf
|
||||||
|
sudo sysctl -p
|
||||||
|
```
|
||||||
@@ -0,0 +1,8 @@
|
|||||||
|
# Trecho de configuração a ser adicionado em /etc/wireguard/wg0.conf da VPS 1 (Hub Central)
|
||||||
|
# Adicione este bloco ao final do arquivo para autorizar a conexão da VPS 4
|
||||||
|
|
||||||
|
[Peer]
|
||||||
|
# VPS 4 (Desenvolvimento / Staging)
|
||||||
|
PublicKey = ln7phEfm4w//jZJqqlkGAjsXKWQnOw2kYc64ni5PXX0=
|
||||||
|
AllowedIPs = 10.99.0.4/32
|
||||||
|
PersistentKeepalive = 25
|
||||||
@@ -0,0 +1,16 @@
|
|||||||
|
# /etc/wireguard/wg0.conf - VPS 4 (Desenvolvimento / Staging)
|
||||||
|
# Configuração de Cliente VPN WireGuard
|
||||||
|
# IP Atribuído: 10.99.0.4
|
||||||
|
|
||||||
|
[Interface]
|
||||||
|
Address = 10.99.0.4/24
|
||||||
|
PrivateKey = 4PAIHMPhK0RSs878Lc275hCu2lluzm0QTY9x7T25XEQ=
|
||||||
|
# DNS opcional para resolução interna segura, se necessário
|
||||||
|
DNS = 1.1.1.1, 8.8.8.8
|
||||||
|
|
||||||
|
[Peer]
|
||||||
|
# VPS 1 (Hub Central / Gateway de Entrada)
|
||||||
|
PublicKey = jUWnuc+82vQ6kLMSI7W1i7hBRBgQKcaSZ8yJy56QSUw=
|
||||||
|
AllowedIPs = 10.99.0.0/24
|
||||||
|
Endpoint = 158.220.109.237:51820
|
||||||
|
PersistentKeepalive = 25
|
||||||
+102
-4
@@ -82,7 +82,7 @@ ALTER DATABASE temporal OWNER TO temporal_user;
|
|||||||
|
|
||||||
## 📊 2. Hardening da Configuração do PostgreSQL (`pg_hba.conf`)
|
## 📊 2. Hardening da Configuração do PostgreSQL (`pg_hba.conf`)
|
||||||
|
|
||||||
Edite o arquivo `/etc/postgresql/15/main/pg_hba.conf` para garantir que o acesso ao banco de dados seja liberado apenas para os papéis designados originados da rede interna da VPN Wireguard:
|
Edite o arquivo `/etc/postgresql/18/main/pg_hba.conf` para garantir que o acesso ao banco de dados seja liberado apenas para os papéis designados originados da rede interna da VPN Wireguard:
|
||||||
|
|
||||||
```text
|
```text
|
||||||
# TYPE DATABASE USER ADDRESS METHOD
|
# TYPE DATABASE USER ADDRESS METHOD
|
||||||
@@ -96,7 +96,10 @@ host newwhats newwhats_user 10.99.0.5/32 scram-sha-25
|
|||||||
# 3. Permitir que o orquestrador Temporal (VPS 5) conecte apenas no database temporal
|
# 3. Permitir que o orquestrador Temporal (VPS 5) conecte apenas no database temporal
|
||||||
host temporal temporal_user 10.99.0.5/32 scram-sha-256
|
host temporal temporal_user 10.99.0.5/32 scram-sha-256
|
||||||
|
|
||||||
# 4. Bloqueio preventivo total para qualquer outro IP ou usuário
|
# 4. Permitir conexões de replicação da VPS 4 (Staging/Replica)
|
||||||
|
host replication replicator 10.99.0.4/32 scram-sha-256
|
||||||
|
|
||||||
|
# 5. Bloqueio preventivo total para qualquer outro IP ou usuário
|
||||||
host all all 0.0.0.0/0 reject
|
host all all 0.0.0.0/0 reject
|
||||||
```
|
```
|
||||||
|
|
||||||
@@ -180,7 +183,7 @@ PostgreSQL (VPS 3)
|
|||||||
```
|
```
|
||||||
|
|
||||||
#### 2. Configuração do `pg_hba.conf` para Múltiplos Projetos:
|
#### 2. Configuração do `pg_hba.conf` para Múltiplos Projetos:
|
||||||
Edite o arquivo `/etc/postgresql/15/main/pg_hba.conf` para mapear de forma cirúrgica as origens permitidas para cada projeto:
|
Edite o arquivo `/etc/postgresql/18/main/pg_hba.conf` para mapear de forma cirúrgica as origens permitidas para cada projeto:
|
||||||
|
|
||||||
```text
|
```text
|
||||||
# TYPE DATABASE USER ADDRESS METHOD
|
# TYPE DATABASE USER ADDRESS METHOD
|
||||||
@@ -197,7 +200,10 @@ host facebook_db facebook_user 10.99.0.1/32 scram-sha-25
|
|||||||
# 4. Projeto NEWWHATS (Backend na VPS 5 -> Banco na VPS 3)
|
# 4. Projeto NEWWHATS (Backend na VPS 5 -> Banco na VPS 3)
|
||||||
host newwhats newwhats_user 10.99.0.5/32 scram-sha-256
|
host newwhats newwhats_user 10.99.0.5/32 scram-sha-256
|
||||||
|
|
||||||
# 5. BLOQUEIO PADRÃO TOTAL (Zero-Trust)
|
# 5. Permitir conexões de replicação da VPS 4 (Staging/Replica)
|
||||||
|
host replication replicator 10.99.0.4/32 scram-sha-256
|
||||||
|
|
||||||
|
# 6. BLOQUEIO PADRÃO TOTAL (Zero-Trust)
|
||||||
host all all 0.0.0.0/0 reject
|
host all all 0.0.0.0/0 reject
|
||||||
```
|
```
|
||||||
|
|
||||||
@@ -210,3 +216,95 @@ Cada aplicação Node.js aberta na VPS 1 tentará criar um pool de conexões per
|
|||||||
```
|
```
|
||||||
* **PgBouncer (Avançado)**: Se o número de projetos escalonar para dezenas de aplicações na VPS 1, configure o **PgBouncer** na VPS 3 para multiplexar centenas de conexões virtuais em poucas conexões físicas reais do Postgres, reduzindo drasticamente o consumo de RAM.
|
* **PgBouncer (Avançado)**: Se o número de projetos escalonar para dezenas de aplicações na VPS 1, configure o **PgBouncer** na VPS 3 para multiplexar centenas de conexões virtuais em poucas conexões físicas reais do Postgres, reduzindo drasticamente o consumo de RAM.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🚀 5. Otimização de Performance e Tuning do PostgreSQL 18
|
||||||
|
|
||||||
|
Para aproveitar ao máximo os **8 GB de RAM e 4 núcleos de CPU** da VPS 3 (Data Appliance) e garantir o processamento rápido e estável de dados para o `newwhats` e o `giteadb`, aplicamos um tuning avançado nativo.
|
||||||
|
|
||||||
|
As configurações foram modularizadas no arquivo `/etc/postgresql/18/main/conf.d/tuning.conf` para manter o `postgresql.conf` limpo e facilitar a portabilidade:
|
||||||
|
|
||||||
|
```ini
|
||||||
|
# ==========================================
|
||||||
|
# PostgreSQL Performance Tuning Configuration
|
||||||
|
# Optimized for 8 GB RAM / 4 CPU Cores
|
||||||
|
# ==========================================
|
||||||
|
|
||||||
|
# Memory Configuration
|
||||||
|
shared_buffers = 2GB
|
||||||
|
effective_cache_size = 6GB
|
||||||
|
maintenance_work_mem = 512MB
|
||||||
|
work_mem = 10MB
|
||||||
|
|
||||||
|
# Write-Ahead Log (WAL) Configuration
|
||||||
|
checkpoint_completion_target = 0.9
|
||||||
|
wal_buffers = 16MB
|
||||||
|
min_wal_size = 1GB
|
||||||
|
max_wal_size = 4GB
|
||||||
|
|
||||||
|
# Disk and Query Planner Settings (assuming SSD/NVMe)
|
||||||
|
random_page_cost = 1.1
|
||||||
|
effective_io_concurrency = 200
|
||||||
|
default_statistics_target = 100
|
||||||
|
|
||||||
|
# Worker Process and Parallelism Settings
|
||||||
|
max_worker_processes = 4
|
||||||
|
max_parallel_workers_per_gather = 2
|
||||||
|
max_parallel_workers = 4
|
||||||
|
max_parallel_maintenance_workers = 2
|
||||||
|
|
||||||
|
# Connections Configuration
|
||||||
|
max_connections = 100
|
||||||
|
```
|
||||||
|
|
||||||
|
### 🏁 Passos de ativação e validação:
|
||||||
|
```bash
|
||||||
|
# Reiniciar o serviço do cluster 18-main
|
||||||
|
sudo systemctl restart postgresql@18-main.service
|
||||||
|
|
||||||
|
# Confirmar os parâmetros carregados
|
||||||
|
sudo -u postgres psql -c "SHOW shared_buffers; SHOW effective_cache_size; SHOW work_mem;"
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🧁 6. Resiliência de Inicialização do Gitea e DragonflyDB (Non-local Bind)
|
||||||
|
|
||||||
|
### 🔴 O Problema do Boot Sequencial
|
||||||
|
Como o Gitea (`HTTP_ADDR = 10.99.0.3`) e o DragonflyDB (`--bind 10.99.0.3`) escutam exclusivamente no IP interno da VPN Wireguard, ocorria uma **falha de bind no reboot**:
|
||||||
|
* O systemd inicializava estes serviços alguns milissegundos **antes** que a interface VPN (`wg0`) estivesse totalmente ativa e com o IP associado.
|
||||||
|
* Isso resultava no erro `bind: cannot assign requested address`.
|
||||||
|
* No caso do Gitea, ele falhava silenciosamente mantendo o processo de gerenciamento ativo, o que impedia o systemd de perceber a queda e reiniciar o serviço automaticamente.
|
||||||
|
|
||||||
|
### 🛡️ Solução Permanente Implementada
|
||||||
|
|
||||||
|
#### 1. Configuração de Kernel: Non-local Bind
|
||||||
|
Ativamos uma diretiva de kernel para permitir que os daemons executem o bind em IPs de interfaces que ainda não estejam totalmente ativas no momento do boot:
|
||||||
|
```bash
|
||||||
|
# Ativar imediatamente
|
||||||
|
sudo sysctl -w net.ipv4.ip_nonlocal_bind=1
|
||||||
|
|
||||||
|
# Persistir para reboots futuros
|
||||||
|
echo "net.ipv4.ip_nonlocal_bind=1" | sudo tee -a /etc/sysctl.conf
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 2. Dependência no Systemd do Gitea
|
||||||
|
Atualizamos a unidade `/etc/systemd/system/gitea.service` para exigir que a rede esteja completamente online antes do início do Gitea:
|
||||||
|
```ini
|
||||||
|
[Unit]
|
||||||
|
Description=Gitea (Git with a cup of tea)
|
||||||
|
After=syslog.target network.target network-online.target postgresql.service
|
||||||
|
Wants=network-online.target
|
||||||
|
```
|
||||||
|
*Após atualizar, execute:* `sudo systemctl daemon-reload`
|
||||||
|
|
||||||
|
#### 3. Dependência no Systemd do DragonflyDB (Override Nativo)
|
||||||
|
Criamos um arquivo de override limpo para o DragonflyDB em `/etc/systemd/system/dragonfly.service.d/override.conf`:
|
||||||
|
```ini
|
||||||
|
[Unit]
|
||||||
|
After=network-online.target
|
||||||
|
Wants=network-online.target
|
||||||
|
```
|
||||||
|
*Após criar, execute:* `sudo systemctl daemon-reload`
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user