Ruby version annoyances: X.times.inject with LocalJumpError

So, you have fancy spiffy code.  It looks kinda like this:

It works great on your local machine, doing what you need.

Then, you deploy.  And the world ends.  It ends, not in fire, or water, but a LocalJumpError, like so

“WTF?” you think.

Check your Ruby versions.  I bet production is 1.8.6 and your local machine in 1.8.7.  Naughty.

1.8.7 will implicitly do a .to_a right before the inject.  1.8.6 does *not*.

Here’s how to make it work in both:

Want an SSH proxy? Think they’re a myth, like unicorns?

They’re not.  Either of them.

Unicorns live in the land of make believe, with leprechauns, fairies, and knowledgeable phone support techs.

Recently, I had the occasion for one.  An SSH proxy, not a unicorn.  Keep up.  Short story, started using a VPN.  Random IPs are not awesome for setting up in a firewall.  But I *do* have a virtual server somewhere.  It’s IP is not random, and never changes.

“I bet I can use it for a proxy” says I.  So I go looking.  Examples of how to do SSH tunnels abound.  That’s not quite what I had in mind.  See, you have to setup a tunnel all the time, in order to use it.  That’s *way* to much work.  Plus remembering that “ssh -p 2222 localhost” is server X, and “ssh -p 2223 locahost” is server Y is a giant pain in the hole.

“There must be a better way” thought I.  And there is.  You can put a ProxyCommand into your ~/.ssh/config file.  

Like so:

This says “when I try to connect to any server that ends in .example.com, use my.virtualserver.com”

This command sets up a nc (read about it) process which just takes your input, and shoves it to the remote server.  Everything works like you’d expect.  Even your ssh-agent.  

Requirements:

  • Server you can SSH too with a fixed IP, ideally auth’d with keys
  • nc installed on said server

That’s all.

What do the bits of the nc command do?

-w 3600: Timeout in 3600s with no input

%h: use this host (SSH fills that in)

%p: use this port on that host (SSH fills that in).

Like screen? Wish it was your login shell?

So do I.  And so did I. And being a smart guy, I made it so.

Oh, didn’t I come to regret that decision.  See, if you make screen your login shell (via /etc/passwd or some other mechanism) lots of things stop working.  Like rsync.  Like ssh’ing with a command, rather than for a shell.

Sure, you get a shared screen environment across *all* your logins.  ( Honest, it’s cool.  Open up two different ssh sessions and type in one.  It’s echo’d to both.  Spiffy. )  But now lots of tools have stopped working, and you just can’t deal with it.

With a heavy heart, you set your shell back to bash.  (Yes, bash.  You zsh guys can go now.  Go on. )

Wait!  Don’t give up.  For I, along with the miraculous powers of the interwebs, have a solution.

Muck with your .bashrc file.  Now, I see the lightbulb.  ”I can just replace my .bashrc contents with `screen -R`!! Yay!!!’  No.  Bad user.  Bad bad user.  Naughty things will happen.  Like a screen loop.  Just think it through.

But happily, there’s an easy solution.

Behold!

See, the extra shell variable only kicks the screen process into life once, then the 2nd time ‘round it executes the rest of your .bashrc file.  Oh, make sure this is real near the top.

Win!  Screen goodness that doesn’t break all your servery tools!!!

What’s screen, you ask?  Hey, why didn’t you ask before we started?  Honestly.  Anyways, it’s a “terminal multiplexer.”  Just go here and read about it.

iptables and you: how to avoid heartbreak

And by “heartbreak” I, of course, “being unable to talk to your server.”

The best advice I can give is, make sure you have easy access to the server console, whether by walking downstairs, across the building, or via some sort of networked console device.  If you don’t have this, you don’t need my advice, because you’re an iptables veteran.

If you’re *not* a veteran, then learn from me.  Or don’t, I care not.

Lots, and I mean *lots* of iptables “how tos” dive into the commands, and a large quantity start with something like this:

Which is all well and good.  Unless you’re typing the commands by hand into an SSH session.  What happens then, you ask?  Well, I’ll tell you.

As soon as you even think about lightly caressing the enter key after typing in “iptables -P INPUT DROP”, the game is over.

You see, in iptables land, that means “LALALALALA NOT LISTENING LALALALA.”  And there’s no “let me enter a bunch of commands, then implement them” feature.  Oh no, everything takes affect at *lightning* speed.

So, use a console.  Or at least have access.  Or put all your commands into a script, which will keep running while your SSH access is axed, then you can log back in.

What’s that?  You’ve already *done* that, and don’t have console access?  Well, best email support at your hosting provider.

What?  You have your own servers in a data center far far away?  That’s silly then.  Hope your emergency callout rate isn’t too high, or that it’s in business hours wherever they are.

Well, there’s *one* thing that would save you.  Just *one*, and it’s unlikely it’ll help *you*, Mr. (or Ms.) interwebs.  If you have some sort of remote power management, or *any* way to power off your server *without* the normal shutdown scripts running, you’re ok.

See, iptables doesn’t save it’s rules after every change.  Only when you ask it to, or on shutdown via most distribution’s init scripts (or whatever they use).  So if you can hard power cycle it, you’ll be ok, since the changes will get “undone.”

Hopefully you’ve found this article before, rather than after.