Thanks for your responses, your points seem quite valid. I may have been
blinded by my specific scenario (actual client machines / users rather than
only backend). Also that I'm dealing with Ubuntu clients just makes the
process a bit more frustrating (client sssd project isn't quite as stable
as Fedora/EL - but I realize its a one-man show).

All your hard work is much appreciated, and I think this is an awesome
project that has long been needed.

Unfortunately the only time I can dedicate is in testing as I await the
RHEL 7 release.

*Steve Dainard *
IT Infrastructure Manager
Miovision <> | *Rethink Traffic*

*Blog <>  |  **LinkedIn
<>  |  Twitter
<>  |  Facebook
 Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON,
Canada | N2C 1L3
This e-mail may contain information that is privileged or confidential. If
you are not the intended recipient, please delete the e-mail and any
attachments and notify us immediately.

On Fri, Feb 14, 2014 at 2:36 AM, Alexander Bokovoy <>wrote:

> On Thu, 13 Feb 2014, Steve Dainard wrote:
>> I don't think this is an issue of bugs or documentation, more of design.
>> Perhaps there's someplace other than a users list this belongs in but:
>> If IPA is a centrally managed identity and access control system, should
>> these configurations not be passed to clients, rather than every client
>> needing configuration changes post join? Obviously I can automate config
>> changes, but why would I want to? I don't think sudoers priv is a fringe
>> case, its pretty much THE case for access/admin control. I cringe to
>> compare to a Windows domain, but I don't have to manually tell a domain
>> client that it should respect the rules I set on a domain controller, I
>> joined it to the domain for this reason.
> When majority of expected features are already implemented, it is easy
> to fall into assumption that everything has to be complete from start.
> That's understandable but we are dealing with a living and evolving
> project where a feature addition often means integrating across multiple
> actual free software projects, all with their own priorities and
> schedules, step by step, or things will never happen.
> SUDO integration is not an exception here. First we needed to expand
> SUDO's support for external plugins. When SUDO data was placed in LDAP,
> it appeared that existing schema isn't really optimal, so FreeIPA schema
> was designed better (but incompatible with existing one from SUDO LDAP),
> but required a compatibility part to work with existing SUDO LDAP
> plugin. Next, we implemented SUDO provider in SSSD for the existing SUDO
> LDAP schema as it gave SSSD wider coverage of SUDO support. Now we
> implemented support for native FreeIPA schema. The next step is to
> integrate configuration of it in ipa-client-install so that clients will
> get set up properly if there are SUDO rules configured on the server or
> ipa-client-install was actually given a bless from the admin (via CLI
> option or answering a question).
> It takes time and effort. Unsurprisingly, this is a relatively minor
> feature in the grand picture because we have dozens of such features all
> asking for attention and time, and our development teams are not
> expanding infinitely regardless how we all wished. :)
> Any help is welcome!
> --
> / Alexander Bokovoy
Freeipa-users mailing list

Reply via email to