Release new image with ĞDev5 chainspecs

[Pini]

If you still work with release/poka-chainspec-gdev5-pini-docker I think we should rebase on master first. This will allow us to discard unwanted commits such as my changes on the CI variables.

I can do that into another release branch. What do you think?

EDIT: I just did that. Actually the only relevant difference between master and release/poka-chainspec-gdev5-pini-docker is the chain-spec. All other commits - but my erroneous ones - were merged into master.

Talking about chain-spec, I thing the release process should be something like:

1. Create a dedicated release branch
2. Add the chain-spec generated from @poka’s tools
3. Release

[HugoTrentesaux]

Ok, I’ll look at this and release and test an official docker image. Thanks!

[edit]

@Pini

I just did that

Did you push your branch? I do not see it.

[Pini]

@HugoTrentesaux

Did you push your branch? I do not see it.

No because I didn’t retain the 2 chain-spec related commits (rationals above). Then the result is… master.

[HugoTrentesaux]

Yes, that’s what I meant by cherry-picking: it’s the same as an interactive rebase dropping all the non-chainspec-related commits. I’ll do it.

[Pini]

Not sure what you want to achieve but in my opinion the previous chain-spec shouldn’t be cherry-picked as it will be replaced with the new one anyway. master should be the actual branch you want to start from.

[HugoTrentesaux]

The “chainspec” means “runtime at genesis”, so if we want to stay on the same network (ĞDev5), we have to keep the same genesis. We could still publish runtime upgrade later on, but we can not rewrite the history of blockchain without launching a new network, and this is not the moment yet. My whish is that the next network is a ĞTest network (and that we keep the ĞDev network at the same time).

[Pini]

@HugoTrentesaux

if we want to stay on the same network (ĞDev5), we have to keep the same genesis

Ah OK, I didn’t get it. Thanks;

[HugoTrentesaux]

If I release a new image, I would like to increase the number of bootnodes.

@poka @HugoTrentesaux @vit @cgeek @pini, can you confirm this is ok for you?
@tuxmain can you give me an endpoint that you think would be ok?

[list edited]

"bootNodes": [
    "/dns/gdev.p2p.legal/tcp/30333/p2p/12D3KooWFrffUkMAGr5AaYK1nfAwXqLpGq7DVtWcN8HsrWmn9VHY", 
    "/dns/gdev.p2p.legal/tcp/30334/p2p/12D3KooWMYJzk1FfBZjEAuEvwUnH2Luj5Bq4ouLX1tgZBPpFegaB", 
    "/dns/gdev.coinduf.eu/tcp/30333/p2p/12D3KooWMCrfuSXdGvokGCjbuN9KZvq9N7WWBoPat91gG1PU4w2b",
    "/dns/gdev.trentesaux.fr/tcp/30333/p2p/12D3KooWMAnBum4Xq8B6NQZgmmXVJvWkHzdLrJ297np3VbMqnz7t",
    "/dns/vit.fdn.org/tcp/30334/p2p/12D3KooWDuzVbBcnnEEKh32R6MUKvQvLENyzLHHUfg4kTyUQq7hp",
    "/dns/gdev.cgeek.fr/tcp/443/wss/p2p/12D3KooWDoEt6m6fBVg3YcgFH8TtsRQTJGmyVMGU3fKkRoM1hWrT",
    "/dns/gdev.pini.fr/tcp/443/wss/p2p/12D3KooWH8fb9TsHvvXfD9cWLJtNuiMGGBTZ3a7gkxV4aXcsfDxG",
    "/dns/gdev-smith.pini.fr/tcp/443/wss/p2p/12D3KooWCEVBrLK9g8unsHLj8wWzobbwArDZMMwg5LeCbiWhB3ug",
    "/dns/gdev.polux.re/tcp/30333/p2p/12D3KooWQ9dAZWSNQLLb3WG1gtNYhqhu7BUpaCXpUACvCFeoq8Ff"
]

[edit] I will probably remove my validator node from endpoints since I intend to change it soon (port and peerId).

[edit] @moul, I see you have a DNS entry:

gdev.moul.re.		3550	IN	A	51.68.188.165

do you have a bootnode to share with us?

[Pini]

@HugoTrentesaux

@pini, can you confirm this is ok for you?

Yes I do. But the endpoint is not correct. Please use:

    "/dns/gdev.pini.fr/tcp/443/wss/p2p/12D3KooWH8fb9TsHvvXfD9cWLJtNuiMGGBTZ3a7gkxV4aXcsfDxG"

EDIT: here is my validator node endpoint, just in case we end up prefering validator nodes as boot nodes.

    "/dns/gdev-smith.pini.fr/tcp/443/wss/p2p/12D3KooWCEVBrLK9g8unsHLj8wWzobbwArDZMMwg5LeCbiWhB3ug"

[HugoTrentesaux]

It depends whether we want to set the mirror or validator node in the bootnodes. I just asked the question here, if you have the answer, you can answer ^^
Note that I set both my validator (gdev.trentesaux.fr and my mirror archive node gdev.coinduf.eu). You could do the same.

[poka]

@HugoTrentesaux

It depends whether we want to set the mirror or validator node in the bootnodes. I just asked the question here, if you have the answer, you can answer ^^

I was about to ask the same question aha
I think we should set validators bootnodes.

Mine:

gdev-duniter-validator-1 | 2023-01-23 13:07:00 🏷 Local node identity is: 12D3KooWMYJzk1FfBZjEAuEvwUnH2Luj5Bq4ouLX1tgZBPpFegaB

Mirror:

duniter-indexer-duniter-rpc-1 | 2023-02-16 22:41:15 🏷 Local node identity is: 12D3KooWFrffUkMAGr5AaYK1nfAwXqLpGq7DVtWcN8HsrWmn9VHY

[Pini]

@HugoTrentesaux

It depends whether we want to set the mirror or validator node in the bootnodes

Both are behind my reverse proxy and their endpoints use wss. The endpoint I gave above is my mirror node in archive mode.

[HugoTrentesaux]

You are right, if I go to https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fgdev.pini.fr%2Fws#/rpc and call system.localListenAddresses() RPC call, I get:

[
  /ip4/127.0.0.1/tcp/30333/ws/p2p/12D3KooWH8fb9TsHvvXfD9cWLJtNuiMGGBTZ3a7gkxV4aXcsfDxG
  /ip4/172.18.0.10/tcp/30333/ws/p2p/12D3KooWH8fb9TsHvvXfD9cWLJtNuiMGGBTZ3a7gkxV4aXcsfDxG
]

[poka]

@Pini

Both are behind my reverse proxy and their endpoints use wss.

I think we don’t care about reverse proxy, libp2p do the job throw.

For instance, my 2 nodes are under a pfsense firewall. I didn’t do any NAT rule for these nodes, I didn’t configure any reverse proxy for my validator node, and yet the latter is accessible by other nodes. libp2p is magic for me…

[Pini]

@poka

I think we don’t care about reverse proxy,

I do care for my server. How would it be a problem?

[poka]

I mean for the bootnodes, it doesn’t need to be behind an accessible reverse proxy to be valid.

I had misunderstood your answer actually, I thought you were saying that it was better to use the mirror because it is behind a reverse proxy, my bad.

---

And you’re right about archiving, I don’t know if there’s any point in setting archive nodes for bootstrap, I would say no it doesn’t matter?

[Pini]

@poka

I didn’t configure any reverse proxy for my validator node, and yet the latter is accessible by other nodes.

But not the mirror:

$ nmap -p 30333-30334 gdev.p2p.legal
Starting Nmap 7.80 ( https://nmap.org ) at 2023-03-07 21:24 CET
Nmap scan report for gdev.p2p.legal (163.172.105.161)
Host is up (0.019s latency).
rDNS record for 163.172.105.161: 163-172-105-161.rev.poneytelecom.eu

PORT      STATE    SERVICE
30333/tcp filtered unknown
30334/tcp open     unknown

@poka

I mean for the bootnodes, it don’t need to be behind an accessible reverse proxy to be valid.

I don’t say it needs to. I say that on my server I chose to do so. And I see no reason for avoiding this setup.

@poka

I think we should set validators bootnodes.

Why? I would say the opposite actually. Because validator nodes should have less exposure as I understand it.

@poka

I don’t know if there’s any point in setting archive nodes for bootstrap, I would say no it doesn’t matter?

I would say that as well. I fail to see any reason why it should matter.

[poka]

@Pini

And I see no reason for avoiding this setup.

I never said that =)

@Pini

Why?

No hard reason, just because validators are the firsts node peoples starts, mirror can be stop more often than validators maybe ? (do not ask me more explanation I don’t have any more )

@Pini

validator nodes should have less exposure as I understand it.

For me, set the node idty of a validator does not particularly expose it to anything.

@Pini

gdev-smith.pini.fr

but this is a useless exposure for instance =)

[Pini]

@poka

@Pini

gdev-smith.pini.fr

but this is a useless exposure for instance =)

Would you mind to share how?

[poka]

I was going to say, just resolving this domain lets you know that your validator node is on the same machine as your mirror node, which can provide an angle of attack.

… but on the one hand everyone suspects it, and on the other hand if you don’t provide a domain for the bootstrap, you have to provide the IP directly so … I don’t know. yet.