-xvzf

Whatever public IP other peers would use to connect to it. Docker and NAT (in docker's case double or triple NAT) complicate matters, you will have to pay attention to how you will have peers communic

Listen is for the bind() call. Peer address is the externally visible address published during discovery. Please research bind() if that is unclear.

https://en.wikipedia.org/wiki/No_true_Scotsman

If you plan on running a p2p node on the public internet, ideally it should be secured such that a firewall (other than possibly a simple port whitelist at the router) isn't needed. If you believe a f

#fabric-questions

You didn't mention if you are having NAT traversal issues or straight up firewall issues. If the latter, opening ports should be sufficient. If the former, put it in a DMZ with real public ip addresse

#fabric-questions

You mean inside channel configuration MSPs, not peer MSPs. Not sure if what I wrote below was clear.

You have to update each applicable channel configuration with the new crls. The peer/orderer MSP would then be checked to make sure the entity making the channel configuration update has permission to

Private VLAN/VPN, or do a proper public IP p2p setup w/o docker swarm. Again, docker swarm and k8s are great for distributed microservices and big load balanced, asymmetrical client/server stacks, not

#fabric

Not to stray too far off topic, but k8s emerged from a client/server microservices/stack deployment requirement, not a p2p requirement. Its popularity for that purpose has (unfortunately, IMO) bled in

This is precisely why k8s and p2p are never a good match. K8s simply breaks far too many networking rfcs. It is suitable for asymmetric client/server microservices or stacks, and even then a tiny subs

From memory (I could be wrong): If you are using a single instance CA, ca-cert.pem is the root cert for both TLS and non-TLS certs issues by ca-server, including the tls-cert.pem issued to itself, so

#fabric-ca

If this is truly the case, using two instances of ca-server (one for TLS, one for non-tls) should be trivial, as well as generating self signed root certs to bootstrap the ca server, as well as distri

To digress a bit: I think the biggest confusion with the ca-server is issuing TLS certs (which end up in an MSP, and not in a way a TLS server can use them), and having to manually copy various things

1) you should not be using the ca-server to create root certificates either, IMO. You should have enough understanding of ssl to know how to create your own. In addition, ideally your TLS architecture

Either way, a network is not static. At some point you are going to have to issue new MSPs, and in order to do that, you have to have an understanding of both the ca-server and the structure and purpo

It is described in the Operations Guide.

Yes, i have extensive hacks that do exactly that. It's a mess and illustrates exactly how badly some of k8s networking is "designed".

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

Unfortunately, the internal DNS inside of a k8s cluster is completely screwed up since a service can't have more than two dots in them w/o a hairpin and external DNS resolution (e.g. host.subdomain.do

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage

I had this issue as well with k8s. k8s is a disaster for p2p protocols, it is a very bad match. Great for monolithic microservice stacks, not much else.

#fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage