domain port ignored

[Andrei-Pozolotin]

can not make host:port stanza to work with acpush:

tester/build.sh

#!/usr/bin/env bash
set -e
dir=$(dirname $0)
conf="$dir/conf"
cd $dir
build="acbuild --debug"
$build begin
trap "{ export CODE=$?; $build end && exit $CODE; }" EXIT
$build set-name tester
$build dep add quay.io/coreos/alpine-sh
$build write --overwrite tester.aci
acpush tester.aci tester.asc "aci-serv:3000/tester" \
    --debug \
    --insecure \
    --local-conf="$conf" \

tester/conf/auth.d/aci-serv.json

{
    "rktKind": "auth",
    "rktVersion": "v1",
    "domains": [ "aci-serv:3000" ],
    "type": "basic",
    "credentials": {
        "user": "default",
        "password": "default"
    }
}

build log

Beginning build with an empty ACI
Setting name of ACI to tester
Adding dependency "quay.io/coreos/alpine-sh"
Writing ACI to tester.aci
searching for push endpoint via meta discovery
meta tag 'ac-push-discovery' not found on aci-serv: Get http://aci-serv?ac-discovery=1: dial tcp 192.168.1.131:80: getsockopt: connection refused
err: Get http://aci-serv?ac-discovery=1: dial tcp 192.168.1.131:80: getsockopt: connection refused
Ending the build

[cgonyeo]

It looks like this is due to the appc discovery library parsing the : used for the port as a version specifier. In your example of pushing to aci-serv:3000/tester, acpush thinks that aci-serv is the host and the version label for your app is 3000/tester.

I'll see if I can put together a patch.

[cgonyeo]

It turns out that the : character isn't allowed in ACI image names. I modified the discovery library to parse the ports in an image correctly, and got this error back.

I've made an issue against the AppC spec for you: appc/spec#628.

[Andrei-Pozolotin]

reading through all of this can give one a confusion attack :-)

1. are you saying port is not allowed in
   host/port combination in a URL as specified by RFC 3986
   https://coreos.com/rkt/docs/latest/configuration.html#rktkind-auth ?

2. assuming acpush becomes rkt push, it would have to use
   /etc/rkt/auth.d configuration resources and conventions, right ?

3. then that would limit rkt to single auth entry per host, (ignore ports) ?

4. what is the proper way to map 1-to-1 from image URI to host URL in the appc/spec?

[cgonyeo]

1. For better or worse, image names are not URLs (despite being very similar). AppC programs (like rkt, acbuild, etc.) will go through a discovery process to convert a given image name into a URL. A short example of how this works, given quay.io/coreos/alpine-sh, is that the client will make a GET request against https://quay.io/coreos/alpine-sh and look for specific meta html tags to specify a URL for it. If it doesn't find such tags, then it'll go up the URL by next attempting https://quay.io/coreos and finally https://quay.io. Due to image names not being quite URLs, they don't allow things like ports and do allow things like labels (e.g. example.com/myapp,env=canary). There is currently an open PR against the AppC spec to allow it to do discovery over arbitrary ports, once this gets merged I can add a flag to acpush for what port to perform discovery over, so the command here would be acpush tester.aci tester.asc "aci-serv/tester --port 3000". Unfortunately this PR hasn't been touched in some time, so I'll poke at it again to see if I can get some more momentum there.

2. Yup. If not, it'll need some other way to configure auth.

3. I suppose so, yeah. I think it doesn't take ports today because no one has requested support for it.

4. Via the discovery process I mentioned in (1) (here's the link again). To see this in action:

Note that I rkt fetch from coreos.com, yet rkt pulls the image from a github URL.

derek@proton ~> sudo rkt fetch coreos.com/etcd:v2.3.7
image: searching for app image coreos.com/etcd
image: remote fetching from URL "https://github.com/coreos/etcd/releases/download/v2.3.7/etcd-v2.3.7-linux-amd64.aci"
image: keys already exist for prefix "coreos.com/etcd", not fetching again
image: downloading signature from https://github.com/coreos/etcd/releases/download/v2.3.7/etcd-v2.3.7-linux-amd64.aci.asc
Downloading signature: [=======================================] 490 B/490 B
Downloading ACI: [=============================================] 8.52 MB/8.52 MB
image: signature verified:
  CoreOS Application Signing Key <[email protected]>
sha512-7d28419b27d5ae56cca97f4c6ccdd309

Now if I curl | grep the coreos website to look for those meta tags...

derek@proton ~> curl -s -L coreos.com | grep ac-discovery
  <meta name="ac-discovery" content="coreos.com/rkt/stage1-coreos https://github.com/coreos/rkt/releases/download/v{version}/stage1-coreos-{version}-{os}-{arch}.{ext}">
  <meta name="ac-discovery-pubkeys" content="coreos.com/rkt/stage1-coreos https://coreos.com/dist/pubkeys/app-signing-pubkey.gpg">
  <meta name="ac-discovery" content="coreos.com/rkt/stage1-fly https://github.com/coreos/rkt/releases/download/v{version}/stage1-fly-{version}-{os}-{arch}.{ext}">
  <meta name="ac-discovery-pubkeys" content="coreos.com/rkt/stage1-fly https://coreos.com/dist/pubkeys/app-signing-pubkey.gpg">
  <meta name="ac-discovery" content="coreos.com/rkt/stage1-kvm https://github.com/coreos/rkt/releases/download/v{version}/stage1-kvm-{version}-{os}-{arch}.{ext}">
  <meta name="ac-discovery-pubkeys" content="coreos.com/rkt/stage1-kvm https://coreos.com/dist/pubkeys/app-signing-pubkey.gpg">
* <meta name="ac-discovery" content="coreos.com/etcd https://github.com/coreos/etcd/releases/download/{version}/etcd-{version}-{os}-{arch}.{ext}">
  <meta name="ac-discovery-pubkeys" content="coreos.com/etcd https://coreos.com/dist/pubkeys/aci-pubkeys.gpg">
  <meta name="ac-discovery-pubkeys" content="coreos.com/etcd https://coreos.com/dist/pubkeys/app-signing-pubkey.gpg">
  <meta name="ac-discovery" content="coreos.com/bootcfg https://github.com/coreos/coreos-baremetal/releases/download/{version}/bootcfg-{version}-{os}-{arch}.{ext}">
  <meta name="ac-discovery-pubkeys" content="coreos.com/bootcfg https://coreos.com/dist/pubkeys/app-signing-pubkey.gpg">
  <meta name="ac-discovery" content="coreos.com/dnsmasq https://github.com/coreos/coreos-baremetal/releases/download/{version}/dnsmasq-{version}-{os}-{arch}.{ext}">
  <meta name="ac-discovery-pubkeys" content="coreos.com/dnsmasq https://coreos.com/dist/pubkeys/app-signing-pubkey.gpg">

The line that I starred is the one that AppC clients find when looking for coreos.com/etcd.

[Andrei-Pozolotin]

got it, thank you for clarification. the confusion came from disbelief that rkt would have to drop existing documented configuration feature. your write up above is good and probably should be part of some how discovery works in practice page

[jonboulle]

👍