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 <http://miovision.com/> | *Rethink Traffic* *Blog <http://miovision.com/blog> | **LinkedIn <https://www.linkedin.com/company/miovision-technologies> | Twitter <https://twitter.com/miovision> | Facebook <https://www.facebook.com/miovision>* ------------------------------ 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 <aboko...@redhat.com>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 Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-users