future of certmaster discussion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



hi all.  skvidal and i were having a discussion the other day about
the future path of certmaster.  Right now this can be a pain because
certmaster has to be installed everywhere that func is due to the
dependance on its libraries.  This can cause confusion with
configuration and setup, even for people that have worked with it
before.

>From the certmaster homepage (http://fedoraproject.org/certmaster):

-    Certmaster is a set of tools and a library for easily
distributing SSL certificates to applications that need them
-    Certmaster originated in the Func project
-    Any application can use certmaster for easy exchange of SSL certificates
-    Certmaster has a a python API and command line tool provided
("certmaster-request") for requesting certificates
-    A daemon, called "certmaster" is included to hand certificates out
-    The tool "certmaster-ca" is used to list certs and sign them when
requests come in.
-    autosigning of new certificate requests is also supported but is
off by default.
-    configuration is all done via minimal text files
-    certmaster has extensive audit logs of certificate operations

>From my understanding (and the 3rd point above) the intention of
certmaster being separate from func in the first place was so that it
could act as a application independent simple CA for applications.
Yet here we are... about 5 years after the introduction of func and
certmaster.  For the most part it seems like no one has taken
certmaster up except for with func, and if you are doing so please let
us know!  Plus, now func can live without certmaster thanks to all the
work skvidal has put into the utilization of puppet's certificates.

So looking towards the future we were looking at a two primary issues/concepts:

1: make func easier/cleaner to install, at least on the minions, but
preferably everywhere.
2: try to minimize changes to the code and operational environment so
that this change is as seamless as possible
3: reduce developer overhead of multiple projects

>From that we discussed 3 basic paths:

1: Merge certmaster into func, but leave pretty much all of the code
the same.  There could be a separate "overlord/certmaster" package
that would have the daemon side tools if desired, but otherwise
everything necessary could end up as a single package.
2: Make certmaster more of just a library package.  There would then
be a separate "overlord/certmaster" package that would have those
daemon side tools, but this leaves a separate code base and still has
func minions needing the certmaster library package.
3: Have func take over the code it uses from certmaster, thus
reversing the dependency. There would then be a separate
"overlord/certmaster" package that would have those daemon side tools,
but despite leaving a separate code base func minions would not need
the certmaster package.  However the certmaster package would need the
func one.

There are several variations that can come out of those 3 paths, and
we would like your input.

I'm attaching the un-edited conversation between us for you to read
through.  If you do read it, please read the whole thing as there were
clarifications and corrections further along in the conversation.

skvidal, if you have any clarifications or points you'd like to add,
please do :)

-greg
<janfrode> btw: it's quite confusing that the minions are using *both* /etc/func/minion.conf and /etc/certmaster/minion.conf. very confusing..
<skvidal> I agree
<skvidal> it's a distinction that made sense once
<skvidal> long ago
<skvidal> but my problem now is -  how to extricate from all this?
<skvidal> one thought is this:
<skvidal> merge cm and func back to one codebase/tarball and get rid of it that way
<skvidal> but that will mean an api-break for most all things
<skvidal> which is not the end of the world - but it will be a pain in the butt
<skvidal> janfrode: I'm open to ideas
<xaeth> skvidal: what about breaking certmaster out to be more of a loadable application instead of one that runs on its own?
<skvidal> I'm not sure I understand what you mean
<skvidal> can you explain more?
<xaeth> let me get my thoughts down in gedit, and i'll paste it
<skvidal> cool
<skvidal> thx
<xaeth> np
<xaeth> alright
<xaeth> certmaster was originally intended to be a re-usable CA, so not just func would benefit.  I'm assuming the theory was that others would use certmaster in the way that we use puppet-ca. Since this doesn't seem to be occurring, and part of that I assume is developers feel it is too closely tied to func and/or have no idea.
<xaeth> 1: Move certmaster binaries and inits to a certmaster-standalone (or some other name) package, with everything else going into certmaster-libs
<xaeth> 2: Since the binaries are effectively single function calls (and if not we should make them) then any application that wants to use certmaster would create their own '${app}-cad' and '${app}-ca', templates could be provided in %{docdir}, but already exist in certmaster-standalone)
<xaeth> 3: The default behavior of those scripts will be to accept a config file (in our case /etc/func/overlord.conf) and parses it looking for a [certmaster] (or [ca]) section, this way it can be a shared config file for applications, or their its own standalone file if their normal config standard isn't ini.
<xaeth> So as an example of use:
<xaeth> 1: func-cad and func-ca would read /etc/func/overlord.conf and find:
<xaeth>   - ssl root storage is in /var/lib/func/ca/
<xaeth>   - cadir is /etc/pki/func/ca
<xaeth> 2: funcd and func would read /etc/func/minion.conf and find:
<xaeth>   - cert dir is /etc/pki/func
<xaeth> Then func-overlord package would installed func-cad and func-ca, along with overlord.conf onto a system, and func-minion (or just func) would install on the minions.  The libraries broken out into func-libs for sharing purposes.
<xaeth> this should actually have a small impact on code changes... unfortunately it means there'll be a significant change for current implementations, but it should be scriptable.
<skvidal> hmm - not sure all those subpkgs are going to be fun for the upgrade, though.
<xaeth> ya.. upgrade was the only catch i could think of for this change
<xaeth> i mean.. arguably we don't need the subpackages
<xaeth> we could stick wit hthe same basic structure except the certmaster-standalone change
<xaeth> and meet the same technical change
<xaeth> the subpackages were mainly just to provide a clearer installation for newbies.  one that didn't just give them everything on all systems ( i know that's confused my co-workers)
<skvidal> so - the issue is this - to me
<skvidal> cm provides a library module
<skvidal> which func itself uses
<xaeth> right
<skvidal> so - we would need to port everything over to func from cm and make cm a tool-only usage
<skvidal> s/tool/cli/
<xaeth> so we're looking at it from 2 different views.
<xaeth> you: Its nice that we tried to make it re-usable, but no one is, so lets merge and move on
<xaeth> me: we tried to make it re-usable, and it should still be but we do need to make it more apart of func from a user experience, so lets make cm more of a standalone library not a tool, maybe someone some day will use it
<xaeth> yes?
<xaeth> i don't mean that in a cheeky way either, and i'm not saying you don't have a point, i was just making sure i understood the difference between our POVs
<skvidal> np
<skvidal> sorry- got pulled away
<xaeth> s'ok
<skvidal> hmm - so I don't think that's what I'm saying
<skvidal> I';m saying - any process to re-merge func and cm will be painful if anyone is using them - and that includes func :)
<skvidal> so it requires effort
<xaeth> okay. i agree. but i think i'm still missing something
<skvidal> I think the only thing missing here is really figuring out how to break the least amount of things while fixing this
<xaeth> okay... and the fix is to just try and make func's use of certmaster more integrated into func?
<skvidal> at the moment I was thinking of something like
<skvidal> take certmaster - put it completely inside func
<skvidal> but have it make the same dirs.
<skvidal> move the libs from cm over to func
<skvidal> and eventually just have cm as a daemon/tool
<skvidal> so we're all in one code base
<skvidal> and one base srpm
<skvidal> but it still generates multiple rpms
<skvidal> but in the case of the cm rpm
<skvidal> it is ONLY the cli tool/daemon
<skvidal> and it requires func, but func does not require it
<xaeth> so maybe its just cause i've been constantly frusted in the past few years by the fact that certmaster provides a great service and no one uses it, but I really don't like the idea of rolling it into func and making it less accessible to others for their own implementation.  I'd personally like to see more people embrace certmaster because its a good idea.  It actually annoys me that we took on puppet's ca capabilities, instead of them extending themselves to work with certmaster's
<skvidal> why?
<xaeth> its not to say there shouldn't be choice.. there should... but it does seem like lots of people re-implementing the same thing
<xaeth> which is why its good that we can use puppet's
<skvidal> well the issue to me was that a lot of people were already using puppet
<skvidal> and keeping 2 different lists of certs seemed.... like a good way to get stuff confused
<xaeth> i was already using func long before puppet came into the picture at my office..
<skvidal> nod - I understand
<xaeth> so it kinda goes both directions.  And like I said.. sharing is good.  So i'm glad we can use puppet certs... just wish that wasn't the only direction it flowed
<skvidal> well I suspect b/c of the puppet business model
<skvidal> they can't do that
<xaeth> And I see merging certmaster into func as removing that re-usability for other projects.
<xaeth> with the nderstanding that, no, no one has cared to use it yet
<skvidal> hmm - okay
<skvidal> I wasn';t thinking about removing anything
<skvidal> just eliminating the need for 2 tarballs
<xaeth> you aren't removing it but it becomes 'func'
<skvidal> they'd still be accessible as  library modules - but in func
<skvidal> yes
<xaeth> which means, regardless of whether you need func in your infrastructure, you have to install it to get to the CA we're making available
<skvidal> true
<xaeth> so in general, i mainly wanted to make sure i expressed my reasons behind that
<skvidal> I get that
<skvidal> I'm not sure what is best here
<xaeth> and that if in 2 years we end up splitting certmaster back out because people are interested... i'll be annoyed ;)
<skvidal> heh
<skvidal> lemme ask this
<skvidal> what if we moved some of the code out of cm into func
<skvidal> but kept them separate
<skvidal> so that func COULD be installed w/o cm
<xaeth> that i guess depends on how much needs to be moved.  I do see the benefit of only having to install 'func' on the minions
<xaeth> oh.. and in general I'm willing to go with your plan.. however i do think we should post this up to the list just in case anyone cares to weigh in.
<skvidal> nod
<skvidal> I agree
<skvidal> I'm not sure I would call what I'm talking about a 'plan' yet
<xaeth> well ya... maybe concept?
<skvidal> more like an idea zygote
<xaeth> kk.. well i need to run to home depot and start plumbing some stuph up... i can post this discussion to the list later today unless you beat me to it.
<skvidal> please feel free
<skvidal> I may be afirc for a while too
<xaeth> will do
<xaeth> k
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list

[Index of Archives]     [Fedora Users]     [Linux Networking]     [Fedora Legacy List]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux