Tails

#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

• blocks Feature #16215: Add monitoring to stone added

#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?

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