Merge branch 'master' into db-log (again) #1857

Merged
merged 98 commits into from Mar 17, 2015

Conversation

Projects
None yet
10 participants
Contributor

mjs commented Mar 17, 2015

To deal with conflicts with master.

(Review request: http://reviews.vapour.ws/r/1183/)

anastasiamac and others added some commits Feb 17, 2015

Merge remote-tracking branch 'origin/cmd-storage' into cmd-storage
Conflicts:
	apiserver/storage/storage_test.go
	featuretests/storage_test.go
Merge remote-tracking branch 'origin/cmd-storage' into cmd-storage
Conflicts:
	state/storage.go
	state/storage_test.go
State: Environment.Users()
Add a Users() method on state.Evironment which lists all the users for
that environment. Fix a bug in factory.MakeEnvUser which made it
create two envUsers instead of one.
APISERVER: new EnvUserInfo method
- Add apiserver.client.EnvUserInfo() which returns information on all
users for the environment.

- Move environment related params to params/envionment.go

- Make state.AddEnvironmentUser take a displayName so that it can be set
for a remote user (envUsers with a local counterpart just inherit
their displayName).

- Improve/tidy up comments and fix bugs with envUser.DisplayName() and
envUser.LastConnection()
CMD: Environment Share
Add Environment Share sub-command and corresponding tests, including
feature test ensuring CMD > API > APIServer > State is hooked up.
Allow adding a user to an environ twice, logging the APIServer error
that a user already exists as a warning. Change feature flag
feature.MESS to feature.JES.

(Review request: http://reviews.vapour.ws/r/1014/)
Merge branch 'jes-cli' of https://github.com/juju/juju into cli-share…
…-environment

Conflicts:
	cmd/juju/environment/environment.go
	cmd/juju/environment/export_test.go
CMD: environment unshare
Add "juju environment unshare" sub-command and corresponding tests in
cmd, api and featuretests. When unshare is called on a user that has
not been added to an environment, the APIServer errors but the CLI
only logs a warning - as the desired outcome has still been reached:
the user does not have access to the environment.

(Review request: http://reviews.vapour.ws/r/1037/)
Merge branch 'master' into cmd-storage
Conflicts:
	state/storage_test.go
Merge branch 'cmd-storage' of https://github.com/anastasiamac/juju in…
…to cmd-storage

Conflicts:
	state/storage_test.go
API: New api.client.EnvironmentUserInfo
Add a new method on the API client: EnvironmentUserInfo(). Test the
facade call. Add an end to end feature test to make sure API >
APISERVER > State are hooked up.
Merge pull request #1774 from waigani/api-environ-users
API: New api.client.EnvironmentUserInfo
Change lxc storage config so that we ony enable mounting loop devices…
… if the container is required to do so according to the volumes specified at creation time
Merge branch 'master' into cmd-storage
Conflicts:
	apiserver/params/storage.go
Merge branch 'cmd-storage' of https://github.com/anastasiamac/juju in…
…to cmd-storage

Conflicts:
	apiserver/params/storage.go
Merge branch 'master' into cmd-storage
Conflicts:
	apiserver/params/storage.go
Merge branch 'cmd-storage' of https://github.com/anastasiamac/juju in…
…to cmd-storage

Conflicts:
	apiserver/params/storage.go
state: copy Pool from params to info on SetXInfo
Set{Volume,Filesystem}Info will now copy the Pool
from Params to Info the first time it's called for
a volume/filesystem.
Merge pull request #1611 from anastasiamac/cmd-storage
Storage list and show commands stack.

This PR has:
    * updates to storage show command as well as supporting api client;
    * new storage list command as well as supporting api client and state implementations.




(Review request: http://reviews.vapour.ws/r/941/)
api: extract connection logic out of Open
The code that establishes a websocket connection to one of the API
servers as been extracted out of Open into a separate Connect
func. Most of the tests for Open were actually exercising this part of
Open so they have been adjusted to match.

This will soon be used by the database logging worker.
Merge pull request #1846 from ericsnowcurrently/fix-1432421-discover-…
…shell-select

Use a better approach to shell-based discovery of the init system.

(fixes https://bugs.launchpad.net/juju-core/+bug/1432421)

The existing approach simply hard-coded a mapping of PID 1 executable to init system.  However, this doesn't work when PID 1 is running via a symlink (e.g. /sbin/init).  This patch addresses that by using a separate script based on the discovery mechanism in discoverLocalInitSystem.

(Review request: http://reviews.vapour.ws/r/1173/)
Merge pull request #1853 from mjs/api-open-refactor
Refactoring of api.Open()

The code that establishes a websocket connection to one of the API servers as been extracted out of Open into a separate Connect func. Most of the tests for Open were actually exercising this part of
the function so they have been adjusted to match. Connect will soon be used by the database logging worker.

Also: use the errors package more

Also: Rearrange and document API connection logic to make it easier to follow

(Review request: http://reviews.vapour.ws/r/1179/)
Testing: fix failing test
Make TestMakeEnvUserParams pass by setting the envUser's DisplayName.
Merge pull request #1826 from wallyworld/lxc-loop-mount
Update lxc config to allow mounting loop devices

We use the "lxc-container-default-with-mounting" appamor profile to allow loop devices to be mounted.

(Review request: http://reviews.vapour.ws/r/1154/)
Merge pull request #1850 from axw/storageprovisioner-api-attachments
storageprovisioner: attachments in API

This branch adds support for handling attachments
in the storageprovisioner API. Mostly, only volumes
are supported at the moment. These changes will
enable the storage provisioner worker to watch
attachments and attach/detach volumes/machines.

(Review request: http://reviews.vapour.ws/r/1176/)
Merge pull request #1854 from juju/jes-cli
Merge approved JES-CLI work from feature branch.



(Review request: http://reviews.vapour.ws/r/1180/)

howbazaar added a commit that referenced this pull request Mar 17, 2015

Merge pull request #1857 from mjs/db-log-merge.2
Merge branch 'master' into db-log (again)

@howbazaar howbazaar merged commit 53a15e8 into juju:db-log Mar 17, 2015

@mjs mjs deleted the mjs:db-log-merge.2 branch Mar 18, 2015

Contributor

xnox commented on service/discovery.go in 2ae93fe Mar 31, 2015

I cringe reading this =)

[ -d /run/systemd/systemd ] -> system is running PID 1 as systemd. You can check that in go code natively, without forking out to a shell.

check that system is running upstart can be done with

  • "initctl version"
  • or check that unix:abstract=/com/ubuntu/upstart socket exists
  • or as a private DBus socket call to Version api over unix:abstract=/com/ubuntu/upstart

This is also wrong -- /sbin/init is different depending on whether you have systemd-sysv or upstart-sysv installed, so checking /proc/cmdline for /sbin/init doesn't tell you anything. Checking for /run/systemd/system is the correct, reliable, and fast thing to do here indeed.

Contributor

ericsnowcurrently replied Mar 31, 2015

@xnox As noted in my last comment, we have to be able to run this on arbitrary remote systems, both via ssh and a cloud-init script. So using a bash script was our best option. We also needed to be confident about the running init system, which is what checking PID 1 accomplishes perfectly.

@martinpitt We no longer assume /sbin/init implies upstart.

You can run ssh remote.server test -d /run/systemd/system through ssh just fine, though.

Contributor

xnox commented on service/service.go in 2ae93fe Mar 31, 2015

This is a security vulnerability, no? symlink race.

Contributor

ericsnowcurrently replied Mar 31, 2015

If it's a security issue then we should fix it. Could you elaborate? What would you suggest to fix it?

It's a predictable file name in a world-writable directory. So any user can destroy any file in the system (also from other users, or from root) by e. g. ln -s /etc/shadow /tmp/discover_init_system.sh and then wait for juju to run. (google for /tmp overwrite race, there have been plenty of CVEs in the past). So if you create/call a shell script, please use mktemp.

But I'm still convinced that this is overkill. You can check what's running on a remote system with a single shell command (testing for /run/systemd/system and/or for initctl --system list).

Contributor

ericsnowcurrently replied Mar 31, 2015

Thanks for the explanation. I'll open a bug for this.

Contributor

xnox commented on 2ae93fe Mar 31, 2015

Please drop all of this crazy shell scripts forking with simply:

if _, err := os.Stat("/run/systemd/system"); err == nil {
    // pid 1 is systemd
} else {
    // pid 1 is upstart
}
Contributor

ericsnowcurrently replied Mar 31, 2015

While that works for the local host, for interacting with remote hosts it isn't an option. We went with a bash script in that case for the confidence that it will work effectively universally. If you know of a better approach that can be used over ssh on arbitrary hosts (as well as in a cloud-init script) then please let us know.

As to the commands for deciding the init system, we went with using the executable running in PID 1 because the approach gives better information in the case that we don't recognize the init system. Furthermore, the only way to be absolutely sure about the running init system is by checking PID 1. Beyond that, we wanted to bake into juju as little knowledge of each init system as possible. The directory that the init system uses is an example of that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment