FAQ_ES

F.A.Q.

1. ¿Cómo se realiza un pull request a alastria-node?
2. Si has realizado un Pull Request y no coge peers
   1. Caso 1
   2. Caso 2
   3. Caso 3
   4. Caso 4
3. El network_id del nodo no se ajusta a la nomenclatura
4. Actualización por cambio de rama (se ha cambiado la red)
5. Too many open files
6. Creación de un fichero swap
7. Error Workarounds

¿Cómo se realiza un pull request a alastria-node?

1. Iniciamos sesión en https://github.com.
2. Navegamos a https://github.com/alastria/alastria-node.
3. Pulsamos sobre el botón Fork y nos creará una copia del repositorio actual alastria node en nuestro usuario, ej.: https://github.com/marcossanlab/alastria-node
4. En este repositorio, navegamos al fichero data/constellation-node.json y con el icono lápiz, agregamos la modificación al final de la lista dentro de los corchetes. Una vez realizados los cambios en el fichero, deberemos utilizar el botón Commit changes.
5. Ahora, navegamos al fichero data/permissioned-nodes_validator.json y con el icono lápiz, navegamos la modificación realizada durante el proceso de configuración del nodo. Una vez realizados los cambios en el fichero, deberemos utilizar el botón Commit changes.
6. Navegando al fichero DIRECTORY_REGULAR y utilizando el icono lápiz, añadimos en la última línea del fichero la información, que en el caso del ejemplo sería:

| Test Alastria |  Marcos Serradilla (@mserradilla, [email protected]) | Amazon AWS (2C/8Gb/100Gb)| BAKMjJL7xeRjUt1za/Ax8pKIb9T66tSJWxW3QfTmOSY= | enode://d0f067fdf960ee637037b1a8dbfe8cabfce64a1fed87b3dcb8c2bab834f1f56e398e30dc10692e82b60e665d3870c18308abff1e03adc3ad24024a272275b8d3@35.176.34.215:21000?discport=0 |

7. Utilizamos el botón Commit changes como en el resto de los casos.
8. Navegamos a la pestaña Pull request y hacemos clic sobre el botón New Pull Request verificando que a la izquierda se encuentra el repositorio alastria\alastria-node y a la derecha tu_usuario\alastria-node .
9. Utilizando el botón Create pull request se crea en el repositorio alastria-node el correspondiente pull request que el equipo de plataforma deberá aceptar e integrar.

Si has realizado un Pull Request y no coge peers

Caso 1

Aunque esté aceptado el Pull request no significa que los servidores se hallan actualizado, por lo que, verifique esto último.

Caso 2

Si esto se ha producido, revise que el puerto UDP 21000 está habilitado en su firewall y confirme mediante alguna herramienta de escaneado de puertos que efectivamente está disponible.

Desde una localización distinta a nuestra red (por ejemplo conectando al wifi del móvil), se debe realizar el siguiente test sudo map -sT -sU -Pn -p 21000 YOUR_IP.

Caso 3

En el caso de verificar todo lo anterior, no puede sincronizar, verifique que el enode con el que se inicia el nodo es el que está publicado para su nodo. Para obtener el enode:

$ geth attach ~/alastria/data/geth.ipc
> admin.nodeInfo

Caso 4

En el caso de que la IP pública del nodo auto-descubierta con init.sh auto no coincida con la IP pública del nodo, hay que realizar un nuevo Pull request modificando el directorio y los ficheros .json de permisionado y constellation.

El network_id del nodo no se ajusta a la nomenclatura

En caso de cambio de NETWORK_ID, sólo es necesario parar el nodo, actualizar el repositorio y levantar de nuevo los servicios.

$ cd ~/alastria-node/scripts
$ git pull
$ ./update.sh

Actualización por cambio de rama (se ha cambiado la red)

Si se está utilizando una rama antigua del repositorio para mantener el nodo en funcionamiento y se necesita cambiar a la rama actual, sería como si se realizara una nueva instalación. Se ha definido una regla de nombrado de los nodos cuya nomenclatura es: TYPE_COMPANY_NET_CORES_RAM_SEQ.

• Type: VAL | BOT | REG.
• NET: DevNet | Testnet | Telsius | RedT | MainNet.
• SEQ: Sequencial empezando en 00.

Así que:

$ rm -Rf alastria-node
$ pkill -f monitor
$ pkill -f bee
$ pkill -f constellation-node
$ pkill -f geth
$ rm ~/alastria/logs/*.log
$ rm -Rf ~/alastria/workspace
$ git clone https://github.com/alastria/alastria-node
$ cd alastria-node
$ git checkout develop
$ cd scripts
$ sudo -H ./bootstrap.sh
$ ./init.sh backup general YOUR_ACTUAL_ID
$ ./update.sh
$ ./monitor.sh update
$ ./monitor.sh start

Too many open files

En algunas ocasiones, se ha identificado que los nodos dejan de sincronizarse y que en el log notifica un error como este:

ERROR[05-04|08:51:10] parsePermissionedNodes: Failed to access nodes err="open /home/ubuntu/alastria/data/permissioned-nodes.json: too many open files"

Para resolverlo, se han seguido los pasos de este tutorial 'Ubuntu 16 - how to increase maximum file open limit ( ulimit -n )' que en resumen nos solicita:

$ sudo nano /etc/sysctl.conf

Añadir al final:

fs.file-max = 131072

Ejecutar:

sudo sysctl -p

Editamos:

sudo nano /etc/security/limits.conf

Añadimos:

* soft     nproc          131072    
* hard     nproc          131072   
* soft     nofile         131072   
* hard     nofile         131072
root soft     nproc          131072    
root hard     nproc          131072   
root soft     nofile         131072   
root hard     nofile         131072

Editamos:

sudo nano /etc/pam.d/common-session

Añadimos:

session required pam_limits.so

Reiniciar el servidor.

Creación de un fichero swap

Durante la ejecución de las transacciones, Quorum realiza reservas de memoria muy elevadas y hemos detectado que en algunos casos, se produce un error Panic dejando el nodo fuera de línea.

Para evitar estos problemas, se puede crear un fichero swap que evita esto último. El siguiente ejemplo crea un fichero swap de 1Gb.

$ sudo fallocate -l 1G /mnt/1GB.swap
$ sudo dd if=/dev/zero of=/mnt/1GB.swap bs=1024 count=1048576
$ sudo mkswap /mnt/1GB.swap
$ sudo swapon /mnt/1GB.swap
$ sudo nano /etc/fstab

Se añade al final:

/mnt/1GB.swap  none  swap  sw 0  0

Se edita:

$ sudo nano /etc/sysctl.conf

Se añade al final:

vm.swappiness=10

Y por último:

$ sudo chmod 600 /mnt/1GB.swap

Error Workarounds

• Aparece un error "Blockchain not empty, fast sync disabled" en el log de Quorum al iniciar el nodo. Quorum se arranca en el script ./start.sh con --fast-sync. Este error aparece cuando se intenta arrancar un nodo no sincronizado pero con una blockchain no vacía, en cuyo caso no se puede utilizar el modo --fast-sync y se pasa a utilizar una sincronización --full. Esto provoca que el nodo tarde algunos minutos en inciarse completamente y estar accesible por RPC para su uso. Referencia Issue #63

Situación de sincronización de nodo:

geth --exec "eth.blockNumber" attach /root/alastria/data/geth.ipc
geth --exec "admin.peers" attach /root/alastria/data/geth.ipc
geth --exec "eth.syncing" attach /root/alastria/data/geth.ipc