David

01
Nov
2021
Funciones útiles con el Subsistema Linux en Windows 10 (WSL)

Funciones útiles con el Subsistema Linux en Windows 10 (WSL)

  • Acceder a una memoria USB desde WSL

En la estructura de archivos del subsistema de Linux vienen por defecto varios directorios con las típicas letras de unidad de disco de windows. En efecto, si miramos el contenido de la carpeta de montaje:

ls /mnt

c d e f

Sin embargo, cuando entramos en el directorio correspondiente a la letra de unidad donde tenemos insertada la memoria, resulta que está vacío. Al parecer, las unidades externas no se montan automáticamente, sino que hay que hacerlo explícitamente mediante el comando mount . En el siguiente ejemplo, vemos los parámetros con los que ejecutar este comando cuando montamos la unidad presente en E:

sudo mount -t drvfs E: /mnt/e

Y para desmontar, exactamente igual que en Linux…

sudo sudo umount /mnt/e

  • Acceder a los archivos del espacio WSL desde Windows

El espacio de archivos utilizado por WSL está disponible directamente desde el explorador de Windows 10 introduciendo esta ruta en la barra de direcciones del explorador de archivos: \\wsl$\Ubuntu

Nota: Si nos fijamos en la notación, veremos que Windows 10 maneja esta ruta como un sitio de red. Para que la ubicación de red esté montada, será necesario que en ese momento se esté ejecutando la sesión correspondiente en el WSL

Publicado por David en Blog, Linux, 0 comentarios
31
Oct
2021

Cómo delegar fondos en un «stake pool»

Para ser capaces de delegar fondos en un determinado Stake Pool será necesario cumplir tres condiciones:

  1. La dirección de payment en la cual tenemos los fondos que deseamos delegar deberá estar asociada a una dirección de stake.
  2. Dicha dirección de stake debe estar convenientemente registrada en la en la cadena de bloques mediante un certificado de registro. Este certificado deberá ser remitido a la cadena de bloques con una transferencia específica que comporta un depósito. En el momento de escribir estas líneas, el depósito es de 2 ₳ 
  3. Será necesario, además, un certificado de delegación que asocie la dirección de stake con el pool seleccionado, que deberá ser remitido a la cadena de bloques con una transferencia estándar con la tarifa mínima.

Una vez realizado el proceso completo, los fondos depositados en la dirección de payment asociada a la clave de stake en cuestión participarán del monto total de fondos delegados al pool, colaborando en la creación de bloques por parte de ese pool y recibiendo recompensas por ello en la misma dirección de stake.

Dado el procedimiento, podemos ver también que cambiar de pool es tan sencillo como crear un nuevo certificado de delegación y remitirlo a la cadena de bloques, lo que implica una transacción estándar con tarifa mínima. El depósito inicial de 2 ₳ es necesario realizarlo solamente una vez para habilitar nuestra dirección a participar en el proceso de delegación. 

  • Crear una dirección de payment asociada a una dirección de stake

Para obtener una dirección de payment asociada a una dirección de stake, el procedimiento es muy sencillo, ya que basta con generar la dirección aportando la clave de verificación de stake, además de la clave de verificación de payment. En este ejemplo, para distinguir la dirección de payment asociada a stake de una dirección de payment regular, la llamaremos paymentwithstake.addr

cardano-cli address build \
--payment-verification-key-file payment.vkey \
--stake-verification-key-file stake.vkey \
--out-file paymentwithstake.addr \
--testnet-magic $MAGIC_NUM

  • Registrar la dirección de Stake

  • Crear un certificado de registro

Antes de poder empezar a delegar fondos es necesario registrar la dirección de stake en la cadena de bloques. Y el primer paso para ellos es crear un certificado de registro de dicha dirección.

cardano-cli stake-address registration-certificate \
--stake-verification-key-file stake.vkey \
--out-file stake.cert

A continuación, es encesario remitir el certificado a la cadena de bloques. Para ello, realizaremos una transacción desde la dirección de pago , en este caso, paymentwithstake.addr en la cual hay que incluir, de la tarifa estándar, el depósito antes mencionado. Ambas se deducen del balance de la dirección de pago a la hora de especificar el cambio devuelto.

Es importante señalar que en este tipo de transacción no se transfieren fondos a ninguna dirección. Tanto la tarifa como el depósito son descontados durante la transacción al calcular el balance resultante que es devuelto en la misma dirección de pago. El destino de ambas cantidades podemos entenderlo como una especie de servicio de tesorería dentro sistema de Cardano, el mismo que genera y administra las recompensas y la expansión monetaria del sistema. Los pasos para realizar la transacción son los habituales:

  • Obtenemos el balance de la dirección de pago

cardano-cli query utxo --address $(cat paymentwithstake.addr) --testnet-magic $MAGIC_NUM

                          TxHash                                 TxIx        Amount
--------------------------------------------------------------------------------------
96c74decbb8079ef017efabe5901ef40ff046a9c1f74ddd0c5eefc46353b53e5     0        1000000000 lovelace + TxOutDatumHashNone

  • Comprobamos la tarifa de registro

Si no lo hemos hecho antes, obtenemos los parámetros del protocolo que guardaremos en el archivo params.json. Entre otras muchas cosas, podemos obtener la tarifa por registrar la dirección de stake que, como ya hemos dicho, en este momento es de 2 ₳.

cardano-cli query protocol-parameters \
--testnet-magic $MAGIC_NUM \
--out-file params.json

  • Calcular el TTL (Time To Live)

Obtenemos el slot actual de la cadena para calcular el TTL (Time To Live) de la transacción

cardano-cli query tip --testnet-magic $MAGIC_NUM

{
    "epoch": 166,
    "hash": "13e9f47d0a19feb5f860a4b7b571162479ad103331cff1c56d24c116a937ae8f",
    "slot": 41347556,
    "block": 3036045,
    "era": "Alonzo",
    "syncProgress": "100.00"
}

Sabiendo que el tiempo entre dos slots es de un segundo, basta con sumar al slot actual un tiempo que consideremos razonable para armar la transacción sin prisas (normalmente, unos pocos minutos es suficiente)

  • Construimos el borrador de la transacción

Esto es necesario como paso previo para poder calcular la tarifa de la transacción. En este caso podemos dar un valor ‘0’ a los parámetros específicos de la transacción, tales como la tarifa, el cambio o el ttl.

cardano-cli shelley transaction build-raw \
--tx-in 96c74decbb8079ef017efabe5901ef40ff046a9c1f74ddd0c5eefc46353b53e5#0 \
--tx-out $(cat paymentwithstake.addr)+0 \
--ttl 0 \
--fee 0 \
--out-file tx.draft \
--certificate-file stake.cert

  • Calcular la tarifa mínima

A partir del borrador, calculamos la tarifa mínima

Es interesante comprobar que la tarifa de la transacción no depende para nada de las cantidades a transferir.

cardano-cli transaction calculate-min-fee \
--tx-body-file tx.draft \
--tx-in-count 1 \
--tx-out-count 1 \
--witness-count 1 \
--byron-witness-count 0 \
--testnet-magic $MAGIC_NUM \
--protocol-params-file protocol.json
 
172761 Lovelace

  • Construir la transacción definitiva

Aquí es donde podemos observar como la única dirección de salida es la misma que aquella de la que se obtienen los fondos y que se especifica solamente para recibir el «cambio» de la transacción, el cual es básicamente el balance inicial menos la tarifa y el depósito.

En mi caso, el cálculo de dicho cambio es el siguiente: 1000.000.000 – 2.000.000 – 172.761 = 997.827.239

cardano-cli transaction build-raw \
--tx-in 96c74decbb8079ef017efabe5901ef40ff046a9c1f74ddd0c5eefc46353b53e5#0 \
--tx-out $(cat paymentwithstake.addr)+997827239 \
--ttl 41444206 \
--fee 172761 \
--out-file tx.raw \
--certificate-file stake.cert

  • Firmar la transacción

Aquí podemos observar una caracterísitica específica de este tipo de transacción con respecto a una transacción convencional de movimiento de fondos: En este caso se proporcionan ambas claves de firma: la de pago y la de stake.

cardano-cli transaction sign \
--tx-body-file tx.raw \
--signing-key-file payment.skey \
--signing-key-file stake.skey \
--testnet-magic $MAGIC_NUM \
--out-file tx.signed

  • Enviar la transacción firmada

cardano-cli transaction submit \
--tx-file tx.signed \
--testnet-magic $MAGIC_NUM

Transaction successfully submitted.

Y… voilà!

  • Registrar la delegación en un determinado pool

  • Crear el certificado de delegación

Si deseamos delegar en un determinado pool, necesitaremos conocer el identificador de dicho pool. Se trata de un valor público que contiene la información necesaria para asociar nuestros fondos al pool sin necesidad de conocer sus claves y, por lo tanto, sin comprometer la seguridad del mismo.

cardano-cli stake-address delegation-certificate \
    --stake-verification-key-file stake.vkey \
    --stake-pool-id <stake pool ID> \
    --out-file deleg.cert

Igual que antes, hay que remitir este nuevo certificado a la cadena de bloques mediante una transacción que, en este caso, no implica realizar ningún depósito más allá de la tarifa estándar. Los pasos serán los mismos que en la transacción anterior.

 

Publicado por David en Blog, Cardano, 0 comentarios
31
Oct
2021
Funciones de fecha y hora en Linux

Funciones de fecha y hora en Linux

  • Cambiar zona horaria

Hay varios modos, pero el más sencillo es:

sudo dpkg-reconfigure tzdata

Seguir las instrucciones del asistente, y listo!

  • Comprobación fecha, hora y estado de sincroncinzación con NTP

timedatectl
(out)Local time: vie 2021-12-03 13:09:12 CET
(out)           Universal time: vie 2021-12-03 12:09:12 UTC
(out)                 RTC time: vie 2021-12-03 12:09:12
(out)                Time zone: Europe/Madrid (CET, +0100)
(out)System clock synchronized: yes
(out)              NTP service: active
(out)          RTC in local TZ: no
Publicado por David en Linux, 0 comentarios
30
Oct
2021
Acceso remoto SSH con clave pública y Google 2FA

Acceso remoto SSH con clave pública y Google 2FA

Las dos maneras más populares de asegurar una conexión SSH son el acceso mediante clave pública y la autenticación en dos pasos (2FA). La primera es la que más tradición tiene y la que llevo años utilizando en mis máquinas domésticas. La segunda es algo más reciente y nunca la había utilizado antes, así que me apeteció probarla para aumentar la seguridad. Hay decenas de tutoriales que explican el procedimiento, bastante sencillo, por cierto. Pero como el objeto de este blog es facilitarme las cosas a mí mismo y evitarme el ponerme a rebuscar, aquí dejo el enlace a la guía oficial de Ubuntu sobre el tema: Configure SSH to use 2FA

La verdad es que el acceso mediante 2FA es una chulada. Metes la contraseña y te pide un código del Google Authenticator. Sin embargo, una vez disipada la ilusión inicial pensé que no estaría de más sustituir el paso de introducir la contraseña por una autenticación mediante clave pública. Mucho más cómodo y, sobre todo, mucho más seguro. Así que configuré un par de claves RSA para entrar al servidor (proceso que aunque he realizado decenas de veces siempre se me olvida, así que también lo he dejado descrito por aquí).

La sorpresa vino cuando intenté la conexión. El hecho de haber configurado el acceso mediante clave hizo que la entrada al servidor fuera inmediata, sin solicitar el código de validación. Investigando un poco me entero de que, al parecer, el acceso mediante clave anula por defecto cualquier otro método de autenticación. Toda la configuración para el Google 2FA a hacer puñetas. Menudo chasco!

Así que vuelta a investigar la manera de poder mantener ambos modos de autenticación aunque, eso sí, sin necesidad de introducir la contraseña. De momento dos factores ya me parecen suficientes. Mejor dejar la autenticación multifactor (MFA) para más adelante.

Partimos de la configuración previa del archivo del servidor SSH, que coloco aquí mientras le busco un sitio mejor

sudo nano /etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication yes
PermitRootLogin prohibit-password

La cuestión es que si deseamos mantener ambos métodos de autenticación, de manera que ya no nos pida la contraseña (gracias a la clave RSA) pero nos continúe pidiendo el código de verificación, deberemos indicárselo explícitamente. Para ello, añadiremos una línea especificando dos posibles vías de autorización: O proporcionamos una clave pública y una contraseña, o bien una clave pública y un código de verificación.Las dos posibilidades están descritas en forma de dos listas de métodos. Las listas están separadas por un espacio. Y en cada lista, los métodos requeridos están separados por comas. Si los requisitos de una lista no se dan, entonces se pasa a la siguiente.
Como la configuración de este parámetro parece algo liosa, dejo aquí este enlace en el que lo explican todo muy bien y de manera muy detallada.

AuthenticationMethods publickey,password publickey,keyboard-interactive

Luego debemos modificar el archivo de configuración de PAM para que no nos pida la contraseña

sudo nano /etc/pam.d/sshd

Y comentamos la siguiente línea

#@include common-auth

Y ya está. Si os estáis preguntando por qué es necesario decirle a PAM que no pida contraseña en lugar de quitarla directamente de la lista de los métodos de autorización, os diré que yo me pregunto lo mismo. Lo único que sé es que hice la prueba y no funcionó, pero con el método descrito va como la seda.

Publicado por David en Blog, Seguridad, SSH, 0 comentarios
29
Abr
2021
Michael Collins – IN MEMORIAM

Michael Collins – IN MEMORIAM

Será como hace unos siete u ocho años que esta biografía cayó en mis manos por primera vez. Y como era natural, no pude resistirme a leerla. No soy muy de biografías, pero leer de primera mano las experiencias de este hombre que tuvo el enorme privilegio de pilotar la nave de la primera expedición humana a la luna resultó una experiencia casi mística. Supongo que siempre he sido un romántico, pero aún ahora me cuesta trabajo concebir un viaje más alucinante que aquel que este hombre protagonizó hace ya la friolera de 52 años.

Michael Collins siempre fue mi preferido. Quizás por ese caracter sencillo que le llevó a aceptar con orgullo el papel, aparentemente ingrato, de mantener la nave en órbita mientras sus dos compañeros descendían a la superficie del satélite ante la mirada atónita de, literalmente, todo el planeta.

Hoy, Michael Collins nos ha dejado. Y con él, se va agrandando ese hueco que van dejando los grandes hombres de mi vida, a los que tanto he admirado y a los que, de niño, tanto anhelaba parecerme. Y tan estremecedor como aquel insólito acontecimiento es el hecho cierto de que en este último viaje todos le acompañaremos un día ya no tan lejano. Sólo espero que el camino haya valido la pena. Hoy, brindo por ello y por mi admirado y querido astronauta.

Que el cielo te acoja de nuevo, Michael Collins.

Publicado por David en De todo un poco, 0 comentarios