#2995 RFE: Deliver FleetCommander URL endpoint from an IPA server
Closed: Fixed 2 years ago Opened 3 years ago by jhrozek.

Fleet Commander wants to be able to delegate the profile data HTTP endpoint
configuration to the domain controller (FreeIPA/AD). This is a per-host
configuration key with a URL.

For now the proposed interface would be for SSSD to drop a fleet commander
specific file in /var/lib/sss/ with the fleet commander "source"

In the future we might explore a solution that would work with Active
Directory GPOs


This is a feature for the Fedora-25 timeframe, therefore targetting 1.15.

milestone: NEEDS_TRIAGE => SSSD 1.15 beta

Fields changed

rhbz: => todo

Fields changed

milestone: SSSD 1.16 beta => SSSD 1.15 Beta

I need to start planning to get the fleet commander bits in place, which is a bit hard to do working "in the blind" until this feature is implemented on the FreeIPA/SSSD side of things.

Can we agree, tentatively on a location/format for the http(s)://host:port/path string?

I took notes about where the other stuff that sssd generates is stored. In my notes I think this was supposed to be stored somewhere in /var/lib/sss/pubconf, am I right?

Sorry, I forgot to add in the comment above, for us the most appropriate format would be a KeyFile (aka .ini) such as this example:

[SSSD]
source=http://some.host:9989/path/to/endpoint

Fields changed

cc: => aruizrui@redhat.com

Replying to [comment:5 aruiz]:

Sorry, I forgot to add in the comment above, for us the most appropriate format would be a KeyFile (aka .ini) such as this example:
{{{
[SSSD]
source=http://some.host:9989/path/to/endpoint
}}}

Can you please describe a scenario in more details for the benefit of people who were not a part of the conversation? Is this an ini file that needs to be injected into the client system by SSSD using information from IPA? Why is this not a DNS record? More details will be welcome.

Replying to [comment:4 aruiz]:

I need to start planning to get the fleet commander bits in place, which is a bit hard to do working "in the blind" until this feature is implemented on the FreeIPA/SSSD side of things.

Can we agree, tentatively on a location/format for the http(s)://host:port/path string?

I took notes about where the other stuff that sssd generates is stored. In my notes I think this was supposed to be stored somewhere in /var/lib/sss/pubconf, am I right?

I'm sorry this slipped, we've been busy for a long time with 7.3 and other work.

In general, I think we should write up all that we agreed on previously on the call in a design page first. But about the patch, /var/lib/sss/ is a directory we own. I think we should create another subdirectory there (/var/lib/sss/fleetcmdr ?), not put files into pubconf, because we mostly put Kerberos-related data into pubconf.

Fields changed

cc: aruizrui@redhat.com => aruizrui@redhat.com, abbra

Replying to [comment:7 dpal]:

Replying to [comment:5 aruiz]:

Sorry, I forgot to add in the comment above, for us the most appropriate format would be a KeyFile (aka .ini) such as this example:
{{{
[SSSD]
source=http://some.host:9989/path/to/endpoint
}}}

Can you please describe a scenario in more details for the benefit of people who were not a part of the conversation? Is this an ini file that needs to be injected into the client system by SSSD using information from IPA? Why is this not a DNS record? More details will be welcome.

In the conversation I basically described the main design principles around Fleet Commander. Basically we have a "profile" server that serves configuration data to all the clients in a domain/network, we don't want to do any host configuration but mostly user session configuration.

I wanted to have a way to delegate the client daemon configuration (mainly, the URL of the HTTP endpoint and the polling interval in seconds) to FreeIPA, so that the domain admin can set it from the web interface and the Fleet Commander client can retrieve that information through SSSD.

I have no interest in suggesting any sort of interface/details on how this would work between the FreeIPA server and the SSSD client, and if using DNS records is a more sensible proposal from the IPA perspective that's okay for me too.

I'm just describing the most convenient scenario for me. I really don't mind using any other method that is more suitable/coherent with the rest of the IPA/SSSD design.

I hope this clarifies.

Replying to [comment:8 jhrozek]:

I'm sorry this slipped, we've been busy for a long time with 7.3 and other work.

In general, I think we should write up all that we agreed on previously on the call in a design page first. But about the patch, /var/lib/sss/ is a directory we own. I think we should create another subdirectory there (/var/lib/sss/fleetcmdr ?), not put files into pubconf, because we mostly put Kerberos-related data into pubconf.

The client daemon runs as root, so any directory would work for me, I have no need for it to be specific so whatever path works best for SSSD works for me too.

As per the rest of the agreement I think we could summarize it as this:

  • FreeIPA to let the system administrator to configure the Fleet Commander HTTP endpoint and polling interval, so basically two pieces of information:

    • (string) Fleet Commander endpoint: HTTP url
    • (integer) Fleet Commander polling interval: the ammount of seconds between polls from the clients
  • SSSD to put that information somewhere in the client side of any machine enrolled in the domain in a path accessible by root. A KeyFile format is preferred but other formats can be discussed as long as it doesn't drag new dependencies.

There was a soft agreement that you guys had the capacity to squeeze this in for F25, it was a major item for us to deliver on F25 and something some customers are keen on seeing happening so any efforts to make it for the Alpha would be greatly appreciated. Let me know if there's something we can do to help.

Thanks!

Right. My idea on IPA side is to treat it similarly to how we do selinuxusermap. It would be a generic resource mapping with a tag:

ipa resourcemap-add --tag=fleetcommander test1 --resource=https://some.host:9989/path/to/endpoint
ipa resourcemap-add-host test1 --hostscat=all

or

ipa resourcemap-add-host test1 --hosts={server1,server2,server3}

This is trivial to implement and maintain in IPA via ipaAssociation subclass in LDAP. SSSD would anyway try to retrieve all groups a host is member of so it would be able to see this resourcemap and use its content to write down needed configuration on the host.

Metadata Update from @jhrozek:
- Issue assigned to fidencio
- Issue set to the milestone: SSSD 1.15.3

2 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset
- Custom field mark reset
- Custom field patch reset
- Custom field review reset
- Custom field sensitive reset
- Custom field testsupdated reset
- Issue close_status updated to: None
- Issue set to the milestone: SSSD 1.15.4 (was: SSSD 1.15.3)

2 years ago

Right now this feature is working as expected. Last changes regarding enabling deskprofile by default does not affect SSSD behavior unless IPA server have deskprofiles plugin installed, and it is needed to be enabled because of usability.

If the sysadmin have to set this option to enabled to every machine, the idea of using fleet commander would be cumbersome.

Just adding a little bit more information here:

Differently to what has been discussed in the beginning of this feature's design, the FC client will be started by SSSD. In other words, what changes is that, previously, FC client would start, drop a configuration file that contains the ipa_enable_deskprofile = True option for the specific domain, then a one-shot service would be fired and, finally, SSSD would fetch the rules. Now, as SSSD is responsible for activating FC client (through a D-Bus call), Alberto has suggested to have the feature enabled by default in order to have it working out of the box for any possible user.

Thus, I have updated the patch set now with the changes asked by Alberto/Oliver and, since last week, have provided a build that Oliver could test that everything works as expected out of the box (right, Oliver?).

Metadata Update from @fidencio:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

2 years ago

Metadata Update from @fidencio:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

2 years ago

Thus, I have updated the patch set now with the changes asked by Alberto/Oliver and, since last week, have provided a build that Oliver could test that everything works as expected out of the box (right, Oliver?).

I think in general this is fine and I agree that features should work out of the box and the additional search is even a bit less complex than the one-shot service. My only worry is that if there is an extra search per login, we might flood the servers in case someone fires a lot of batch jobs. So I propose that we cache the results at least in the form of 'realm has FC profiles' or 'realm has no FC profiles at all' in memory somewhere in the IPA context and if the first search didn't find anything, don't fire additional search for a certain amount of time (minutes?).

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

2 years ago

@aruiz and me agree with the change of caching the request. Production wise it makes sense.

As long as we can remove the SSSD cache and database files and restart it to force the check during development it shounds good.

Metadata Update from @jhrozek:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1471015 (was: todo)

2 years ago

Metadata Update from @jhrozek:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1471015 (was: todo)

2 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue tagged with: PR

2 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

2 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue set to the milestone: SSSD 1.16.0 (was: SSSD 1.15.4)

2 years ago

Login to comment on this ticket.

Metadata