Archivo

Archivo del autor

InRelease de Debian

domingo, 8 de diciembre de 2019 Sin comentarios

Si cuando realizamos un «apt update» en nuestra Debian recibimos el siguiente mensaje:

N: Repository ‘http://deb.debian.org/debian buster InRelease’ changed its ‘Version’ value from ‘10.1’ to ‘10.2’

Debemos ejecutar el siguiente comando para aceptar los cambios de forma explícita:

apt-get –allow-releaseinfo-change update

Categories: Debian, GNU/Linux Tags:

Reiniciando Plasma de KDE sin reiniciar el sistema

sábado, 23 de noviembre de 2019 Sin comentarios

A veces el uso de una versión inestable del entorno de escritorio puede hacer que éste sufra algún tipo de error que fuerce su cerrado y nos deje sin barra de tareas. Si en dicha ocasión reiniciar el ordenador es un inconveniente, siempre nos quedará la posibilidad de, en versiones Plasma superiores a la 5.10, usar los siguiente comandos desde un terminal o desde ALT+F2:

kquitapp5 plasmashell
kstart5 plasmashell

En versiones inferiores a Plasma 5.10, supuestamente (no lo he probado) se deben utilizar los siguientes comandos:

killall plasmashell
kstart plasmashell

Categories: GNU/Linux, Software Libre Tags: , ,

Jellyfin como sustituto de Plex

sábado, 9 de noviembre de 2019 Sin comentarios

Jellyfin es un gestor de contenido multimedia que permite hacer streaming de nuestra música, películas, series, etc. Es como un sustituto de Plex y Emby (del cual proviene) de código totalmente abierto y gratuito.

Existe una imagen preparado con él en Turnkey que nos permite tener funcionando el sistema en cuestión de pocos minutos.

Si queremos tener la posibilidad de trascodificar nuestro contenido puede ser que nos salga el siguiente error al querer utilizar, por ejemplo, nuestro navegador:

PlaybackErrorNoCompatibleStream

Para darle solución sólo tendremos que instalar ffmpeg de la siguiente forma:

apt install ffmpeg

Después, desde el panel de control de Jellyfin dentro de la sección de «Reproducción» tendremos que poner la siguiente ruta en «Ruta de FFmpeg:»:

/usr/bin/ffmpeg

Seafile con editor para ofimática

miércoles, 23 de octubre de 2019 Sin comentarios

Si tenemos funcionando un servidor de Seafile para tener nuestros documentos siempre a mano como alternativa a NextCloud, podemos dotarlo de un complemento que nos permitirá visualizar y editar ficheros en línea del tipo .odt, .docx, etc. Para ello sólo tenemos que seguir unas instrucciones bastantes básicas como usuario root para el supuesto caso de que tengamos Debian:

curl -sL https://deb.nodesource.com/setup_8.x | bash –

apt update

apt dist-upgrade

apt-get install postgresql

su postgres

psql -c «CREATE DATABASE onlyoffice;»

psql -c «CREATE USER onlyoffice WITH password ‘onlyoffice’;»

psql -c «GRANT ALL privileges ON DATABASE onlyoffice TO onlyoffice;»

exit

apt-get install redis-server

apt-get install rabbitmq-server

apt-get install npm nginx-extras

apt install dirmngr

apt-key adv –keyserver hkp://keyserver.ubuntu.com:80 –recv-keys CB2DE8E5

echo «deb https://download.onlyoffice.com/repo/debian squeeze main» | tee /etc/apt/sources.list.d/onlyoffice.list

apt-get install onlyoffice-documentserver

Después deberemos editar un fichero de configuración ( conf/seahub_settings.py ) de nuestro servidor Seafile para que derive al otro la apertura de este tipo de documentos. Concretamente hay que añadir lo siguiente:

# Enable Only Office
ENABLE_ONLYOFFICE = True
VERIFY_ONLYOFFICE_CERTIFICATE = False
ONLYOFFICE_APIJS_URL = ‘http://mi-servidor/web-apps/apps/api/documents/api.js’
ONLYOFFICE_FILE_EXTENSION = (‘doc’, ‘docx’, ‘ppt’, ‘pptx’, ‘xls’, ‘xlsx’, ‘odt’, ‘fodt’, ‘odp’, ‘fodp’, ‘ods’, ‘fods’)
ONLYOFFICE_EDIT_FILE_EXTENSION = (‘docx’, ‘pptx’, ‘xlsx’)

Sólo nos quedaría reiniciar los servicios de Seafile y ya debería dejarnos consultar y editar los documentos desde la interfaz web.

Error al crear contenedor en Proxmox

lunes, 21 de octubre de 2019 Sin comentarios

Si al intentar desplegar un template en un container de Proxmox obtenemos los siguientes errores:

tar: ./var/spool/postfix/dev/random: Cannot mknod: Operation not permitted
tar: ./var/spool/postfix/dev/urandom: Cannot mknod: Operation not permitted

Es debido a que, por defecto, los CT se despliegan con la opción marcada de «Unprivileged container» y algunas imágenes necesitan acceso a ciertas zonas como los «random» o «unrandom». Para solucionarlo sólo hay que desmarcar la opción en la primera pantalla de creación del CT.

Categories: Proxmox Tags: ,

Exception setuid y Buffer Overflow en Mldonkey

viernes, 20 de septiembre de 2019 Sin comentarios

Mldonkey es un software con bastantes años a sus espaldas que permite compartir archivos entre múltiples tipos de redes: torrent, edonkey, kadmelia, DC++, etc. Una de sus principales virtudes es que, además de ser multiplataforma, se puede ejecutar sin interfaz gráfica, con lo que el consumo de recursos es bastante moderado.

Si en alguna ocasión decidimos mover su carpeta de instalación (que contiene toda la configuración de puertos, limitaciones de ancho de banda, etc.), es probable que nos encontremos con el siguiente error en su log («/var/log/mldonkey/mldonkey-server.log»):

2008/03/08 19:41:24 [dMain] mldonkey is now running as user mldonkey
2008/03/08 19:41:24 [dMain] Exception setuid failed: Operation not permitted trying to set user_uid [107]

Esto es debido a que el «id» del usuario que ejecuta ahora el servicio de mldonkey ha cambiado. Basta con averiguar el nuevo id de nuestro usuario «mldonkey» con el comando «id -u mldonkey» y actualizar el fichero «downloads.ini» (alojado en «/var/lib/mldonkey/») cambiando el atributo «run_as_userid» y «run_as_user» en caso de haber cambiado también de nombre de usuario.

Por otro lado, si tenemos una conexión a Internet de alta velocidad es probable que nos encontremos con el siguiente error en el log:

[TCP_BS]: BUFFER OVERFLOW 488680+16397> 500000 MESSAGE: [(0)(0)(64)(9)(7)(0)(0)(0)(64)(0)(36)(128)(0)(2)(186)(3)(230)(247)(95)(152)…]

Tendremos por tanto que ampliar la directiva «client_buffer_size» del fichero «download.ini» de 500000 a 5000000

Categories: GNU/Linux Tags:

Configuración de TorGuard

viernes, 20 de septiembre de 2019 Sin comentarios

TorGuard es un servicio de VPN que mantiene la norma de no mantener un registro (log) de la actividad de sus usuarios como forma clara de mantener su privacidad y de ser amigable con el P2P. Dispone de un gran número de servidores repartidos por todo el mundo y mantiene una velocidad bastante buena en comparación con la competencia. La anualidad del servicio sale por unos $59.99 pero gracias al programa de afiliados puedes conseguir descuentos de hasta un 50%. Por ejemplo, yo mismo he generado un cupón ( TORCHRIS ) para la gente de mi entorno.

Si disponemos una máquina sin interfaz gráfica y deseamos que en su arranque inicie OpenVPN para que todo lo posterior vaya a través del túnel sólo tenemos que seguir una pautas sencillas.

sudo apt install openvpn unzip

cd /etc/openvpn

sudo wget https://torguard.net/downloads/OpenVPN-TCP-Linux.zip

sudo unzip OpenVPN-TCP-Linux.zip

sudo cp /etc/openvpn/OpenVPN-TCP/* /etc/openvpn/

rename -v ‘s/\.ovpn/\.conf/’ *.ovpn

Ahora mismo tendríamos un montón de fichero «*.conf» que representan cada una de las zonas en las que tenemos disponible servidores que den servicio. De esta forma podríamos lanzar el comando «openvpn server.conf» y se nos preguntaría el nombre y usuario para la conexión. Como no queremos que pregunte usuario y contraseña, crearemos un fichero que lo contenga con el comando «sudo nano /etc/openvpn/userPass.txt» y que rellenaremos con nuestros datos tal que así:

miusuario@concorreo.com

miContraseña9%Compleja

Copiaremos el fichero de configuración del servidor que nos interesa para hacerle una pequeña modificación:

sudo cp /etc/openvpn/TorGuard.Norway.conf /etc/openvpn/client.conf

Editaremos una línea de dicho fichero «sudo nano /etc/openvpn/client.conf»:

auth-user-pass /etc/openvpn/userPass.txt

Ahora le indicaremos a OpenVPN cuál es el fichero de configuración que tiene que cargar por defecto editando el fichero «sudo nano /etc/default/openvpn»

#AUTOSTART=»all»
#AUTOSTART=»none»
AUTOSTART=»client»

Refrescaremos la configuración y habilitaremos el servicio al inicio de OpenVPN:

sudo systemctl daemon-reload

sudo systemctl enable openvpn

Para comprobar que realmente estamos pasando por el servidor VPN basta con ejecutar el comando «curl ifconfig.me» que nos devolverá nuestra IP pública.

 

Categories: Debian Tags: ,

OpenVPN en Proxmox

viernes, 20 de septiembre de 2019 Sin comentarios

Instalar un cliente VPN en un contenedor de Proxmox (LXC) no debería ser un gran problema, simplemente realizar un «apt install openvpn», configurar la conexión con el servidor VPN y ya está. Pero no, existen problemas con la interfaz de red TUN/TAP a la que intenta tener acceso OpenVPN debido a que no existe:

ERROR: Cannot open TUN/TAP dev /dev/net/tun

Para solucionarlo hay que ir al fichero de configuración del contenedor («/etc/pve/lxc/XXX.conf») y añadir las siguientes líneas:

lxc.cgroup.devices.allow: c 10:200 rwm
lxc.hook.autodev: sh -c «modprobe tun; cd ${LXC_ROOTFS_MOUNT}/dev; mkdir net; mknod net/tun c 10 200; chmod 0666 net/tun»

Esto nos permitirá poder hacer uso de OpenVPN desde que la máquina arranca, ya que generar la estructura en un script de «init.d» o «crontab», a pesar de que funciona si iniciamos a mano OpenVPN, no lo hará de forma no asistida.

A pesar de todo lo anterior, veremos que perdemos cierta conectividad con la máquina y el log del sistema («/var/log/syslog») se nos llenará de mensajes del siguiente tipo:

Dec 21 07:12:11 gateway kernel: martian source 98.187.15.124 from 98.187.15.97, on dev br1

Dec 21 07:12:11 gateway kernel: ll header: ff:ff:ff:ff:ff:ff:00:14:f1:e8:69:db:08:06

Quizás por una mala configuración de interfaces de red por mi parte, pero habiendo sólo una con su IP fija no creo que debiese ser problemático. Al final opté por crear una máquina virtual en vez de un contenedor con una Debian 10 y todo ha ido prácticamente a la primera (salvo lo de montar una unidad NFS al arranque, que necesita de una IP asignada de manera estática, pero eso ya es otro cuento).

Como nota final, cabe tener en cuenta que, para ahorrar consumo de CPU (hasta un 20% de ahorro con un núcleo), existe la necesidad de habilitar las instrucciones extendidas AES del procesador (si las tuviese). Para ello debemos configurar la máquina virtual con un tipo de CPU host y máquina Q35. Para comprobar que la CPU tiene dichas instrucciones sólo hay que lanzar el comando «cpuid | grep -i aes | sort | uniq» que nos devolverá algo como esto:

AES instruction = true
VAES instructions = false

Y comprobar que se carga el módulo correspondiente con el comando «sort -u /proc/crypto | grep module» que debería darnos algo tal que así:

module : aesni_intel
module : aes_x86_64
module : crc32c_generic
module : crc32c_intel
module : crc32_pclmul
module : crct10dif_pclmul
module : cryptd
module : ghash_clmulni_intel
module : kernel

Categories: Proxmox Tags: , , ,

Servidor de arranque en red PXE

jueves, 15 de agosto de 2019 Sin comentarios

Resulta bastante útil tener disponible diversas distribuciones de Linux, herramientas e incluso un instalador de Windows con sólo conectar un equipo a la red. Hoy en día prácticamente cualquier equipo puede arrancar mediante PXE y la única pega es que pueden utilizar un sistema basado en UEFI o en BIOS de toda la vida. Este hecho nos limita las versiones y software que podemos utilizar a la hora de desplegar un servidor que cubra nuestras necesidades.

Syslinux

El primer intento que hice fue utilizando un servidor basado en Dnsmasq + Syslinux y funcionaba muy bien para los equipos con arranque en BIOS, pero para que los que tuviesen UEFI pudieran también arrancar tuve que dar con la versión de syslinux-6.04. Con esta versión podía arrancar los equipos con UEFI.

La configuración del servidor Dnsmasq que convivía con el propio servidor DHCP del router era la siguiente:

# Deshabilita el servidor DNS
port=0

# Se indica el servidor TFTP

dhcp-option=66,»192.168.1.200″

# Habilita la depuración
log-dhcp

# Responderá a las peticiones PXE y actuará de proxy para el otro servidor DHCP
dhcp-range=192.168.1.0,proxy

# Dependiendo de la arquitectura activamos una etiqueta
dhcp-match=x86PC, option:client-arch, 0 #BIOS x86
dhcp-match=BC_EFI, option:client-arch, 7 #EFI x86-64

# Dependiendo de la arquitectura del cliente se carga una imagen diferente
pxe-service=tag:x86PC,X86PC, «Install Linux on x86 legacy BIOS», bios/pxelinux.0
pxe-service=tag:BC_EFI,BC_EFI, «Install Linux on x86-64 UEFI», efi/syslinux.efi,192.168.1.200

# Dependiendo de la etiqueta se da una imagen u otra de arranque
dhcp-boot=tag:x86PC,bios/pxelinux.0 # for Legacy BIOS detected by dhcp-match above
dhcp-boot=tag:BC_EFI,efi/syslinux.efi,192.168.1.200 # for UEFI arch detected by dhcp-match above

# Se habilitar el servidor TFTP incorporado y el directorio donde se almacena todo
enable-tftp
tftp-root=/var/lib/tftpboot

Esto al principio funcionaba para BIOS y UEFI. Parecía que funcionaba bien pero no era así, el soporte de este último en syslinux está todavía poco pulido y no existe alternativa viable para usar Memdisk, una utilidad que nos permite cargar en memoria una ISO para que el equipo en red sea capaz de arrancar con ella. Por lo que el instalador de Windows se nos hacía imposible entre otras cosas.

iPXE

Tras muchas vueltas acabé cambiando el sistema para utilizar Dnsmasq+iPXE que parecía tener mejor proyección. Tuve que leer mucha documentación, muchos foros y realizar muchas pruebas que, debido a la poca posibilidad de depuración de Dnsmasq, se hace tortuoso. Finalmente di con esta configuración que adapté a mi gusto y entorno:

# Deshabilitar servidor DNS
port=0
dhcp-option=66,»192.168.1.204″

# Habilitar depuración de DHCP
log-dhcp

# Habilitar el modo proxy de DHCP
dhcp-range=192.168.1.0,proxy

# Para los equipos que arranquen como iPXE y manda la opción 175
dhcp-match=set:ipxe,175

# Para cada arquitectura se asigna una etiqueta concreta
dhcp-vendorclass=set:bios,PXEClient:Arch:00000
dhcp-vendorclass=set:efi32,PXEClient:Arch:00002
dhcp-vendorclass=set:efi32,PXEClient:Arch:00006
dhcp-vendorclass=set:efi64,PXEClient:Arch:00007
dhcp-vendorclass=set:efi64,PXEClient:Arch:00008
dhcp-vendorclass=set:efi64,PXEClient:Arch:00009

# Para romper el bucle, aquello que llevan la etiqueta ipxe tienen un arranque diferente
tag-if=set:loadbios,tag:!ipxe,tag:bios
tag-if=set:loadefi32,tag:!ipxe,tag:efi32
tag-if=set:loadefi64,tag:!ipxe,tag:efi64

# Para los equipos que siendo de tipo BIOS arrancan con su propio iPXE pero queremos que cojan el nuestro
tag-if=set:loadCombo,tag:ipxe,tag:bios

# Se administra una imagen de arranque particular para cada arquitectura
pxe-service=tag:loadbios,x86PC,»iPXE Network boot (BIOS)»,ipxe/bios/undionly.kpxe
pxe-service=tag:loadCombo,x86PC,»iPXE Network boot (BIOS)»,ipxe/bios/undionly.kpxe
pxe-service=tag:loadefi32,IA32_EFI,»iPXE Network boot (EFI32)»,ipxe/efi/ipxe.efi
pxe-service=tag:loadefi32,BC_EFI,»iPXE Network boot (EFI32)»,ipxe/efi/ipxe.efi
pxe-service=tag:loadefi64,X86-64_EFI,»iPXE Network boot (EFI)»,ipxe/efi/ipxe.efi
pxe-service=tag:loadefi64,IA64_EFI,»iPXE Network boot (EFI)»,ipxe/efi/ipxe.efi

# Para los que ya arrancan en iPXE se les pasa el menú
# Para el loadCombo no hace falta porque la imagen undionly lo lleva compilado dentro
dhcp-boot=tag:ipxe,tag:!loadCombo,http://192.168.1.204/bootMenu.ipxe

# Habilitamos servidor TFTP e indicamos su ruta
enable-tftp
tftp-root=/var/lib/tftpboot

Pero para poder hacer funcionar esta configuración en equipos BIOS con su propio iPXE, debemos compilar una versión propia del cargador de arranque «undionly.kpxe», pues no queda más remedio que incrustar el menú de arranque, aunque también nos deja la puerta abierta para añadir ciertas personalizaciones. Para ello debemos bajarnos el fuente:

  • git clone git://git.ipxe.org/ipxe.git

Y creamos un fichero «ipxe/src/chain.ipxe» con el siguiente contenido:

#!ipxe

dhcp
chain http://192.168.1.200/bootMenu.ipxe

Procedemos a su compilación:

  • make bin/undionly.kpxe EMBED=chain.ipxe

Y copiamos el fichero generado («bin/undionly.kpxe») a su sitio correspondiente dentro del árbol de nuestro servidor TFTP.

A todo esto deberemos tener un servidor web Apache (o similar) que nos pueda ir entregando ciertos fichero como el del «bootMenu.ipxe» que yo he utilizado para cargar un Windows PE:

#!ipxe

kernel wimboot
initrd win10/files/bcd bcd
initrd win10/files/boot.sdi boot.sdi
initrd win10/files/boot.wim boot.wim
boot

La estructura por tanto queda de la siguiente forma dentro de «/var/lib/tftpboot»:

  • /apache2
    • bootMenu.ipxe
    • index.html
    • wimboot
    • /win10
      • /files
        • bcd
        • boot.sdi
        • boot.wim
  • /ipxe
    • /bios
      • undionly.kpxe
    • /efi
      • ipxe.efi

Instalación de Pi-Hole en Proxmox

miércoles, 14 de agosto de 2019 1 comentario

Pi-Hole es un servidor intermediario de DNS que filtra las petición de aquellas URL’s que contienen publicidad, haciendo la navegación más limpia y rápida. Ideal para aquellos dispositivos donde no tenemos acceso de administración como en un teléfono móvil Android o iPhone, porque no tenemos que instalar nada más adicional en estos terminales.

Su instalación se puede hacer en una simple Raspberry Pi o, como es mi caso, un contenedor LXC en Proxmox. Después de desplegar una imagen básica de Debian desde Turnkey, descargaremos el instalador de Pi-Hole:

  • wget -O basic-install.sh https://install.pi-hole.net

Tendremos que realizar una pequeña modificación porque el instalador busca el fichero «/etc/apt/sources.list», cuando nuestro sistema lo tiene en «/etc/apt/sources.list.d/sources.list». Abriremos con «nano basic-install.sh» el instalador, buscaremos (CTRL+W)  el término «APT_SOURCES» y modificaremos su valor para que quede de la siguiente forma:

  • APT_SOURCES=»/etc/apt/sources.list.d/sources.list»

Con eso debería bastar pero, en mi caso, al intentar instalar las dependencias el instalador se me cortó y tuve que instalar una de ellas a mano con el siguiente comando:

  • apt install php-sqlite3

Una vez instalado, sólo tendremos que cambiar las DNS de nuestros dispositivos a la IP de esta instancia.