Archivo

Archivo para la categoría ‘Hardware’

Contraseña en la BIOS del portátil

miércoles, 27 de mayo de 2020 Sin comentarios

La mayoría de fabricantes de portátiles permiten asignar una contraseña de acceso a su BIOS para evitar que se efectúen cambios en su configuración. Si nos encontramos con este inconveniente vamos a descubrir que dichos fabricantes no se esforzaron mucho en tal tarea.

Cuando al acceder a la BIOS el portátil nos pregunte la contraseña introduciremos una a una las siguientes contraseñas:

  1. 3hqgo3
  2. jqw534
  3. 0qww294e

Esto hará que el portátil nos devuelva un mensaje de error en hash. Dependiendo de la marca del portátil tendrá un formato u otro:

 Fabricante  Tipo de hash  Ejemplo de hash
 Asus Fecha 01-01-2011
 Compaq 5 dígitos decimales 12345
 Dell Número de serie 1234567-595B
 Fujitsu-Siemens 5 dígitos decimales 12345
 Fujitsu-Siemens 8 dígitos hexadecimales DEADBEEF
 Fujitsu-Siemens 5×4 dígitos hexadecimales AAAA-BBBB-CCCC-DEAD-BEEF
 Fujitsu-Siemens 5×4 dígitos decimales 1234-4321-1234-4321-1234
 Fujitsu-Siemens 6×4 dígitos decimales 8F16-1234-4321-1234-4321-1234
 Hewlett-Packard 5 dígitos decimales 12345
 Hewlett-Packard/Compaq Netbooks 10 caracteres CNU1234ABC
 Insyde H20 (generic) 8 dígitos decimales 03133610
Phoenix (generic) 5 dígitos decimales 12345
Sony 4×4 dígitos hexadecimales 1234-1234-1234-1234
Sony 7 dígitos numéricos 1234567
Samsung 12 dígitos hexadecimales 07088120410C0000

Con ese hash y un script en python (en la mayoría de los casos) podremos obtener una contraseña para cuando arranque de nuevo el portátil. Y de dónde sale el script, pues normalmente de Internet como todo lo que la gente comparte.

Categories: Portátiles Tags: , ,

Asus RT-AC66U_B1 haciendo de cliente de VPN

sábado, 4 de abril de 2020 Sin comentarios

Haciendo uso del firmware de Asuswrt-Merlin se permiten hacer ciertas cosas bastante provechosas. En otra entrada comenté cómo montar un cliente OpenVPN bajo Proxmox y que no consumiese excesivos recursos, pero seguía sin ser todo lo óptimo que deseaba. Al final me decanté por dejar dicha carga al servicio de un router libre de Asus.

Lo primero de todo es ir a la sección «VPN->Cliente VPN» y configurar los parámetros según nuestro proveedor. Una vez en marcha y habiendo marcado la opción de «Force Internet traffic through tunnel» como «Policy Rules (strict)», podremos añadir la IP de las máquinas que queramos que pasen por dicha VPN.

Si además necesitamos redirigir puertos, la cosa de complica un poco más. Necesitaremos habilitar el acceso por ssh a nuestro router desde «Administración->Sistema->Enable SSH» y también habilitar la partición JFFS desde «Administración->Sistema->Enable JFFS custom scripts and configs». Accederemos por ssh con nuestro login habitual de la interfaz web y crearemos un nuevo fichero:

nano /jffs/scripts/nat-start

En él introduciremos reglas de enrutado:

#!/bin/sh

DEV=»tun11″
PROTO=»tcp»
EXT_PORT=»50001″
INT_IP=»192.168.1.100″
INT_PORT=»22″

ipt() {
# precede insert/append w/ deletion to avoid dupes
while iptables ${@/-[IA]/-D} 2> /dev/null; do :; done
iptables $@
}

# create internal port forward
ipt «-t nat -I PREROUTING -i $DEV -p $PROTO –dport $EXT_PORT -j DNAT –to $INT_IP:$INT_PORT»
ipt «-I FORWARD -i $DEV -p $PROTO -d $INT_IP –dport $INT_PORT -j ACCEPT»

exit 0

El parámetro «tun11» equivaldría al primer cliente de VPN configurado en nuestro router y el script debería funcionar sin problemas como se indica en este foro de donde lo saqué nada más reiniciar el router. Pero a mi no me funcionó, es más, perdía toda la conectividad hacia el exterior. Lo acabé solucionando dejando simplemente una línea tras mucho probar:

iptables -t nat -I PREROUTING -i tun11 -p tcp –dport 50001 -j DNAT –to 192.168.1.100:22

 

Acceso a discos KVM

sábado, 4 de abril de 2020 Sin comentarios

Para acceder a unidades de disco utilizadas por máquinas virtuales KVM sólo tenemos que seguir algunos sencillos pasos.

Lo primero es identificar la primera unidad loopback disponible:

losetup -f

Asociaremos la unidad que nos devuelve el paso anterior con nuestra imagen de disco:

losetup /dev/loop0 /rutaKVM/discoWindows.img

A continuación podremos identificar las particiones contenidas en el fichero anterior:

kpartx -av /dev/loop0

Podemos visualizar las particiones mapeadas con el siguiente comando:

ls -la /dev/mapper/

Y al final podremos montarla del siguiente modo:

mount /dev/mapper/loop0p2 /mnt/virtualHDD/

Cuando hayamos terminado de trabajar con la unidad de disco virtual desharemos lo hecho:

umount /mnt/virtualHDD/

kpartx -dv /dev/loop0

losetup -d /dev/loop0

Si lo que tenemos es un disco con formato «qcow2» podemos recurrir a otra estrategia. Habilitamos el módulo NBD (Network Block Devices):

modprobe nbd max_part=8

Conectamos al dispositivo como si fuese una unidad de red:

qemu-nbd –connect=/dev/nbd0 /rutaKVM/discoWindows.qcow2

Buscamos las particiones del disco:

fdisk /dev/nbd0 -l

Montamos la que deseemos:

mount /dev/nbd0p1 /mnt/virtualHDD/

Y para cuando terminemos, deshacemos lo hecho:

umount /mnt/virtualHDD/
qemu-nbd –disconnect /dev/nbd0
rmmod nbd

Recuperando archivos de medios dañados

sábado, 4 de abril de 2020 Sin comentarios

Cuando nos encontramos con una unidad de almacenamiento con daños que impiden la lectura de alguno de sus sectores y, por tanto, impiden la extracción de alguno de sus ficheros, podemos recurrir a ciertos métodos, sobretodo cuando se tratan de vídeos e imágenes que pueden subsistir de manera razonable a falta de algunos bytes de datos.

dd if=ArchivoConBloquesDañados of=ArchivoRecuperado bs=4k conv=noerror,sync

Sustituyendo Proxmox por una Ubuntu Server con KVM

lunes, 23 de marzo de 2020 Sin comentarios

Debido al hardware específico (HP Miniserver Gen8) que tengo y que para poder resolver los problemas de su BIOS con la paravirtualización se necesita aplicar un parche en el kernel que me dejó de funcionar en Proxmox en la última actualización, pues decir librarme de la comodidad de Proxmox en busca de algo más flexible.

Quería una distribución con software relativamente actualizado y documentado en el que me sintiese cómodo. Opté por una Ubuntu 18.04 para servidores que, aunque no está entre mis favoritas para el uso cotidiano, es bastante cómoda para funciones de servidor.

Software de virtualización

Después de la instalación básica necesitaba una serie de herramientas para virtualizar máquinas:

apt-get install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils

adduser `id -un` libvirt

Preparación previa del hardware

Hice que no cargase ningún driver de la gráfica a la que tenía pensada hacerle passthrough :

echo blacklist nouveau > /etc/modprobe.d/blacklist-nvidia-nouveau.conf

echo options nouveau modeset=0 >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf

echo blacklist snd_hda_intel > /etc/modprobe.d/blacklist-nvidia-nouveau.conf

Con el comando «lpsci -nn» encontré los datos de la gráfica que me interesaban:

07:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:1c82] (rev a1)
07:00.1 Audio device [0403]: NVIDIA Corporation GP107GL High Definition Audio Controller [10de:0fb9] (rev a1)

Y edité el fichero de configuración de Grub «/etc/default/grub»:

GRUB_CMDLINE_LINUX=»intel_iommu=on vfio_pci.ids=10de:1c82,10de:0fb9″

Para terminar de curarme en salud, creé el fichero «/etc/modprobe.d/vfio_pci.conf»:

options vfio_pci ids=10de:1c82,10de:0fb9

Y edité el de «/etc/initramfs-tools/modules»:

vfio
vfio_iommu_type1
vfio_virqfd
options vfio_pci ids=10de:1c82,10de:0fb9
vfio_pci ids=10de:1c82,10de:0fb9
vfio_pci

¿Excesivo? Puede ser. Quizás sobrase con sólo haber editado el fichero de Grub, pero se llega a un punto en el cual has dado tantas vueltas sobre lo mismo que no te fías con hacer lo mínimo indispensable.

Finalmente toca rehacer el arranque con los siguientes comandos:

update-grub
update-initramfs -u

Compilación del kernel

Editamos las fuentes de apt para poder descargar el fuente del software «/etc/apt/sources.list»:

deb-src http://es.archive.ubuntu.com/ubuntu/ bionic main restricted

deb-src http://es.archive.ubuntu.com/ubuntu/ bionic-updates main restricted

Descargamos el software necesario:

apt update

apt-get build-dep linux linux-image-$(uname -r) git fakeroot dkms default-jdk

Es posible que nos topemos con el siguiente error:

la descarga se realiza de forma desprotegida como superusuario, ya que al archivo «linux-signed_4.15.0-91.92.dsc» el usuario «_apt» no pudo acceder. – pkgAcquire::Run

Para solventarlo nos basta con hacer lo siguiente:

chown _apt /var/lib/update-notifier/package-data-downloads/partial/

Dentro de la carpeta «/usr/src/» descargaremos los fuentes del kernel de Ubuntu Bionic:

git clone git://kernel.ubuntu.com/ubuntu/ubuntu-bionic.git

Editaremos el fichero «/usr/src/ubuntu-bionic/drivers/iommu/intel-iommu.c» donde pone:

if (device_is_rmrr_locked(dev)) {
dev_warn(dev, «Device is ineligible for IOMMU domain attach due to platform RMRR requirement. Contact your platform vendor.\n»);
return -EPERM;
}

Pondremos lo siguiente:

if (device_is_rmrr_locked(dev)) {
dev_warn(dev, «Device is ineligible for IOMMU domain attach due to platform RMRR requirement. PARCHEADO.\n»);
}

En este paso, si tratamos de compilar el kernel nos encontraremos con un error relacionado con el script «ubuntu-bionic/debian/scripts/retpoline-check» y que tuve que modificar de este código:

count=$( diff -u «$prev» «$curr» | grep ‘^+[^+]’ | wc -l )
if [ «$count» != 0 ]; then
rc=1

A este otro:

count=$( diff -u «$prev» «$curr» | grep ‘^+[^+]’ | wc -l )
if [ «$count» != 0 ]; then
rc=0

Sé que está relacionado con las mitigaciones sobre las CPU de Intel pero no es algo que en esta máquina me importase mucho.

Desde el directorio de «/usr/src/ubuntu-bionic» lancé la compilación que duró un periodo de tiempo considerable:

fakeroot debian/rules clean

fakeroot debian/rules binary

De dicho proceso se generaron una serie de paquetes .deb que instalé:

dpkg -i *.deb

Una vez instalado el kernel modificado, ahora sólo necesitaba que el equipo siempre arrancase con él, con lo que había que realizar algunos cambios en el cargador de arranque. Para saber qué modificaciones tenía que aplicar lancé el siguiente comando:

sed -nre «/submenu|menuentry/s/(.? )'([^’]+)’.*/\1 \2/p» < /boot/grub/grub.cfg

Me devolvió el listado visual de Grub que tenía que tener en cuenta:

menuentry Ubuntu
submenu Opciones avanzadas para Ubuntu
menuentry Ubuntu, con Linux 4.15.0-91-generic
menuentry Ubuntu, con Linux 4.15.0-91-generic (recovery mode)
menuentry Ubuntu, con Linux 4.15.0-88-lowlatency
menuentry Ubuntu, con Linux 4.15.0-88-lowlatency (recovery mode)
menuentry Ubuntu, con Linux 4.15.0-88-generic
menuentry Ubuntu, con Linux 4.15.0-88-generic (recovery mode)
menuentry Ubuntu, con Linux 4.15.0-76-generic
menuentry Ubuntu, con Linux 4.15.0-76-generic (recovery mode)

Entonces edité el fichero «/etc/default/grub» acorde:

GRUB_DEFAULT=»Opciones avanzadas para Ubuntu>Ubuntu, con Linux 4.15.0-88-generic«

Y además bloquee la posibilidad de que sufriese cambios a través de alguna actualización del gestor de paquetes y regeneré la configuración de Grub:

apt-mark hold 4.15.0-88-generic

update-grub

Si en un futuro queremos actualizar el kernel, para desbloquear el que tenemos modificado bastará con lanzar el comando «apt-mark unhold 4.15.0-88-generic».

Tras un reinicio del equipo y con el comando «dmesg | grep -i vfio» deberíamos poder ver lo siguiente:

[230727.140577] vfio-pci 0000:07:00.1: Device is ineligible for IOMMU domain attach due to platform RMRR requirement. PARCHEADO.
[230727.730169] vfio_ecap_init: 0000:07:00.0 hiding ecap 0x19@0x900

Configuración del puente de red

Para que las máquinas virtuales puedan tener acceso directo a nuestra y así poder hacer uso de los recursos que en ella se encuentran hay que configurar un puente de red. Modificaremos el fichero «/etc/netplan/01-netcfg.yaml»:

network:
version: 2
renderer: networkd

ethernets:
eno2:
dhcp4: false
dhcp6: false

bridges:
br0:
interfaces: [eno2]
addresses: [192.168.1.10/24]
gateway4: 192.168.1.1
mtu: 1500
nameservers:
addresses: [192.168.1.1]
parameters:
stp: true
forward-delay: 4
dhcp4: no
dhcp6: no

El dispositivo «eno2» sería nuestra tarjeta de red con conectividad y «br0» sería al puente hacia nuestras máquinas virtuales. Hay que tener en cuenta que yo he preferido establecer una IP fija para mi tarjeta con conectividad física pero se podría haber dejado con DHCP.

Gestión web del servidor

Para poder gestionar de manera fácil el servidor a través de un entorno web, he optado por hacer uso de Cockpit, el cual se puede instalar de la siguiente forma:

apt install cockpit cockpit-machines cockpit-docker cockpit-system cockpit-packagekit

Ahora podremos gestionar el servidor desde http://127.0.0.1:9090

Gestión de las máquinas virtuales

Si bien se pueden gestionar las máquinas virtuales de Cockpit de manera fácil, el interfaz es algo limitado con respecto a lo que podía hacer con Proxmox. Pero esto es fácilmente solucionable si las gestionamos desde Virtual Machine Manager, un software que puede estar instalado en nuestro sobremesa o portátil y que permite gestionar tanto las máquinas virtuales en local como remotas.

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.

Portátil Dell G7 7790 en Linux

lunes, 12 de agosto de 2019 Sin comentarios

El Dell G7 7790 que he podido configurar incorpora la siguiente configuración hardware:

  • 17″ IPS 144Hz Full HD.
  • i7 8750H.
  • 16 GB de RAM DDR4 ampliado a 32GB.
  • Nvidia GTX 2070 Max-Q.
  • SSD M.2 NVMe de 512MB cambiado por un SSD M.2 NVMe de 2TB de Intel 660P.
  • Batería de 90Wh.

Cambio de RAID a AHCI

Para poder realizar la instalación de alguna distribución Gnu/Linux hay que cambiar, desde la BIOS, las opciones de dispositivos de almacenamiento para que la controladora se comporte como AHCI en vez de como RAID, de lo contrario nuestra distribución no será capaz de detectar los discos duros. Pero si realizamos el cambio sin más y queríamos conservar la partición con Windows 10, este no arrancará. Por lo que tendremos que seguir estos pasos antes:

  1. Abrir un cmd como derechos de administrador.
  2. Ejecutar el siguiente comando: «bcdedit /set {current} safeboot minimal» o de forma alternativa: «bcdedit /set safeboot minimal».
  3. Reiniciar el portátil y entrar en la BIOS.
  4. Cambiar el comportamiento de la controladora de dispositivos de almacenamiento de RAID a AHCI.
  5. Windows arrancará en modo seguro reconociendo los cambios sobre el hardware.
  6. Abrir un cmd como derechos de administrador.
  7. Ejecutar el siguiente comando para deshacer lo anteriormente hecho: «bcdedit /deletevalue {current} safeboot» o de forma alternativa: «bcdedit /deletevalue safeboot «.
  8. Reiniciar el equipo nuevamente y Windows 10 arrancará como normalmente lo hace.

Instalación de OpenSuse

Para lanzar la instalación de OpenSuse Leap es posible que tengamos que incorporar el parámetro «nomodeset» al kernel, de lo contrario la pantalla simplemente aparecerá en negro.

La instalación la podremos realizar sin ninguna pega. Cabe recordar que habrá que definir la partición EFI sobre la ya existente y no formatearla para que puedan convivir tanto Windows como OpenSuse.

Teclas Fn para el control del brillo

Una vez arranque OpenSuse, probablemente no funcionarán las teclas de brillo. Para solucionarlo sólo tendremos que editar el fichero «/usr/share/X11/xorg.conf.d/10-nvidia-brightness.conf» y añadir lo siguiente:

Section «Device»

Identifier «Device0»

Driver «nvidia»

VendorName «NVIDIA Corporation»

BoardName «GTX 2070»

Option «RegistryDwords» «EnableBrightnessControl=1»

EndSection

Podremos reiniciar y comprobar que ya funcionan las teclas de control de brillo. Cierto es que si nada más iniciar la sesión, hacemos uso de dichas teclas puede que no funcionen y nos toque cerrar sesión y volverla abrir, pero no es algo habitual.

Hibernación al cerrar la tapa

Para hacer funcionar la hibernación cuando cerramos la tapa, tendremos que colocar los siguientes parámetros para el kernel:

splash=silent nomodeset resume=/dev/disk/by-id/nvme-INTEL_SSDREKT8_BTN-part7 quiet nouveau.blacklist=1 acpi_rev_override=1 acpi_osi=Linux nouveau.modeset=0 pcie_aspm=force drm.vblankoffdelay=1 scsi_mod.use_blk_mq=1 nouveau.runpm=0 mem_sleep_default=deep

En OpenSuse lo podemos hacer desde Yast -> Boot Loader -> Parámetros del núcleo en la casilla que pone «Parámetro opcional de la línea de comandos del kernel». Hay que tener en cuenta que el dato «/dev/disk/by-id/nvme-INTEL_SSDREKT8_BTN-part7» es diferente en cada equipo y define la partición donde se aloja la swap.

Undervolt y gestión de rendimiento

Sabido es para este tipo de procesadores que un pequeño «undervolt» mejora con creces la temperatura del mismo y evita que se llegue al throttling. Para conseguirlo hago referencia a una entrada que publiqué no hace mucho.

Y para poder gestionar la actuación de los ventiladores y la frecuencia de la CPU publiqué otra entrada muy interesante para este tipo de portátiles.

Control de Intel P-state y CPUFreq en KDE

jueves, 2 de mayo de 2019 Sin comentarios

A la hora de gestionar el rendimiento y las capacidades de refrigeración en un portátil, a veces un buen widget para gestionarlo de forma rápida viene bien. Este es el caso del proyecto de Plasma-pstate.

Su instalación es sencilla:

git clone https://github.com/jsalatas/plasma-pstate
cd plasma-pstate
sudo ./install.sh

De lo único que tenemos que asegurarnos es de estar en el sudoers y, en caso de OpenSuse, utilizar la herramienta propia de configuración de sudo por medio de Yast para agregar tu propio usuario para ejecutar como root sin necesidad de contraseña el siguiente script:

/usr/share/plasma/plasmoids/gr.ictpro.jsalatas.plasma.pstate/contents/code/set_prefs.sh

De lo contrario acabaremos con un panel que se despliega de color gris sin nada en su interior.

Controlar el voltaje de la CPU en Linux

sábado, 27 de abril de 2019 Sin comentarios

Sobretodo en portátiles se suele hacer uso de herramientas que limitan el voltaje que le llega a la CPU para así reducir el consumo y sobretodo la temperatura («undervolting», lo que ayuda a evitar el llamado «thermal throttling«.

Para Windows es muy común utilizar ThrottleStop. Para Linux, en cambio, se puede utilizar Undervolt.

Se instala sencillamente con el siguiente comando:

pip install undervolt

Para consultar los parámetros actuales de nuestro sistema:

undervolt –read

temperature target: -0 (100C)
core: 0.0 mV
gpu: 0.0 mV
cache: 0.0 mV
uncore: 0.0 mV
analogio: 0.0 mV

Para modificar el voltaje de un procesador como un i7 8750H podríamos aplicar el siguiente comando:

undervolt –core -125 –cache -125

Cabe resaltar que hay que realizar los cambios con cuidado, porque una excesiva reducción del voltaje puede provocar inestabilidad en el sistema.

Let’s Encrypt y ISPConfig

martes, 25 de septiembre de 2018 Sin comentarios

Let’s Encrypt nos facilita tener un certificado SSL de forma gratuita e ISPConfig nos automatiza el proceso marcando un par de checks, pero puede que haya problemas si utilizamos una Ubuntu 16.04 (Xenial): cuando marcamos los checks para activar el SSL y Let’s Encrypt en el dominio deseado, no se quedan permanentes, se desactivan como si el proceso no se hubiese llevado a cabo.

Todo esto se debe a que necesitamos actualizar el proceso de automatización de solicitud de certificados de seguridad. Nos es suficiente con realizar estas acciones para instalar Certbot:

apt-get update
apt-get install software-properties-common
add-apt-repository ppa:certbot/certbot
apt-get update
apt-get install python-certbot-apache

Una vez realizado los pasos anteriores, podremos acudir de nuevo a ISPConfig y marcar los checks.

Categories: Servidores, Ubuntu Tags: , ,