Warning: possible access problems this weekend
« previous post | next post »
The Linguistic Data Consortium will change its network IP address between 4PM and 6PM EST on Friday, November 12th. During that time, Language Log will be unavailable, since its server is on the LDC network.
It may take up to 72 hours for external networks to propagate the new IP addresses, so Language Log readers may have trouble accessing the site until Monday, November 15th. The new IP address, if you're able to make use of this information, should be 128.91.252.31.
In addition, I'm now in Groningen for ExAPP 2010, and will be traveling back to the U.S. on Saturday, so I may be an even worse correspondent than usual this weekend for independent reasons.
Peter G. Howland said,
November 11, 2010 @ 7:49 pm
Whole leash hit, Mark! Now whatta my gonna do this weekend?
K. Krishnamurthy said,
November 11, 2010 @ 7:53 pm
I thought the title was going to be another crash blossom and sat here for five minutes not reading your post trying to guess what it might mean (I couldn't understand how the last one with the skeletons was supposed to be a crash blossom either!)
Amy Reynaldo said,
November 11, 2010 @ 7:54 pm
What?!? This is an outrage. Please cancel my susbscription and refund the remaining Language Log dues I have paid.
People, shall we convene a protest at Language Log Plaza Friday at 5:00? I'll bring cookies.
Telofy said,
November 11, 2010 @ 8:11 pm
Am I right to assume that it’s mostly a DNS issue? If so, then you could just give us the new IP address so that we can access the site directly, when the domain ceases to work.
Julie said,
November 11, 2010 @ 9:07 pm
How are we going to survive?
Andrew said,
November 12, 2010 @ 12:35 am
Did they not know that they were going to be doing this? Because if they did, then they could have reduced the TTLs ahead of the change (one TTL ahead) to cut down the outage quite a bit.
(On the good news front, the current TTL is actually 24 hours, so properly-run networks shouldn't see an outage longer than that.)
Jason Stokes said,
November 12, 2010 @ 6:24 am
Am I right to assume that it’s mostly a DNS issue? If so, then you could just give us the new IP address so that we can access the site directly, when the domain ceases to work.
Perhaps, but connecting directly to the IP address doesn't work with Virtual Domain Hosting, which depends on the DNS name as provided in the HOST http 1.1 header to work. I understand most sites use virtual domain hosting these days.
But if you absolutely can't do without language log for a weekend, virtual hosting problems could be worked around by pairing languagelog.ldc.upenn.edu and the new IP address in your local hosts.txt file. You could find out the new IP address by querying a DNS server web gateway to whom the new IP address has already propogated. Perhaps a gateway based in the .edu domain, most likely to use a TLD server close to the upenn DNS.
It's just a matter of how much techie wonkery you want to have to figure out.
GeorgeW said,
November 12, 2010 @ 7:38 am
@:Julie: That was my initial reaction as well. Then after calming down, I thought why not make the best of a bad situation and use the time to replace that broken window, unplug the toilet and figure out why the refrigerator isn't working.
zoetrope said,
November 12, 2010 @ 9:19 am
Make sure you get a nice warm stroopwafel while you're here =)
Telofy said,
November 12, 2010 @ 3:58 pm
@Jason Stokes: Thanks. At the moment, there don’t seem to be any vhost problems, though. I suspected that too, but when I tried 158.130.17.5, it was Language Log herself who answered.
The University of Pennsylvania has at least three DNS servers: 128.91.2.13, 128.91.254.1, and 128.91.254.4. There are a few more in what, I guess, may be the vicinity: 128.175.13.16, 128.175.13.17, 128.91.254.1, and 128.91.251.158.
If you use (something akin to) Linux, just put those servers—or the one whose IP looks prettiest—prefixed with “nameserver ”, into your /etc/resolv.conf. For example:
$ cat /etc/resolv.conf
nameserver 128.91.2.13
nameserver 128.175.13.16
nameserver 192.168.0.1
You can also resolve the domain name manually with “dig @server languagelog.ldc.upenn.edu”. For example:
$ dig @128.91.254.1 languagelog.ldc.upenn.edu
(Please correct me if there are made any mistakes.)
Alternatively, someone could just stop by and tell us the future IP address.
Good luck everybody!
[(myl) I'm told that the new IP address will be 128.91.252.31]
Telofy said,
November 12, 2010 @ 6:07 pm
Marvelous, thanks! Those four bytes will likely save the weekend for many of us.
(And, um, I couldn’t decide between the first person and the expletive construction, so I went for a hybrid.)
Chris said,
November 12, 2010 @ 6:19 pm
@Jason I only have wink as a political reference. Is it being used in other semantic domains as well?
Chris said,
November 12, 2010 @ 6:21 pm
"Wonk"; damn you autocorrect!
groki said,
November 13, 2010 @ 11:42 am
@Chris:
the political usage seems to have grown out of an academic one: wonk's thesaurus entry at thefreedictionary.com says "an insignificant student who is ridiculed as being affected or boringly studious," with synonyms dweeb, grind, nerd, and swot.
(and I hope the typo gremlin leaves me alone here!)
xyzzyva said,
November 13, 2010 @ 3:49 pm
Is this also responsible for the inoperative RSS feeds for comments (at least when using Google Reader)?
How dare I be asked to use my limited supply of bookmarks to remember to check for responses to my comments… uh oh, here goes another one.
Sili said,
November 13, 2010 @ 7:04 pm
Plz for to make account to pay for appreciating LL. Kiva or Donors Choose will do.
john riemann soong said,
November 16, 2010 @ 4:05 am
languagelog redirects languagelog.org and languagelog.com not currently working.
Nick Lamb said,
November 16, 2010 @ 9:07 am
"It may take up to 72 hours for external networks to propagate the new IP addresses"
This is an administrative goof. Yet it's astoundingly common. It's as if it was normal for businesses to move premises and not mention in advance (flyers – window signs – maybe even a local radio commercial) where they're going, and so for a few days nobody will know where the Happy Mart went…
DNS is a caching infrastructure. Each DNS answer has an associated validity period or Time To Live. So the question "what's the address of languagelog.ldc.upenn.edu" might get an answer "128.91.252.31 and that's good for 18 hours and 6 minutes". The intermediate servers between your authoritative server and the many clients run by readers will pass on the cached answers they have, until their TTL is exhausted. Then they ask again.
So before changing addresses you (and "you" here could mean "the computer, automatically, upon being instructed in advance of the change") should reduce the TTL for the affected records. This means the cache is less efficient (loading LL may be a tiny bit slower for some people) but the change will be picked up more quickly when it happens. Then once the change is made you should put the TTL back.
This isn't aimed at our favourite Language Log Team, but at their minions (or more realistically, some UPenn sysadmin who ought to know how to do this properly by now). When planning your next address change, put "reduce DNS TTL" in the diary for a few days before the change. But to the team and anyone non-technical reading – if you know about a change in advance you can avoid this problem, don't accept "it's hard" for an answer from professional sysadmins.
Nick Lamb said,
November 16, 2010 @ 9:16 am
john riemann soong, the "right" way to have made those names work is with a DNS CNAME record, but instead they just copy-pasted the IP address.
It's the difference between "Covenant Expansion – see John Smith" and "Covenant Expansion – see page 76". One of these references still works after you move the entry on John Smith's Covenant Expansion to page 84, the other does not.
languagelog.org seems to be owned by Mark Liberman so perhaps he can fix it to use CNAME or just the newer address.