Task #1154
closedadd IPv6 to manitu servers
0%
Description
The manitu servers currently come without IPv6 - the VM hosts do not have it, while the VMs have it
Updated by Florian Effenberger over 9 years ago
- Subject changed from add IPv6 to falco to add IPv6 to manitu root servers and big boxes
Updated by Florian Effenberger over 9 years ago
- Subject changed from add IPv6 to manitu root servers and big boxes to add IPv6 to manitu servers
- Description updated (diff)
Updated by Florian Effenberger over 8 years ago
Is there a lot of work involved? Before groing our infra, it might make sense to get this dealt with, now that Debian 8 is rolled out
It's still not high priority, so if it takes lots of resources, we can defer - interested to hear if it takes a lot of effort (e.g. wrt. firewalling and routing).
Updated by Alexander Werner over 8 years ago
It's just stupid work that takes some time.
Good time during the migration on the rack.
Updated by Alexander Werner over 8 years ago
- Related to Task #1835: migration to own rack added
Updated by Florian Effenberger over 8 years ago
- Target version changed from Pool to Qlater
Shifting to later due to the infra changes
Updated by Florian Effenberger about 8 years ago
- Assignee changed from Alexander Werner to Guilhem Moulin
re-assigning to Guilhem in order to clean up Redmine queues
nothing concrete to do at the moment
Updated by Florian Effenberger over 7 years ago
I read something about IPv6 firewalling in the recent agenda - is this still an issue, or has this ticket been dealt with?
Updated by Florian Effenberger over 7 years ago
A sudo ifconfig | grep inet6
on the big manitu boxes yield only fe80:: addresses, so it seems to be pending still indeed ;-)
Updated by Florian Effenberger over 7 years ago
- Target version changed from Qlater to Q4/2017
Updated by Florian Effenberger about 7 years ago
- Related to deleted (Task #1835: migration to own rack)
Updated by Florian Effenberger over 6 years ago
- Target version changed from Q4/2017 to Q2/2018
With this ticket being regularly shifted, I wonder how much work the task entails and what other constraints apply
Major firewall topics?
Adjustments for Gluster?
I'd like to prioritize this one accordingly
It's not a big deal, but still something we IMHO should "just do" if possible :)
Maybe for one of the next maintenance windows, when there's a downtime anyways?
Updated by Guilhem Moulin over 6 years ago
Florian Effenberger wrote:
Major firewall topics?
Adjustments for Gluster?
Neither. The firewall will stay shut (only TCP/22 for incoming packets), and Glusterd will keep chatting in the private v4 space (using the 10G pipe that can be found in the rack).
I'd like to prioritize this one accordingly
It's not a big deal, but still something we IMHO should "just do" if possible :)
Yeah but it falls in the “nice to have” category as v6-only admins can still reach the boxes. In fact the only thing I can think of where lacking v6 would hit us is if one of the very few hosts these boxes try to reach (deb.debian.org, mail.documentfoundation.org, and it's pretty much it) removes v4 records. And that's veeery unlikely.
Maybe for one of the next maintenance windows, when there's a downtime anyways?
No need to bring the network (let alone the host) down to do this.
Updated by Florian Effenberger over 6 years ago
- Target version changed from Q2/2018 to Pool
Ok, then let's de-prioritize that and put it to pool
Updated by Florian Effenberger over 5 years ago
- Status changed from New to Rejected
Let's drop this one - not really important