Closed
Bug 563646
Opened 14 years ago
Closed 12 years ago
[irc.mozilla.org] Add IPv6 if its not already added
Categories
(mozilla.org Graveyard :: Server Operations, task)
mozilla.org Graveyard
Server Operations
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 757373
People
(Reporter: jesper, Assigned: justdave)
References
Details
We're running out of IPv4 address space. So adding IPv6 should be done. The Unrealircd version installed already supports it, but has to be recompiled if its not Can be done during ./Config
Comment 1•14 years ago
|
||
We don't really have a production v6 network where irc.mozilla.org could live. That's not likely to change any time soon either.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Comment 2•13 years ago
|
||
Sticking this back in the projects queue for when IPv6 support at Mozilla is working, especially since Mozilla now has its own IPv6 block (http://whois.arin.net/rest/net/NET6-2620-101-8000-1).
Assignee: server-ops → nobody
Status: RESOLVED → REOPENED
Component: Server Operations → Server Operations: Projects
Resolution: WONTFIX → ---
Updated•13 years ago
|
Status: REOPENED → NEW
Comment 3•13 years ago
|
||
Still not likely to change without swapping out certain vendor hardware that doesn't support v6.
Comment 4•13 years ago
|
||
Is that what bug 630581 is about? (I can't see that bug) Might be nice if Mozilla could take part in World IPv6 day :-) (http://isoc.org/wp/worldipv6day/)
Comment 5•13 years ago
|
||
Bug 630581 is the master tracking bug "Deploy IPv6 to the infrastructure." World IPv6 Day is symbolic, and while we will attempt to have some subset of services in place our primary focus organization wide is the release of FF4. There are also many other prerequisites to having a v6 offering that may not allow us to be ready in time. Rest assured, however, v6 is on Netops road map and once the infrastructure is in place we can begin offering services in earnest.
Updated•13 years ago
|
Assignee: nobody → server-ops
Component: Server Operations: Projects → Server Operations
Whiteboard: [ Post FF4 ]
Updated•13 years ago
|
Assignee: server-ops → nmeyerhans
Comment 6•13 years ago
|
||
Let me know when you have it up and I'll give it a shot. I just moved my IRC client to a v6 single-stack host due to having exhausted my /28 of v4 space.
Comment 7•13 years ago
|
||
The current status here is that concrete.mozilla.org has v6 connectivity. It's currently using an autoconfigured address. The next steps should be as simple as: 1. Allocate and configure a static address, per netops address assignment policies. 2. Configure DNS. 3. Restart ircd. I'm hesitant to do this right now because concrete is in the irc.mozilla.org rotation and thus has active users on it.
Comment 8•13 years ago
|
||
Why do you need to restart the ircd? The *only* potential reason I could see for that is if the server binary itself didn't have IPv6 support compiled in...
Comment 9•13 years ago
|
||
Because ircd won't magically bind to the newly configured v6 addresses. It does that at startup.
Comment 10•13 years ago
|
||
Can't you just configure the new IP in the config under listener ports and rehash?
Assignee | ||
Comment 11•13 years ago
|
||
We could attempt that, and if it fails, then we just wait till the next time it's getting restarted for something else and it'll magically pick it up. The problem, though, is that the irc geodns is being done by CNAME right now, so we'd essentially have to put concrete's IPv6 address into DNS as an address for sand to avoid breaking people if sand doesn't also have connectivity.
Comment 12•13 years ago
|
||
(In reply to Dave Miller [:justdave] from comment #11) > We could attempt that, and if it fails, then we just wait till the next time > it's getting restarted for something else and it'll magically pick it up. > > The problem, though, is that the irc geodns is being done by CNAME right > now, so we'd essentially have to put concrete's IPv6 address into DNS as an > address for sand to avoid breaking people if sand doesn't also have > connectivity. That's probably not necessary, unless you're worried about breaking ipv6-only hosts. A dual-stack host that gets only sand's v4 address back from DNS will be OK. However, digging further into ircd's setup, it does appear that we'll need to rebuild ircd. config.status indicates the following: configured by ./configure, generated by GNU Autoconf 2.61, with options \"'--with-showlistmodes' '--enable-nospoof' '--enable-hub' '--enable-ssl' '--enable-ziplinks' '--with-listen=5' '--with-dpath=/home/ircd/unreal' '--with-spath=/home/ircd/unreal/unrealircd' '--with-nick-history=5000' '--with-sendq=3000000' '--with-bufferpool=18' '--with-hostname=concrete.mozilla.org' '--with-permissions=0600' '--with-fd-setsize=4096' '--enable-dynamic-linking'\" We're apparently missing: --enable-inet6 Make the IRCd support IPv6 Testing concrete's build of unrealircd on another host confirms that v6 support is completely missing.
Comment 13•13 years ago
|
||
If you're going to rebuild, go ahead and update to Unreal3.2.8.1. Though, reading the release notes for the (unreleased) Unreal3.2.9, there are a few IPv6-related things that may be of note under bugs fixed: - IPv6: admins no longer have to tweak sysctl, like on FreeBSD & newer Linux systems - IPv6: IPv4 ip's in link::bind-ip did not work properly which made the IRCd either not bind to the correct IP, or - like on FreeBSD - made it unable to link at all. - CGI:IRC & IPv6: sometimes a users' IP was incorrectly formatted, causing 'ghosts'
Comment 14•13 years ago
|
||
More specifics: - Fixed IPv4 ip's in link::bind-ip on IPv6 builds. This caused issues ranging from not binding to that ip when linking, to not being able to link at all. Also fixed a very small memory leak upon /REHASH. Bug reported by Mr_Smoke (#0003858). - IPv6: it seems some recent Linux dists decided to make IPv6 sockets IPv6-only, instead of accepting both IPv4&IPv6 on them like until now. FreeBSD (and other *BSD's) already did that move a few years back, requiring server admins to sysctl. We now make use of a new option to explicitly disable "IPv6-only". This should work fine on Linux. Whether it provides a complete solution for FreeBSD, I don't know, testing is welcome! In theory setting net.inet6.ip6.v6only to 0 should no longer be needed, but you might still need to enable ipv6_ipv4mapping. - IPv6 clones detection support (#2321). allow::ipv6-clone-mask determines the number of bits used when comparing two IPv6 addresses to determine if allow::maxperip is exceeded. This allows an admin to recognize that most IPv6 blocks are allocated to individuals, who might each get a /64 IPv6 block. set::default-ipv6-clone-mask defaults to 64 and provides default value for the allow blocks.
Updated•13 years ago
|
Assignee: nmeyerhans → dparsons
Comment 15•12 years ago
|
||
16:42 < cj> any idea when we'll see an AAAA record? 16:42 < cj> for irc 16:43 <@ashish> fox2mike: ^^ 16:45 <@fox2mike> not really sure 16:46 <@dumitru> cj: https://bugzilla.mozilla.org/show_bug.cgi?id=563646 16:46 <@dumitru> we have a tracking bug already... 16:47 < cj> so never? 16:47 <@dumitru> the bug is not closed 16:47 < cj> it doesn't take seven months to close this type of bug :) Do you need me to fix this for you? 16:49 <@dumitru> looking at the last comments, it seems that we'll need to recompile unrealircd with ipv6 support, and also an upgrade was suggested 16:50 <@dumitru> unfortunately we got swamped with other projects more critical than this enhancement...we'll get to it eventually :) 16:50 < cj> I could certainly compile unrealircd for you. What platform should I target? 16:51 < cj> do you need a server in SEA? I could host one for you or give you a VM, provided the person I give an account to isn't more than a couple of hops from 0xBA27A83C 16:53 <@dumitru> looks like all our 3 nodes are on 32bit flavor of RHEL 5.7 16:54 <@dumitru> thanks for the offer for the VM cj
Comment 16•12 years ago
|
||
Hey there Dan, http://pgp.cs.uu.nl/mk_path.cgi?FROM=C52E920F&TO=BA27A83C&PATHS=trust+paths I can't say I know anybody past Mako, but I know it's hard to get an @mozilla.com address, so it'll do. I don't have an RHEL license, though, so I might need to bother you or someone at redhat. I'll go do that now. Cheers, C.J.
Assignee | ||
Comment 17•12 years ago
|
||
We'll probably do this as part of our migration to the new datacenter over the next month or so. Since we'll need to deploy a new IRC server then anyway, it'll be a good time to do it.
Assignee: dparsons → justdave
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 14 years ago → 12 years ago
Resolution: --- → DUPLICATE
Updated•9 years ago
|
Product: mozilla.org → mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•