>
>
> > > I totally agreed with Dick solution, but out of completeness's you
> have
> > > the
> > > slurp module [1] that stores the data in memory.
> > > But if the control machine has swap and is swapping some data could
> end up
> > > on the disk.
> > >
> > > [1]
On tirsdag 29. august 2017 12.21.39 CEST Dick Visser wrote:
> On 25 August 2017 at 10:01, Kai Stian Olstad
>
> wrote:
> > On fredag 25. august 2017 03.28.23 CEST pixel fairy wrote:
> >> maybe a script to randomly generate a key, archive, compress, and encrypt
>
On 25 August 2017 at 10:01, Kai Stian Olstad
wrote:
> On fredag 25. august 2017 03.28.23 CEST pixel fairy wrote:
>> maybe a script to randomly generate a key, archive, compress, and encrypt
>> the folder, fetch to local, copy to standby and decrypt there. that
On Friday, August 25, 2017 at 1:02:20 AM UTC-7, Kai Stian Olstad wrote:
>
> On fredag 25. august 2017 03.28.23 CEST pixel fairy wrote:
> > maybe a script to randomly generate a key, archive, compress, and
> encrypt
> > the folder, fetch to local, copy to standby and decrypt there. that
>
>
> I totally agreed with Dick solution, but out of completeness's you have
> the
> slurp module [1] that stores the data in memory.
> But if the control machine has swap and is swapping some data could end up
> on
> the disk.
>
i like this approach better. one less ansible folder with a
On fredag 25. august 2017 03.28.23 CEST pixel fairy wrote:
> maybe a script to randomly generate a key, archive, compress, and encrypt
> the folder, fetch to local, copy to standby and decrypt there. that could
> be put in a handler when run on the active node, and a check for exist on
> all
Aha. But that means that the playbook isn't truly idempotent.
I would recommend spending some time changing the role (I assume you're
using https://github.com/Stouts/Stouts.openvpn) to be idempotent.
I had to do similar work on roles that generate key materials on the remote
host.
What I ended up
On Thursday, August 24, 2017 at 9:45:30 PM UTC-7, Dick Visser wrote:
>
> So you're running a playbook against one host, then want to clone the
> resulting configuration state to other hosts?
> As you already mentioned that sounds indeed like a lot of work.
> Why not simply run the playbook
So you're running a playbook against one host, then want to clone the
resulting configuration state to other hosts?
As you already mentioned that sounds indeed like a lot of work.
Why not simply run the playbook against *all* the machines?
Dick
On Fri, 25 Aug 2017 at 03:28, pixel fairy
when making a service thats set up remotely, in this case openvpn, id like
to set it up on two machines that already have keepalived between them and
have it listen on the floating address, so all requests will go to "active"
instead of standby.
Stouts.openvpn runs on a single host and does
10 matches
Mail list logo