Skip to main content

Posts

Fixing "DB_RUNRECOVERY: Fatal error, run database recovery" when attempting to run yum update

Comcast is my current home ISP. Over the last year, I've had a ton of problems with them filtering all sorts of legitimate (outbound) traffic . The latest fun times I've had is the random dropping of SSH connections on both standard (22) and non-standard TCP ports. This occurred while I was running a `yum update` on one of my servers and I hadn't used ` nohup ` or ` disown ` to allow the processes I had spawned to continue to run. By the time I had got a VPN connection up and running, the yum process had been terminated, which in turn caused yum's database to become corrupt. How can you tell that your server's yum database is corrupt? Running yum will generate this vaguely-terrifying error: # yum update error: rpmdb: BDB0113 Thread/process 4498/140039588845376 failed: BDB1507 Thread died in Berkeley DB library error: db5 error(-30973) from dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db5

The most irritating part of the Windows UI

Its come to my attention that blog has way too much helpful technical information and not nearly enough bitching & complaining. With today's post, I hope to tip the scales a bit. During the course of the day, I use a variety of operating systems. Most of my desktop computers use Windows, most of my servers use some version of either linux or bsd, and a large number of my customers use Macs (which I know underneath the branding is also linux, but we are talking about UI stuff in this post, and in that department OS X qualifies as its own thing). Over the last 20 or so years I've alternated between which operating system I use most frequently, based on what kind of work I'm doing as well as what is inexpensive, secure and effective at the time. Lately I've had a series of Windows laptops that I've spent a fair amount of time working with. It is what it is, I don't want to get off topic. This isn't some mouth-breather-y attempt to measure the manhood be

Torrent data transfer problem: Description & workaround

    Several days ago I noticed that several Comcast / Xfinity residential internet connections throughout the Southeastern US were unable to download or upload torrents. I have a hunch that Comcast implemented a new manner of filtering for customers in my area with the intent of stamping out P2P traffic, however I am not certain if this is the case yet, so I am holding off on a tirade about the friendly neighborhood corporatist internet monopoly for now. I'm interested to know if any other P2P users have encountered similar issues - if so, I hope this post can help.      The torrent client used for file sharing on these connections was qbittorrent, and listened for incoming connections using a random TCP port assignment that changed each time the client was restarted. Outbound connections used something in the high range on the local side (e.g. TCP port 59999) while on the remote side the port would also be random. It was possible to establish a connection to remote hosts using

Can Keybase.io save the internet?

When used correctly, encryption works really well. It works so well that most people can't wrap their brain around how powerful it is. The biggest gains we can make in improving online security and privacy won't be the result of making encryption better. Most of our problems are the result of how encryption is used. At the moment, using encryption is complicated. Its not complicated to the point where you need special training to use it, but its complicated enough that its a pain in the ass for non-technical people to adopt. So non-technical people don't adopt encryption. That's a real problem - because most people are non-technical. Actually, its worse than that, because it means only communications between technical people can be secured with any regularity. Even technical people can't communicate securely with non-technical people. Encryption can only be truly successful with massive levels of adoption. Even with all of its problem, HTTP-based SS

Free Bitcoin giveaway from Coinbase

Popular Bitcoin exchange Coinbase has started a Bitcoin giveaway. Signup for a Coinbase account using the partner URL below, purchase US$100 worth of Bitcoin, and get US$10 worth of free Bitcoin for your trouble. Here is the special partner URL . You have to signup using a partner URL in order to be eligible. So sign up, tell your friends, and get some free BTC!

Recovering network access to EC2 instances

So you've screwed something up. You made a typo in your sshd_config file. You added a firewall rule, or a route, or some other thing, and lost your network access to your EC2 instance. And of course whatever you broke, you broke permanently - you wrote your firewall rules directly to /etc/sysconfig/iptables, you made your goofy change to /etc/sysconfig/network-scripts/whatever-interface; so rebooting won't make a damn bit of difference. You read the warnings, you know you shouldn't have. But you did anyway. Oh, and you don't have any backups. Or you have backups from three months ago. Restoring from your crappy backups would mean hours to days of non-stop work and consistent downtime. Or Amazon or whatever other company you're using for backups actually broke your backups/lost your backups/never actually provided you with the backups you paid for. Don't panic. You've got this . You remember that Amazon has some sort of Java-based something or other. Its

PuTTY hack keeps SSH session data out of Windows registry

A lot of people connect to Linux machines from a Windows desktop computer. Despite the number of people that have to do this for one reason or another, there are hardly any SSH clients for Windows. Basically there's three - Bitvise , Dameware and PuTTY . I've almost always used PuTTY. There are problems with all of these clients, including PuTTY. One of the smaller issues with PuTTY that I've nonetheless always found annoying is that it is not quite as portable as it appears to be. Installing the client is usually as simple as downloading and running the EXE file, but vital information about saved sessions as well as seed data gets stored in the Windows registry, where it can be forgotten about. Or where someone else can grab it. That's not really the fault of the developer; if I was making PuTTY today I doubt I would do anything differently. Its a garbage collection thing. The problem is that PuTTY information can be valuable to attackers. Just about everyone who