tritondatacenter / sdc-vmtools-lx-brand Goto Github PK

Most distributions we support come with bash as the default shell except for Alpine Linux. For the Alpine image we need to install bash in the image so the guest tools function. If we updated the shebang in all the scripts to use /native/usr/bin/bash we would no longer need to have bash installed as a dependency. So for instance if someone were to remove the bash package from an Alpine lx-brand instance, the guest tools scripts would be fine.

This will need some testing but offhand I don't see it causing any issues with the guest tools scripts.

The "resolvers" metadata does not get passed to an lx-brand container and /etc/resolv.conf always defaults to the google name servers.

The guest tools should be updated to retrieve that metadata and configure the container.

SmartOS instances use SmartLogin which is a plugin to ssh that allows a dynamic lookup of ssh keys. This allows for dynamic ssh key updating when ssh keys are added or removed via CloudAPI.

Newer versions of sshd have an AuthorizedKeysCommand option (man sshd_config) that "specifies a program to be used to look up the user's public keys." It looks like this could duplicate the SmartLogin functionality on lx-brand where there is a new enough version of sshd available.

Reference: http://manpages.ubuntu.com/manpages/zesty/man5/sshd_config.5.html

We would also need to set AuthorizedKeysCommandUser, preferably to the nobody user or a user with limited access (nologin) for running the script.

Interestingly, various tokens are available that can be passed to the AuthorizedKeysCommand command, such as %u for the username being authenticated. Currently the user would only ever be root (with the keys stored as the root_authorized_keys meta data value.

http://manpages.ubuntu.com/manpages/zesty/man5/sshd_config.5.html#contenttoc4 (see TOKENS)

In the future this could be used to authenticate different users instead of just root.

. ./lib/smartdc/common.lib will only succeed if the calling process is run from /

should either be . /lib/smartdc/common.lib or determine the lib folder path prior to the import like

. $(cd $(dirname $0) && pwd)/common.lib

or

. $(realpath $(dirname $0))/common.lib

realpath seems to be available in the busybox sh as well.

Line 73 in mdata-fetch tests whether /root/.ssh/authorized_keys exists. If the file doesn't exist, the root_authorized_keys metadata is fetched and placed into /root/.ssh/authorized_keys.new.

This means that when the machine metadata is updated, the authorized_keys file will not get updated -- since it already exists. The documentation for the Metadata API (https://docs.joyent.com/sdc6/api-documentation/using-the-metadata-api) indicates, however, that the authorized_keys file should be updated on reboot.

The script after line 73 indicates that there was consideration for updating the authorized_keys or removing them, depending on what was retrieved from the metadata store. I would expect the behavior should be consistent with the Metadata API documentation and the intent of the logic after line 73. I suggest re-evaluating whether line 73 should test for /root/.ssh/authorized_keys alone.

Utilizing Debian container image 1adf7176-8679-11e5-9ff7-3beedf8060b9, generated dated 20151109.

On native zones tail -f svcs -L mdata:execute`` get you the output of the user script.
There is no way (that I know of) to get the output in LX zones. It would be nice that it ends up in triton.log

Re-opened here as per @chorrell

Passing a metadata "hostname" value does not set the hostname for an lx-brand container.

The guest tools should retrieve that value, if available, and set it accordingly in the container

"/lib/smartdc/common.lib" has this:

LOG='/var/log/triton.log'
touch $LOG
exec 4<> $LOG
export PS4='[\D{%FT%TZ}] ${BASH_SOURCE}:${LINENO}: ${FUNCNAME[0]:+${FUNCNAME[0]}(): }'
export BASH_XTRACEFD=4
set -o xtrace

Most of the boot scripts in /lib/smartdc are sourcing common.lib. That's resulting in multiple processes overwriting triton.log such that content is lost. Here is an example showing messed up results: https://gist.github.com/trentm/6702d5d81a5d3816ba5ee9062546ee07

The suggestions from discussion were to do one of:

1. do the redirect to "triton.log" in joyent_rc.local instead of in common.lib; or
2. update to exec 4<>> $LOG to append

According to the vmadm man page:

dns_domain:

    For OS VMs this specifies the domain value for /etc/hosts that gets set
    at create time. Updating this after create will have no effect.

    type: string (domain name)
    vmtype: OS
    listable: yes
    create: yes
    update: no
    default: local

Looking at the zoneinit code, it's not immediately obvious which file is being modified though with the dns_domain value. The man page says /etc/hosts, but you'd think this is something that would be in /etc/resolv.conf?

https://github.com/joyent/zoneinit/blob/master/includes/11-files.sh

It looks like any file in /etc and /opt/local/etc with a @DOMAINNAME@ value will get the dns_domain value. I can't figure out what files are relevant.

Regardless, we should probably do the expected thing for lx-brand and modify resolv.conf. I will get some clarification on what the expected behaviour is.

Hi,

Sorry if this is the wrong repo but it's not clear to me, from searching, where would be and this seemed like a good place to start to be redirected to the correct place.

I've been trying to run Concourse on Triton and hit an issue where there is no uid_map (and probably gid_map) files in /proc. I understand on Triton that this isn't ever going to be a thing. However, I do wonder whether there should be some stub code for them?

panic: open /proc/self/uid_map: no such file or directory

goroutine 1 [running]:
panic(0xd24700, 0xc4201d78c0)
        /usr/local/go/src/runtime/panic.go:500 +0x1a1
code.cloudfoundry.org/guardian/sysinfo.must(0x0, 0xf22f700, 0xc4201d78c0, 0xf22f700)
        /tmp/build/9674af12/garden-runc-release/src/code.cloudfoundry.org/guardian/sysinfo/max_valid_uid.go:69 +0x66
code.cloudfoundry.org/guardian/sysinfo.MustGetMaxValidUID(0xd39e00)
        /tmp/build/9674af12/garden-runc-release/src/code.cloudfoundry.org/guardian/sysinfo/max_valid_uid.go:15 +0x58
code.cloudfoundry.org/guardian/guardiancmd.init.1()
        /tmp/build/9674af12/garden-runc-release/src/code.cloudfoundry.org/guardian/guardiancmd/command.go:225 +0x37
code.cloudfoundry.org/guardian/guardiancmd.init()
        /tmp/build/9674af12/garden-runc-release/src/code.cloudfoundry.org/guardian/guardiancmd/seccomp.go:1598 +0x349
main.init()
        /tmp/build/9674af12/gopath/src/github.com/concourse/bin/cmd/concourse/worker_unix.go:24 +0xdf