On 08/16/2016 08:12 PM, Alexander Bokovoy wrote: > On Tue, 16 Aug 2016, Ben Lipton wrote: >> On 08/10/2016 08:52 AM, Ben Lipton wrote: >>> The pull request at https://github.com/LiptonB/freeipa/pull/4/commits has >>> been brought up to date (with a force push), and also includes 3 more >>> patches, described below. >>> >>> The patchset is also attached. To make sure that everything applies, I just >>> regenerated the whole set, though there may not be meaningful changes. >>> >> After a discussion about how to address some of the concerns that have been >> voiced about this project, there have been some changes to the project >> direction. So, I wanted to provide an update about what the plans are. If you >> have objections or feel that I'm not representing it correctly, please let me >> know. >> >> Since we have yet to see all the ways people will want to use this feature, >> the immediate goal is to provide something that we can iterate on. To make >> this easier, we will avoid storing rule data on the server or modifying the >> server schema, as those changes would need to be supported long term/handled >> correctly on update. I plan to approach this as follows: >> - Separate the provider of mapping rules into a separate component from the >> generation of a config based on those rules >> - Build an alternative rule provider that reads local files rather than >> querying IPA >> - Move the implementation of CSR config formatting from the server API into a >> library (where should this go? ipalib? ipapython?), and then provide a >> client-side command that builds a config using the library. > Up to you -- ipapython is traditionally used for very basic dependencies > when nothing is configured and is used by both installers and the > framework, ipalib -- for common code in the framework itself. > >> - Templates for at least two profiles ("user" profile with >> CN=<username>,<subject_base> subject and email address SAN, "service" profile >> with CN=<fqdn>,<subject_base> subject and DNS SAN) will be provided. Users >> will be able to build custom profiles by putting files in the appropriate >> directories on their client machines (but we will not guarantee backward >> compatibility for the format of these files). >> - If we decide to move forward with storing rules on the server, the library >> call can be referenced from the server code, using the rule provider that >> pulls rules from the API. However, at that point we may also go in the >> direction of making automatic cert generation fully the responsibility of >> Dogtag, and keep the CSR-generation approach client-side only. >> >> Comments welcome! Unless the changes are more complex than I anticipate, I >> hope to have a prototype of this approach for review by the end of this week. > The summary above looks fine.
+1, this looks good to me too. Thanks Ben, good job! Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
