Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Merge branch 'master' into db-log (again) #1857
Conversation
anastasiamac
and others
added some commits
Feb 17, 2015
added a commit
that referenced
this pull request
Mar 17, 2015
howbazaar
merged commit 53a15e8
into
juju:db-log
Mar 17, 2015
mjs
deleted the
mjs:db-log-merge.2
branch
Mar 18, 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
|
martinpitt
replied
Mar 31, 2015
|
This is also wrong -- |
|
@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. |
martinpitt
replied
Mar 31, 2015
|
You can run |
|
This is a security vulnerability, no? symlink race. |
|
If it's a security issue then we should fix it. Could you elaborate? What would you suggest to fix it? |
martinpitt
replied
Mar 31, 2015
|
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. 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 |
|
Thanks for the explanation. I'll open a bug for this. |
|
Please drop all of this crazy shell scripts forking with simply:
|
|
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. |
mjs commentedMar 17, 2015
To deal with conflicts with master.
(Review request: http://reviews.vapour.ws/r/1183/)