Ir al contenido principal

Configurando un SAI en Linux I

Estamos trabajando en un proyecto, llevamos varias páginas de texto escrita y de repente se va la luz. Esto es algo que le puede suceder a cualquiera que trabaje con un PC. Si trabajamos con un portátil la batería del mismo nos protege ante estas situaciones. Pero, ¿podemos ponerle una batería a un PC? La respuesta es sí y se llama SAI, Sistema de Alimentación Ininterrumpida.

Es normal que los servidores estén protegidos frente a picos  o caídas de tensión gracias al uso de SAI, pero no es habitual que los usuarios tengan uno en sus PC. Actualmente el precio de los SAI ha bajado considerablemente y un usuario doméstico se lo puede permitir.

En mi caso particular, sufro constantes corte de luz debido a que el diferencial de mi casa salta aleatoriamente. Al principio pensaba que el problema estaba ocasionado por algún electrodoméstico de la casa, pero me di cuenta de que el problema es externo. No sólo me afecta a mí sino a muchos vecinos. De hecho, más de una vez ha saltado el diferencial cuando estaba asomado a la ventana y he visto como a varios vecinos se le ha ido la luz al mismo tiempo.

Para evitar que estos cortes de luz me afecten cuando estoy trabajando con mi PC decidí comprar un SAI, en concreto un APC Back-up 1400VA con tomas schuko. Este modelo excede mis necesidades, pero estaba de oferta.

Me decanté por la marca APC ya que tiene un buen soporte para Linux, al contrario que otras marcas. Todos traen software para Windows pero carecen de aplicaciones para Linux.

A la hora de instalarlo sólo hay que conectar el PC y los periféricos al SAI. Se conecta el SAI a un enchufe y listo. Bueno, de esta manera funciona pero el PC no sabe que está conectado a un SAI. Para que el PC se comunique con el SAI hay que conectarlo por medio de un cable USB.

Una vez conectado el cable USB, Linux Mint lo reconoce directamente y lo gestiona como la batería de un portátil. En la barra de notificaciones aparece un icono de batería,




y si le hacemos clic sobre él, nos muestra la siguiente ventana indicando el nivel de carga de las baterías del SAI.





Instalación y Configuración

Pero si queremos más información o queremos controlar el SAI, tenemos que instalar el paquete apcupsd. Para ello tecleamos desde la terminal:

$ sudo apt install apcupsd

Este paquete instala un servicio (daemon en inglés, de ahí que termine en "d" su nombre) que se comunica con el SAI de APC y nos permite, con ayuda de otras herramientas, monitorizarlo.

Una vez instalado el paquete anterior tenemos que configurarlo. El primer paso es editar el fichero /etc/default/apcupsd y poner a yes el parámetro ISCONFIGURED, a continuación se muestra como quedaría este fichero tras el cambio:

# Defaults for apcupsd initscript
# Apcupsd-devel internal configuration

APCACCESS=/sbin/apcaccess
ISCONFIGURED=yes

Como en la mayoría de los ficheros de configuración los comentarios comienzan con el carácter almohadilla.

El siguiente paso consiste en editar el fichero /etc/apcupsd/apcupsd.conf para configurar el software, aquí vamos a modificar varios parámetros:

UPSNAME: Este parámetro nos permite ponerle un nombre al SAI, en mi caso he puesto miSAI.

UPSNAME miSAI

UPSCABLE: Este parámetro sirve para indicar que tipo de cable conecta el SAI con el PC. Si se utiliza un cable USB, que es lo más normal hoy en día, cambiaremos smart por usb.

UPSCABLE usb

UPSTYPE y DEVICE: Estos dos parámetros están relacionados  e indican el tipo de SAI. Para nuestro caso que estamos utilizando un cable USB debemos indicar que UPSTYPE es usb y debemos dejar en blanco el parámetro DEVICE.

UPSTYPE usb
DEVICE

A continuación encontramos una serie de parámetros relacionados con el comportamiento del PC a la hora de un fallo en el suministro eléctrico, yo personalmente he dejado los valores que venían por defecto ya que son adecuados para la mayoría de las situaciones:

ONBATTERYDELAY: Indica el tiempo en segundos que el software debe esperar desde que se produce el corte de luz hasta que empieza a reaccionar, por defecto 6. Si se producen microcortes con este parámetro nos ahorramos que el software empiece a actuar.

BATTERYLEVEL, MINUTES y TIMEOUT: Estos tres parámetros pueden disparar el evento que provocaría el apagado del equipo. El primero de los tres que se cumpla desencadenará dicho evento.

BATTERYLEVEL: Indica el porcentaje  restante de la batería, por defecto 5. Esto quiere decir, que si estamos ante un apagón y queda un 5%  o menos de carga de batería, el evento se disparará.

MINUTES: Por defecto, 3. Significa que si estamos ante un corte del suministro y queda menos de 3 minutos de batería, el evento se disparará.

TIMEOUT: Se utiliza en SAI antiguos, con los nuevos no es necesario y un valor de 0, que es el que viene por defecto, lo deshabilita.

ANNOY: Es el tiempo en segundos antes de que ocurra uno de los eventos anteriores, que el SAI utilizará para empezar a avisar a los usuarios que el sistema se va a apagar.

Por otro lado, apcupsd también cuenta con un servidor de red que permite a los usuarios comunicarse con él desde otros equipos. 

NETSERVER: Indica si se activa o no el servidor de red, por defecto viene activado on.

NISIP: Dirección IP por la cual escuchará las peticiones, por defecto 0.0.0.0. Esto quiere decir que atenderá cualquier petición que le llegue por la red. En mi caso he puesto 127.0.0.1 para que sólo se pueda acceder desde el propio PC y no atienda las peticiones externas.

NISPORT: Es el puerto TCP que utiliza, por defecto 3551.

Con esto ya tendremos nuestro software de monitorización del SAI configurado, ahora tenemos que reiniciarlo para que los cambios surtan efecto.

$ sudo service apcupsd restart

Como la mayoría de los servicios admite, start, stop, restart y status.

Monitorizando

Ahora que ya hemos terminado con la instalación y configuración podemos acceder a la información del SAI con el comando apcaccess:

$ apcaccess 
APC      : 001,036,0855
DATE     : 2018-10-14 13:35:02 +0200  
HOSTNAME : pc001
VERSION  : 3.14.12 (29 March 2014) debian
UPSNAME  : miSAI
CABLE    : USB Cable
DRIVER   : USB UPS Driver
UPSMODE  : Stand Alone
STARTTIME: 2018-10-14 11:48:23 +0200  
MODEL    : Back-UPS XS 1400U  
STATUS   : ONLINE 
LINEV    : 236.0 Volts
LOADPCT  : 9.0 Percent
BCHARGE  : 100.0 Percent
TIMELEFT : 72.5 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
SENSE    : Medium
LOTRANS  : 155.0 Volts
HITRANS  : 280.0 Volts
ALARMDEL : 30 Seconds
BATTV    : 27.1 Volts
LASTXFER : Low line voltage
NUMXFERS : 0
TONBATT  : 0 Seconds
CUMONBATT: 0 Seconds
XOFFBATT : N/A
SELFTEST : NO
STATFLAG : 0x05000008
SERIALNO : XXXXXXXXXXXX  
BATTDATE : 2018-07-28
NOMINV   : 230 Volts
NOMBATTV : 24.0 Volts
NOMPOWER : 700 Watts
FIRMWARE : 926.T2 .I USB FW:T2
END APC  : 2018-10-14 13:35:08 +0200 

Con la utilidad apctest podemos realizar diversos test. Pero para que esta utilidad funcione, primero debemos parar el servicio apcupsd:

$ sudo service apcupsd stop

Ahora, ya con el servicio parado podemos ejecutar los tests:

$ sudo apctest

2018-10-14 13:42:15 apctest 3.14.12 (29 March 2014) debian
Checking configuration ...
sharenet.type = Network & ShareUPS Disabled
cable.type = USB Cable
mode.type = USB UPS Driver
Setting up the port ...
Doing prep_device() ...

You are using a USB cable type, so I'm entering USB test mode
Hello, this is the apcupsd Cable Test program.
This part of apctest is for testing USB UPSes.

Getting UPS capabilities...SUCCESS

Please select the function you want to perform.

1)  Test kill UPS power
2)  Perform self-test
3)  Read last self-test result
4)  View/Change battery date
5)  View manufacturing date
6)  View/Change alarm behavior
7)  View/Change sensitivity
8)  View/Change low transfer voltage
9)  View/Change high transfer voltage
10) Perform battery calibration
11) Test alarm
12) View/Change self-test interval
 Q) Quit

Select function number: 

Ya dependiendo de lo que queramos hacer seleccionaremos una opción u otra. Una vez finalizado el uso de este programa, debemos volver a poner en marcha el servicio apcupsd con:

$ sudo service apcupsd start

Y esto es todo por ahora. En un siguiente artículo explicaré como podemos acceder de forma gráfica a la información que nos suministra apcupsd.

@josrrp

Comentarios

Entradas populares de este blog

Instalando Moodle con Docker

En este blog ya hemos hablado en varios artículos sobre la tecnología de contenedores, pero hasta ahora nos habíamos centrado en LXD . En este artículo vamos a explicar cómo podemos instalar Moodle en menos de un minuto (dependiendo de la velocidad de descarga que se tenga, se puede alargar un poco más) usando contenedores. Acerca de Moodle No voy a explicar que es Moodle ni como instalarlo desde cero, para eso existe en Internet multitud de tutoriales. Lo que sí quiero comentar es que para instalar Moodle hace falta un servidor web con PHP . Además requiere que PHP tenga instalado una serie de componentes adicionales. Por otro lado, necesitamos tener instalado en el servidor un sistema de gestión de bases de datos relacional, ya que Moodle almacena la información en él. Normalmente se utiliza MySQL , MariaDB o PostgreSQL . También debemos crear una base de datos específica para Moodle con su respectivo usuario. Durante la instalación Moodle creará las tablas necesari

Analizando el protocolo HTTP

El objetivo de este artículo es el de explicar de forma práctica el funcionamiento del protocolo HTTP y entender el intercambio de datos que se realiza entre los servidores y los clientes web. Por otro lado, cubre la necesidad de tener un texto en español que sirva de referencia a mis alumnos de Servicios en Red  a la hora de realizar la práctica de clase  HTTP-1 . La idea es ver de forma práctica el funcionamiento interno del protocolo HTTP . Para ello, vamos a utilizar un par de herramientas de la línea de comandos de Linux ( telnet y netcat ), con las que vamos a simular el comportamiento tanto del navegador como del servidor web. HTTP es un protocolo de la capa de aplicación, y como muchos otros protocolos de esta capa, está basado en texto. De hecho, los comandos que envía el navegador al servidor y sus respuestas se pueden leer perfectamente en inglés. Por defecto, HTTP utiliza el puerto 80 TCP y HTTPS  el puerto 443 TCP. Los ejemplos que vamos a ilustrar serán

ZFS, Primera parte

Cuando el año pasado instalé LXD y lo configuré por primera vez, me encontré que podía utilizar, de hecho se recomienda, el sistema de ficheros ZFS para albergar los contenedores. Posteriormente, cuando instalé Proxmox en el servidor de mi departamento, me encontré de nuevo con  ZFS . Anteriormente no le había prestado mucha atención a  ZF S , normalmente utilizo EXT4 o XFS , pero estaba claro que había una estrecha relación entre  ZFS  y los sistemas de virtualización. ZFS  es un sistema de ficheros desarrollado por Sun Microsystems  (creadores también del lenguaje de programación Java ), posteriormente la empresa fue adquirida por Oracle , actuales propietarios. OpenZFS  es la variante libre y posee una licencia de tipo  CDDL , que aunque es software libre, es incompatible con GPL . Por este motivo, el kernel de Linux no lo incorpora de serie. Sin embargo, los usuarios pueden instalarlo sin problemas ya que se encuentra en los repositorios de la mayoría de las distribucione