On 08/16/2016 03:04 PM, Martin Kosek wrote:
it took a little longer than I expected, but the client-side
implementation is now available for review at
https://github.com/freeipa/freeipa/pull/10. Please take a look when you
get a chance.
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
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
- 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!
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code