On Tue, Oct 3, 2017 at 9:51 AM, R.I.Pienaar <r...@devco.net> wrote:
>
>
> On Tue, Oct 3, 2017, at 15:38, Trevor Vaughan wrote:
> > General exec seems fine and I'm a fan of gRPC in general with the caveat
> > that none of this is viable in a FIPS environment unless it gets wrapped
> > in stunnel or IPSec.
>
> presumably neither does the entire Go based agent though :) We discussed
> a plan for this previously, I'll potentially allow you to compile your
> own binary that can setup a SSL tunnel using the go FIPS compliant
> library and run the NATS over that, then you get what you want without
> quite as much hassle
>
Fair enough :-D. I was thinking of gRPC in this case but, if you wrap that,
things would work well. HashiCorp has been particularly adamant about not
sullying the Go awesomeness with underlying system ties that enable FIPS
compliance.
>
> > I don't think you need a shell-script optimized agent since I'm assuming
> > that the 'shell' provider will stick around for a while.
>
> you mean the shell agent from puppetlabs?
>
> I do want to find a way to strike a balance between random shell stuff
> and the structure an agent provide with its action based authorization.
> Somewhere in the middle where you can easily/trivially whitelist
> commands or provide small shell scripts or something and have those be
> subject to AAA
>
Yeah, I did, and I certainly get what you're saying. How about a hash aware
list?
{
user: awesome_user
allowed_commands:
{
'command_title_one': <Hash of user selection - SHA512, 256,
whatever...>
}
}
That would make it REALLY easy to implement.
I would also highly recommend allowing an LDAP backend for the AAA
components.
>
>
> > In terms of the DDL, please pick something that support comments. HOCON,
> > YAML, whatever. Alternatively, bake comments into the JSON "schema" as
> > the first item in the list.
>
> yes, the VS Code plugins let you use JSON Schema to validate/author
> YAML, I'd aim to support both JSON and YAML if I go that way
>
I would probably go JSON and HOCON at this point so that you don't have to
worry about YAML safe loading nonsense and people (like me) that abuse the
power of YAML occasionally.
>
>
> > Also, if we could reuse the DDL in the processed languages, that would be
> > ideal. It was always irritating to write the DDL and then have to go
> > reimplement half of it in the plugin code (maybe that's fixed?).
>
> its not needed. You're thinking about using it to make 'application',
> for which you should use the 'mco rpc ....' to get auto generated client
> code.
>
> I know you dont like the word RPC here so I have some mockups of
> revisiting that
> https://github.com/choria-io/mcollective-choria/issues/72
>
> Today and for ages and ages, you did not HAVE to write an application
> plugin. You choose to do so if you want to provide a alternative UI
> from the auto generated one.
>
Yeah, I usually wanted the alternative UI, mostly because I wanted to
restrict what users could do and/or make it less confusing. The referenced
issue seems like it will do nicely (sorry for forgetting about that), so
I'm good there.
>
> > I'll have to go back through my old agent code to see what issues I had
> > with it. I do remember the lack of internal consistency being an issue in
> > that the basic examples were *too* basic and the real-life code was not
> > given a consistent pattern for doing anything advanced.
> >
> > I guess I would like to see a single unified method for writing agents
> > where the parts are all clearly defined regardless of language (again,
> > maybe I missed something).
>
> Not sure I follow the concern here, they're already pretty standardised
> around agent/action boundaries, obviously what goes into those bits as
> code is entirely up to you apart from the conventions around the request
> and reply structures. This cannot really change since its a generic
> extension point.
>
> However a lighter weight abstraction like the shell one I mentioned
> above would provide a more rigid set of guard rails.
>
Honestly, the shell method might solve most user's issues overall. Make it
simple and then let me do whatever crazy processing I need to do on the
back end.
Frankly, if you combined it with a scrip 'push' mechanism, that's probably
all 90% of users would use (I base this on the observation that it's what I
see 90% of Ansible users using).
mco script src=my_script.sh hosts=elastic_cluster
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "mcollective-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mcollective-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
--
---
You received this message because you are subscribed to the Google Groups
"mcollective-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mcollective-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
