?

Log in

No account? Create an account
Michael Mol
16 December 2012 @ 06:51 pm
Got more stuff done today. Went to put up the new blinds in the living room yesterday, drill battery died while predrilling holes. Don't know where other battery is; it wasn't on the charger. New battery to charger, resume subsequent day.

Got holes predrilled, discover I don't have the arm or wrist for manually driving the screws for the mounts...and the drill wasn't going to fit in there. Trip to Home Depot to get a shaft extension.
 
It's easily the handiest tool I've puchased. Between that and a screw guide, getting the blinds up was almost a piece of cake; the second set certainly was.

Then come to discover I had the right drill bit for tightening some loose screws in the new chairs...and the shaft extension made that easy to handle. So crank down the torque, tighten the screws in all the chairs. The chairs are nice and rigid again.

Finally, picked up a couple toggle bolts and an L bracket...got a cabinet affixed safely and securetly to the plaster wall. Incidentally, I always know where the furnace ducts are, now...they're wherever I'm about to drive a 5/8" paddle bit in preparation to deploy a toggle bolt.
 
 
Michael Mol
09 December 2012 @ 03:40 pm
I'm loving the sound of our mechanical clock.

Tick-tock.

Tick-tock.

Tick-tock.

It just sits there, in the background, a soothing rhythmic noise. And not as offensive to other people as dubstep.

https://soundcloud.com/mikemol6453/clock
 
 
 
Michael Mol
09 December 2012 @ 08:44 am
 
 
Michael Mol
08 December 2012 @ 08:40 pm
Logs of good stuff got done today. A friend came over and helped me with a bunch of labor.

First, got the carpet in Marcus's old room ripped up and thrown out. Smelled of dog pee. What's left is a hardwood floor in dire need of refinishing, but at least the room is now usable, and we can start doing things with it.

Second, got definitive "rough opening" measurements on the side door. Involved a little demolition.

Third, ripped down the drywall ceiling in the basement. Found some mold, found some terrible electrical work, and found that at least three floor joist channels had been cold air returns for the floor above. The entire basement is now a cold air return. Thanking God I've got an inline MERV13 and a supplemental HEPA system pulling all that dust and crap out of the air. I don't think the cables running through there were plenum rated, either. Well, more stuff to fix and yank when it comes time to replace the electrical service. Need to get someone to come by and remove 80 lbs or so of torn-down drywall and other refuse. Probably going to leave the ceiling open, just because of how much more open it feels. Might take the time to drive some nails between the floorboards from below to see how much I can reduce squeaking.

Fourth, got the replacement side door ordered.

What's left on the TODO list? A lot of things. But seeing this much progress in one day makes me feel very, very good. It's like its own vacation. Just being able to see the shoddy electrical work gives me more confidence that it can be dealt with. More knowns, fewer unknowns. Feelings like that make me ambitious about tearing apart and rebuilding the house floor by floor...but I need to spread that out over time. It's rather important to have a livable house. ^^
 
 
 
Michael Mol
04 December 2012 @ 11:31 am
Every person who tells me Linux doesn't have games strikes me as ignorant.
  • Let's ignore WINE, and the thousands of Windows games it allows you to play reasonably well. (Some of those games can now only be played under WINE, since they no longer run on current versions of Windows)
  • Let's ignore the web browser, and the *millions* of small web-based games a billion or so people play every day.
  • Let's ignore Linux-native ports of every id Software game released. Let's ignore that Valve software is actively porting Steam and some of their games to Linux.
  • Let's ignore the hundreds of games that run equally well on Linux and Windows...nobody's heard of them, since nobody spent a hundred million dollars marketing them.
  • Let's ignore the thousands of games that were originally developed on Linux or other UNIX variants, and still run just fine. Again, since nobody's ever heard of them, since nobody ran a huge marketing campaign for them.
  • Let's ignore things like console emulators, making available tens of thousands of games (if you can find the ROMs) from NES, SNES, Sega Genesis, Sega 32X, Playstation, PS2 and a dozen handheld systems. Further, let's ignore that the user experience of those games is often better under emulators, for reasons ranging from more ergonomic or convenient controls to being able to save game state in games that didn't originally support it.

Ignore all that, and you might be able to say Linux has no games. But I doubt it. What you mean is that Linux doesn't have any games you've ever heard of.
I've been playing games on Linux for over ten years. What games? Call me a hipster, but you probably never heard of them...
 
 
 
Michael Mol
20 November 2012 @ 11:37 am
Saw this on Facebook today, and it struck a chord:
Back in the day, my dad bought a license. Just like me, he believes that one should adhere to the license if one use a certain piece of software.
Now, of course, we all use 7zip, which does the job just fine.
Oh, and for the record: last week I bought my first copy of Windows 7 (Hehe, yes, I did that on purpose, even though 8 was out) because my brother in law lives with us and I do not want illegal software on my network. Since his PC had a not-so-legal version of 7 on it and it needed a reinstall anyway, I coughed up the dough for it. It's a matter of principle.
Strange, you bring it up: Just yesterday, I thought of posting a status like "The availability of free software made me buy more software, because you get more aware of the ethics".
-- Jorg Willekens
 
 
 
Michael Mol
07 November 2012 @ 03:50 pm
Damn you, #google, thanks to your new #gmail  compose feature, I've watched a LUG mailing list go from mostly-bottom-or-inline posting to almost entirely top-posting. Those that have avoided top-posting simply don't quote anything, making context difficult to figure out.

#fixit. Jeez!
 
 
Michael Mol
04 November 2012 @ 08:32 am
Seriously. How often have you received a message from noreply@example.com, without a custom "Reply-To" field?

Typically, such messages will have, somewhere in them, "Do not reply to this message. If you have any questions, contact <contact details>"

This is absolutely retarded! They've sent you an email, often as part of a specific process. The email likely contains a transaction number or an incident number, enough to be part of a traceable sequence of events.

But rather than allow a response via email, they push you to a web form, or to a phone call. There's no need for this! All that's necessary is for them to use a transaction-unique email address in the Reply-To: field, and they can ensure any response gets routed to the proper destination. They can use some unique, randomized string as part of that response, to avoid spammers. Facebook does this, and I love it; most of my interaction with Facebook is via email. Or they can use a common reply address, and keep the identifying string in the subject line. Atlassian JIRA does this to attach emails as comments to bug reports.

Bottom line: If you're a developer building systems for dispatching email notification, fix your system so that email replies can be routed back as part of the process! If the next stage in the system doesn't have support for receiving routed responses that way, at least leave allowances in your portion of the system to be able to plug it in.

"noreply" needs to die.
 
 
 
Michael Mol
08 October 2012 @ 08:17 pm
Spam is incredibly common because it's dirt cheap, right? So let's make it more expensive.

What we're doing...

Our goal here is to make sending bulk email just slightly more expensive than it is, in terms of CPU consumption. It's not a bother to someone if their laptop takes a tenth of a second longer to send an email, but that same computation requirement applied to a bulk mailer who's trying to pump out several hundred thousand messages per minute? Consider that it currently would only take them perhaps a few thousandths of a seconds' worth of CPU to sling out a spam email, and a tenth of a second of CPU per email just raised their costs by a couple order of magnitude. Holy ouch!

In a world...

Imagine a system where sent emails include three additional headers:
  • X-BCrypt-Hash
  • X-BCrypt-Salt
  • X-BCrypt-Rounds
These all relate to bcrypt, which is a hashing algorithm whose computational expense can be linearly scaled by repeating a portion of the algorithm a configurable number of times. In our case, we store this scaling factor in X-BCrypt-Rounds.

bcrypt also requires a salt...which we keep in X-BCrypt-Salt. Being a hashing algorithm, bcrypt's output is a hash of its input data...which we'll store in X-BCrypt-Hash.

For input data, we'll use the concatenation of the subject and body of the message. It's not necessary to use the attachments, and we probably wouldn't want to; too many systems strip attachments before relaying messages, and the hash, subject and body are likely sufficient for our purposes.

Further, it should probably be a requirement that the value in X-BCrypt-Salt correspond to one of the listed recipients in the email. This helps ensure someone can't simply calculate the hash once and reuse it for ten thousand emails. If the X-BCrypt-Salt value doesn't correspond to a listed recipient, the server should return a permanent failure.

All three headers, X-BCrypt-Hash, X-BCrypt-Salt and X-BCrypt-Rounds must be present and valid if any are present. If any are present, and some of the three are either missing or invalid, then the server should return a permanent failure.

This time, it's for real...

As technology improves and CPUs get faster, we can increase the the value of X-BCrypt-Rounds, to increase the CPU requirements for calculating the hash for each message. Low-volume systems (so, human-driven ones) will be less affected than high-volume systems (bulk mailers and spammers).

Let us negotiate...

So, let's say both the sender and recipient servers implement this idea, but the sender is skating by with some very small scaling factor, such as '2'. Perhaps the administrator of the sending server wants to cut down on the amount of bulk mail he receives, and is insisting that senders use a scaling factor of '10'.

As the receiving server is receiving the email, it should look for the X-BCrypt-Rounds header. If it finds one, and if the value listed in that header is lower than the server demands, then the server should return a 3xx error code indicating the minimum-required value.

Now, there is a catch. The receiving server needs to go through the same calculations as the sender in order to verify the hash matches. If the receiving server didn't go through the effort, then a sender can cheaply make up any value it wants for the X-BCrypt-* headers, and not get caught!

At the same time, this does raise costs on the receiving server. A server might be tempted to forgo calculations for an email with an onerously high scaling factor. For example, let's say some joker decided to set an onerously high scaling factor, such as 1337455. Until the server has completed all of the bcrypt rounds, it can't know that the joker just provided a garbage value for X-BCrypt-Hash. Instead, the server administrator can configure an upper limit on the number of rounds it will accept.

If the sender sends a message with a too-high X-BCrypt-Rounds value, the server should return a 3xx error code indicating the maximum-allowed value. (Gee, maybe it'd help if the server simply stated up front what the parameters should be? I Don't know SMTP all that well, but maybe that'd make more sense.) The sender can then turn around and re-hash the message with a lower-than-too-high X-BCrypt-Rounds value.

A measured response...

This opens up a huge number of dynamic configuration possibilities, too. Let's say you're using an assessment heuristic such as spamassassin. After receiving the message (but before calculating X-BCrypt-Hash), the receiving server can pass the message into the analyzer and get a confidence value back. If you think the message may be spam, then you can tell the sender to re-send with a higher X-BCrypt-Rounds value. How much higher? Use whatever spamassassin told you its spam factor was. The more suspect the message, the heavier the burden you can place on the sending server.

Is it worth it?

I think so. You're never going to get rid of all spam, but the more expensive you make it, the less worthwhile it will be for the senders. Even zombie botnets qualify as limited resources for the people who are paying for their use, and you can make the botnet less valuable per-message.

But what about people who don't use it?

Well, there's the rub. In order for it to be really effective, there does need to be a significant number of people using it. At least, for starters, you can get some mileage out of telling spamassassin that messages which provide X-BCrypt-* are more likely to be ham, and that messages received after a successful up-negotiation of X-BCrypt-Rounds are more likely to be ham; this gives valid senders reason to implement X-BCrypt-*. (And if the hash calculates out correctly, senders might even be able to peek their way out of DNSBLs, despite having naughty network neighbors!)

(No, I don't expect to be the one to implement this. I don't have the time. But perhaps I'll manage to inspire someone who does have the time and motivation.)
 
 
Michael Mol
Key principle: Redundant everything.

Only thing I have really worked out is storage, so far. Storage is going to consist of two units with these characteristics:
  • Four disks combined in RAID10. Probably using hardware RAID
  • Atom processor.
  • Redundant PSUs
  • RAID array is a unit in a DRBD setup
  • NFS server serving up the content from the array.
  • Two NICs
Both boxes will have the same IP address (going with IPv6 for the smaller header size) and MAC spoofing. Two switches, with a cable each to each storage box, and a cable each to the VM hosts. Jumbo frames enabled.

Beyond that, still working out a lot of details.

The VM hosts are probably going to run XCP. Linux-HA is what's been recommended to me for handling failover of the VM hosts.