We changed our privacy policy. Read more.

Hot answers tagged

8

Yes you can run tezos-signer separately from source binary and then let it connect to tezos-node running in docker container. This is how you can do it. On tezos-signer server run following 3 commands from directory where tezos-signer binary is downloaded: tezos-signer gen keys alice cat ~/.tezos-signer/public_key_hashs This will output something like ...


6

The docker builds are generally aimed at those individuals who are not comfortable with, or have no experience in compiling software. There is no advantage over running docker builds vs compile on your own; the code is the same. The docker builds are indeed supported by the core devs. With each new release of the core code, the docker images are also updated....


6

At the moment the following appears to work: alphanet.sh start --rpc-port 127.0.0.1:8732. Note --rpc-port and NOT --rpc-addr, this is a special case option in alphanet.sh. This will insert a entry: ports: - "127.0.0.1:8732:8732" into the generated docker-compose.yaml, causing the RPC to be exposed to localhost at the specified port -- it was ...


6

When you launch the docker node with ./mainnet.sh start, you can add extra arguments such as --private-mode --peer AAA.BBB.CCC.DDD:PORT (you probably need to specify --peer to connect your private node to your public node).


6

If you want to remain in private-mode, you must provide an argument --peer node:port when starting your node, or edit the config.json file of the node to add such peers (which is better, as it will be used everytime you restart it).


4

General remarks: raw text snapshots are more convenient for developers than pictures because you can quote them :-) It looks like tezos-client does not understand the "uri" format file:/[...]. It's an annoying bug which is worth reporting at https://gitlab.com/tezos/tezos/issues . I don't know if docker keeps the files it puts in /tmp/ or if it erases them ...


4

I believe this is because of a build issue with some OCaml module that checks hardware architecture at build time 😳 This leaks into the Docker images which throws Illegal instruction when run a different arch. You can read more about it here and here. The solution is to build the Tezos Docker image yourself on the infra/hardware you want to run it. You ...


4

It looks like your config.json has been corrupted. You can try deleting it or restoring it from a backup if you have one.


4

You typically mount volumes into docker containers. If you are using the official tezos/tezos image with it's entrypoint.sh you want to mount the following directories: volumes: - /data/tezos/mainnet/node:/var/run/tezos/node - /data/tezos/mainnet/client:/var/run/tezos/client Where the /data/tezos/mainnet path is the location of the tezos data on your ...


4

Of course the use of the Docker makes it easier to build a node, and it is useful for people with an initial level of knowledge of programming on Linux. The fact is that when you build a node for baking through the Docker, you may encounter errors that will not be easy enough to understand. I advise you to collect the node by the steps prescribed in this ...


4

SOLVED Ref. https://gitlab.com/tezos/tezos/issues/475 Apparently the USER env variabled needs to be set for it to work 😝 It is not set by default in official docker images. I'm reaching out to have them set it 👍


4

This is caused by an awkward behavior of the docker entrypoint script: it passes the node options along to tezos-node config {init,update} every time, which means options can accumulate and become impossible to remove through the entrypoint. :( One option would be to just delete your config.json and start over: ./mainnet.sh shell, then in the shell rm /var/...


4

So the answer is the import will work if you use an absolute path to your snapshot file. The snapshot filename alone will not work. Nor will a relative path the filename. The correct command will look like this: ./mainnet.sh snapshot import /absolute/path/to/snapshotfile/snapshotfile.full


3

You could use Docker's cp command as a workaround. In your case it would be something like: docker cp tz1Zvjxu9Vzt76uRLtV6CHZMPu1zKA5YV4QX.json alphanet_node_1:/home/tezos/tz1Zvjxu9Vzt76uRLtV6CHZMPu1zKA5YV4QX.json ./alphanet.sh client activate account myfaucet with tz1Zvjxu9Vzt76uRLtV6CHZMPu1zKA5YV4QX.json


3

It turned out to be a specific issue with docker-compose version 1.23.0 and 1.23.1, where containers get hashes appended to their names when running them (source: this serverfault question). This turns eg. mainnet_baker-003-PsddFKi3_1 into mainnet_baker-003-PsddFKi3_1_fefc704f16d2. The solution is to upgrade docker-compose to version 1.23.3or higher and ...


3

You could use Flextesa In a docker-compose file, it should look like the following: version: '3.6' services: sandbox: image: tqtezos/flextesa:20210316 command: edobox start -P 8732 container_name: sandbox environment: block_time: 1 TEZOS_CLIENT_UNSAFE_DISABLE_DISCLAIMER: Y ports: - "8732:8732" It will bake ...


2

Normally, the Docker images are supposed to follow the mainnet-staging branch of the Tezos repository: https://gitlab.com/tezos/tezos/commits/mainnet-staging


2

Okay so this is my first stackexchange answer ever and I'm surprised I was the one to figure this out but here's what I did after several hours. The problem is that docker cannot access the place in your filesystem that has your temp wallet in it. So I found this article detailing how to mount a volume to a docker container while it is running: https://...


2

I've had the exact same problem. I've filed a bug against it. See this issue here


2

To generate docker images from scratch locally, the full recipe is (a lot of patience and disk space) $ wget https://gitlab.com/tezos/opam-repository/-/archive/v8.2/opam-repository-v8.2.tar.bz2 $ tar xf opam-repository-v8.2.tar.bz2 $ cd opam-repository-v8.2/ $ scripts/create_docker_image.sh tezos_build_deps v8.2 $ cd .. $ wget https://gitlab.com/tezos/tezos/-...


2

Even though I'm still getting that error, when I run a get balance I can see that the activation worked and my account has tez


2

The command tezos-client show address <name> -S will show you the public and secret key of the user name. For instance, assuming that the dockerized tezos-client is accessible through the ./babylonnet.sh, you can run: ./babylonnet.sh client show address <name> -S However, you can also find the directory that corresponds to ~/.tezos-client used ...


1

I was able to make this work using the following commands: ./babylonnet.sh client gen keys MY_WALLET_NAME ./babylonnet.sh client show address MY_WALLET_NAME -S


1

You can use the following command: ./alphanet.sh admin-client list rejected blocks


1

The babylonnet.sh script accepts node options. You can inspect the node options via tezos-node run --help. The option you're looking for is: --cors-origin=ORIGIN: CORS origin allowed by the RPC server via Access-Control-Allow-Origin; may be used multiple times


1

All interaction with the dockerized tezos-node (should) go through the ./babylonnet.sh, alphanet.sh or mainnet.sh script (the name of the script depends on which network your node is connecting to.) Typically, you do not interact with tezos-node directly, and indeed, the script has few commands related to the node. Excerpt from ./babylonnet.sh --help: ./...


1

Can you open an issue on https://gitlab.com/tezos/tezos/issues/ ? And a few details such as : is your script up to date ? did you bootstrapped your node from nothing ? Or used a storage snashpot ? are you running your node in Full or Rolling (or don't know) mode ?


1

This problem was fixed here: https://gitlab.com/tezos/tezos/issues/531 .


1

You have to specify the data directory of your container using --data-dir argument: tezos-node snapshot export --block BMEH5XAWK4Z1Ds632VVyu9PjW2SKW27Mts4reL8fJCUQVFfgJu7 BMEH5XAWK4Z1Ds632VVyu9PjW2SKW27Mts4reL8fJCUQVFfgJu7.full --data-dir /var/run/tezos/node/data You can use docker inspect to find it, look for the Cmd entry in the output, e.g.: docker ...


1

I think you node hadn't sync with the alphanet full block yet. after start your docker or if you build from source that execute this bellow command ./tezos-node run --rpc-addr 127.0.0.1:8732 --connections 10 You need to wait until the block fully sync, to verify the block execute bellow command: ./tezos-client bootstrapped If you see the timestamp and ...


Only top voted, non community-wiki answers of a minimum length are eligible