[HowTo] Cómo unir una computadora con Windows 10 home al dominio

Otro título sugerido: cómo instalar Windows 10 pro en una computadora que venía con Windows 10 home.

TL:DR: No se puede. NO-SE-PUE-DEEEEEE. No vas a poder nunca unir una computadora con Windows 10 Home Edition a un dominio a menos que la formatees y reinstales Windows 10 Professional Edition.

Cuando tu versión es pirata (guiño guiño) o simplemente preferís formatear a usar DISM o el nuevo asistente de Windows para convertir, -hacer el upgrade- desde Windows 10 Home a Windows 10 Professional, la clave de activación de producto que venía con tu computadora te lo impedirá, la muy hija de puta.

El número de serie viene hardcodeado por UEFI y durante la instalación no sólo no te lo pregunta sino que además te instala de prepo la versión Home Edition de Windows (o alguna otra versión limitada) que tampoco te permite unirla al dominio. Y acá es donde vengo a darte una mano y de paso documentarlo para mi, por que ya me pasó varias veces y me hinché la pelotas o de googlearlo o de tener que explicarlo.

Tu product activation key podría no ser del todo legal y eso te impide la instalación o upgrade de Windows 10 home a Windows 10 pro por que la clave viene hardcodeada por UEFI y ni te la pregunta durante la instalación.

Durante la instalación de Windows 10, se utiliza el siguiente criterio para decidir cuál versión instalar:

  1. Si existe y contiene información válida, el archivo PID.txt tiene prioridad y se instalará la versión que corresponda a la key de Windows que allí esté definida.
  2. En caso contrario se instalará la versión que corresponda a la product activation key almacenada en el firmware UEFI.
  3. Si todo lo anterior falla se le pide al usuario que ingrese una clave durante la instalación.
  4. Si el usuario elige «no tengo, soy pobre» se le pregunta cuál versión instalar, si Pro o Home.
Sigue leyendo

No se puede ejecutar una VM en VMWare por que los módulos vmmon y vmmet no se pueden cargar.

Otro título sugerido: SecureBoot, la puta que te parió SecureBoot.

Hola, vengo de sobrevivir a esto y me lo voy a agendar por que tengo la sospecha de que si el kernel de Linux se actualiza me va a volver a pasar:

Al ejecutar VMware workstation Player o cualquiera de sus variantes en una computadora que tiene habilitado secureboot (y por consiguiente, todos los módulos y componentes del kernel firmados con una clave privada) via UEFI / Secureboot, la ejecución falla diciendo que el módulo vmmon no está cargado.

Mas específicamente, el mensaje de error reza:

Could not open /dev/vmmon: No such file or directory.
Please make sure that the kernel module `vmmon’ is loaded.

Para uno, que ya está versado en estos menesteres y va la consola a cargar el puto módulo como corresponde, convencido de que todo irá sobre rudas siempre es un ingrato despropósito encontrarse con que no, que no se va a poder:

modprobe vmnet

modprobe: ERROR: could not insert 'vmnet': Required key not available

Y ahí, justo ahí, empiezan tus problemas. Puteás mentalmente a todos los santos y acudís a Google a que te salve las papas. Con un poco de suerte, llegás hasta acá y te explico como seguir.

Foto real de una persona intentando utilizar VMware en Linux. Luego se preguntan por qué la gente odia Linux y prefiere Windows.

Lo que sigue es eso, como arreglar este problema, como cargar el módulo vmmon (y vmnet, que también vas a necesitar, sólo que todavía no lo sabés) si tu computadora y tu sistema operativo están usando secureboot en Linux y la cosa resulta relativamente sencilla una vez que entendés de que va todo:

Sigue leyendo

[TIP] Como pasar/convertir del timestamping del syslog (dmesg) a hora human readable en Linux

 

Lo tiro acá para toda la posteridad. Un pequeñísimo script para convertir el timestamping de syslog (la cantidad de segundos transcurridos desde que booteó el sistema) a hora local, cosa que a priori parece trivial pero que a la tercera vez que tenés que usar ya te cansa la cabeza.

 

Un poco de bash scripting. Convertir de Unix timestamping en el syslog de Linux a Hora en formato human readable.

 

Este script no es mío, lo robé de algún lado hace años y desde entonces me acompaña a todas partes:

#!/bin/bash

if [ "$#" != "1" ] ; then
echo "Usage: `basename $0` time-offset-integer"
exit 1
elif [ "`echo $1 | sed 's/[0-9]//g'`" != "" ] ; then
echo "Usage: `basename $0` time-offset-integer"
exit 1
fi

N=`date +'%s'`
U=`FS="." /usr/bin/awk '{print $1;}' < /proc/uptime | sed 's/[^0-9].*//'`
TS=`expr $N - $U + $1`
T=`date --date="@$TS"`

echo "$1 seconds after boot was about $T."

 

Como se usa.

A la típica salida del comando dmesg, o /var/log/syslog por ejemplo:

[511684.749771] Process accounting resumed
[511684.842941] systemd[1]: apt-daily-upgrade.timer: Adding 33min 25.167508s random time.
You have new mail in /var/mail/root

 

 

Ejecutás el script anterior, que en este caso llamé syslogtohuman.sh:

~# ./syslogtohuman.sh 511684
511684 seconds after boot was about Thu Aug 16 11:20:13 -03 2018.

 

Y así sabés que esa entrada en el syslog en particular aproximadamente en esa fecha y a esa hora: Thu Aug 16 11:20:13 -03 2018

 

De nada.

[HowTo] Como enviar todo el tráfico de tu iPhone por un tunel SSH

 

Va una no tan obvia y que me llevó su buen rato investigar: Como enviar (y recibir también, no sean pelotudos, es tráfico bi-direccional) todo el tráfico que genera tu iPhone o iPad -o cualquier otro dispositivo que exista en el futuro y corra iOS- por un tunnel SSH para que aparezca como tráfico generado por el servidor donde corre el SSH Server en Linux. Lo que también se conoce como proxy tipo socks.

 

Ya en el pasado le he dedicado diversos artículos a esta técnica que usé y uso hasta varias veces por semana según se me va presentando cada escenario, por ejemplo:

Si no están familiarizados con las tecnologías y protocolos implicados puede que quieran ir a leer primero alguno de los artículos anteriores.

 

Configurando un tunnel SSH que puedas utilizar luego desde tu iphone o ipad para acceder a ese servicio de streaming bloqueado en tu país, ciudad o empresa o como cagarte en todos los firewalls poniendo el servicio SSH de tu servidor a escuchar en el puerto 53 TCP.

 

Ingredientes:

  1. Un servidor corriendo Linux en algún lado.
  2. Un web server en algún lado donde se pueda escribir un archivo. No es estrictamente necesario.
  3. Una PC con Windows o Linux que hará las veces de socks proxy y puede ser el mismo servidor que corre el Linux
  4. Putty, si la PC socks proxy corre Windows. Bajalo de acá.

Sigue leyendo