Some checks failed
Deploy corp04 / deploy (push) Successful in 1s
Deploy corp02 / deploy (push) Successful in 1s
Deploy corp03 / deploy (push) Successful in 4s
Deploy corp01 / deploy (push) Has been cancelled
Deploy corp05 / deploy (push) Has been cancelled
Deploy corp06 / deploy (push) Has been cancelled
Deploy corp07 / deploy (push) Has been cancelled
165 lines
4.3 KiB
Markdown
165 lines
4.3 KiB
Markdown
# Coleta de Registros FreeSWITCH + FusionPBX
|
|
|
|
Este script coleta os registros SIP ativos do FreeSWITCH, cruza com os ramais cadastrados no FusionPBX (PostgreSQL) e gera CSVs por domínio contendo status, dispositivo, troncos e DDR.
|
|
|
|
## O que ele gera
|
|
|
|
- Pasta `csv_registrations/` com um CSV por domínio.
|
|
- Colunas: Ramal, Domínio, Status, Dispositivo, Troncos, DDR.
|
|
|
|
## Requisitos
|
|
|
|
- Python 3.8+
|
|
- Acesso local ao `fs_cli` no servidor do FreeSWITCH
|
|
- Acesso local ao banco PostgreSQL do FusionPBX
|
|
- Dependência Python:
|
|
- `psycopg2-binary`
|
|
|
|
## Configuração
|
|
|
|
1. Copie o arquivo `.env.example` para `.env` e ajuste os valores.
|
|
2. Garanta que o usuário do banco tenha permissão de leitura nas tabelas do FusionPBX.
|
|
|
|
### Variáveis do `.env`
|
|
|
|
- `FS_CLI_PATH`: caminho do `fs_cli` (ex.: `fs_cli` ou `/usr/bin/fs_cli`)
|
|
- `FS_PROFILE`: perfil do FreeSWITCH (ex.: `internal`)
|
|
- `FS_CLI_TIMEOUT`: timeout em segundos do comando `fs_cli` (ex.: `10`)
|
|
- `DB_HOST`: host do Postgres
|
|
- `DB_PORT`: porta do Postgres
|
|
- `DB_NAME`: nome do banco
|
|
- `DB_USER`: usuário
|
|
- `DB_PASSWORD`: senha
|
|
|
|
## Como rodar
|
|
|
|
```bash
|
|
pip install -r requirements.txt
|
|
python3 coleta_registro.py
|
|
```
|
|
|
|
## Replicar para outros servidores
|
|
|
|
1. Clone este repositório no servidor que roda o FreeSWITCH.
|
|
2. Configure o `.env` com os parâmetros daquele servidor.
|
|
3. Instale dependências e execute.
|
|
|
|
Esse fluxo é o mais confiável porque o `fs_cli` normalmente precisa rodar localmente no servidor do FreeSWITCH.
|
|
|
|
## Deploy com Gitea Actions (runner no servidor)
|
|
|
|
Os workflows em `.gitea/workflows/` usam labels por servidor (ex.: `corp01`, `corp02`, etc.).
|
|
Para cada servidor:
|
|
|
|
1. Instale e registre o runner no próprio servidor.
|
|
2. Atribua a label correspondente (ex.: `corp03`).
|
|
3. Faça o clone em `/opt/collect-registry`.
|
|
|
|
No push, o runner com a label correta executa o deploy localmente, sem SSH.
|
|
|
|
## Adicionando um novo servidor (corp01, corp05, corp06, corp07...)
|
|
|
|
### 1. Obter o token do repositório
|
|
|
|
No Gitea, acesse o repositório → **Settings** → **Actions** → **Runners** → **Create Runner**.
|
|
Copie o token gerado.
|
|
|
|
### 2. Copiar o binário do act_runner
|
|
|
|
Copie o binário de um servidor que já tem o runner configurado (ex.: corp02):
|
|
|
|
```bash
|
|
mkdir -p /opt/act_runner
|
|
scp -P 60000 sothis@177.73.177.111:/opt/act_runner/act_runner /opt/act_runner/act_runner
|
|
chmod +x /opt/act_runner/act_runner
|
|
```
|
|
|
|
Ou baixe diretamente na página de releases do seu Gitea, se preferir.
|
|
|
|
### 3. Registrar o runner
|
|
|
|
```bash
|
|
cd /opt/act_runner
|
|
./act_runner register \
|
|
--instance http://10.0.120.75:3030 \
|
|
--token SEU_TOKEN \
|
|
--name corp05-runner \
|
|
--labels "corp05,self-hosted,linux" \
|
|
--no-interactive
|
|
```
|
|
|
|
Ajuste `--name` e `--labels` com o número do servidor correspondente.
|
|
|
|
### 4. Gerar e ajustar o config.yaml
|
|
|
|
```bash
|
|
./act_runner generate-config > config.yaml
|
|
```
|
|
|
|
Edite o `config.yaml` e substitua a seção `labels` para usar executor `host` (sem Docker):
|
|
|
|
```yaml
|
|
labels:
|
|
- "corp05:host"
|
|
- "self-hosted:host"
|
|
- "linux:host"
|
|
```
|
|
|
|
### 5. Criar o serviço systemd
|
|
|
|
Crie o arquivo `/etc/systemd/system/act_runner.service`:
|
|
|
|
```ini
|
|
[Unit]
|
|
Description=Gitea Actions Runner
|
|
After=network.target
|
|
|
|
[Service]
|
|
Type=simple
|
|
User=root
|
|
WorkingDirectory=/opt/act_runner
|
|
ExecStart=/opt/act_runner/act_runner daemon --config /opt/act_runner/config.yaml
|
|
Restart=always
|
|
RestartSec=5
|
|
|
|
[Install]
|
|
WantedBy=multi-user.target
|
|
```
|
|
|
|
```bash
|
|
systemctl daemon-reload
|
|
systemctl enable --now act_runner
|
|
systemctl status act_runner
|
|
```
|
|
|
|
### 6. Instalar o pip (se não estiver instalado)
|
|
|
|
Em servidores com Debian Buster (EOL), o pip pode não estar disponível via apt. Instale manualmente:
|
|
|
|
```bash
|
|
curl https://bootstrap.pypa.io/pip/3.7/get-pip.py -o get-pip.py
|
|
python3 get-pip.py
|
|
```
|
|
|
|
Verifique a instalação:
|
|
|
|
```bash
|
|
/usr/bin/python3 -m pip --version
|
|
```
|
|
|
|
### 7. Clonar o repositório e configurar o .env
|
|
|
|
```bash
|
|
git clone http://10.0.120.75:3030/Sothis/fusion-registration-hunter.git /opt/collect-registry
|
|
cp /home/sothis/.envs/collect/.env /opt/collect-registry/.env
|
|
```
|
|
|
|
O workflow do servidor correspondente cuidará do restante a cada push na branch `main`.
|
|
|
|
## Exemplo de crontab (rodar todos os dias às 02h)
|
|
|
|
```cron
|
|
0 2 * * * /usr/bin/python3 /opt/collect-registry/coleta_registro.py >> /var/log/coleta_registro.log 2>&1
|
|
```
|
|
|
|
Ajuste o caminho do Python e do projeto conforme o seu servidor. |