Project

General

Profile

Feature #16214

Bug #15071: Make our server backup process more usable

Add stone to our VPN

Added by groente 7 months ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Infrastructure
Target version:
Start date:
12/10/2018
Due date:
% Done:

100%

Spent time:
Feature Branch:
Type of work:
Sysadmin
Blueprint:
Starter:
Affected tool:

Description

stone should become part of our VPN so we can monitor it.


Related issues

Blocks Tails - Feature #13284: Core work: Sysadmin (Adapt our infrastructure) Confirmed 06/30/2017
Blocks Tails - Feature #16215: Add monitoring to stone Confirmed 12/10/2018

History

#1 Updated by intrigeri 7 months ago

  • Blocks Feature #13284: Core work: Sysadmin (Adapt our infrastructure) added

#2 Updated by CyrilBrulebois 7 months ago

  • Target version changed from Tails_3.11 to Tails_3.12

#3 Updated by intrigeri 6 months ago

#4 Updated by intrigeri 6 months ago

  • Description updated (diff)

#5 Updated by anonym 6 months ago

  • Target version changed from Tails_3.12 to Tails_3.13

#6 Updated by groente 5 months ago

  • Assignee changed from groente to intrigeri
  • QA Check set to Info Needed

hey, trying to puzzle out a way to integrate vpn nicely in masterless puppet, i couldn't help but wonder: is there any reason why key-generation is done manually and not with an exec from puppet?

#7 Updated by bertagaz 5 months ago

@groente wrote:

hey, trying to puzzle out a way to integrate vpn nicely in masterless puppet, i couldn't help but wonder: is there any reason why key-generation is done manually and not with an exec from puppet?

It's been a long time since this code has been written, but IIRC that's because every VPN hosts needs to have the public key of the others to identify them. So we needed a way to distribute this public keys, and the easiest way was to add them to the puppet manifest. But maybe there are clever ways.

#8 Updated by groente 5 months ago

  • Assignee changed from intrigeri to bertagaz

thanks for the quick feedback! i'm starting to see there's little added value to automating key generation in puppet the way things are now - and this will only get worse with masterless. now i'm in doubt between:

- removing vpn/hosts.pp entirely and turning the host keys that we have as static files into fullfledged tinc host definitions (including network config) in files/vpn/tailsvpn/

or

- moving the network configuration of the tinc nodes to hiera and let vpn/hosts.pp work its magic from there, instead of using exported resources

the first is simple, but has some double configuration of network configuration which won't pick up network changes (this may bite us when lizard has to move ip for a ddos-mitigation or scenario's like that)

the second is quite a bit harder, atleast if we want to prevent double configuration, and would require a fair bit of redesign.

i'm tempted to now go for option 1 and work out option 2 when we do our overall puppet redesign. what do you think?

#9 Updated by bertagaz 5 months ago

  • Assignee changed from bertagaz to groente

groente wrote:

thanks for the quick feedback! i'm starting to see there's little added value to automating key generation in puppet the way things are now - and this will only get worse with masterless. now i'm in doubt between:

- removing vpn/hosts.pp entirely and turning the host keys that we have as static files into fullfledged tinc host definitions (including network config) in files/vpn/tailsvpn/

or

- moving the network configuration of the tinc nodes to hiera and let vpn/hosts.pp work its magic from there, instead of using exported resources

the first is simple, but has some double configuration of network configuration which won't pick up network changes (this may bite us when lizard has to move ip for a ddos-mitigation or scenario's like that)

the second is quite a bit harder, atleast if we want to prevent double configuration, and would require a fair bit of redesign.

i'm tempted to now go for option 1 and work out option 2 when we do our overall puppet redesign. what do you think?

Is that because of the masterless puppet node, you need to modify this code? I'm not sure what you're trying to fix or achieve with this changes. If that's the reason, then the plan you're proposing makes sense, othserwise I'd say leave the things as they are, and we'll jump on proposal 2 directly when we redesign our puppet code.

#10 Updated by groente 5 months ago

  • Assignee changed from groente to bertagaz

Is that because of the masterless puppet node, you need to modify this code?

Yes, I need to integrate stone - which runs masterless - in the VPN and rather than a one-off hack to insert stone's pubkey in all the other nodes, i'd rather have a consistent mechanism that can deal with all nodes in the same fashion.

I'm not sure what you're trying to fix or achieve with this changes. If that's the reason, then the plan you're proposing makes sense, othserwise I'd say leave the things as they are, and we'll jump on proposal 2 directly when we redesign our puppet code.

so, is it clear now what i'm trying to achieve? and what would your suggestion be? (sorry, it feels a bit ambiguous still)

#11 Updated by bertagaz 5 months ago

  • Assignee changed from bertagaz to groente

groente wrote:

so, is it clear now what i'm trying to achieve? and what would your suggestion be? (sorry, it feels a bit ambiguous still)

Yes, now I got the masterless puppet difference that requires adaptation to our code. Sorry, I should have given a bit more thought about it.

And so yes, your proposed plan (in two stages) makes sense to get things running and this ticket tackled faster. :)

#12 Updated by groente 5 months ago

  • Status changed from Confirmed to Resolved
  • % Done changed from 0 to 100
  • QA Check deleted (Info Needed)

done, but the tails vpn code could really do with some redesign...

Also available in: Atom PDF