All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Mayhew <smayhew@redhat.com>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: kdevops@lists.linux.dev
Subject: Re: [PATCH 5/5] fstests/nfs: add krb5 support
Date: Fri, 8 Mar 2024 14:33:24 -0500	[thread overview]
Message-ID: <ZetoBP8hyobREhJO@aion> (raw)
In-Reply-To: <ZetDZRwClb76Q_gm@bombadil.infradead.org>

On Fri, 08 Mar 2024, Luis Chamberlain wrote:

> My review comments are not requirements, they are how to enhance this
> so we can scale better and long term goals to keep in mind. Whether or
> not you do the work is up to you.
> 
> On Thu, Mar 07, 2024 at 08:14:14AM -0500, Scott Mayhew wrote:
> > diff --git a/Makefile b/Makefile
> > index 9ca3a5f3..df4aad7b 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -115,6 +115,11 @@ ifeq (y,$(CONFIG_KDEVOPS_SETUP_NFSD))
> >  include scripts/nfsd.Makefile
> >  endif # CONFIG_KDEVOPS_SETUP_NFSD
> >  
> > +ifeq (y,$(CONFIG_KDEVOPS_SETUP_KRB5))
> > +include scripts/kdc.Makefile
> > +include scripts/krb5.Makefile
> > +endif # CONFIG_KDEVOPS_SETUP_KRB5
> 
> This sort of clutter can be compartamentalized now, see right above:
> 
> include scripts/provision.Makefile                                               
> include scripts/systemd-timesync.Makefile                                        
> include scripts/journal-server.Makefile                                          
>                                                                                  
> KDEVOPS_BRING_UP_DEPS += $(KDEVOPS_BRING_UP_DEPS_EARLY)                          
> KDEVOPS_BRING_UP_DEPS += $(KDEVOPS_PROVISIONED_DEVCONFIG) 
> 
> This let's us now split work which needs to be set up early
> and this can vary depending on if the dep is a localhost (hypervisor or
> command and control) setting or a target node (guest or taret node on
> cloud) setting.
> 
> So for example systemd-timesync has both parts:
> 
> LOCALHOST_SETUP_WORK += timesyncd-server
> KDEVOPS_BRING_UP_DEPS_EARLY += timesyncd-client
> 
> Then the clutter is kept on the target makefile. This let's us also keep
> ordering by the Makfile include order. So we should be able to move
> siw ktls nfs setup to this methodology too. That will let us scale this
> and keep our top level Makefile neat and makes orer explicit and clear.
> 
> It seems in this case it's all being set up on the target node so only
> KDEVOPS_BRING_UP_DEPS_EARLY is needed.

Just so I'm clear on what you're suggesting...

1. move the ifeq...endif directives inside the target makefiles
2. move the KDEVOPS_BRING_UP_DEPS stuff out of bringup.Makefile and into the
   target makefiles (and use KDEVOPS_BRING_UP_DEPS_EARLY instead)
3. move the includes up above this line:
KDEVOPS_BRING_UP_DEPS += $(KDEVOPS_BRING_UP_DEPS_EARLY)

Does that sound right?

Also, did you see my reply to Chuck about doing the krb5 client setup
automatically?  In order to do that I need to have a "post" bringup
step, so that bringup target would look like this:

bringup: $(KDEVOPS_BRING_UP_DEPS) update_etc_hosts $(KDEVOPS_BRING_UP_POST)

Is that okay?  Note that the krb5 client setup has to run after update_etc_hosts,
so KDEVOPS_BRING_UP_LATE_DEPS wouldn't be appropriate for this.

> 
> BTW you may benefit from CONFIG_DEVCONFIG_ENABLE_SYSTEMD_TIMESYNCD as it
> sets up NTP on the host/nodes. But if you're going to enable that
> you could just enable systemd-remote-journal too, which we now have
> support for in guestfs.
> 
> > diff --git a/kconfigs/Kconfig.bringup.goals b/kconfigs/Kconfig.bringup.goals
> > index 71948e9b..26ffac98 100644
> > --- a/kconfigs/Kconfig.bringup.goals
> > +++ b/kconfigs/Kconfig.bringup.goals
> > @@ -109,3 +109,15 @@ menu "Configure the kernel NFS server"
> >  source "kconfigs/Kconfig.nfsd"
> >  endmenu
> >  endif
> > +
> > +config KDEVOPS_SETUP_KRB5
> > +	bool "Set up KRB5"
> > +	default n
> > +	help
> > +	  Configure and bring up a MIT Kerberos V5 KDC.
> > +
> > +if KDEVOPS_SETUP_KRB5
> > +menu "Configure the KRB5 KDC"
> > +source "kconfigs/Kconfig.kdc"
> > +endmenu
> > +endif
> 
> I think its cleaner if we move the config and the if to the
> kconfigs/Kconfig.kdc, the similar change could be done with
> KDEVOPS_SETUP_NFSD so its easier to add things the the top level
> kconfigs/Kconfig.nfsd is kept clean.

Will do.

> 
> > diff --git a/playbooks/roles/fstests/templates/nfs/nfsmount.conf b/playbooks/roles/fstests/templates/nfs/nfsmount.conf
> > new file mode 100644
> > index 00000000..73b6a8e4
> > --- /dev/null
> > +++ b/playbooks/roles/fstests/templates/nfs/nfsmount.conf
> > @@ -0,0 +1,2 @@
> > +[ NFSMount_Global_Options ]
> > +# Sec=sys
> > diff --git a/playbooks/roles/gen_hosts/templates/fstests.j2 b/playbooks/roles/gen_hosts/templates/fstests.j2
> > index 74057952..b94e89da 100644
> > --- a/playbooks/roles/gen_hosts/templates/fstests.j2
> > +++ b/playbooks/roles/gen_hosts/templates/fstests.j2
> > @@ -27,3 +27,20 @@ ansible_python_interpreter =  "{{ kdevops_python_interpreter }}"
> >  {% endif %}
> >  [nfsd:vars]
> >  ansible_python_interpreter =  "{{ kdevops_python_interpreter }}"
> > +[kdc]
> > +{% if krb5_realm is defined %}
> > +{{ kdevops_hosts_prefix }}-kdc
> > +{% endif %}
> > +[kdc:vars]
> > +ansible_python_interpreter =  "{{ kdevops_python_interpreter }}"
> > +[krb5]
> > +{% if krb5_realm is defined %}
> > +{% for s in fstests_enabled_test_types %}
> > +{{ kdevops_host_prefix }}-{{ s }}
> > +{% endfor %}
> > +{% if nfsd_threads is defined %}
> > +{{ kdevops_hosts_prefix }}-nfsd
> > +{% endif %}
> > +{% endif %}
> > +[krb5:vars]
> > +ansible_python_interpreter =  "{{ kdevops_python_interpreter }}"
> 
> We should add an kdc_enable which defaults to False and if true then we
> include the clutter below.
> 
> In retrospect the same should be done for nfsd.
> 
> Ie, if no one enabled nfsd or kdc we should hide targets for these
> options too and so the user has no make targets to use them and so no
> reason to clutter exisitng hosts file for user who don't enable these
> things.

I did notice that those stanzas were present even if those options weren't
enabled.

Do I really need a separate kdc_enable or should I just use the
krb5_enable variable that you suggested below?  

> 
> > diff --git a/playbooks/roles/gen_nodes/tasks/main.yml b/playbooks/roles/gen_nodes/tasks/main.yml
> > index 2f5c48b6..1181ef10 100644
> > --- a/playbooks/roles/gen_nodes/tasks/main.yml
> > +++ b/playbooks/roles/gen_nodes/tasks/main.yml
> > @@ -55,6 +55,18 @@
> >    when:
> >      - nfsd_threads is defined
> >  
> > +- name: Set kdc_nodes list
> > +  set_fact:
> > +    kdc_nodes: "{{ [ kdevops_host_prefix + '-kdc' ] }}"
> > +  when:
> > +    - krb5_realm is defined
> 
> We shoudl have a respective krb5_enable or something like that
> which defaults to False and here we shiould use krb5_realm_enable|bool
> instead.
> 
> The respective kconfig option would be
> 
> CONFIG_KRB5_REALM_ENABLE
> 
> The rationale would be that we later extend kconfig support so
> each kconfig option can have below say an extra tag to indicate
> "generate yaml", so our extra_vars.yaml file is automatically generated
> for us by kconfig itself. That is, we'd tell kconfig which kconfig
> symbols we want it to generate respective yaml entries for. So it'd
> just lowercase the symbol name and remove config prefix. Then later
> we can remove tons of Makefile changes which modify something to True.

Will do.

> 
> > +- name: Add a KRB5 KDC if one was selected
> > +  set_fact:
> > +    generic_nodes: "{{ generic_nodes + kdc_nodes }}"
> > +  when:
> > +    - krb5_realm is defined
> 
> Same.
> 
> > +
> >  - name: Set fstests config file variable for {{ fstests_fstyp }}
> >    set_fact:
> >      is_fstests: True
> > @@ -217,6 +229,13 @@
> >      - is_fstests|bool
> >      - nfsd_threads is defined
> >  
> > +- name: Add the KRB5 KDC if one was selected
> > +  set_fact:
> > +    fstests_enabled_nodes: "{{ fstests_enabled_nodes + kdc_nodes }}"
> > +  when:
> > +    - is_fstests|bool
> > +    - krb5_realm is defined
> 
> Same.
> 
> > diff --git a/playbooks/roles/kdc/tasks/main.yml b/playbooks/roles/kdc/tasks/main.yml
> > new file mode 100644
> > index 00000000..b67f38d0
> > --- /dev/null
> > +++ b/playbooks/roles/kdc/tasks/main.yml
> > @@ -0,0 +1,119 @@
> > +---
> > +- name: Get OS-specific variables
> > +  ansible.builtin.include_vars: "{{ lookup('ansible.builtin.first_found', params) }}"
> > +  vars:
> > +    params:
> > +      files:
> > +        - '{{ansible_distribution}}.yml'
> > +        - '{{ansible_os_family}}.yml'
> > +        - default.yml
> > +      paths:
> > +        - 'vars'
> 
> Ah.. this is a good alternative to Kconfig defaults but ...
> 
> > diff --git a/playbooks/roles/kdc/vars/default.yml b/playbooks/roles/kdc/vars/default.yml
> > new file mode 100644
> > index 00000000..ed97d539
> > --- /dev/null
> > +++ b/playbooks/roles/kdc/vars/default.yml
> > @@ -0,0 +1 @@
> > +---
> 
> This is empty, it should have all sensible defaults and .. it's a good
> time to evaluate whether or not having things configurable is better,
> but I undersand that can be a second step. The other reason to have
> things configurable is it lets you document things. But that's totally
> optional.

I can add defaults, but they'll be the Red Hat defaults and might not
work with other distros.  Originally I didn't have those configurable at
all, and when I went and tested Debian and Suse I found that stuff
didn't work.  Unfortunately the names of the systemd services and where
they look for configuration files and data differs from distro to
distro, so I had to have a least some of the stuff configurable... but I
tried to keep the number of variables to a minimum.

> 
> > index 5a477847..5c6a59c3 100644
> > --- a/scripts/bringup.Makefile
> > +++ b/scripts/bringup.Makefile
> > @@ -33,6 +33,10 @@ ifeq (y,$(CONFIG_KDEVOPS_SETUP_SIW))
> >  KDEVOPS_BRING_UP_DEPS += siw
> >  endif # KDEVOPS_SETUP_SIW
> >  
> > +ifeq (y,$(CONFIG_KDEVOPS_SETUP_KRB5))
> > +KDEVOPS_BRING_UP_DEPS += kdc
> > +endif # KDEVOPS_SETUP_KRB5
> 
> See same ordering thing here. Granted, I am not sure if this is
> a dep which needs to be set up early, so you should decide, but as
> our deps grow I thought it would be good to split them by regular
> services Vs optional later things.
> 
>   Luis
> 


  reply	other threads:[~2024-03-08 19:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-07 13:14 [PATCH 0/5] add initial support for testing nfs with krb5 Scott Mayhew
2024-03-07 13:14 ` [PATCH 1/5] nfsd: make sure the appropriate fsprogs package is installed Scott Mayhew
2024-03-07 13:14 ` [PATCH 2/5] update_etc_hosts: fix up hostnames on debian guestfs hosts Scott Mayhew
2024-03-07 13:14 ` [PATCH 3/5] nfsd: use EXTRA_VAR_INPUTS for export options Scott Mayhew
2024-03-07 13:14 ` [PATCH 4/5] devconfig: set /etc/hostname earlier Scott Mayhew
2024-03-07 13:14 ` [PATCH 5/5] fstests/nfs: add krb5 support Scott Mayhew
2024-03-08 16:57   ` Luis Chamberlain
2024-03-08 19:33     ` Scott Mayhew [this message]
2024-03-08 21:08       ` Scott Mayhew
2024-03-08 21:20         ` Luis Chamberlain
2024-03-08 21:18       ` Luis Chamberlain
2024-03-08 22:13         ` Scott Mayhew
2024-03-08 22:47           ` Luis Chamberlain
2024-03-08 15:01 ` [PATCH 0/5] add initial support for testing nfs with krb5 Chuck Lever III
2024-03-08 15:50   ` Scott Mayhew

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=ZetoBP8hyobREhJO@aion \
    --to=smayhew@redhat.com \
    --cc=kdevops@lists.linux.dev \
    --cc=mcgrof@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.