kdevops.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Frederick Lawler <fred@cloudflare.com>
To: mcgrof@kernel.org
Cc: kdevops@lists.linux.dev, kernel-team@cloudflare.com,
	Frederick Lawler <fred@cloudflare.com>
Subject: [RFC PATCH] fstests: Request inferred user
Date: Wed, 30 Aug 2023 18:53:33 -0500	[thread overview]
Message-ID: <20230830235333.1658555-1-fred@cloudflare.com> (raw)

Currently when running make fstests for bare-metal setups, the data_user
'vagrant' is set for the /data partition. This is currently set as the default
data_user. We have the option to edit this in extra_vars.yml.

make linux checks for an inferred user prior to setting the uid/gid for
the /data partition.

In the situation where we don't add the 'vagrant' user to the
bare-metal, we get a "user does not exist" on make fstests.

In both cases we do not want to switch users between the two targets,
nor do we want to necessarily ensure that the 'vagrant' user exists on
the metal. Therefore, request the inferred user on make fstests.

Signed-off-by: Frederick Lawler <fred@cloudflare.com>
Since this is essentially in two places, I figure this should be more
generic and then included in other make targets like cxl. But this is to
get the discussion going if this or some other generic approach is
 playbooks/roles/fstests/tasks/main.yml | 37 ++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/playbooks/roles/fstests/tasks/main.yml b/playbooks/roles/fstests/tasks/main.yml
index e2d7ce5295b7..2898833b0732 100644
--- a/playbooks/roles/fstests/tasks/main.yml
+++ b/playbooks/roles/fstests/tasks/main.yml
@@ -10,6 +10,43 @@
       skip: true
   tags: vars
+- name: Get username we are using
+  command:
+    cmd: whoami
+  register: username_on_target
+  when:
+    - infer_uid_and_group|bool
+- name: Set target user as a fact
+  set_fact:
+    target_user: "{{ username_on_target.stdout }}"
+  when:
+    - infer_uid_and_group|bool
+- name: Run getent against the inferred target user
+  getent:
+    database: passwd
+    key: "{{ target_user }}"
+  register: getent_running_user
+  when:
+    - infer_uid_and_group|bool
+- name: Run getent against the inferred target group
+  getent:
+    database: group
+    key: "{{ target_user }}"
+  register: getent_on_group
+  when:
+    - infer_uid_and_group|bool
+- name: Override user and group with inferred settings if feature is enabled
+  set_fact:
+    user: "hplip"
+    data_user: "{{ target_user }}"
+    data_group: "{{ ((getent_on_group.values() | first).values() | first).keys() | first }}"
+  when:
+    - infer_uid_and_group|bool
 - include_role:
     name: create_data_partition
   tags: [ 'oscheck', 'data_partition' ]

             reply	other threads:[~2023-08-30 23:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-30 23:53 Frederick Lawler [this message]
2023-08-31 10:13 ` [RFC PATCH] fstests: Request inferred user Jeff Layton
2023-08-31 13:51   ` Frederick Lawler
2023-08-31 19:30     ` Luis Chamberlain
2023-08-31 19:35       ` Jeff Layton
2023-08-31 19:36         ` Luis Chamberlain
2023-08-31 19:35 ` Luis Chamberlain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230830235333.1658555-1-fred@cloudflare.com \
    --to=fred@cloudflare.com \
    --cc=kdevops@lists.linux.dev \
    --cc=kernel-team@cloudflare.com \
    --cc=mcgrof@kernel.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).