fusion-registration-hunter/README.md

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

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):

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

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

./act_runner generate-config > config.yaml

Edite o config.yaml e substitua a seção labels para usar executor host (sem Docker):

labels:
  - "corp05:host"
  - "self-hosted:host"
  - "linux:host"

5. Criar o serviço systemd

Crie o arquivo /etc/systemd/system/act_runner.service:

[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

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:

curl https://bootstrap.pypa.io/pip/3.7/get-pip.py -o get-pip.py
python3 get-pip.py

Verifique a instalação:

/usr/bin/python3 -m pip --version

7. Clonar o repositório e configurar o .env

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)

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.