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)

task
Not set
normal

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
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
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 → ---
Status: REOPENED → NEW
Depends on: 630581
Whiteboard: [ Post FF4 ]
Still not likely to change without swapping out certain vendor hardware that doesn't support v6.
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/)
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.
Blocks: 631416
No longer depends on: 630581
Assignee: nobody → server-ops
Component: Server Operations: Projects → Server Operations
Whiteboard: [ Post FF4 ]
Assignee: server-ops → nmeyerhans
Depends on: 657489
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.
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.
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...
Because ircd won't magically bind to the newly configured v6 addresses.  It does that at startup.
Can't you just configure the new IP in the config under listener ports and rehash?
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.
(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.
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'
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.
Assignee: nmeyerhans → dparsons
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
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.
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
Blocks: 726783
Status: NEW → RESOLVED
Closed: 14 years ago12 years ago
Resolution: --- → DUPLICATE
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.