Either patch it manually:

• Edit wp-admin/includes/file.php and change line 448 to a more reasonable default.
• The line sould become something like: $response = wp_remote_get($url, array('timeout' => 600));

Or use this patch:

When I tried adding the above patch as a download (using the download monitor plugin) I got this failure:

What the fuck guys, this is a TEXT file. Grepping through the sources I find the wp-admin/includes/file.php file to be the nazi. Apparently I’m not allowed (as site admin) to pass this current_user_can( 'unfiltered_upload' ). Security hardening, yeah… against idiots perhaps.
I’m expecting an update of either wordpress or the download monitor plugin soon.
Meanwhile I simply uploaded the file manually and added an existing download. Pfffrt, the hassle.

Do they have a cute little firewall at your work that only allows outgoing traffic on a certain port? Does some site have retarded IP restrictions? Does the piratebay block you from home?
Have no fear, ssh is slow as a bear. (huh?)

Anyway, you could use an anonymous proxy to get around all of this, but they are often slow and hard to find. Not only that, they often require you to use a specific port.
So the simple solution for all this: use ssh. Of course this requires you to have ssh access on a machine outside of the network that you’re trying to get out of.
But if you don’t even have that, you probably suck anyway. (get lost with your micro~s fail piece of cardboard).

Solution #1, for simple TCP port forwards. For instance when you’re trying to access a remote snmp server that has the irc port (6667 by default) firewalled:

After a successful login you can now connect an IRC program to localhost on port 1234 and it will act as if you were connecting to the remote machine directly. (bypassing the firewall).
Woei. Too bad this fails for UDP though. You also need to keep the ssh connection open, but that’s pretty obvious.

Solution #2, for a real proxy solution. When you’re trying to access a remote web server it becomes more annoying to use a simple port forward, since your browser will not pass the correct
information to the remote server. (It will say Host: 127.0.0.1 for where it was supposed to be Host: www.piratebay.org for example).
To make this work we simply turn ssh into a socks proxy like this:

Now you can enter localhost and port 1234 in your browser’s proxy configuration in the SOCKS proxy section. Magic, you can now go to any site and it will be tunneled through the nicely encrypted ssh session. (although it might be a bit slower).

Well, so much for the obvious stuff today.

So after the latest local root exploit thing, and testing it on some machines during har2009, I figured it might be nice to get the patch into my kernels. Running a webserver usually means you’re at risk after all, especially when it’s running wordpress

So I grabbed the latest kernel that had that patch and went for the usual make menuconfig ordeal. After half an hour of selecting “yes”, “maybe”, “I guess so”, and
some XEN options (CONFIG_PARAVIRT_GUEST=y, CONFIG_XEN=y, CONFIG_HVC_DRIVER=y, CONFIG_XEN_BLKDEV_FRONTEND=y, CONFIG_XEN_NETDEV_FRONTEND=y, CONFIG_XEN_KBDDEV_FRONTEND=y, CONFIG_HVC_XEN=y, CONFIG_XEN_BALLOON=y, CONFIG_XEN_SCRUB_PAGES=y, CONFIG_XENFS=y, CONFIG_XEN_COMPAT_XENFS=y) I built the thing.
As I usually build bzImages I also did so here. make bzImage modules modules_install.
Half an hour later I had a shiny bzImage. Let’s try it on a test domain!

I copied the bzImage to /boot, changed the kernel = "/boot/vmlinuz-xen-old" option to the new place, and GO!
This is what it told me:

Huh, where’s my console?
Checking xm list it seemed to be there… but paused… and with constantly increasing ids. Waaait a minute!
Checking the log files (xend.log in this case) revealed a secret:

Note the ‘WARNING’ line. Crashed?!
Gee, that’s … interesting. Why? Took me 5 minutes to find the other log file, but xend-debug.log had a magic line:
ERROR Invalid kernel: xc_dom_find_loader: no loader found
… great. Another why.
In case you’re wondering, the increasing status in ‘xm list’ was caused by the on_crash = 'reboot' line in the xen host config.
I quickly destroyed the doman and changed it to a oneshot try: on_crash = 'destroy'

After some searching another hint presented itself. Aren’t they nice?
This hint was: “Xen is a retarded piece of cancer and can’t decypher the bzImage format, try vmlinux instead”. Aha!
Back to the kernel, make vmlinux, copy, and another try to boot it. Obviously this was way too simple. It still crashed.
Checking my old kernel that works for both dom0 and domU with file I noticed that gz should at least work.

Some more details about the crashing domains can be found using xm dmesg
It gave me something like:

As you can see, that’s really useful…..

A useful page with some info can be found here. It confirms that a gz kernel should work (but bz probably doesn’t) since I’m still running Xen 3.2. However, I can’t find a good reason for why it won’t work.

Google to the rescue! Hard to find a useful keyword, since most xen kernel issues seem to be similar, but eventually I found this tidbit:
tiny kernel patch.
Weird that this should be needed, one would hope that basic shit like this would work after 8 kernel versions, but obviously they’re all retards when it comes to this.
Thanks Jeremy Fitzhardinge for the patch!
Just for quick reference, this is the actual patch:

So much for ‘vanilla’.

However, it boots now:

and a lot more yadieyada until it hits a new wall: root device.
Well, that sounds solvable.

In fact, here’s a solution. What you say?
“AAAAH, I GET NOTHING, IT WON’T EVEN CRASH ANYMORE, JUST NO OUTPUT???!”
Ah yeah, I forgot to mention: they changed the console device as well as the block device. So here’s a solution for both issues:
Edit your xen host config file and make it so:

(xvda1 is what used to be sda1, you can figure out the rest).

And after all this: HAHA! Success is mine!
Except of course for the undeniable fact that my domU has a fucked up fstab and all, but no issues there
Now go mess up your own system! Oh, I see… you already did. Good luck fixing it

Update

I just tested a testing kernel — 2.6.31-rc8, and it seems like they fixed it. Probably has been fixed in the testing branch for quite a while now, but still not in stable 2.6.30
Let’s hope they release 2.6.31 soon.

As for the upgrade, once again I had to manually increase their timeout to more than 60 seconds.
Just for reference:
Edit wp-admin/includes/file.php with your favorite editor and change line 448 so it has a more reasonable timeout, I put it to 300: