TritonDataCenter/triton-cns

Existing zones not showing up in CNS after installation

Closed this issue · 5 comments

benjamin-bergia commented

After installing CNS, i followed the Internal-only corporate setup example and added an external NIC to my CNS instance and made it the default interface.

After doing this step, the forward zone get automatically updated and a new reverse zone is created for my network. When fetching all the records using dig axfr mydomain.com @localhost, all the records returned are zones from the headnode (SDC zones). None of the zones from my external network are available.

arekinath commented

Would you mind providing the output of:

root@headnode# sdc-sapi /services?name=cns | json -Ha metadata

for me? (Run this on the headnode, not inside any zone). Just want to check what your exact config looks like. Thanks!

benjamin-bergia commented 
# sdc-sapi /services?name=cns | json -Ha metadata
{
  "SERVICE_NAME": "cns",
  "SERVICE_DOMAIN": "cns.mydc.mydomain.com",
  "user-script": "#!/usr/bin/bash\n#\n# This Source Code Form is subject to the terms of the Mozilla Public\n# License, v. 2.0. If a copy of the MPL was not distributed with this\n# file, You can obtain one at http://mozilla.org/MPL/2.0/.\n#\n\n#\n# Copyright (c) 2014, Joyent, Inc.\n#\n\nexport PS4='[\\D{%FT%TZ}] ${BASH_SOURCE}:${LINENO}: ${FUNCNAME[0]:+${FUNCNAME[0]}(): }'\n\nset -o xtrace\nset -o errexit\nset -o pipefail\n\n#\n# The presence of the /var/svc/.ran-user-script file indicates that the\n# instance has already been setup (i.e. the instance has booted previously).\n#\n# Upon first boot, run the setup.sh script if present. On all boots including\n# the first one, run the configure.sh script if present.\n#\n\nSENTINEL=/var/svc/.ran-user-script\n\nDIR=/opt/smartdc/boot\n\nif [[ ! -e ${SENTINEL} ]]; then\n    if [[ -f ${DIR}/setup.sh ]]; then\n        ${DIR}/setup.sh 2>&1 | tee /var/svc/setup.log\n    fi\n\n    touch ${SENTINEL}\nfi\n\nif [[ ! -f ${DIR}/configure.sh ]]; then\n    echo \"Missing ${DIR}/configure.sh cannot configure.\"\n    exit 1\nfi\n\nexec ${DIR}/configure.sh\n",
  "sapi-url": "http://x.x.x.x",
  "use_login": true
}

# cnsadm config
my_name:         cns.mydc.mydomain.com
hostmaster:      hostmaster@mydomain.com
use_login:       true
use_alias:       true
allow_transfer:  127.0.0.1

# cnsadm status
ZONE                      LATEST SERIAL  CHANGED   
mydc.cns.mydomain.com           374477975      18 hrs ago
y.y.y.in-addr.arpa      374477975      18 hrs ago  <== This is the "external" network used by SDC zones
z.z.z.in-addr.arpa  374477975      18 hrs ago  <== This is the "external" network used by my zones

PEER       ZONE                  LATEST SERIAL  DRIFT  VERSION                       
127.0.0.1  mydc.cns.mydomain.com       374477975             Triton CNS 0.1.0, node v0.12.9
y.y.y.in-addr.arpa  374477975  <== SDC external network

Hope it helps.

Here is what I noticed: only the SDC zones that have a NIC on the external tag show up in the DNS zones. SDC zones that are only connected to internal are not registered in CNS and all the other zones, that are all on external, do not show up in CNS.

arekinath commented

Have you set the "triton_cns_enabled" flag on the accounts that own these zones? You can see in the output of sdc-useradm get <username or uuid> whether it's set or not. This flag has to be set before any records will be listed.

If it's set, can I get you to find the UUID of one zone that should be listed in CNS but currently isn't, and then look at the output of:

# cat $(svcs -L cns-updater) | grep $UUID | bunyan

(run this inside the CNS service zone). If you get no output from this, restart the cns-updater (using svcadm restart cns-updater) and try it again.

I'm looking for a log message that looks like:

[2016-07-07T01:19:59.478Z] DEBUG: cns/24595 on 859bd73b-9766-444b-ac8d-ea2f8209fea8: updating vm (stage=UpdateStream)
    info: {
      "vm": "51acbd8f-2705-4044-90eb-b490fe562a14",
      "why": [
        "user_en_flag"
      ],
      "l_s": false,
      "l_i": false,
      "svcs": [],
      "c": {},
      "o": "cf"
    }

In particular, the value of the "why" field here will explain why CNS refused to list this VM, which should get us closer to figuring out what's going on here.

benjamin-bergia commented

@arekinath Thank you very much. You saved my day.

I had no idea about triton_cns_enabled. I just ran sdc-useradm add-attr myUser triton_cns_enabled true and restarted the cns-updater.

All my zones are now listed.

I checked again and this part of the setup seems to be missing from the doc. I followed https://github.com/joyent/triton-cns/blob/master/docs/operator-guide.md

  • 🎉1
arekinath commented

Yeah, it's only mentioned in the user docs: https://docs.joyent.com/public-cloud/network/cns/usage . I'll update the operator guide to include at least a little note referring to it. Glad you got it sorted!

  • 👍1