Olá sejam bem-vindos a mais uma documentação voltada para Freepbx, esta será curta e objetiva.
O nosso amigo e parceiro
RAFAEL TAVARES
da
Ibinetwork
desenvolveu um script de instalação customizada do freepbx 14 e asterisk 13 para Linux CentOS versão 7, este estamos trabalhando em melhorias juntamente com o apoio da comunidade no telegram
[FreePBX Brasil Community]
o mesmo faz a instalação dos módulos básicos para uso no dia-dia, regras sip para o firewalld, instalação dos áudios em português, codec g729 e tratamento de hangupcause, abaixo o link do script onde pode conferir mais detalhes, contamos com a sua ajuda para melhora-lo ainda mais.
O procedimento abaixo não será extenso como a maioria, apenas para documentar as configurações desconexão do equipamento DINSTAR(FXO), ao observar que existe uma certa carência deste tipo de documentação para tal modelo, este processo foi resolvido juntamente com o auxilio do Luciano Cavalcante amigo e parceiro da comunidade FreePBX Brasil Community.
Laboratório:
Asterisk 11;
DINSTAR – MODELO DAG1000-4O;
Linha Analógica da Operadora Oi.
Antes de mais nada se possível atualize seu equipamento, abaixo o link para acesso ao diretório compartilhado com as ultimas firmwares.
No equipamento no caminho:
Advanced
»
FXO Parameter
Segue a imagem abaixo:
Preencha com as seguintes informações de cadência: 250,230,250,230,250,230,330,230
Confira as demais informações acima e se caso tiver algo diferente no seu equipamento, ajuste.
Espero que esta documentação ajude e não deixe de compartilhar e contribuir com a comunidade, se caso você tiver alguma documentação relevante que queira compartilhar aqui, nos contate que será um prazer criarmos um post com novos conhecimentos.
O Systemd é responsável por gerenciar sistemas e serviços de alguns OS Linux. Foi desenvolvido para ser compatível com os scripts init do SysV e disponibiliza vários recursos, como a iniciar serviços em paralelo ao linux no momento do boot, a ativação por demanda de daemons ou a lógica de controle de serviço baseada em dependência. Um exemplo no CentOS 7 assim como em sistemas baseados em Red Hat , o systemd substitui o Upstart como o sistema init padrão.
O conceito de unidades systemd, são representadas por arquivos de configuração de unidade localizados em um dos diretórios listados na tabela abaixo,“Localizações de arquivos da unidade Systemd” e disponibilizam informações sobre serviços do sistema e outros objetos que são importantes para o sistema init, este será mencionado a seguir. Para ter acesso a mais informações sobre a lista completa dos tipos de unidade systemd disponíveis, confira na lista a seguir,“Tipos de unidade systemd disponíveis”.
Tipos de unidade systemd disponíveis
Tipo de Unidade
Extensão de Arquivo
Descrição
Unidade de serviço
.service
Um serviço do sistema.
Unidade alvo
.target
Um grupo de unidades systemd.
Unidade de montagem automática
.automount
Um ponto de montagem automática do sistema de arquivos.
Unidade do dispositivo
.device
Um arquivo de dispositivo reconhecido pelo kernel.
Unidade de montagem
.mount
Um ponto de montagem do sistema de arquivos.
Unidade de caminho
.path
Um arquivo ou diretório em um sistema de arquivos.
Unidade de escopo
.scope
Um processo criado externamente.
Unidade de fatia
.slice
Um grupo de unidades organizadas hierarquicamente que gerenciam processos do sistema.
Unidade de instantâneo
.snapshot
Um estado salvo do gerenciador do systemd.
Tomada de unidade
.socket
Um soquete de comunicação entre processos.
Unidade de swap
.swap
Um dispositivo de troca ou um arquivo de troca.
Unidade de temporizador
.timer
Um temporizador systemd.
Localizações dos arquivos da unidade Systemd
Diretório
Descrição
/usr//lib/systemd/system/
Arquivos unitários do Systemd distribuídos com pacotes RPM instalados.
/run/systemd/system/
Arquivos unitários do Systemd criados no tempo de execução. Esse diretório tem precedência sobre o diretório com arquivos da unidade de serviço instalados.
/etc/systemd/system/
Arquivos unitários do Systemd criados por systemctl enable arquivos de unidade adicionados para estender um serviço. Esse diretório tem precedência sobre o diretório com arquivos de unidade de tempo de execução.
Agora que foi feita uma breve abordagem do Systemd, será descrito a seguir um pouco do antecessor, init.
No sistema operacional Linux, init é a forma simplificada de Initialization. O init é um processo daemon que inicia no boot do servidor e continua em execução até que ele seja encerrado. O init é o primeiro processo que começa quando seu servidor inicializa, tornando-o o pai de todos os outros processos em execução direta ou indiretamente e normalmente é atribuído e identificado nos processos como "pid=1".
Se ocorrer algum erro e o daemon init não puder iniciar, nenhum dos demais processos serão inicializados e o sistema no boot irá apresentar falhas normalmente identificada como “Kernel Panic”. init é geralmente referido como Sistema de V (abreviado, SysV ou System Five) de inicialização. O System V é o primeiro sistema operacional UNIX comercial projetado e o uso do init na maior parte do Linux Distribution de hoje é idêntico ao System V OS com algumas exceções, como o Slackware usando estilo BSD e o Gentoo usando init customizado.
A demanda para substituição do init por algo melhor foi identificada no momento que foram desenvolvidas, algumas das substituições do init nativa da distro, segue algumas:
Upstart - Um daemon de substituição de init implementado no Ubuntu GNU / Linux e projetado para iniciar o processo de forma assíncrona.
Epoch - Um daemon de substituição de init criado em torno da simplicidade e do gerenciamento de serviços, projetado para iniciar o processo de thread único.
Mudar - Um daemon de substituição de init escrito em Python, implementado no Pardus GNU / Linux e projetado para iniciar o processo de forma assíncrona.
systemd - Um daemon de substituição de init projetado para iniciar o processo em paralelo, implementado em um número de distribuição padrão - Fedora, OpenSuSE, Arch, RHEL, CentOS, etc.
Analisando essas mudanças e observando que surgem algumas dúvidas no caso do CentOS 7, o habito de fazer uso do rc.local para inicialização de scripts customizados no boot do servidor, etc.
A seguir será apresentado duas formas de trabalhar com essas mudanças, a inicio será criado no systemd para no boot iniciar o seu script, no caso do laboratório será usado um script bash como exemplo, em segundo ambiente de estudo, será descrito como ativar no systemd para que carregue o rc.local do Linux.
Laboratório:
Virtualbox v5.2.26
OS - CentOS Linux Release 7.5.1804(Core)
Memoria 1024 MB
Disco 40GB
Este será criado no systemd para iniciar um script básico de firewall como um serviço comum do servidor.
Vá até o diretorio abaixo:
[root@labfreepbx ~]# cd /etc/rc.d/
Crie o seguinte arquivo:
[root@labfreepbx ~]# vim firewall.sh
Com o conteúdo:
#!/bin/bash
# Autor: Profº Kowalski
# Comunidade FreePBX Brasil
# Variaveis
LAN="enp0s3"
REDE_INTERNA="172.16.100.0/24"
# Limpa regras
iptables -t filter -F
iptables -t nat -F
# Policy default
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT
# Liberar interface lo e rede interna
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A INPUT -s $REDE_INTERNA -i $LAN -m comment --comment "REDE LOCAL" -j ACCEPT
Observações:
As variáveis “$LAN” e “$REDE_INTERNA” devem ser alteradas para as que atendam o seu ambiente de estudo, lembrando que este é apenas um script de estudo usado para simular uma necessidade diária, se for fazer uso deste em produção recomendo que revise e adeque as suas necessidades.
Após alimentar o script com as informações corretas do seu ambiente, salve e saia, se caso não souber no VIM usa-se ESC + :x! (Dois pontos, X minúsculo e exclamação), assim você salva e sai do arquivo forçando as alterações.
Agora será necessário a permissão de execução do script.
[root@labfreepbx ~]# chmod +x firewall.sh
Pronto, script criado, se for caso para não ter surpresas execute o mesmo somente para efeito de teste, e a seguir será criado o arquivo que o systemd inicie seu script no boot.
Onde “After=network.target” significa que ele inicializará após o serviço de rede, “ExecStart” defini o caminho do nosso arquivo bash e o “WantedBy” em qual destino da inicialização ele será executado.
Após alimentar o arquivo, salve e saia, a seguir rode os comandos para recarregar o systemd e habilitar no boot a execução do seu serviço/script.
Agora já pode reiniciar o seu servidor e veja se ao iniciar o mesmo executou o script como deve ser.
Até agora já abordamos como criar no systemd a inicialização dos seus serviços, correto! Mas Profº Kowalski se eu quiser utilizar o meu rc.local sem necessidade de criar para cada script um serviço no systemd, isso é possível? Sim, claro vamos lá! Você pode sim fazer desta forma, será descrito a seguir.
Desative seu atual serviço para não conflitar com as configurações a seguir ou se preferir pode remover.
Após alimentar o arquivo, salve e saia, a seguir rode os comandos para recarregar o systemd e habilitar no boot a execução do seu serviço/script.
A seguir reinicie o seu servidor para validar seu procedimento, ao voltar rode o seguinte comando:
[root@labfreepbx ~]# systemctl status rc-local.service
Observe que o status deve está como “Active” sendo assim o systemd está executando o rc.local no boot corretamente.
Essa foi mais uma documentação para comunidade, não deixe de acompanhar as nossas mídias sociais, um forte abraço e até a próxima.
