As an early birthday present, Jen bought me an hour ride on a Flyboard. It’s an awfully fun way to fly.
Tag: technology
the ROI on LED
Did you do a break even analysis yet? How long will it take you to recoup the expense?
The way to calculate break even (or Return On Investment) is to know roughly how much each bulb costs to use. To determine that, I built a spreadsheet that listed all 49 light fixtures in my house, the number of bulbs in each fixture, watts per bulb, lumens, and the estimated hours of monthly use. From that list, I picked the 24 most expensive bulbs to operate and replaced them with LEDs, at the cost of $217.
Conclusions:
- Halogen track lights are horrifically inefficient. Replace immediately.
- Old transformers are terribly inefficient. Replace immediately.
- LED track light bulbs are hard to find locally and horrifically expensive. Instead, buy direct from China.
- Considering their lumen output, 4′ fluorescent bulbs aren’t that bad
- The ROI is usually less than a year for bulbs used more than an hour a day
For the bulbs in my “top 24” list, the ROI period was less than 12 months, and that was purchasing the bulbs at late 2012 prices. Today I can buy most of those bulbs for about 30% less, so the ROI is even faster. Today at Costco, I purchased 850 lumen dimmable LED bulbs for $8 each.
Also consider that many of the bulbs I replaced were CFL. The savings in going from CFL to LED are much lower than when switching from incandescent, lowering my ROI. But the instant on, dimming, and improved light quality of LED bulbs make the switch worth while.
What LED’s do you recommend?
I recommend whatever LED bulbs cost about $10 for 850 or more lumens. I would buy them only at a local store with a good return policy. Out of 40 bulbs, I’ve had two fail. At $10/ea, they cost just enough that it’s worth taking them back for an exchange.
It’s worth noting that both my bulb failures were on the same power circuit as the 12v track lights, and I suspect the 12v power transformer played a role in their failures.
Did you bypass CFL altogether?
We used many CFL bulbs from 2009-2012. The light quality of the earliest ones was quite awful, so we confined them to areas where that didn’t matter. Price was never an issue, as Seattle City Light subsidizes them: a 6-pack of CFL bulbs has cost $1 for years now. As CFL bulb quality improved, CFL bulbs found their way into more rooms. But unlike LED bulbs, they never became good enough that we liked them.
eGallon
The eGallon is a new and more comprehensible way to compare the fuel costs of gas versus electric cars. The eGallon is the cost of driving an electric car the equivalent distance that a gas powered car would travel on 1 gallon of gas.
According to the U.S. Department of Energy, here in the Northwest an eGallon costs $0.84 versus gasoline at $3.87 per gallon. In most states, the cost per eGallon is about 1/3 that of gasoline. If the Chevy Volt and Nissan Leaf didn’t have $10,000 price premiums, one of our cars would be electric.
LED light bulbs
The graph above from Seattle City Light shows 12 months of our household electric usage (Jun-May). Each bar is 2 months, so the first is Jun-Jul and the last is Apr-May. The lighter colored left bar is the prior years usage, and the darker colored right bar is the current year (Jun 2012-May 2013) usage. Can you guess in which 2-month period I replaced all our light bulbs with LEDs?
Geeky things to do with DMARC
May 25th edition.
Between 2013-05-24 17:00:00 and 2013-05-25 16:59:59, somebody at the United States Army base in Fort Huachuca, Arizona (home of the “U.S. Army Intelligence Center and the U.S. Army Network Enterprise Technology Command (NETCOM)/9th Army Signal Command”) attempted to forge an email to a Yahoo email address purporting to be from my domain cadillac.net.
I discovered this while testing the report analysis tools in Mail::DMARC, my nearly complete implementation of DMARC. DMARC is a nifty bit of tech where mail server operators (in this case, Yahoo!) report message delivery information to domain owners (in this case, me). In this case, Yahoo received the non-conforming message attempt from IP 141.116.211.97, which resolves to host-141-116-211-97.ptr.hqda.pentagon.mil. GeoIP locates the IP at:
US, AZ, Fort Huachuca, 85613, 31.527300, -110.360703, 789, 520.
Because the message didn’t conform to my published DMARC policy, Yahoo rejected it and reported information about the attempt to me. To rule out the possibility of this being a legit message being forwarded, I checked my logs and found zero messages being sent from that domain during the time period. I’d be quite curious to hear an explanation for this attempt.
DKIM and mailing lists
I recently deployed DKIM on a number of my domains. For those readers of my blog that are unfamiliar with DKIM (Hi Mom and Dad, I love you.), DKIM is just a fancy way to stamp emails with a special digital signature. DKIM makes it so other mail programs can inspect the message and determine if it really is from me.
I also manage a number of email lists, and I subscribe to a number of other lists. Email lists have a habit of appending trailers with helpful instructions for managing subscriptions, and adding prefixes to the subject. This altering of the message as it passes through the mailing list invalidates the DKIM signature.
Today I tested a “fix” for one of my Ezmlm mailing lists with these commands:
cd path/to/ezmlm/list; rm prefix text/trailer addtrailer
Then I sent a test email to the list, and voila, the message passes DKIM validation.
How domain registrations were done in 1996
Received: from ic.net (falcon.ic.net [152.160.101.1]) by ops.internic.net
(8.7.4/InterNIC-RS) with SMTP id CAA03959 for ;
Fri, 12 Apr 1996 02:12:39 -0400 (EDT)
Received: from michweb.net by ic.net with smtp
(Smail3.1.28.1 #6) id m0u7S0n-003EooC; Thu, 11 Apr 96 15:26 WET DST
Date: Thu, 11 Apr 96 15:26 WET DST
From: matt@michweb.net (Matt Simerson)
To: HOSTMASTER@INTERNIC.NET
Subject: [NIC-960412.367] NEW DOMAIN
Message-ID:
MIME-Version: 1.0
Received: from porthos.michweb.net [152.160.182.5] by michweb.net
with ESMTP (Mail Server 5.0.2); Thu, 11 Apr 96 20:34:53 GMT
Content-Type: text/plain; charset="us-ascii"
Status: O
******************* Please DO NOT REMOVE Version Number ********************
Domain Version Number: 2.0
**************** Please see attached detailed instructions *****************
******** Only for registrations under ROOT, COM, ORG, NET, EDU, GOV ********
0. (N)ew (M)odify (D)elete....: N
1. Purpose/Description........: Business Web Site
2. Complete Domain Name.......: michweb.com
Organization Using Domain Name
3a. Organization Name..........: MichWeb Inc.
3b. Street Address.............: 621 N. Lake Street
3c. City.......................: Cadillac
3d. State......................: MI
3e. Postal Code................: 49601
3f. Country....................: USA
Administrative Contact
4a. NIC Handle (if known)......: MICHWEB2.DOM
4b. Name (Last, First).........: Simerson, Matt
4c. Organization Name..........: MichWeb Inc.
4d. Street Address.............: 621 N. Lake Street
4e. City.......................: Cadillac
4f. State......................: MI
4g. Postal Code................: 49601
4h. Country....................: USA
4i. Phone Number...............: (616) 775-8416
4j. E-Mailbox..................: matt@michweb.net
Technical Contact
5a. NIC Handle (if known)......: MICHWEB2.DOM
5b. Name (Last, First).........: Simerson, Matt
5c. Organization Name..........: MichWeb Inc.
5d. Street Address.............: 621 N. Lake Street
5e. City.......................: Cadillac
5f. State......................: MI
5g. Postal Code................: 49601
5h. Country....................: USA
5i. Phone Number...............: (616) 775-8416
5j. E-Mailbox..................: matt@michweb.net
Billing Contact
6a. NIC Handle (if known)......: MICHWEB2.DOM
6b. Name (Last, First).........: Matt Simerson
6c. Organization Name..........: MichWeb Inc.
6d. Street Address.............: 621 N. Lake Street
6e. City.......................: Cadillac
6f. State......................: MI
6g. Postal Code................: 49601
6h. Country....................: USA
6i. Phone Number...............: (616) 775-8416
6j. E-Mailbox..................:
Primary Name Server
7a. Primary Server Hostname....: dns.michweb.net
7b. Primary Server Netaddress..: 152.160.182.1
Secondary Name Server(s)
8a. Secondary Server Hostname..: mail.michweb.net
8b. Secondary Server Netaddress: 152.160.182.4
Invoice Delivery
9. (E)mail (P)ostal...........: E
A domain name registration fee of $100.00 US is applicable. This charge
will cover the $50.00 maintenance fee for two (2) years. After the two
year period, an invoice will be sent on an annual basis.
The party requesting registration of this name certifies that, to her/his
knowledge, the use of this name does not violate trademark or other
statutes.
Registering a domain name does not confer any legal rights to that name and
any disputes between parties over the rights to use a particular name are to
be settled between the contending parties using normal legal methods
(see RFC 1591).
By applying for the domain name and through the use or continued
use of the domain name, the applicant agrees to be bound by the terms of
NSI's then current domain name policy (the 'Policy Statement') which is
available at ftp://rs.internic.net/policy/internic/internic-domain-1.txt.
(If this application is made through an agent, such as an Internet Service
Provider, that agent accepts the responsibility to notify the applicant of
the conditions on the registration of the domain name and to provide the
applicant a copy of the current version of the Policy Statement, if so
requested by the applicant.) The applicant acknowledges and agrees that
NSI may change the terms and conditions of the Policy Statement from time
to time as provided in the Policy Statement.
The applicant agrees that if the use of the domain name is challenged by
any third party, or if any dispute arises under this Registration Agreement,
as amended, the applicant will abide by the procedures specified in the
Policy Statement.
This Registration Agreement shall be governed in all respects by
and construed in accordance with the laws of the United States of America
and of the State of California, without respect to its conflict of law rules.
This Registration Agreement is the complete and exclusive agreement of the
applicant and NSI ("parties") regarding domain names. It supersedes, and
its terms govern, all prior proposals, agreements, or other communications
between the parties. This Registration Agreement may only be amended as provided
in the Policy Statement.
Corsair SSD + Mac = pain
Until recently, having a 3 year old laptop was unthinkably slow. Yet today I find myself with a mid-2010 MacBook Pro. Not long ago, RAM and processors leapt past the point of being good enough. My long-in-the-tooth laptop is sporting a 2.66 GHz Core i7 CPU, 8GB of RAM, and half TB of storage. All of those specs are sufficient for my needs.
The problem with my old system was the performance of the spinning disk. Its laggard ways had me lusting after a new Retina MBP with 512GB SSD. I would have leapt, but two things held me back: Anand’s advice, and my employer donating a Corsair CSSD-F240GB2 to me. Dropping in a SSD made a dramatic difference. Instead of drooling after a new laptop, I was like a satiated diner, admiring the dessert menu, but passing.
I was content, until my Mac started to hang once a week with identical symptoms each time. Apps that did not need disk I/O (terminal & IM sessions) would keep running while those in need of disk would hang interminably. The only solution is a hard power off. I looked into it and Corsair offers a firmware update, principally to address wake-from-sleep hangs on Windows. The firmware updater is Windows only. It’s worth a try, right?
My first stab was connecting the SSD to another Mac running Windows 7 in VMware, via USB. The update utility didn’t see the drive. To follow the updater instructions and connect via a Windows 7 computer via SATA and AHCI enabled, I would have to install Windows 7 via Boot Camp. Installing Boot Camp is generally easy: run the Boot Camp Assistant, let it carve out some disk space for Windows, reboot to the Windows install DVD and install.
Except I had a few obstacles:
- I had replaced my DVD drive with the SSD.
- Boot Camp Assistant will only allow a USB drive install of Windows on newer machines that ship without a DVD drive.
- Boot Camp could not partition my disk because it could not move some files.
To get Windows installed, I had to wipe my spinning disk, clone my SSD back to it, replace the SSD with the DVD drive, boot onto the spinning disk, run Boot Camp to partition the disk, install Windows 7, replace the DVD drive with the SSD, tweak the registry to support AHCI on my SSD, and finally run the Corsair firmware update utility. Which still did not recognize my disk. My next SSD will not be made my Corsair. And it might be wrapped in a new rMBP.
monitoring exim with nagios
I was setting up monitoring of mail queues with the nagios plugin check_mailq and found it didn’t work on cPanel servers. Google led me to a few shell scripts that used sudo to run exim -bpc. I didn’t like that option so I dove into check_mailq, expecting to make a few changes to the code. Instead, I discovered that for exim, the check_mailq plugin expects to parse the input of a queue listing. From there, the solution was straight forward.
Edit nagios/utils.pm and set $PATH_TO_MAILQ = “/usr/sbin/exiqgrep”;
Add the nagios user to the mailnull group in /etc/group.
Add this to nrpe.cfg:
command[check_mailq]=/usr/local/nagios/libexec/check_mailq -w 100 -c 500 -M exim
Restart nrpe, and it works perfectly.
Nolisting
Nolisting is a spam fighting technique that works by listing an unavailable MX as the highest priority (lowest MX value) mail server. The idea is that any proper mailer will detect the unavailable MX and automatically retry the next highest priority MX record.
On Feb 7th, 2012, I dedicated one of my IPs to the job of not listening for SMTP traffic, set up a host record, and then configured a few mail domains with my faux MX as the highest priority.
On March 5, I removed the faux MX records. Over the course of a month, the half dozen users of these mail domains had all experienced the loss of valid mail and noticed. Undoubtably, they lost more valid messages than they noticed.
Before I removed the faux MX records, I did some sniffing of the SMTP traffic hitting my faux MX. During observation, most of the failures I witnessed were being sent by an application written using JavaMail. Apparently it’s popular with banks (for sending account notifications), news organizations, and online photo processors.