Monday, December 29, 2008

Yet another list-of-predictions for 2009

Everyone likes to make predictions for the coming year. Here's my baker's dozen of 2009 predictions for system administration and technology in general.

  1. Cloud computing will experience a major fail. As a result smaller clouds ("Mom and Pop Cloud computing" ?) will appear, powered by ASP/ISP/Enterprise "cloudlike" computing offerings from large vendors.
  2. Further balkanization of the field of system administration. More divergence into "operator" and "analyst" type roles. MIS graduates rejoice.
  3. Little progress will be made by ISP's for solving the last mile problem, U.S. will remain in the boradband backwater. Things might look more promising after the Obama administration kicks in with their broadband initiatives but it'll take more than a year. 3G cell service and 4G tech like WiMax and LTE really won't make a major impact unless you live in a test market and even then, you're paying to beta test stuff that will probably go away shortly after the kinks are worked out.
  4. Video, facbook/myspace, twitter, blogging, RSS will start to surpass email. David Allen already prepping an updated revision of GTD with sections on coping with tweets and FriendFeed.
  5. One major tech company will fail. IBM? AT&T? Sun? Vonage? Someone is going down. What happens in the aftermath will be interesting in terms of Free Software (will a failure result in a large drop of code from the cathedral?) and in terms of what everyone else does (I expect most companies will pull in risky ventures and focus on "core competencies" ... the funny thing will be that those who don't do that will probably be the most successful ones).
  6. Configuration management will continue to see increased adoption rates; someone might actually figure out how to do something for unix and windows in one system. Regardless, expect management to start to want systems and networks to be more autonomic and less hand mangled^Wmanaged.
  7. Linux won't happen on the desktop, but SugarOS will make play for the netbook market as a way to keep the OLPC project running.
  8. More hardware will have iPhone-like touch input methods. For example: your fridge.
  9. Digital Rights Management will see a major downturn in adoption. Consumers hate it, vendors find it challenging to have to support something forever, etc.... My supposition is either more trust with unencumbered formats, with more targeted RIAA/MPAA suits or larger adoption of "leased media" models where you can have all you can eat for a regular fee.
  10. Computer security won't get much better, despite some very high profile breeches. Seriously, we're still trying to get patch management and virus mitigation under control. Managing a wider body of threat vectors is nearly impossible right now. See also: prediction #6.
  11. Corollary to 5: the failure will cause some ramifications in terms of the internet continuing to function. Eg: If Sun poops, that's a lot of unsupported servers in critical roles that will need migrating to something and sitting unpatched and vulnerable. The loss of a major player in the tech sector will cause "availability ripple" as people react.
  12. Someone will figure out how to do backups and restores right for mere mortals. Apple's Time Machine is pretty good, but it's ecosystem specific and has the usual list of Appleisms. Someone will figure out to take the elegance of Apple's interface, make it work on Linux/OSX/Windows and back up your cloud data too (Gmail, google docs, flickr, facebook, etc..) too. See also: prediction #1.
  13. Corollary to 6: Configuration management and autonomic computing will spur better monitoring and log analysis. The lack of instrumentation in a lot of technology will finally start to be understood.

Saturday, December 13, 2008

Making apline see a default CAFile on OSX

One of the problems with doing Linux almost exclusively is that I get real lazy when it comes to small things. Most Linux distros sand the rough edges well enough that there's stuff I just don't remember how to do anymore because "they just work" now, when previously they didn't. Dealing with OpenSSL's default CAFile is one of those things.

Luckily, OSX to the rescue. I've started using OS X as my primary desktop platform for 100% of my duties. This includes email so I need my mail client of preference: pine. For the last bunch of years I've just been using Fedora which has had alpine (and Dag had pine for RHEL in the pre-alpine days.. thanks Dag!). Even when I was using a Mac in the past, I'd ssh over to the Linux box to use pine because it was easier. Now, I'm not ditching Linux, but I am trying some different workflows and working methods out as part of my new job.

So I installed pine with MacPorts, which also installed a MacPorts version of OpenSSL, which also does not come with a default ca-bundle.crt. This causes alpine (and/or most SSL apps in MacPorts) to complain LOUDLY about not being able to validate the cert as trusted. Worse, is that after poking at pine with dtrace it was using what I think is a very linuxy version of the ca-bundle.crt (eg: /opt/local/etc/openssl/cert.pem instead.. ha!).

So to fix (after a few hours of poking around... this stuff is not well documented) do something akin to the following:
  • Grab the mk-ca-bundle.pl script from the fine folks at cURL.
  • This script is perl, and needs LWP. I'm assuming you're using MacPorts, so
    sudo port install p5-libwww-perl
  • Run mk-ca-bundle.pl
  • sudo -s
  • cd /opt/local/etc/openssl
  • mkdir certs
  • cp /path/to/generated/ca-bundle.crt certs/ca-bundle.pem
  • ln -s certs/ca-bundle.pem cert.pem
  • cd certs
  • c_rehash .
  • ln -s ca-bundle.pem ca-bundle.crt
After which MacPorts bianries (including alpine) should have a nice large CAFile by default and much of your "O. M. G. YOUR SSL IZ BUSTED" errors should go away.

You'll also note that I rename the bundle with a .pem extension and then may a symlink for the .crt pointing at them .pem. I do this mainly because I'm kind of anal.. the ca-bundle.crt that is generated by mk-ca-bundle.pl is full of PEM formatted CA certs, as openssl expects. So I like to be extra descriptive about what exactly the file is, but lots of stuff seems to maybe expect a ca-bundle.crt as well.

Sigh. Security needs be easier than this.