Feature #16214

Add stone to our VPN

Added by groente 2018-12-10 13:33:22 . Updated 2019-02-27 20:55:07 .

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

100%

Feature Branch:
Type of work:
Sysadmin
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

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


Subtasks


Related issues

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

History

#1 Updated by intrigeri 2018-12-11 10:00:56

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

#2 Updated by CyrilBrulebois 2018-12-16 14:03:03

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

#3 Updated by intrigeri 2019-01-21 11:10:13

#4 Updated by intrigeri 2019-01-21 11:10:37

  • Description updated

#5 Updated by anonym 2019-01-30 11:59:22

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

#6 Updated by groente 2019-02-27 12:01:48

  • 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 2019-02-27 12:20:48

@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 2019-02-27 12:52:50

  • 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 2019-02-27 14:24:30

  • 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 2019-02-27 14:57:05

  • 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 2019-02-27 15:21:31

  • 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 2019-02-27 20:55:07

  • 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…