Integrar Onlyoffice y Collabora con Owncloud/Nextcloud sin usar certificados SSL

En entornos de pruebas es posible usar Onlyoffice y Collabora integrado con Owncloud o Nextcloud sin usar SSL.
Configurar SSL es engorroso expresamente si se intentar usar certificados autofirmados. Para pruebas de funcionalidad, es posible no usar certificados en absoluto.
Esto solo debe usarse en entornos aislados de prueba, ya que el uso de SSL es imperativo en entornos de producción si se desea mantener cierto nivel de seguridad.

Ambas suites se pueden integrar en Owncloud y Nextcloud de forma muy similar a través de los plugins de los respectivos 'markets'.
En primer lugar es necesario que en el acceso a Owncloud/Nextcloud no se esté usando HTTPS.

Despliegue del contenedor de Collabora

• Descargar la imagen docker

docker pull collabora/code

• Ejecutar el contenedor. Hacer que escuche en la IP local del equipo. Esta debe ser alcanzable desde la máquina donde esté instalado Owncloud/Nextcloud

docker run -t -d -p 192.168.1.112:9980:9980 --cap-add MKNOD collabora/code

• Ejecutar comando en el contenedor para deshabilitar SSL

docker exec -it   /bin/bash -c "apt-get -y update && apt-get -y install xmlstarlet && xmlstarlet ed --inplace -u \"/config/ssl/enable\" -v false /etc/loolwsd/loolwsd.xml && xmlstarlet ed --inplace -u \"/config/ssl/termination\" -v false /etc/loolwsd/loolwsd.xml"

• Reiniciar el  contenedor con la nueva configuración sin SSL

docker restart

Despliegue del contenedor de Onlyoffice 

• Descargar la imagen docker

docker pull onlyoffice/documentserver

• Ejecutar el contenedor. Solo es necesario hacer que el servicio del docker escuche el puerto 80

docker run -i -t -d -p 192.168.1.112:9981:80 -v /app/onlyoffice/DocumentServer/logs:/var/log/onlyoffice      -v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data  onlyoffice/documentserver

Integración con Owncloud/Nextcloud

En primer lugar es necesario que en el acceso a Owncloud/Nextcloud no se esté usando HTTPS.

• Instalar  la "app" de integración

• Configurar el enlace a Onlyoffice o Collabora

 

• Probar la operatividad

Archivo para SWAP (ayuda de emergencia)

En alguna ocasión he tenido que usar esto.
Una máquina Linux se queda sin memoria ni swap y empieza a ir muy lenta.

Si aún es posible acceder a ella y que responda a algunos comandos, es posible salvarla del reinicio o al menos ganar algo de tiempo y operatividad.
Consiste en ampliar la SWAP con un fichero en el filesystem.

• Crear un fichero vacío con el tamaño de swap que se quiera ampliar (vg.- 256MB):

# dd if=/dev/zero of=/swapgrow bs=1M count=256

• 'Formatearlo' para SWAP:

# mkswap /swapgrow

• Activarlo:

# swapon /swapgrow

Tunel SSH

Control de brillo en Asus UL30VT con Linux Mint 18

Este portátil (Asus UL30VT) funciona bastante bien con Linux Mint. Usando la tarjeta de video Intel, por defecto las combinaciones de botones "Fn+F5/F6" no funcionan para subir o bajar el brillo de la pantalla.
La solución consiste en indicarle al demonio acpid los eventos que debe esperar y las acciones a ejecutar.
Basta crear/modificar 3 archivos en Linux Mint 18 (también válido para Mint 17) y otras distribuciones.

/etc/acpi/events/screen-brightness-up

event=hotkey ATK0100:00 0000001[0123456789abcdef]
action=/etc/acpi/brightness up

 /etc/acpi/events/screen-brightness-down

event=hotkey ATK0100:00 0000002[0123456789abcdef]
action=/etc/acpi/brightness down

/etc/acpi/brightness

#!/bin/bash
export SEED=10
if [ ! -f ~/.brightness ]; then
       echo 255 > ~/.brightness;
fi
export BRIGHTNESS=`cat ~/.brightness`
case "$1" in
       "up")
               export BRIGHTNESS=$[$BRIGHTNESS+$SEED];
       ;;
       "down")
               export BRIGHTNESS=$[$BRIGHTNESS-$SEED];
       ;;
       *)
               export BRIGHTNESS=1;
       ;;
esac
if [ "$BRIGHTNESS" -gt "255" ]; then
       export BRIGHTNESS=255;
fi
if [ "$BRIGHTNESS" -gt "0" ]; then
       echo $BRIGHTNESS > ~/.brightness
    setpci -s 00:02.0 F4.B=`printf '%x' $BRIGHTNESS`
fi
if [ "$BRIGHTNESS" -lt "0" ]; then
       echo "This makes your screen off";
fi

chmod +x /etc/acpi/brightness 

systemctl restart acpid

Gestión de actualizaciones de seguridad en Ubuntu (16.04)

Ubuntu dispone del paquete "unattended-upgrades", que usando "cron" y "aptitude" descarga e instala las actualizaciones del sistema de forma automática.

Resulta útil pero tiene algunos problemas como la pérdida de control de las propias actualizaciones. Las actualizaciones se buscan, descargan e instalan de forma desatendida.

A continuación se explica como hacer una gestión menos agresiva de las actualizaciones de seguridad en Ubuntu 16.04 Server, manteniendo el control de cuando instalarlas.
Además se permite que el sistema busque las actualizaciones de seguridad, que puede ser útil para avisar al operador (vía correo automático, sistema de monitorización, etc) del número de actualizaciones de seguridad disponibles.

Deshabilitar las actualizaciones automáticas

• En la instalación, Ubuntu pregunta sobre esto. Si se deshabilitaron en aquel momento no es necesario hacer nada más por ahora.
• Comprobar que está instalado el paquete "unattended-upgrades". En caso negativo, instalarlo. 
• Editar "/etc/apt/apt.conf.d/10periodic

[...]
APT::Periodic::Unattended-Upgrade "0";
[...]

Nota: Si la linea no existe, no es necesario añadirla. El efecto es el mismo.

Permitir que el sistema busque automáticamente las actualizaciones

• Editar "/etc/apt/apt.conf.d/10periodic 

[...]
APT::Periodic::Update-Package-Lists "1";
[...]

Nota: El valor '1' hace referencia a la frecuencia, en días, que se ejecuta la búsqueda. El efecto es similar a ejecutar "apt-get update".

Bloquear paquetes 'problemáticos'

Algunos paquetes, como el kernel, pueden bloquearse para que no se actualicen mediante procesos automáticos (habrá que actualizarlos manualmente). Para bloquear el kernel:

apt-mark hold linux-image-generic
apt-mark hold linux-headers-generic

Nota: Los paquetes marcados con hold no aparecen en la lista de paquetes a actualizar.

Listar los paquetes con actualizaciones de seguridad pendientes

Existen varias formas de obtener esta información:

• Ejecutar:

 /usr/lib/update-notifier/apt_check.py

 Devuelve una cadena de formato XX;YY, donde XX es el número de actualizaciones totales e YY es el número de actualizaciones de seguridad.

• Ejecutar:

apt-get -s dist-upgrade | grep "^Inst" |  grep -i security

Aparece una lista de los paquetes con actualizaciones pendientes.

• A partir de aquí se puede elaborar un script como este:

#!/bin/bash
bold=$(tput bold)
normal=$(tput sgr0)
echo "Refrescando lista de paquetes..."
apt-get update
NUMERO_ACTUALIZACIONES=$(apt-get -s dist-upgrade | grep "^Inst" |  grep -i security | wc -l)
echo "Actualizaciones de seguridad pendientes: ${bold}$NUMERO_ACTUALIZACIONES${normal}"
echo ""
apt-get -s dist-upgrade | grep "^Inst" |  grep -i security

Actualizar los paquetes (solo actualizaciones de seguridad)

Se puede actualizar cada paquete de uno en uno o ejecutar una orden para todos del tipo:

    apt-get -s dist-upgrade | grep "^Inst" | grep -i security | awk -F " " {'print $2'} | xargs apt-get install

O un script un poco más elaborado:

#!/bin/bash

echo "Actualizaciones de seguridad disponibles:"
echo "-----------------------------------------"
apt-get -s dist-upgrade | grep "^Inst" |  grep -i security
echo ""
read -r -p "¿Actualizar estos paquetes? [y/N] " response
if [[ "$response" =~ ^([yY][eE][sS]|[yY])+$ ]]
then
    echo "Actualizar..."
    apt-get -s dist-upgrade | grep "^Inst" | grep -i security | awk -F " " {'print $2'} | xargs apt-get install
else
    echo "No Actualizar"
fi

if [ -f /var/run/reboot-required ]; then
    echo ""
    echo "Reboot is Required!!!!"
fi

echo ""
echo "Es posible que deja ejecutar apt autoclean para eliminar paquetes antiguos"

Últimos detalles (posible reinicio y limpieza)

Cuando se actualizan paquetes que requieren o recomiendan el reinicio de la máquina, se genera el archivo vacío

/var/run/reboot-required

Para eliminar las cachés de paquetes descargados y liberar espacio en disco se puede ejecutar:

apt-get autoclean

Cuellos de botella en Linux

Los cuellos de botella se pueden producir en múltiples lugares del sistema. Detectarlos es importante para saber como está rindiendo una máquina.

CPU
Detección de cuello de botella en la CPU debido a su carga

Usando top, uptime, o cualquier comando que devuelva al carga media:

load average: 1,23, 1,42, 1,54

Estos valores indican el número medio de procesos que hay en cola para entrar al procesador.
Si estos valores superan o se acercan el número de cores del procesador, es probable que los procesos estén esperando por acceder a la CPU mucho más que el tiempo que tardan en hacer el cambio de contexto.
En este ejemplo, es una máquina con 2 cores. La CPU aún no es cuello de botella para su rendimiento. Un 10% por debajo del número de cores es señal de alarma.

Nota: Existe un caso en el que los valores de 'load average' crecen muy por encima del número de cores y sin embargo no se percibe una pérdida de rendimiento en el sistema. Habitualmente estos valores altos son debidos a procesos que realizan operaciones de E/S que se quedan en espera o bloqueados. El consumo real de CPU es  mínimo pero se contabilizan como procesos en cola. En estos casos, el % de uso de la CPU está por debajo del 100%.

DISCO
Detección de cuellos de botella en el almacenamiento (disco)
Los cuellos de botella en el sistema de E/S están normalmente relacionados con la carga de CPU debida a las operaciones de E/S, la latencia del almacenamiento y sus IOPS máximas.

Idealmente es necesario saber de antemano cual es la latencia mínima e IOPS máximas que el almacenamiento puede ofrecer. Un disco SATA de 7200rpm suele dar en números redondos una latencia de 5 ms y unas 90 IOPS.
Cuando el almacenamiento está llegando a su límite de rendimiento (es decir, alcanzando su límite de IOPS), la latencia comienza a aumentar de forma considerable. Esta es la señal de alarma.

Si los procesos realizan muchas operaciones de Entrada/Salida, puede darse en caso de que saturen la CPU, el almacenamiento o ambos.

IOSTAT
Herramienta para saber en tiempo real el número de IOPS sobre un dispositivo de almacenamiento: iostat

iostat -d /dev/sda 1

'tps': Operaciones totales realizadas desde la última actualización (1 segundo). IOPS en 'tiempo real'
kB_read/s, kB_wrtn/s: KBs leidos/escritos por segundo.

Cuando el valor de 'tps' se acerca al límite del máximo que puede ofrecer el almacenamiento, este es un cuello de botella.

Se puede obtener más información interesante jugando con los parámetros de 'iostat':

 Las medidas *await hacen referencia a la 'latencia'. Son una medida de lo que tarda (ms) una operación de E/S al disco 'sda' contando (OJO!) tanto el tiempo de sistema para el procesado de la petición como el tiempo de espera para que el disco devuelva la respuesta.

svctm indica la espera (ms) debida específicamenteal dispositivo del almacenamiento. Según el tipo de sistema, un svctm por debajo de 10ms en entornos 'enterprise' ó de 50ms en entornos de 'escritorio' son aceptables. Por encima de eso la pérdida de rendimiento es evidente.
Estos valores se deben comparar con los valores teóricos que debe dar el dispositorio de almacenamiento recurriendo a las specs del fabricante.

El valor '%util' indica la carga del procesador que es debida a las operaciones de E/S. Si este valor es alto (especialmente si es del 100% o cercano), el sistema se está saturando en operaciones de E/S. Puede estar relacionado con la saturación del propio disco o sistema de almacenamiento, pero no en todos los casos.
iostat 

RAM
MEMORIA RAM
El tiempo de acceso a la memoria principal del sistema es constante en todos los casos salvo averías o algunos sistemas NUMA.
Por lo tanto, detectar fallas de rendimiento debido a la memoria RAM se centra en:

1. Descubrir si el sistema está haciendo swapping y en que medida.
2. Descubrir el tiempo de espera para acceder a la memora

free

El sistema tieme partición de swap activa y se está utilizando (~11MB) .

vmstat

La cantidad de swap utilizada es de 11812KB y en ratios de 1 segundo se aprecia que las operaciones de lectura/escritura (si/so) sobre ella son nulas.
Si la swap tiene un uso intensivo (si/so >>0) el rendimiento del sistema disminuye.

La cantidad de espacio libre en la memoria principal (free) "no es reprententativo" ya que la memoria RAM se utiliza como caché del almacenamiento para agilizarlo.
Si la memoria se llena totalmente nuevos procesos no podrán ejecutarse, pero el rendimiento dependiente de su uso no se ve afectado (con excepciones). El cuello de botella a tener en cuenta en lo que a la memoria respecta es el swapping.


MISCELANEA

Ordenar procesos por:

Uso de CPU:

ps aux --sort=-pcpu

Acceso a disco:

iotop

Tamaño en memoria por KBs y %:

ps aux --sort -rss

Columna RSS: KBs
Columna %CPU: %CPU

Uso de swap:
http://yoseman.blogspot.com.es/2014/06/quien-esta-consumiendo-swap.html

Acceso a swap

iotop (columna SWAPIN)

Uso de red
Usando el programa "nethogs"

Procesos con uso de CPU <> 0

ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm \ 

--sort=+pcpu | awk '$8!=0.0 {print}' | awk 'NR>1'

Prioridad de procesos

ps -lax  (Columna NI)

Mapas de memoria (off-topic)
Herramienta:

pmap

Demonio bash linux

Esquema de script muy sencillo para hacer un demonio en bash corriendo en background:

#!/bin/bash

# At first you have to redirect stdout and stderr to /dev/null
exec >/dev/null
exec 2>/dev/null

# Fork and go to background
(
while true; do
    echo 'hi' >> ~/hihihi
    sleep 10
done
)&
# Parent process finished but child still working

Visto en: http://stackoverflow.com/questions/41258219/how-to-daemonize-a-script