Update tests to run commands on LXD as non root by lucasmoura · Pull Request #694 · canonical/cloud-init

lucasmoura · 2020-11-25T16:12:16Z

For us to support running commands through LXD as non-root, as described in this PR, we need to update some our integration tests for this new scenario

blackboxsw · 2020-11-26T00:00:47Z

-        assert (
-            "XAAAAAtzc2gtZWQyNTUxOQAAACDbnQGUruL42aVVsyHeaV5mYNT"
-            "OhteXao0Nl5DVThJ2+Q") in out
+    @pytest.mark.parametrize(


nice parametrize use here

blackboxsw · 2020-11-26T02:57:03Z

    def test_ssh_authkey_fingerprints_disable(self, client):
-        cloudinit_output = client.read_from_file("/var/log/cloud-init.log")
+        cloudinit_output = client.read_from_file(
+            "/var/log/cloud-init.log", use_sudo=True


You don't need use_sudo here, /var/log/cloud-init.log is world readable

blackboxsw

Looks pretty good Lucas. I think we determined a couple PRs ago through @TheRealFalcon branch that integration tests will work toward a common non-root/ssh only approach to all clouds at the moment for simplicity. If we need to specfically grow/tailor an LXD exec root-only approach to driving all cloud platforms, then we can grow that in pycloudlib and reflect some of those changes into cloud-init integration tests in the future. I'll leave you to review and discuss a couple of the comments (no need for use_sudo in a couple places) and will check back on this.

blackboxsw · 2020-11-26T03:11:42Z

+        )
+    )
+    def test_ssh_provided_info(self, config_path, expected_out, class_client):
+        out = class_client.read_from_file(config_path, use_sudo=True).strip()


I also don't think use_sudo=True is needed here either.

Suggested change

out = class_client.read_from_file(config_path, use_sudo=True).strip()

out = class_client.read_from_file(config_path).strip()

I think we do need the use_sudo for some of these operations. Running it without we get errors like:

cat: /etc/ssh/ssh_host_ed25519_key: Permission denied cat: /etc/ssh/ssh_host_ed25519_key.pub: Permission denied cat: /etc/ssh/ssh_host_ecdsa_key: Permission denied

But I do agree that the sshd file can be read without sudo. I think for it, I can remove it from the parametrize matrix

blackboxsw · 2020-11-26T04:08:00Z

+        sshd_config = class_client.read_from_file(
+            "/etc/ssh/sshd_config", use_sudo=True
+        )


no need for use_sudo here: ls -l /etc/ssh/sshd_config world readable -rw-r--r--

Suggested change

sshd_config = class_client.read_from_file(

"/etc/ssh/sshd_config", use_sudo=True

)

sshd_config = class_client.read_from_file("/etc/ssh/sshd_config")

blackboxsw · 2020-11-26T04:14:39Z

-            '{sudo} apt-get update -q && '
-            '{sudo} apt-get install -qy cloud-init'
-        ).format(sudo='sudo' if self.use_sudo else '', repo=repo)
+            'sudo add-apt-repository {repo} -y && '


Yes I think this should always be sudo for this operation, the only subclass of IntegrationInstance which sets use_sudo = False is Lxd, if we are saying for this iteration that we want to keep all cloud platforms using non-root user for most commands, then I'd say this is a hardcode "sudo" command. I'd also say the same with the related install_deb and install_proposed_image. I'll let you guys chat about this tomorrow. But, wouldn't this branch be the point where we drop the self.use_sudo stuff from all clouds, and just assume yes on all clouds?

I think you are right here. My assumption was that some commands would not need to use sudo by default and we should avoid that. However, the other clouds do not follow this pattern. I think it is better to drop use_sudo as mentioned.

I will update the code

OddBloke

Thanks for this Lucas! I have a few inline comments; the most important is the first in test_set_password.py.

OddBloke · 2020-11-26T16:48:53Z

    elif integration_settings.CLOUD_INIT_SOURCE.startswith('ppa:'):
        client = session_cloud.launch()
-        client.install_ppa(integration_settings.CLOUD_INIT_SOURCE)
+        client.install_ppa(


There are a few places where we aren't changing code but are making it take up more space (I think from a previous iteration of this proposal?). Can we clean these up?

OddBloke · 2020-11-26T16:51:53Z

        if use_sudo is None:
-            use_sudo = self.use_sudo
+            use_sudo = True


I believe this if clause is only present because the default was dependent on the cloud previously. Now that the default is True everywhere, I think we can just have it in the method signature.

OddBloke · 2020-11-26T16:55:55Z


-    def read_from_file(self, remote_path) -> str:
-        result = self.execute('cat {}'.format(remote_path))
+    def read_from_file(self, remote_path, use_sudo=None) -> str:


Nothing passes use_sudo to read_from_file, so I think we can drop this change until we need it.

OddBloke · 2020-11-26T16:57:26Z

+        remote_script = 'dpkg -i {path}'.format(
+            path=remote_path)


Suggested change

remote_script = 'dpkg -i {path}'.format(

path=remote_path)

remote_script = 'dpkg -i {}'.format(remote_path)

OddBloke · 2020-11-26T17:22:55Z

  - name: tom
    # md5 gotomgo
    passwd: "$1$S7$tT1BEDIYrczeryDQJfdPe0"
+    sudo: ALL=(ALL) NOPASSWD:ALL


I think this actually revealing a bug in the planned implementation: we assume that the default user (with passwordless sudo) will be created as UID 1000. With this user-data, though, tom is UID 1000. To maintain the interface with other platforms (we access the instance as ubuntu and use sudo to gain UID 0), I think pycloudlib will need to look up the UID of self.username before executing commands.

(As an aside: examining the cc_users_groups code, there is no particular guarantee as to what order users will be created in: it depends on dict iteration behaviour. This behaviour is not guaranteed to be order of insertion before Python 3.7 (and isn't order of insertion before CPython 3.6). So we're likely to find that tom will not be UID 1000 some of the time on xenial. On 3.6+, as we remove the default user and re-add it, I believe the default user is guaranteed to be the last user created.)

Yeah, I honestly thought about that issue, but I assumed that we would always have a non-root user as 1000 to use. But you are totally correct that this assumption is not good and that we should be consistent on using only the ubuntu user to run the commands across different instance types. I will update the pycloudlib code to address that

OddBloke · 2020-11-26T17:23:15Z

-        out = class_client.execute(
-            "test -e {}".format(ssh_key_path)
-        )
+        out = class_client.execute("test -e {}".format(ssh_key_path))


As this is removing needless lines, let's keep this one.

lucasmoura · 2020-11-26T19:50:08Z

@OddBloke Code Update. I have also update the pycloudlib LXD PR to address the issue we had regarding the user id

pycloudlib will stop running commands as root by default on LXD. To align with that change and make the behavior consistent with other clouds we support, our LXD instances will now run the commands with sudo by default.

OddBloke

Thanks for all the iteration!

Chad is OOO and the proposal has changed substantially since he reviewed it

lucasmoura force-pushed the update-test-for-non-root-lxd branch from efb84ce to dda0743 Compare November 25, 2020 16:32

blackboxsw reviewed Nov 25, 2020

View reviewed changes

Comment thread tests/integration_tests/instances.py Outdated

lucasmoura requested a review from blackboxsw November 25, 2020 18:17

lucasmoura force-pushed the update-test-for-non-root-lxd branch 2 times, most recently from 4474fd5 to 7e80caf Compare November 25, 2020 21:19

blackboxsw reviewed Nov 26, 2020

View reviewed changes

blackboxsw previously requested changes Nov 26, 2020

View reviewed changes

lucasmoura force-pushed the update-test-for-non-root-lxd branch 2 times, most recently from 178acac to 67217c4 Compare November 26, 2020 14:32

lucasmoura requested a review from blackboxsw November 26, 2020 14:59

OddBloke suggested changes Nov 26, 2020

View reviewed changes

lucasmoura force-pushed the update-test-for-non-root-lxd branch from 67217c4 to 2943156 Compare November 26, 2020 19:26

lucasmoura force-pushed the update-test-for-non-root-lxd branch 2 times, most recently from 3b7f30b to 6d902ff Compare November 26, 2020 21:27

Drop use_sudo attribute on IntegrationInstance

1712c82

pycloudlib will stop running commands as root by default on LXD. To align with that change and make the behavior consistent with other clouds we support, our LXD instances will now run the commands with sudo by default.

lucasmoura force-pushed the update-test-for-non-root-lxd branch from 6d902ff to 1712c82 Compare November 26, 2020 21:43

OddBloke approved these changes Nov 26, 2020

View reviewed changes

OddBloke merged commit 53f2bfb into canonical:master Nov 26, 2020

This was referenced May 12, 2023

Release 21.1 #3846

Closed

Randomly set credentials written in cleartext to world-readable file #3854

Closed

	out = class_client.read_from_file(config_path, use_sudo=True).strip()
	out = class_client.read_from_file(config_path).strip()

	remote_script = 'dpkg -i {path}'.format(
	path=remote_path)
	remote_script = 'dpkg -i {}'.format(remote_path)

Conversation

lucasmoura commented Nov 25, 2020

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

blackboxsw Nov 26, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

blackboxsw left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

OddBloke left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lucasmoura commented Nov 26, 2020

Uh oh!

OddBloke left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

blackboxsw Nov 26, 2020 •

edited

Loading