sexta-feira, 9 de março de 2018

Nobreak TS Shara Soho II - NUT - Linux - Raspberry PI - Como configurar

Este deve ser o post final de como configurar o NUT no linux para utilizar o nobreak TS Shara - SOHO. Vários detalhes tansformaram essa tarefa que devia ser fácil em um luta de algumas semanas. O objetivo era ter um nobreak que desligue e ligue automaticamente meu servidor de forma controlada no caso de falta e retorno de energia.

O maior problema encontrado é que nobreak parece repetir o ultimo comando enviado para ele sempre que a usb é reconectada. Isso é um problema quando o último comando pede que o nobreak seja desligado, aí quando ele é ligado novamente ele executa o comando de desligamento e apaga no meio do boot. E fica assim até voce desligar a usb ou executar alguma combinação de ligar no botão, tirar da tomada, etc.

Outro comando que não funciona corretamente neste nobreak é o desligar e ligar o nobreak após alguns minutos, que é o comando default utilizado durante o shutdown no NUT. No caso de falta de energia ele deveria ficar desligado até a energia voltar, e ligar automaticamente após os minutos configurados. Oque ele realmente faz é ficar ligando com ou sem energia.

O comando que funcionou corretamente é para somente desligar o nobreak. Quando ele é executado na falta de energia ele desliga o nobreak e liga quando a energia voltar. Isso esta ok. O problema é quando o comando é executado e ainda existe energia: neste caso ele desliga definitivamente e só liga manualmente no botão. Além disso caso aparece o problema de repetir o ultimo comando, e o nobreak apaga durante o boot.

Para contornar todos esse problemas a configuração encontrada foi esta:

Instalei somente o básico do nut:
sudo apt-get install nut-client nut-server

Fiz a configuração dele adicionando o texto abaixo em cada arquivo:

/etc/nut/nut.conf
MODE=standalone

/etc/nut/ups.conf
[tsshara]
        driver = nutdrv_qx
        desc = "tsshara"
        port = auto
        protocol = "megatec"
        offdelay = 60
        ondelay = 0

É importante ter ondelay = 0, para que o comando de shutdown correto seja enviado para o nobreak. Se alterar esse delay ele não funciona direito.

/etc/nut/upsd.users
[upsmon]
        password = "123456"
        upsmon master
        actions = SET
        instcmds = ALL

/etc/nut/upsmon.conf
MONITOR tsshara@localhost 1 upsmon "123456" master
NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC

Teste do driver. Ele deve mostrar algum erro se não funcionar.
sudo upsdrvctl start

Depois de um boot tudo deve funcionar. Para testar use:
upsc tsshara

Que deve apresentar algo assim:
Init SSL without certificate database
battery.charge: 92
battery.voltage: 12.80
battery.voltage.high: 13.00
battery.voltage.low: 10.40
battery.voltage.nominal: 12.0
device.mfr: UPS  700 VA AUT
device.model: TS Shara
device.type: ups
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.protocol: megatec
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.data: Megatec 0.06
driver.version.internal: 0.28
input.current.nominal: 4.0
input.frequency: 60.0
input.frequency.nominal: 60
input.voltage: 0.0
input.voltage.fault: 0.0
input.voltage.nominal: 115
output.voltage: 111.0
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.firmware: 20070731-5
ups.productid: 0035
ups.status: OB
ups.type: offline / line interactive
ups.vendorid: 0483

Para evitar o problema de repetir o último comando foi adicionada a última linha no arquivo /lib/systemd/system-shutdown/nutshutdown

#!/bin/sh
/sbin/upsmon -K >/dev/null 2>&1 && /sbin/upsdrvctl shutdown
# Comando para fazer uma leitura simples no nobreak e evitar bug de repeticao de shutdown
/lib/nut/nutdrv_qx -a tsshara 

Essa linha faz uma leitura genérica no nobreak, e contorna o bug de repetir o shutdown.

O desligamento pode ser testado com:
sudo upsmon -c fsd

Se o sistema estiver sem energia ele vai voltar quando a energia voltar. Se ele estiver com energia então isso vai desligar o sistema, e neste caso é necessário ligar manualmente o nobreak.

Essa configuração parece ser a que melhor funciona. Ela garante que o sistema seja desligado corretamente quando falta energia, e retorne quando a energia voltar. Existe uma chance que ela não funcione corretamente: se a energia voltar antes do sistema terminar o desligamento automático o nobreak não vai religar, o sistema vai ficar desligado. Será necessário religamento manual do nobreak. Entretando essa configuração protege o sistema do bug de repetição de comando e evita que o nobreak desligue no meio do próximo boot. Conclusão: pelo menos os sitema de arquivos não vai estragar. Se vc tiver muito azar as vezes vai precisar religar o sistema manualmente.

Em resumo esse nobreak da forma que está não é indicado para aplicações onde o nobreak precisa ligar/desligar automaticamente computador. Se eu soubesse de toda a dificuldade em fazer ele funcionar teria comprado outro modelo...(mas nada garante que outros modelos de nobreak não tenham bugs).

Importante notar que versões antigas do nutdrv_qx não funcionam no TS Shara. Outro ponto é que sistema linux diferentes do Raspberry podem ter o script the shutdown localizados em outro lugar. As versões utilizadas aqui podem ser vistas nos dados mostrados acima.


quarta-feira, 7 de março de 2018

Controle de nobreak TS Shara em Linux - Raspberry pi

Tenho um servidor em um Raspberry, e estava sofrendo com problema de sistema de arquivos corrompidos devido desligamento incorreto ( falta de energia ). Para resolver isso procurei um nobreak. Mas como é um servidor, e niguém fica por perto o nobreak precisa fazer duas coisas: (1) desligar o servidor de forma controlada quando faltar energia, e (2) ligar novamente o servidor quando a energia voltar. Procurei o nobreak mais barato com controle por USB e encontrei o TS Shara Solo II.

Para o do nobreak escolhi utilizar o pacote NUT, pois o fabricante oferece esse software no site (apesar de desatualizado).

Instalei somente o básico do nut:
sudo apt-get install nut-client nut-server

Fiz a configuração dele adicionando os texto abaixo em cada arquivo:

/etc/nut/nut.conf
MODE=standalone

/etc/nut/ups.conf
[tsshara]
        driver = nutdrv_qx
        desc = "tsshara"
        port = auto
        protocol = "megatec"

/etc/nut/upsd.users
[upsmon]
        password = "123456"
        upsmon master
        actions = SET
        instcmds = ALL

/etc/nut/upsmon.conf
MONITOR tsshara@localhost 1 upsmon "123456" master
NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC

Teste do driver. Ele deve mostrar algum erro se não funcionar.
sudo upsdrvctl start

Depois de um boot tudo estava funcionando. Para testar use:
upsc tsshara

Que deve apresentar algo assim:
Init SSL without certificate database
battery.charge: 92
battery.voltage: 12.80
battery.voltage.high: 13.00
battery.voltage.low: 10.40
battery.voltage.nominal: 12.0
device.mfr: UPS  700 VA AUT
device.model: TS Shara
device.type: ups
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.protocol: megatec
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.data: Megatec 0.06
driver.version.internal: 0.28
input.current.nominal: 4.0
input.frequency: 60.0
input.frequency.nominal: 60
input.voltage: 0.0
input.voltage.fault: 0.0
input.voltage.nominal: 115
output.voltage: 111.0
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.firmware: 20070731-5
ups.productid: 0035
ups.status: OB
ups.type: offline / line interactive
ups.vendorid: 0483

Hora de testar o desligamento/religamento controlado dele:
sudo upsmon -c fsd

O raspberry fez o shutdown direitinho e o nobreak desligou após 30 segundos. Após 180 segundos ele ligou novamente e no meio do boot o nobreak apagou!! Após 180 segundos ele ligou novamente e apagou no meio do boot novamente. E ficou ligando e desligando até eu aceitar que alguma coisa não estava funcionando direito. O sistema de arquivo ja tinha ido pro saco e tive que restaurar a imagem para fazer o raspberry funcionar novamente.

Esse não era o comportamento esperado, o nobreak não deveria desligar no meio do boot. Fiz alguns testes e identifiquei um possível bug no firmware do nobreak. Consegui fazer um paliativo para esse bug (apresentado em outro post) mas outro problema apareceu: o nobrek não ficava desligado quando estava sem energia, ele ligava, o raspberry dava boot, via que tinha pouca carga na bateria, mandava o nobreak desligar. O nobreak desligava por alguns minutos e ligava novamente, mesmo que ainda não tivesse energia. Ele ficava fazendo isso até acabar toda a carga da bateria. Logicamente não era isso que eu queria.

Após uma olhada no código fonte, e uma conversa com os desenvolvedores do NUT cheguei a seguinte configuração que funcionou:

/etc/nut/ups.conf
[tsshara]
        driver = nutdrv_qx
        desc = "tsshara"
        port = auto
        protocol = "megatec"
        offdelay = 30
        ondelay = 0

O parametro offdelay é o tempo em segundos que ele aguarda para desligar após receber o comando para desligar. o ondelay é o tempo que ele deveria esperar para voltar a funcionar após a energia ser reestabelecida. Entretanto utilizar um valor de ondelay diferente de zero não funciona neste nobreak, e ao invés de ele ficar desligado, ele fica reiniciando.

Nos testes também tentei o parametro stayoff, mas o nobreak não parece ser compativel com este comando e também fica reiniciando. Entretanto observei o seguinte ao utilizar a configuração acima:

1 - Quando falta energia e a bateria do nobreak esta próximo do fim, o NUT força o desligamento do nobreak. Quando a energia volta o nobreak liga após uns 5 segundos e o sistema volta a operar.
2 - Se o comando de desligamento do nobreak for feito enquanto ainda existe alimentação, o nobreak desliga e não retorna mais. E pior: quando o nobreak é ligado ele lembra do ultimo comando de shutdown e desliga novamente no meio do boot, e puff...arrebenta com o sistema de arquivo. No caso de faltar energia, e o sistema começar a fazer shutdown, se a energia voltar antes do nobreak desligar o sistema vai permanecer desligado, e quanto ele for ligado novamente pode ocorrer o desligamento do nobreak no boot. Não bom!

Portanto, quando for testar o desligamento do nobreak, tirar ele da tomada para simular uma falta de energia.

Para ficar 100% é necessário que o fabricante corrija os bugs do firmware do nobreak. Vou tentar um contato com eles para ver se chego em alguma coisa.