Dev.SN ♥ developers
Sections
Dev.SN
As part of wanting to be part of a brighter and sunny future, we've decided to disconnect IPv4 on our backend, and go single-stack IPv6. Right now, reading to this post, you're connected to our database through shiny 128-bit IP addressing that is working hard to process your posts. For those of you still in the past, we'll continue to publish A records which will allow a fleeting glimpse of a future without NAT.Believe it or not, we're actually serious on this one.
We're not publishing AAAA records on production just yet as Slash has a few minor glitches when it gets an IPv6 address (they don't turn into IPIDs correctly), though we are publishing an AAAA record on dev. With one exception, all of our services communicate with each other on IPv6.
Perhaps I will write an article about our backend and the magical things that happen there :-).
We're not publishing AAAA records on production just yet as Slash has a few minor glitches when it gets an IPv6 address (they don't turn into IPIDs correctly), though we are publishing an AAAA record on dev. With one exception, all of our services communicate with each other on IPv6.
Perhaps I will write an article about our backend and the magical things that happen there :-).
This discussion has been archived.
No new comments can be posted.
We've Killed IPv4!
|
Log In/Create an Account
| Top
| 1000 moderator points
| 69 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
I'm not a robot like you. I don't like having disks crammed into me... unless they're Oreos, and then only in the mouth.
-- Fry
(Score: 2) by VLM on Tuesday April 01 2014, @08:59AM
"With one exception, all of our services communicate with each other on IPv6."
Well, don't leave us in suspense... As a guy who's had a tunnel at home of one sort or another for WAY more than a decade, the only thing that immediately comes to mind is non-cutting edge version of AFS. Which I'm guessing you're not using. So...
Hopefully not some "duh" kind of thing like you've got quagga software routing with ospfd which is inherently ipv4 only, if you wanted ipv6 you'd run ospf6d, that kind of "duh". Which as a side issue as an ex network guy it was hilarious how you could have dual stack with independent routing protocols with independent tables, and if you called those two protocols RIP and BGP no one would bat an eye but it confuses the hell out of people if both the protocols are called OSPF its just the ipv4 doesn't in any way cooperate with the ipv6 version of the same protocol. Good times, good times...
(Score: 3, Informative) by NCommander on Tuesday April 01 2014, @09:36AM
Funny you should bring up OpenAFS, as we were considered it as a method to deploy slash to the web frontends (basically have one box be an OAFS master, and the webheads replicate locally so we can update once and deploy everywhere). The main reason we dumped IPv4 is we got into the rather silly situation of having to run NAT/VPN on our staff box so we could suck up backups easily (due to our firewall setup, you can only get into our internal cluster through one point).
While OAFS is shiny, its a fucking PITA to setup, and I've got concerns about its fragility (we've got kerberos, but if our internal BIND takes a crap, kerberos stops working which breaks OAFS). We're probably going to go NFSv4 with replica to make this work, or cobble something our of rsync. Worse case scenario, we'll update nodes one by one (backwards compatibility on DB schemas makes this relatively easy).
I ran through the list of services we run, and decided to go full monty on this, and make IPv4 a legacy technology. Here's specifically what we're running with IPv6 only
I'm probably forgetting a couple of things, but these were the major ones. Aside from our mystery service (which we'll announce later today), and Apache 1.3, our migration was seemless, and we can now have our clouds interconnect and not need to NAT.
Still always moving
(Score: 2) by VLM on Tuesday April 01 2014, @10:33AM
"While OAFS is shiny, its a fucking PITA to setup"
Oh its not that bad. Google spinlocksolutions and AFS. Obviously start following the tutorial with LDAP, then kerberos, then afs... The tutorials are extremely long because of endless screencaps and tests/experiments, the actual work required is pretty minimal. My puppetmaster has a couple files, maybe a screen of manifest instructions, that's about it. It really does make life easy in the long run.
"but if our internal BIND takes a crap, kerberos stops working which breaks OAFS"
That is true, I did end up with a ridiculous amount of replication. Multiple LDAP servers, multiple BIND, etc. If you're in physical world this is cheap/free, but I can totally see in virtual/cloudy world where each virtual machine costs $$$$ and every bit/cycle is accounted for, this is a bit of a scaling/financial issue. Every 24x7 machine I have is a primary for exactly one thing also a secondary for as many other things as I can set up.
The biggest annoyance I have with AFS at home is the eternal battle between cron and AFS (really, kerberos) ... they just don't conceptually get along very well.
Mystery service that doesn't like NAT... let me guess it involves SIP protocol? SIP doesn't like NAT very much. OR let me guess, minecraft.dev.soylentnews.org?
(Score: 2) by NCommander on Tuesday April 01 2014, @10:42AM
I'll take your word for it. We're still undecided on the filesystem issue, but it looks like IPv6 support still hasn't landed in OAFS, and I rather not reintroduce IPv4 back into our BIND instance. We're going to glue the sysops heads together somepoint this month and discuss it more indepth.
As for cron and kerberos, keytabs are a wonderful thing; we use kerberosized SSH for our cron services so we don't have to deal with SSH authorized_keys madness (we have a backported OpenSSH on the server which can pop a key from LDAP which we use for staff gaining access to the network and for the SSH proxy), but kerberos allows us to have one central list of authentication. We've got master/slave KDCs setup, and BIND is replicated, though we haven't tested failover (yet). LDAP isn't, mostly because slapd is a fucking pig to setup (they threw out a perfectly sane config file for putting everything in LDAP and then poorly documented it to boot!), but all the services are using local accounts so the site itself will stay up if LDAP takes a shit on us.
As for our IPv4 only service, you'll have to wait and see. Trust me, I think you'll approve of this (and I plan to write patches to bring it to IPv6 sooner or later)
Still always moving