How does ZeroOs recognize the Node

#1

Hello community ! since months i asking my self how ZeroOs does check for the Hardware of a Node…

I think this is a point which some of the farmere are interested into.

For example i have a Node which farms with 0,12 condition and i change something afterwards…

following examples (non certified and certified servers):
if i change open or intern IP
if i change from IPv4 to IPv6
if i change CPUs
if i change RAMs
if i change SSDs or HDDs
if i change the NIC
if the Mainboard is broken and i have to change.
if i change the ZeroOs-Skript Version or the Farmers ID
if i change from ZeroOsv1 to ZeroOsv2

… will the Node get remembered as te same?

what do I have to be aware of?

thanks alot!

1 Like
#2

Very interesting question.

So let me example how it works for both v1 and v2.

In v1, our goal was to be able to identify a node based on some hardware unique identification. We did some research and try quite some things but it turns out you cannot really rely on hardware vendor to properly populate the ID of they hardware. We found that most of the time these ID field are empty or the same for all. So we drop that idea and instead used the mac address of the NIC that received the default gateway when the node boot.

This means when you run 0-OS v1. If you change the NIC or if you plug your network cable in a another NIC, then the node ID will change.

In 0-OS v2. We change that behavior to make avoid having any change of the node ID during the all lifetime of node.
In v2, the node ID is the base58 encoded version of the public key of the node. Each node the first time it boots will generate a key pair that is used throughout its life for cryptographic things (encryption, signature,…)
This key pair never change even you change the hardware of the node, which mean the node ID is also always the same.

I hope that answers you question :slight_smile:

2 Likes
#3

Thank you - yes now its more clear.

But i dont understand the part with 0-OS v2 …

Each node the first time it boots will generate a key pair that is used throughout its life for cryptographic things (encryption, signature,…)

First I understand - in 0-Os v2 it doesnt get on MAC-Address.

I dont understand:
If I start the server with an USB-Stick which has 0-Os v2 on it, the Node will be generated and goes online - right?.
What if I later change the USB-Stick to a different one? or I change all Disks? Where is the Information of the Node (key pair?) be saved?

I really dont get it, how it will remember the Node if I change everything? for me it sounds like, everytime I start the node from ground up - with for example a new USB-Stick or a PXE-Server - it will be a new Node.

Last question:

I understand, if I Change from 0-Os v1 to 0-Os v2 it will be a new Node.
Doesnt that erase the 0,12 rate of a Node to a 0,15 rate, cause at end of this month it will be the 0,15 rate for all new Nodes?

Sorry for my english and thank you very much!

#4

Nothing happens, the image is the same for everyone this doesn’t impact anything

If you change all the disks at the same time, then you will end up with a new node. But loosing all disk at the exact same time is not something that is expected to happen.

That’s not the case. The way you boot the node has 0 impact on the identity of the node.

You will get a new node ID when migrating to v2 yes. But your rate should remain the same cause the OS is still able to generate the nodeID v1 the same way as before. So we are able to link the nodeID from v1 to the one in V2 and thus keep the rate you had before the migration.

1 Like
DIY Nodes Guide
#5

Is there any description how this is handled in V3? I’ve read that the TPM module is used to recognize the node. Would this mean that a broken motherboard would result in the loss of the node? I guess you have a solution for that, but could someone please explain?

#6

Currently on v3, the node id is still generated by the node and stored on disk (currently just one disk, but will be all disks on a future version of Zos).

Identification via TPM is a work in progress, so I can’t say for sure how such cases will be handled. Allowing a node identity to persist across a motherboard replacement seems like a nice feature to me, as long as the hardware specs are comparable. If the replacement also constitutes a major upgrade, perhaps the node should just be considered a new node.