Merge ~chad.smith/cloud-init:dhclient-from-var-tmp into cloud-init:master
| Status: | Merged |
|---|---|
| Approved by: | Scott Moser on 2017-09-19 |
| Approved revision: | 8aac9a7f85c0f20064ffd3b6374de1230ec0f42b |
| Merged at revision: | 7eb3460b0d6d3e362a246958a7ea0a9ee5d91d5e |
| Proposed branch: | ~chad.smith/cloud-init:dhclient-from-var-tmp |
| Merge into: | cloud-init:master |
| Diff against target: |
249 lines (+132/-16) 5 files modified
cloudinit/net/dhcp.py (+3/-2) cloudinit/net/tests/test_dhcp.py (+12/-6) cloudinit/temp_utils.py (+15/-7) cloudinit/tests/test_temp_utils.py (+101/-0) cloudinit/util.py (+1/-1) |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Scott Moser | 2017-09-16 | Approve on 2017-09-19 | |
| Server Team CI bot | continuous-integration | Approve on 2017-09-18 | |
| Dimitri John Ledkov (community) | 2017-09-16 | Needs Information on 2017-09-16 | |
|
Review via email:
|
|||
Description of the Change
ec2: Fix maybe_perform_
/run/cloud-init/tmp is on a filesystem mounted noexec, so running
dchlient in Ec2Local during discovery breaks with 'Permission denied'.
This branch allows us to run from a different tmp dir so we have exec
rights.
LP: #1717627
| Scott Moser (smoser) wrote : | # |
PASSED: Continuous integration, rev:356586cb4e1
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/
| Chad Smith (chad.smith) wrote : | # |
Test ran this on ass instances and cloud-init properly found Ec2Local datasource with no traceback.
| Dimitri John Ledkov (xnox) wrote : | # |
Reading the bug report, and this merge proposal, I am slightly concerned and would want to more information.
Ec2Local datasource is called "local" yet it clearly brings network up. Can you explain a bit how it works? Does it discover something else behind dhcp and chain loads something else? Instead of dhclient can it generate "dhcp first interface" netplan config and use that to bring networking up? Note that default dhcp client in artful and up is simply systemd-networkd internal implementation. It would be interesting to see if cloud-init can switch to that away from dhclient.
The security issue concerns me a lot of how dhclient is run. It seems like you are hitting default ubuntu security policy and trying to circumvent that. In particular, why can you not run /sbin/dhclient from where it is, and use /run/ configs / auxiliary files for it? Do we need to bring in security team to assist in operating dhclient safely and in a simple manner? Imho executing /sbin/dhclient as root, and pointing it to use state files in /run is still architecturally right solution, even if we need to change apparmor policy etc. If need be, we can even ship a custom systemd dhclient-
- a3a33b4... by Chad Smith on 2017-09-18
FAILED: Continuous integration, rev:a3a33b43c3c
https:/
Executed test runs:
SUCCESS: Checkout
FAILED: Unit & Style Tests
Click here to trigger a rebuild:
https:/
- 78674e9... by Chad Smith on 2017-09-18
| Chad Smith (chad.smith) wrote : | # |
Tested on AWS with success using needs_exe param:
2017-09-18 21:45:19,929 - util.py[DEBUG]: Copying /sbin/dhclient to /var/tmp/
2017-09-18 21:45:20,240 - handlers.py[DEBUG]: finish: init-local/
FAILED: Continuous integration, rev:78674e9c8c5
https:/
Executed test runs:
SUCCESS: Checkout
FAILED: Unit & Style Tests
Click here to trigger a rebuild:
https:/
- 8aac9a7... by Chad Smith on 2017-09-18
PASSED: Continuous integration, rev:8aac9a7f85c
https:/
Executed test runs:
SUCCESS: Checkout
SUCCESS: Unit & Style Tests
SUCCESS: Ubuntu LTS: Build
SUCCESS: Ubuntu LTS: Integration
SUCCESS: MAAS Compatability Testing
IN_PROGRESS: Declarative: Post Actions
Click here to trigger a rebuild:
https:/


Requesting Dimitri's' review as he helped us with bug 1707222