root key location?

[ohmydata]

I am running the latest notary

notary
Version: 0.4
Git commit: 3a944e8

with docker 1.12.1 and my private registry.

When I try to push an image this is what I get:

docker push my-registry:5004/test/trusttest:trusted
The push refers to a repository [my-registry/test/trusttest]
5f70bf18a086: Layer already exists
c22f7bc058a9: Layer already exists
trusted: digest: sha256:ebf59c538accdf160ef435f1a19938ab8c0d6bd96aef8d4ddd1b379edf15a926 size: 734
Signing and pushing trust metadata
open /root/.docker/trust/private/root_keys/99a8715713015c4eb7c559d7d5ab2364f373de0c8fe31b27ce1687b128b77e06.key: no such file or directory

My "~/.notary/config.json" looks like this:

{
"trust_dir" : "~/.docker/trust",
"remote_server": {
"url": "https://notary-server:4443",
"root_ca": "/root/notary/root-ca.crt"
}
}

When I look at the keys using notary key list the keys are located in /root/.docker/trust/private and not in /root/.docker/trust/private/root_keys.

What is the expected behavior, where should the root keys be located?

Thanks.

[cyli]

@sbkumar007 Apologies, we have flattened the keystore (#549, #872) in master (the version should be bumped up to 0.5-dev (#983) for master, although that hasn't happened yet).

The released 0.4.x will still put them in /root/.docker/trust/private/root_keys, and 0.4.1-0.4.2 can read the keys in /root/.docker/trust/private. (see https://github.com/docker/notary/releases/tag/v0.4.2)

[ohmydata]

Thanks, checkout from commit tag - c8aa8cf - 0.4.2 seem to have fixed the problem. docker can read and push/pull image.

[endophage]

This seems to be resolved so I'm closing the issue. Feel free to re-open if I'm misunderstanding.

[cyli]

@sbkumar007 Thanks for letting us know that it worked! I've also updated the README file to reflect the fact that master is our development branch, as well as noted any upcoming changes in master in our CHANGELOG file: #991

[endophage]

FYI we do try and keep master stable and working, i.e. you should be able to make binaries && docker-compose up to get a working local client and server. We don't make any promises though that the master branch will always work against an older server deployed to production.

Our approach so far has been to try and ensure old clients work against new servers, but new clients aren't guaranteed to work against old servers.