cmd/juju/commands: InitJujuXDGDataHome should not create files
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Expired
|
Medium
|
Unassigned |
Bug Description
TL;DR: InitJujuXDGDataHome should not have side-effects.
The juju command, even if you just run it with --version, makes
the $HOME/.
generated SSH client key there if one does not already exist.
This means that if you happen to run juju without access rights
to that directory for some reason (for example because you've
run juju as root by accident), you cannot do anything - even find out the
current version. You see this error message instead:
$ juju --version
error: cannot load ssh client keys: mkdir /home/ubuntu/
For a start, this error message is not very helpful - "I'm just running juju --version,
why is it failing with this error?!"
In general, just running the juju binary should not have side-effects on the filesystem.
The juju client ssh key should be generated only when required, not
before command line flags have been parsed.
Changed in juju: | |
status: | New → Triaged |
importance: | Undecided → Medium |
milestone: | none → 2.0.1 |
Changed in juju: | |
milestone: | 2.0.1 → none |
juju version should also not be making network connections.
ubuntu@mojo:~$ juju version
Since Juju 2 is being run for the first time, downloading latest cloud information.
Fetching latest public cloud list...
Your list of public clouds is up to date, see `juju clouds`.
2.0.0-trusty-amd64
I originally saw this bug after running mojo using sudo (which is how it used to have to be done). Mojo modifies its behavior based on whether it is running Juju 1 or 2, as they are incompatible. So the first thing mojo does is use juju version to find what command lines it should use. It is likely that many third party tools will want to do this, they should be free to do so without potentially rendering juju unusable for the user.