Delay in behavior when making changes to custom plugins

[Scott Serr]

My environment is: CentOS 8.2, FreeIPA 4.8.4, single instance, no clients

My minimal test case plugin looks like this:

user.takes_params += ( 
Str('useraffiliation?', 
cli_name = 'useraffiliation', 
label = _('User Affiliation'), 
), 
) 
user.default_attributes.append('useraffiliation')

Say I modify the label. That change isn't shown in IPA cli: 
ipa user-find foo --all

Then about an hour later (go eat dinner) then the label has changed.

Restarting the ipa service, another kinit, even rebooting doesn't hurry this process along.

2 Questions: 
1. What is causing this delay in reflecting my changes? 
2. Is there a way to force my changes to be reflected right away?

Thank you!

[Alexander Bokovoy]

On ke, 09 syys 2020, Scott Serr via FreeIPA-users wrote:
> My environment is: CentOS 8.2, FreeIPA 4.8.4, single instance, no clients
>
> My minimal test case plugin looks like this:
>
> user.takes_params += (
> Str('useraffiliation?',
> cli_name = 'useraffiliation',
> label = _('User Affiliation'),
> ),
> )
> user.default_attributes.append('useraffiliation')
>
> Say I modify the label. That change isn't shown in IPA cli:
> ipa user-find foo --all
>
> Then about an hour later (go eat dinner) then the label has changed.
>
> Restarting the ipa service, another kinit, even rebooting doesn't hurry this process along.
>
> 2 Questions:
> What is causing this delay in reflecting my changes?
> Is there a way to force my changes to be reflected right away?

The issue you see is a client-side caching of IPA API schema metadata.
In order to avoid retrieving API definition every time we call into
JSON-RPC, we retrieve API definition once and cache it locally.

When you change API definition, such as adding your plugin or adding
params to existing objects and restarting a server side, the fingerprint of
the API would change. However, the client doesn't know about that until
it retries to retrieve the new API definition.

A client-side workaround is to remove content of
~/.cache/ipa/servers/<servername> every time you are changing the server
content.  If you want, you can remove the whole cache in ~/.cache/ipa as
it also includes older schema definitions.

[Rob Crittenden]

Scott Serr via FreeIPA-users wrote:
> My environment is: CentOS 8.2, FreeIPA 4.8.4, single instance, no clients
>
> My minimal test case plugin looks like this:
>
> user.takes_params += (
>     Str('useraffiliation?',
>         cli_name = 'useraffiliation',
>         label = _('User Affiliation'),
>     ),
> )
> user.default_attributes.append('useraffiliation')
>
> Say I modify the label. That change isn't shown in IPA cli:
> ipa user-find foo --all
>
> Then about an hour later (go eat dinner) then the label has changed.
>
> Restarting the ipa service, another kinit, even rebooting doesn't hurry
> this process along.
>
> 2 Questions:
> What is causing this delay in reflecting my changes?
> Is there a way to force my changes to be reflected right away?

It's probably the cached schema in ~/.cache/ipa/schema/. You can safely
remove that at any time and it will be retrieved upon the next ipa command.

rob

[Scott Serr]

On 9/9/20 9:17 AM, Rob Crittenden wrote:
> Scott Serr via FreeIPA-users wrote:
> > My environment is: CentOS 8.2, FreeIPA 4.8.4, single instance, no clients
> >
> > My minimal test case plugin looks like this:
> >
> > user.takes_params += (
> >      Str('useraffiliation?',
> >          cli_name = 'useraffiliation',
> >          label = _('User Affiliation'),
> >      ),
> > )
> > user.default_attributes.append('useraffiliation')
> >
> > Say I modify the label. That change isn't shown in IPA cli:
> > ipa user-find foo --all
> >
> > Then about an hour later (go eat dinner) then the label has changed.
> >
> > Restarting the ipa service, another kinit, even rebooting doesn't hurry
> > this process along.
> >
> > 2 Questions:
> > What is causing this delay in reflecting my changes?
> > Is there a way to force my changes to be reflected right away?
>
> It's probably the cached schema in ~/.cache/ipa/schema/. You can safely
> remove that at any time and it will be retrieved upon the next ipa command.
>
> rob

Thank you Rob and Alexander!  Yes, that was the problem.

A small follow on:

I see the custom attribute fine with the admin user doing "ipa user-find 
foo --all" but other users even with all permission cannot see the new 
custom attribute.  (even with --all)  Any ideas?

[Rob Crittenden]

Scott Serr wrote:
> On 9/9/20 9:17 AM, Rob Crittenden wrote:
> > Scott Serr via FreeIPA-users wrote:
> > > My environment is: CentOS 8.2, FreeIPA 4.8.4, single instance, no
> > > clients
> > >
> > > My minimal test case plugin looks like this:
> > >
> > > user.takes_params += (
> > >      Str('useraffiliation?',
> > >          cli_name = 'useraffiliation',
> > >          label = _('User Affiliation'),
> > >      ),
> > > )
> > > user.default_attributes.append('useraffiliation')
> > >
> > > Say I modify the label. That change isn't shown in IPA cli:
> > > ipa user-find foo --all
> > >
> > > Then about an hour later (go eat dinner) then the label has changed.
> > >
> > > Restarting the ipa service, another kinit, even rebooting doesn't hurry
> > > this process along.
> > >
> > > 2 Questions:
> > > What is causing this delay in reflecting my changes?
> > > Is there a way to force my changes to be reflected right away?
> >
> > It's probably the cached schema in ~/.cache/ipa/schema/. You can safely
> > remove that at any time and it will be retrieved upon the next ipa
> > command.
> >
> > rob
>
> Thank you Rob and Alexander!  Yes, that was the problem.
>
> A small follow on:
>
> I see the custom attribute fine with the admin user doing "ipa user-find
> foo --all" but other users even with all permission cannot see the new
> custom attribute.  (even with --all)  Any ideas?

You probably need to create an ACI to grant permission to read the
attribute. You can take inspiration from "System: Read User Standard
Attributes"

rob