md at rpzdesign.com
2015-Jan-12 04:05 UTC
TINC config files layout not human or script friendly
I would say the weakest part of the TINC design is the configuration file layout. There is no way to split out the essentially static configuration for all nodes in the cluster and isolate the node specific settings to one configuration file. So that means I have to keep an inventory of configuration files per node so I can edit and deliver them and keep everything straight. The private keys are in standalone files, but the public key is buried in along with other node specific settings in the host identifer file. So that makes it difficult to use a batch script and SSH and just update all the nodes with a new public/private key pair. Better yet, an option for a new key pair to autogenerate every N days or hours and then self deliver the public keys across the net via VPN. Also, in tinc-up script, I use the $INTERFACE for dynamic device name, but I would love if more config files, tinc.conf and the host config files could make more use of the $VARIABLE mechanism and maybe have a variables config file per node. That way my tinc-up file would be the same for every node. And my tinc.conf file. That way all per node specific settings would be in ONE file and all the other config files would be static for all nodes in the cluster. This message is part rant, part request, sorry if I offend anyone. md
md at rpzdesign.com
2015-Jan-12 04:47 UTC
TINC config files layout not human or script friendly
Oops, did I forget to mention how good a design the REST of tinc is, operationally speaking. Config files aside, it is a really good VPN. md On 1/11/2015 10:05 PM, md at rpzdesign.com wrote:> I would say the weakest part of the TINC design is the configuration > file layout. > > There is no way to split out the essentially static configuration for > all nodes in the cluster and isolate the node specific settings to one > configuration file. > > So that means I have to keep an inventory of configuration files per > node so I can edit and deliver them and keep everything straight. > > The private keys are in standalone files, but the public key is buried > in along with other node specific settings in the host identifer file. > > So that makes it difficult to use a batch script and SSH and just update > all the nodes with a new public/private key pair. > > Better yet, an option for a new key pair to autogenerate every N days or > hours and then self deliver the public keys across the net via VPN. > > Also, in tinc-up script, I use the $INTERFACE for dynamic device name, > but I would love if more config files, tinc.conf and the host config > files could make more use of the $VARIABLE mechanism > and maybe have a variables config file per node. > > That way my tinc-up file would be the same for every node. And my > tinc.conf file. > > That way all per node specific settings would be in ONE file and all the > other config files would be static for all nodes in the cluster. > > This message is part rant, part request, sorry if I offend anyone. > > md > > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >
On Sun, Jan 11, 2015 at 10:05:44PM -0600, md at rpzdesign.com wrote:> I would say the weakest part of the TINC design is the configuration file > layout. > > There is no way to split out the essentially static configuration for all > nodes in the cluster and isolate the node specific settings to one > configuration file.[...]> So that makes it difficult to use a batch script and SSH and just update all > the nodes with a new public/private key pair.Since 1.0.14 you can put all host configuration variables for the local node in tinc.conf as well. You can then have a hosts/ directory with files that only contain Address statements and public keys. Note that there exist projects to manage tinc configuration for large numbers of unattended nodes, like the one used by ChaosVPN (https://github.com/ryd/chaosvpn).> Better yet, an option for a new key pair to autogenerate every N days or > hours and then self deliver the public keys across the net via VPN.The whole idea of public keys is that they last a long time. They are not used directly to encrypt traffic, instead they are used to securely exchange session keys which in turn are used to encrypt all your VPN traffic. The session keys are already changed every hour by default. You wouldn't create a new certificate for a website every N hours either, right?> Also, in tinc-up script, I use the $INTERFACE for dynamic device name, but I > would love if more config files, tinc.conf and the host config files could > make more use of the $VARIABLE mechanism > and maybe have a variables config file per node. > > That way my tinc-up file would be the same for every node. And my tinc.conf > file.There are only a few environment variables that tinc sets, and I don't think any of those would make sense for host config files. For tinc.conf, you can actually use Name = $HOST, and it will use the local hostname as Name. In tinc-up you can use $NAME to find out what the Name of the local tinc daemon is. You can use this to read information from the local node's host config file, like this: #!/bin/sh MyAddress=`grep ^MyAddress /etc/tinc/$NETNAME/hosts/$NAME | cut -d= -f2` ip addr add $MyAddress dev $INTERFACE ip link set $INTERFACE up This example allows you to put "MyAddress = 192.168.1.1/24" in host config files, and then it will be used to configure the VPN interface. Since MyAddress is not a valid configuration variable, tinc itself will ignore it. Granted, it doesn't look nice and on Windows it will be even harder to do something equivalent. If you still can't do what you want to do, or maybe you can but you think it's awful, please let me know how you would like your configuration to be; provide a mock-up of your desired tinc configuration directory.> This message is part rant, part request, sorry if I offend anyone.No offence taken :) -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20150112/7149cfa8/attachment.sig>
md at rpzdesign.com
2015-Jan-12 12:17 UTC
[SOLVED] Re: TINC config files layout not human or script friendly
Hello Tinc users & Guss: I was sleeping last night and I figured out how to accomplish everything I ranted about below with no source code changes to TINC. The first thing to do is create TEMPLATES for tinc.conf, tinc-up, and the NODE files. Then during the startup script, use the linux cp command and sed to copy the template to the correct name and sed to text replace "variables" with correct values. For example, in the tinc.conf, have the line Name = [NAME] and sed can find and replace that text with the proper value supplied in a single configuration file, THE STARTUP script! The public key can also be replaced by sed using [PUBLIC KEY] Another script can run on a cron job and replace Now all I have to do is every so often, upload a new public and private key file to the nodes and then remotely call the reload script which will use sed to manipulate the templates and copy the files to the right locations with the right values. Sorry for my earlier rant, only through frustration do we get inspiration! Cheers all, md On 1/11/2015 10:47 PM, md at rpzdesign.com wrote:> Oops, did I forget to mention how good a design the REST of tinc is, > operationally speaking. > > Config files aside, it is a really good VPN. > > md > > On 1/11/2015 10:05 PM, md at rpzdesign.com wrote: >> I would say the weakest part of the TINC design is the configuration >> file layout. >> >> There is no way to split out the essentially static configuration for >> all nodes in the cluster and isolate the node specific settings to one >> configuration file. >> >> So that means I have to keep an inventory of configuration files per >> node so I can edit and deliver them and keep everything straight. >> >> The private keys are in standalone files, but the public key is buried >> in along with other node specific settings in the host identifer file. >> >> So that makes it difficult to use a batch script and SSH and just update >> all the nodes with a new public/private key pair. >> >> Better yet, an option for a new key pair to autogenerate every N days or >> hours and then self deliver the public keys across the net via VPN. >> >> Also, in tinc-up script, I use the $INTERFACE for dynamic device name, >> but I would love if more config files, tinc.conf and the host config >> files could make more use of the $VARIABLE mechanism >> and maybe have a variables config file per node. >> >> That way my tinc-up file would be the same for every node. And my >> tinc.conf file. >> >> That way all per node specific settings would be in ONE file and all the >> other config files would be static for all nodes in the cluster. >> >> This message is part rant, part request, sorry if I offend anyone. >> >> md >> >> _______________________________________________ >> tinc mailing list >> tinc at tinc-vpn.org >> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >> > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >