Difference between revisions of "Quattor and IPv6"
From PDP/Grid Wiki
Jump to navigationJump to searchLine 1: | Line 1: | ||
− | This is a summary of what it has been done so far, in order to configure servers via quattor with IPv6 connectivity. It's divided in 4 parts: The installation and configuration of a quattor server | + | == Abstract == |
+ | |||
+ | This is a summary of what it has been done so far, in order to configure servers via quattor with '''IPv6''' connectivity. It's divided in 4 parts: | ||
+ | |||
+ | * The installation and configuration of a quattor server. | ||
+ | * The changes that have been made in the templates. | ||
+ | * The changes of the network component written by Stijn de Weirdt. | ||
+ | * The changes of the iptables component written by Joao Martins, Alasdair Earl, and Jan Iven. | ||
== Configuration of a Quattor server == | == Configuration of a Quattor server == | ||
− | I'm gonna skip all the steps to configure a quattor server and focus on the adaption of the DNS protocol to support IPv6. From the moment that it's possible to boot via PXE with IPv6, then we can include information about DHCPv6, but so far it's nonsense. | + | I'm gonna skip all the steps to configure a quattor server and focus on the adaption of the DNS protocol to support '''IPv6'''. From the moment that it's possible to boot via PXE with '''IPv6''', then we can include information about DHCPv6, but so far it's nonsense. |
=== DNS === | === DNS === | ||
− | The prefix that I was given is ''2001:610:120:e120::\64''. We need need to define two different zones in /etc/named.conf, one for localhost (::1), and another one for the servers in general: | + | The prefix that I was given is ''2001:610:120:e120::\64''. We need need to define two different zones in ''/etc/named.conf'', one for localhost (::1), and another one for the servers in general: |
+ | |||
+ | zone "1::.ip6.arpa"{ | ||
+ | type master; | ||
+ | file "data/db.1"; | ||
+ | }; | ||
+ | zone "0.2.1.e.0.2.1.0.0.1.6.0.1.0.0.2.ip6.arpa"{ | ||
+ | type master; | ||
+ | file "data/db.2001:610:120:e120"; | ||
+ | }; | ||
− | + | Then, in ''/var/named/data'', we need to create two new files for the reverse DNS of locahost and the other servers via IPv6 (''db.1'' and ''db.2001:610:120:e120''), which have as content: | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | db.1: | |
+ | ... | ||
+ | 1 IN PTR localhost.nikhef.nl. | ||
+ | ... | ||
+ | db.2001:610:120:e120: | ||
+ | ... | ||
+ | 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR quattor-server.nikhef.nl. | ||
+ | 3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ce.nikhef.nl. | ||
+ | 4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR wn-001.nikhef.nl. | ||
+ | 5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR wn-002.nikhef.nl. | ||
+ | 6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR torque.nikhef.nl. | ||
+ | 7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR wms.nikhef.nl. | ||
+ | 8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR bdii.nikhef.nl. | ||
+ | 9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR ui.nikhef.nl. | ||
+ | ... | ||
− | db | + | For the direct resolution, I just need to make modifications in ''/var/named/data/db.nikhef.nl'': |
− | |||
− | |||
− | |||
− | + | nikhef.nl. IN A 10.50.50.1 | |
− | + | IN AAAA 2001:610:120:e120::1 | |
− | + | localhost IN A 127.0.0.1 | |
− | + | IN AAAA ::1 | |
− | + | quattor-server.nikhef.nl. IN A 10.50.50.2 | |
− | + | IN AAAA 2001:610:120:e120::2 | |
− | + | ce.nikhef.nl. IN A 10.50.50.3 | |
− | + | IN AAAA 2001:610:120:e120::3 | |
− | + | wn-001.nikhef.nl. IN A 10.50.50.4 | |
− | + | IN AAAA 2001:610:120:e120::4 | |
− | ... | + | wn-002.nikhef.nl. IN A 10.50.50.5 |
+ | IN AAAA 2001:610:120:e120::5 | ||
+ | torque.nikhef.nl. IN A 10.50.50.6 | ||
+ | IN AAAA 2001:610:120:e120::6 | ||
+ | wms.nikhef.nl. IN A 10.50.50.7 | ||
+ | IN AAAA 2001:610:120:e120::7 | ||
+ | bdii.nikhef.nl. IN A 10.50.50.8 | ||
+ | IN AAAA 2001:610:120:e120::8 | ||
+ | ui.nikhef.nl. IN A 10.50.50.9 | ||
+ | IN AAAA 2001:610:120:e120::9 | ||
− | + | == The templates == | |
+ | Since the original schema only supports one IP per interface, some changes were necessary, in order to support two IPs for the interface. | ||
− | + | === $L/cfg/standard/components/network/config.tpl === | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
This template invokes the installation of the network component, and since the new version needs to be installed, I just changed it to invoke the new one: | This template invokes the installation of the network component, and since the new version needs to be installed, I just changed it to invoke the new one: | ||
Line 67: | Line 74: | ||
�/software/components/network/version� ?= �1.2.7�; | �/software/components/network/version� ?= �1.2.7�; | ||
+ | === $L/cfg/standard/components/network/core-schema.tpl === | ||
+ | Several solutions were considered for making possible the adaption of the schema to '''IPv6''' addresses. The first one is to change the the definition of ''type_ip'' to: | ||
− | |||
− | |||
type type_ip = { | type type_ip = { | ||
"ipv4" : type_ipv4 | "ipv4" : type_ipv4 | ||
"ipv6" ? type_ipv6 | "ipv6" ? type_ipv6 | ||
}; | }; | ||
− | This one was quickly out, since this would need more changes in the network component, and since so far sites use only IPv4, it would make no sense to have a type_ip with only one parameter. | + | |
− | The second one was to define | + | This one was quickly out, since this would need more changes in the network component, and since so far sites use only IPv4, it would make no sense to have a ''type_ip'' with only one parameter. |
− | Finally, the third solution, which is the adopted one, just includes some extra parameters in the types structure_network, structure_interface, and structure_interface_alias. I thought that this solution would be the easiest one to implement, since not all the parameters in a structure would need to be defined, so this would be ideal for sites that wanted only IPv4. | + | |
− | The interface (Also the alias) need to include an extra IP (Only type_ipv6). The interface includes the gateway for IPv6 and a parameter to initialize IPv6 in that interface. I have bolded the new parameters: | + | The second one was to define ''ip'' as ''type_ip[]'' in the ''structure_interface'' and ''structure_interface_alias'', but this also would make more difficult the changes in the component. |
+ | |||
+ | Finally, the third solution, which is the adopted one, just includes some extra parameters in the types ''structure_network'', ''structure_interface'', and ''structure_interface_alias''. I thought that this solution would be the easiest one to implement, since not all the parameters in a structure would need to be defined, so this would be ideal for sites that wanted only IPv4. | ||
+ | The interface (Also the alias) need to include an extra IP (Only ''type_ipv6''). The interface includes the gateway for '''IPv6''' and a parameter to initialize '''IPv6''' in that interface. I have bolded the new parameters: | ||
type structure_interface_alias = { | type structure_interface_alias = { | ||
Line 86: | Line 96: | ||
"broadcast" ? type_ip | "broadcast" ? type_ip | ||
}; | }; | ||
− | |||
type structure_interface = { | type structure_interface = { | ||
"ip" ? type_ip | "ip" ? type_ip | ||
Line 110: | Line 119: | ||
"ring" ? structure_ethtool_ring | "ring" ? structure_ethtool_ring | ||
"ethtool" ? structure_ethtool | "ethtool" ? structure_ethtool | ||
− | |||
"vlan" ? boolean | "vlan" ? boolean | ||
"physdev" ? string with exists ("/system/network/interfaces/" + SELF) | "physdev" ? string with exists ("/system/network/interfaces/" + SELF) |