Eu estava usando a versão 24.05 Tux 4.9 há 2 anos, e funcionava perfeitamente. Porém, semana passada meu disco começou a encher durante o backup da madrugada e o Mkauth parava de autenticar os clientes por falta de espaço em disco. Os clientes que desconectavm o pppoe na madrugada ficavam desconectados. Então eu excluía o backup e voltavam a autenticar imediatamente.
Porém, dia de sábado, há 4 dias atrás, o disco encheu que nem fez o backup da madrugada e amanheceram desconectados. No sábado eu fiz uma nova instalação do Mkauth em um disco maior. Instalei a versão 24.xx Tux 6.6 e fiz upgrade que atualizou para a última disponível (25.03 Tux 6.6) e restaurei o backup. Todos os clientes autenticaram normalmente até ontem terça feira.
Porém, hoje amanheceu com os clientes desconectados. No log do Mikrotik, apareciam tentando autenticar via PPPoE com erro "user renilza authentication failed - radius timeout". Selecionei alguns clientes no Mkauth e mandei reparar, mas não voltaram. Então reiniciei o Mkauth, e todos voltaram.
Mas descobri algo: eles pararam de autenticar logo após o Mkauth ter feito o backup da madrugada. O backup finalizou às 02:27h e, um minuto depois, uma cliente desconectou e já não conseguiu mais se conectar.
A partir daí, todos os clientes que foram desconectando passaram a apresentar o mesmo erro no log, sem conseguir reconectar. Só voltaram após eu reiniciar o MKAuth à 06:40h.
Antes do horário em que o Mkauth fez o backup, todos os PPPoEs que desconectavam reconectavam normalmente logo em seguida. Ou seja, o problema começou após a execução do backup. O HD atual está com 70 GB livres, então não é mais falta de espaço.
As configurações entre Mikrotik e MKAuth estão corretas e passaram no teste da regra de SSH — tanto que os clientes reconectaram normalmente durante os 3 dias após a instalação.
O problema agora é a insegurança de não saber em qual dia os clientes podem amanhecer desconectados novamente.
No Netwatch do Mikrotik, tenho um ping que me envia e-mail caso o kauth pare de responder, mas ele não parou de pingar — ou seja, o servidor estava ativo, mas o serviço de autenticação aparentemente travou após o backup.
Lembrei que ontem eu executei esse comando no putty pois queria saber se conseguia um script que fizesse bachup completo /opt/mk-auth/hhvm/5-3-16/bin/php /opt/mk-auth/scripts/backup.php 2> /dev/null Esse script pode ter causado isso?
Respostas
Estou com esse problema:
Eu estava usando a versão 24.05 Tux 4.9 há 2 anos, e funcionava perfeitamente. Porém, semana passada meu disco começou a encher durante o backup da madrugada e o Mkauth parava de autenticar os clientes por falta de espaço em disco. Os clientes que desconectavm o pppoe na madrugada ficavam desconectados. Então eu excluía o backup e voltavam a autenticar imediatamente.
Porém, dia de sábado, há 4 dias atrás, o disco encheu que nem fez o backup da madrugada e amanheceram desconectados. No sábado eu fiz uma nova instalação do Mkauth em um disco maior. Instalei a versão 24.xx Tux 6.6 e fiz upgrade que atualizou para a última disponível (25.03 Tux 6.6) e restaurei o backup. Todos os clientes autenticaram normalmente até ontem terça feira.
Porém, hoje amanheceu com os clientes desconectados. No log do Mikrotik, apareciam tentando autenticar via PPPoE com erro "user renilza authentication failed - radius timeout". Selecionei alguns clientes no Mkauth e mandei reparar, mas não voltaram. Então reiniciei o Mkauth, e todos voltaram.
Mas descobri algo: eles pararam de autenticar logo após o Mkauth ter feito o backup da madrugada. O backup finalizou às 02:27h e, um minuto depois, uma cliente desconectou e já não conseguiu mais se conectar.
A partir daí, todos os clientes que foram desconectando passaram a apresentar o mesmo erro no log, sem conseguir reconectar. Só voltaram após eu reiniciar o MKAuth à 06:40h.
Antes do horário em que o Mkauth fez o backup, todos os PPPoEs que desconectavam reconectavam normalmente logo em seguida. Ou seja, o problema começou após a execução do backup.
O HD atual está com 70 GB livres, então não é mais falta de espaço.
As configurações entre Mikrotik e MKAuth estão corretas e passaram no teste da regra de SSH — tanto que os clientes reconectaram normalmente durante os 3 dias após a instalação.
O problema agora é a insegurança de não saber em qual dia os clientes podem amanhecer desconectados novamente.
No Netwatch do Mikrotik, tenho um ping que me envia e-mail caso o kauth pare de responder, mas ele não parou de pingar — ou seja, o servidor estava ativo, mas o serviço de autenticação aparentemente travou após o backup.
Lembrei que ontem eu executei esse comando no putty pois queria saber se conseguia um script que fizesse bachup completo /opt/mk-auth/hhvm/5-3-16/bin/php /opt/mk-auth/scripts/backup.php 2> /dev/null
Esse script pode ter causado isso?
BOM DIA
JÁ SOLICITEI A SUA AMIZADE
Bom dia VoxNet,
Solicite minha amizade aqui no fórum, que vou te ajudar.
Qualquer dúvida, estamos à disposição.
Atenciosamente,
Atendimento de suporte ao sistema
___________ MK-AUTH __________
Elton já fiz isso não deu certo não, não esta autenticando os clientes não, no firewall em Filter Rules o mk-auth mando o teste normalmente.
repara cliente e ver se vai derrubar ele
MK-AUTH 24.06 :: TUX 6.6
Bom dia prezado(a),
Estava funcionando e parou ou nunca funcionou?
A integração foi feita conforme manual https://mk-auth.com.br/page/manual-1 ?
Qual a versão do sistema?
Me envie o print dos logs do Mikrotik onde aparecem o erro de autenticação dos clietes.
Qualquer dúvida, estamos à disposição.
Atenciosamente,
Atendimento de suporte ao sistema
___________ MK-AUTH __________
Não autentica os clientes