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.

Fields changed

design: => https://fedorahosted.org/sssd/wiki/DesignDocs/FleetCommanderIntegration
owner: somebody => fidencio

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?).

Here's the link for the PR: https://github.com/SSSD/sssd/pull/241

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?).

@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.

Issue linked to Bugzilla: Bug 1471015

• master:
• 4a31170
• 85517b5
• 85a93ca
• 684a13e
• 4b37ee7
• dd6a4fb
• c9e104f
• 9d98e98
• b054e7d
• f982039
• 6f466e0
• 5b93634
• 7c1d139
• 18d898d
• ee16491
• 0f62345
• d2a0b4a
• e17e37c
• 21909d3
• 9a18f78
• 8a26d32

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4036

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.