----- Original Message ----- > From: "Christopher Wood" <christopher_w...@pobox.com> > To: "mcollective-users" <mcollective-users@googlegroups.com> > Sent: Thursday, 6 October, 2016 20:29:16 > Subject: Re: [mcollective-users] translate activemq subcollectives to nats.io
> On Thu, Oct 06, 2016 at 08:43:54AM +0100, R.I.Pienaar wrote: >> >> >> ----- Original Message ----- >> > From: "Christopher Wood" <christopher_w...@pobox.com> >> > To: "mcollective-users" <mcollective-users@googlegroups.com> >> > Sent: Wednesday, 5 October, 2016 22:19:50 >> > Subject: Re: [mcollective-users] translate activemq subcollectives to >> > nats.io >> >> > Subcollectives indeed work fine. So far I have things running on a single >> > host >> > and the setup was much easier than doing something similar with activemq >> > several years ago. Everything I could think to try works the same. >> > >> > Next to fully puppetize the setup and persuade the security department to >> > open >> > another port for nats (oh dear). >> >> Did you use the module the wiki recommend? It's simple but does what you want >> including >> clustering >> >> > Mild nitpick: there doesn't seem to be a client config file option for >> > cert and >> > key. I know there are environment variable options but enough people will >> > forget to set those on every login (environment with no persistent >> > .bash_profile or similar, yes indeed). My workaround will be to provide a >> > short >> > puppet manifest to reshape their client config since any shuffling errors >> > will >> > be obvious when mailed back. It would definitely be easier to have people >> > copy >> > activemq cert params into choria cert params. >> >> why do you wish to change these paths? It defaults to the same ones puppet >> use >> for a reason - you should not need to make any client configuration at all, >> just >> put the certs in the puppet location - which 'mco choria request_cert' does >> for >> you > > If I were setting things up from scratch in regular home directories the > choria > technique would be suitable, but I'm not. > > I have the usual corporate things going on: > > 1) The new cert location is not in "$HOME/.mcollective.d". It took a great > deal > of protracted discussion with the security department to permit .mcollective > and .mcollective.d (certs and things) to persist overnight in users' home > directories. Most every other file under $HOME on the authorized mco client > hosts get removed nightly. I will be re-opening that discussion. OK, well adding configurable overrides for these would not be hard, I dont mind adding more flags, feel free to open a issue in the choria github > 2) Everybody has their own (working) certs and configs from the current > production install. It was like pulling teeth the first time to get people set > up despite the detailed instructions; what is straightforward and obvious to > me > is not so obvious to others. That includes running a cert management command > based on my experience here. reusing those would be hard right? There were never a CA involved in making those the new stuff does CA validation > NB: This is of course a policy issue not an mcollective issue, I myself > wouldn't > go and add this functionality based on the description of the issues. Policies > have results and working around them in a corporate environment rarely ends > well. no its fair enough, this stuff matters and mcollective is one of few in this space with solid AAA story because I want it to appeal to exactly this kind of user, so if overrides will help I will add them -- --- 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.
