|
How to unpackage (or unpack, unzip, extract) a chaincode?
-xvzf
By
...
· #7729
·
|
|
CORE_PEER_CHAINCODEADDRESS when peer is not running in a docker container
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
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
|
By
...
· #7643
·
|
|
CORE_PEER_ADDRESS vs CORE_PEER_LISTENADDRESS
Listen is for the bind() call. Peer address is the externally visible address published during discovery. Please research bind() if that is unclear.
Listen is for the bind() call. Peer address is the externally visible address published during discovery. Please research bind() if that is unclear.
|
By
...
· #7635
·
|
|
Is HLF a DLT or a blockchain?
https://en.wikipedia.org/wiki/No_true_Scotsman
https://en.wikipedia.org/wiki/No_true_Scotsman
|
By
...
· #7629
·
|
|
#fabric-questions Fabric Networking
#fabric-questions
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
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
|
By
...
· #7608
·
|
|
#fabric-questions Fabric Networking
#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
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
|
By
...
· #7600
·
|
|
Revoke User certificate
You mean inside channel configuration MSPs, not peer MSPs. Not sure if what I wrote below was clear.
You mean inside channel configuration MSPs, not peer MSPs. Not sure if what I wrote below was clear.
|
By
...
· #7489
·
|
|
Revoke User certificate
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
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
|
By
...
· #7485
·
|
|
Multi-network node deployments
#fabric
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
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
|
By
...
· #7257
·
|
|
Does Raft orderer work across multiple Kubernetes clusters?
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
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
|
By
...
· #7222
·
|
|
Does Raft orderer work across multiple Kubernetes clusters?
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
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
|
By
...
· #7217
·
|
|
Which cert should be copied for TLS( ca-cert.pem or tls-cert.pem)
#fabric-ca
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
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
|
By
...
· #7158
·
|
|
Alternative of cryptogen for Prod
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
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
|
By
...
· #7136
·
|
|
Alternative of cryptogen for Prod
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
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
|
By
...
· #7134
·
|
|
Alternative of cryptogen for Prod
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
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
|
By
...
· #7132
·
|
|
Alternative of cryptogen for Prod
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
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
|
By
...
· #7131
·
|
|
Alternative of cryptogen for Prod
It is described in the Operations Guide.
It is described in the Operations Guide.
|
By
...
· #7102
·
|
|
Major security hole in Hyperledger Fabric - Private Data is not private
#fabric-chaincode
#ssl
#fabric
#fabric-questions
#fabric-dstorage
Yes, i have extensive hacks that do exactly that. It's a mess and illustrates exactly how badly some of k8s networking is "designed".
Yes, i have extensive hacks that do exactly that. It's a mess and illustrates exactly how badly some of k8s networking is "designed".
|
By
...
· #7096
·
|
|
Major security hole in Hyperledger Fabric - Private Data is not private
#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
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
|
By
...
· #7094
·
|
|
Major security hole in Hyperledger Fabric - Private Data is not private
#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.
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.
|
By
...
· #7092
·
|