<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="/stylesheets/rss.css"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
  <channel>
    <title>The BFC Computing Weblog: Category Open Source</title>
    <link>http://blog.bfccomputing.com/articles/category/open-source</link>
    <language>en-us</language>
    <ttl>40</ttl>
    <description>My God, It's Full of Source!</description>
    <item>
      <title>peth0 missing from Xen Dom0 (RHEL, CentOS)</title>
      <description>&lt;p&gt;Just a quick note for the search engines to find - peth0 can go missing from &lt;code&gt;ifconfig&lt;/code&gt; if there is a &lt;code&gt;GATEWAY=&lt;/code&gt; entry in ifcfg-eth0 (anaconda puts it here) and presumably -eth1, etc..  Put the default gateway in &lt;code&gt;/etc/syconfig/network&lt;/code&gt; instead and use &lt;code&gt;route-eth1&lt;/code&gt; files instead to specify gateways.&lt;/p&gt;

&lt;p&gt;Reboot for xend to do its setup correctly (please commment if there's a way to do this without reboot that works...) and instead of 'no peth0' you'll find one now exists.  Also, your xenbr0 will be set up properly.&lt;/p&gt;</description>
      <pubDate>Mon, 26 Jul 2010 15:20:00 -0400</pubDate>
      <guid isPermaLink="false">urn:uuid:514472d8-6392-401c-9bf9-2b2a28859f41</guid>
      <author>Bill McGonigle</author>
      <link>http://blog.bfccomputing.com/articles/2010/07/26/peth0-missing-from-xen-dom0-rhel-centos</link>
      <category>Open Source</category>
      <category>Linux</category>
      <trackback:ping>http://blog.bfccomputing.com/articles/trackback/4815</trackback:ping>
    </item>
    <item>
      <title>NFSv4 from Linux to ZFS under Solaris</title>
      <description>&lt;p&gt;If you're seeing this, this article isn't quite done yet.  Still setting things up right.&lt;/p&gt;

&lt;p&gt;Fedora client, Nexenta Server.&lt;/p&gt;

&lt;p&gt;On the linux side, start rpcidmapd and set it to start on boot.&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;service rpcidmapd start
chkconfig --levels 345 rpcidmapd on
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Wherever your DNS is, make sure your forward and reverse are set up correctly.  No, really, make sure.&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;$ host my.linux.host.fqdn
my.linux.host.fqdn has address 1.2.3.4
$ host 1.2.3.4
4.3.2.1.in-addr.arpa domain name pointer my.linux.host.fqdn.
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Make sure &lt;code&gt;dnsdomainname&lt;/code&gt; returns correctly on the linux host.  You need to have my.linux.host.fqdn first on the line with 127.0.0.1 in /etc/hosts.  This sets the NFSv4 domain name.  Restart rpcidmapd if you needed to fix this.  If this is wrong your files will all show as nobody:nobody on the mount (at this point everybody in the mailing lsit archives gives up and goes back to the crummy NFSv3).  Make sure linux's &lt;code&gt;dnsdomainname&lt;/code&gt; matches the output of Solaris's:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;cat /var/run/nfs4_domain
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Now, share under zfs:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;zfs set sharenfs=rw=my.linux.host.fqdn,root=my.linux.host.fqdn pool/vol/subvol
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;mount under linux:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;mount -t nfs4 solarismachine:/vol/subvol /mnt/localmount/ -o rw,intr,hard,proto=tcp,port=2049
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Then set up a root nfs mount by:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;blah, blah, blah, todo, todo, todo
&lt;/code&gt;&lt;/pre&gt;</description>
      <pubDate>Tue, 22 Jun 2010 11:24:00 -0400</pubDate>
      <guid isPermaLink="false">urn:uuid:3cbc142d-23f0-40f9-9014-cf575ada05a2</guid>
      <author>Bill McGonigle</author>
      <link>http://blog.bfccomputing.com/articles/2010/06/22/nfsv4-from-linux-to-zfs-under-solaris</link>
      <category>Internet</category>
      <category>Open Source</category>
      <category>Linux</category>
      <trackback:ping>http://blog.bfccomputing.com/articles/trackback/4814</trackback:ping>
    </item>
    <item>
      <title>Installing MythTV 0.23 on Jolicloud</title>
      <description>&lt;p&gt;I've got Jolicloud on the wife's netbook, and it's a nice easy-to-use distro. &lt;/p&gt;

&lt;p&gt;Trouble is, it's based on Jaunty, which has old mythtv packages.  These won't connect to our MythTV 0.23 backend in the TV room.&lt;/p&gt;

&lt;p&gt;There is hope, though, the Avendard repo has newer packages compiled for Jaunty, but they're a bit tricky to install.&lt;/p&gt;

&lt;p&gt;The process roughly:&lt;/p&gt;

&lt;p&gt;Create a file:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;/etc/apt/sources.list.d/avenard.list
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;with the lines:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;deb http://www.avenard.org/files/ubuntu-repos jaunty release
deb http://www.avenard.org/files/ubuntu-repos jaunty testing
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;and run the commands:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;wget http://www.avenard.org/files/ubuntu-repos/ubuntu-repos.key &amp;amp;&amp;amp; sudo apt-key add ubuntu-repos.key &amp;amp;&amp;amp; rm ubuntu-repos.key
apt-get update
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;to pull in the new repo.  Now, remember this is dpkg/apt, so we can't just go installing mythtv first as the dependency resolution needs a bit of help.&lt;/p&gt;

&lt;p&gt;First do:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;sudo apt-get update
sudo apt-get install nvidia-glx-185 nvidia-185-libvdpau nvidia-185-kernel-source
sudo apt-get install libvdpau1
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Now do:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;sudo apt-get dist-upgrade mythtv-frontend mythvideo
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;and whichever other modules you need.&lt;/p&gt;

&lt;p&gt;Then run: &lt;/p&gt;

&lt;pre&gt;&lt;code&gt;sudo dpkg-reconfigure mythtv-common
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;to set your backend password.&lt;/p&gt;

&lt;p&gt;Finally, install nfs and autofs to be able to mount your storage directory:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;sudo apt-get install autofs nfs-common
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;and then edit:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;/etc/auto.master
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;uncomment the /net entry, save, and run:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;/etc/init.d/autofs restart
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Then symlink to however you have your backend storage configured, e.g.:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;ln -s /net/192.168.1.10/storage/ /storage
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Now, launch mythfrontend from the Jolicloud Sound &amp;amp; Video group, where it will ask you for sudo access to add your user to the mythtv group and logout.  Do it.&lt;/p&gt;

&lt;p&gt;Log back in again, launch MythTV again, and go into 'Setup' and configure the storage directories for your media and/or recordings.  Set parental controls as needed, they're front-end specific.  Change the theme if needed, and set your painter to OpenGL if appropriate.&lt;/p&gt;

&lt;p&gt;Those being done, you should be good to go to exit and start MythFrontend from the menu and just use it normally.  SD MPEG-2 DVD video streams over 802.11g seems to work fine here in an ASUS 1000HE netbook.  And now you have the world's most complex second(third,fourth) television.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;Update&lt;/em&gt;: Jolicloud support writes via Twitter: "Adding third-party repositories could compromise your configuration. We won't be able to provide you support. ^CD"  I suspect if you're reading this you can handle your own support, but be forewarned if you count on Jolicloud support.  Personally, I'd rather see them engaging and supporting their community, but I understand about resource constraints.&lt;/p&gt;</description>
      <pubDate>Wed, 02 Jun 2010 11:02:00 -0400</pubDate>
      <guid isPermaLink="false">urn:uuid:2ab94268-7680-42b4-b131-7558ec20334d</guid>
      <author>Bill McGonigle</author>
      <link>http://blog.bfccomputing.com/articles/2010/06/02/installing-mythtv-0-23-on-jolicloud</link>
      <category>Hardware</category>
      <category>Wireless</category>
      <category>Open Source</category>
      <category>Linux</category>
      <trackback:ping>http://blog.bfccomputing.com/articles/trackback/4813</trackback:ping>
    </item>
    <item>
      <title>Rescuing a Broken pfSense Install</title>
      <description>They don't make flash drives like they used to.  I've seen several pfSense installs fail recently due to drives flaking out and the wear-leveling  not working as advertised.
&lt;br&gt;&lt;br&gt;
Of course, you make regular backups of your config file, but in case you forgot, we can probably rescue your config file off of a disk image.  Re-installing pfSense doesn't take too long, but rebuilding a working config file can take many hours, so rescuing is preferential.
&lt;br&gt;&lt;br&gt;
This script has worked for me with dozens of file versions, but one can imagine scenarios with fragmented files where it would fail.  There's nothing fancy going on here (this was hacked up with a client standing in my office with a broken pfSense box), but it might prove useful in a pinch.
&lt;br&gt;&lt;br&gt;
&lt;code&gt;&lt;pre&gt;
#!/usr/bin/perl -w
use strict;
use warnings FATAL=&gt;'all';

=comment
pfsense_extract.pl - extract pfSense configs from an input stream
(c) 2010 BFC Computing, LLC.  Licensed under the same terms as pfSense.

This is useful for taking an image file of a damaged pfSense install
and pulling out config files.  If you can mount the image normally, you
should do that first.

Due to the nature of the filesystem, there are often many copies of a 
config file in a disk image, from each time it was saved.  You will 
find a bunch of output files named: pfsense-config-1.xml, pfsense-config-2.xml,
etc.  You can then use tools like diff to find out which the right one was.

Example: 
   dd if=/dev/sdg of=broken_pfsense_image.dd bs=2M conv=sync,noerror
   strings broken_pfsense_image.dd | perl pfsense_extract.pl

Processing a 1GB image as per the example takes about 20 seconds on a standard 
2GHz desktop machine.
=cut

my $BASENAME='pfsense-config-X.xml';
my $counter = 0;
my ($outfile);
my $do_output = 0;

while (&lt;&gt;) {

    chomp;

    if ($_ eq '&amp;lt;pfsense&amp;gt;') {
	$counter++;
	my $filename = $BASENAME;
	$filename =~ s/X/$counter/;
	open($outfile,"&gt;$filename");
	$do_output = 1;
    }

    if ($do_output) {
	print $outfile $_ . "\n";
    }

    if ($_ eq '&amp;lt;/pfsense&amp;gt;') {
	close $outfile;
	$do_output = 0;
    }
    
}
&lt;/pre&gt;
&lt;/code&gt;

</description>
      <pubDate>Wed, 03 Mar 2010 13:54:00 -0500</pubDate>
      <guid isPermaLink="false">urn:uuid:6e218b5b-04c0-49be-b453-9854f613bff4</guid>
      <author>Bill McGonigle</author>
      <link>http://blog.bfccomputing.com/articles/2010/03/03/rescuing-a-broken-pfsense-install</link>
      <category>BFC Computing</category>
      <category>Development</category>
      <category>Open Source</category>
      <trackback:ping>http://blog.bfccomputing.com/articles/trackback/4811</trackback:ping>
    </item>
    <item>
      <title>Dual Screen vs. MythTV vs. Mouse Focus</title>
      <description>&lt;p&gt;There's a problem when running two X-displays with MythTV - some events on the non-Myth screen will steal focus and then the MythTV controls will no longer respond.  &lt;a href="http://ubuntuforums.org/showthread.php?t=191313"&gt;This thread&lt;/a&gt; describes the problem well, but is now closed for comments.&lt;/p&gt;

&lt;p&gt;Since then, &lt;a href="http://digamma.cs.unm.edu/trac.dmohr/wiki/DualscreenMouseUtils"&gt;mouse-switchscreen&lt;/a&gt; has been written, and solves the problem correctly.  It's possible to bind the program to a hotkey.&lt;/p&gt;

&lt;p&gt;In the end, I found it better to just run one display at a time since I couldn't prevent the focus stealing.&lt;/p&gt;</description>
      <pubDate>Thu, 24 Sep 2009 00:35:00 -0400</pubDate>
      <guid isPermaLink="false">urn:uuid:d3a31e1a-336c-4995-9cbc-fd83e43afdf1</guid>
      <author>Bill McGonigle</author>
      <link>http://blog.bfccomputing.com/articles/2009/09/24/dual-screen-vs-mythtv-vs-mouse-focus</link>
      <category>Hardware</category>
      <category>Open Source</category>
      <category>Linux</category>
      <trackback:ping>http://blog.bfccomputing.com/articles/trackback/4810</trackback:ping>
    </item>
    <item>
      <title>Converting a Windows Vista KVM Virtual Machine to Redhat VirtIO Drivers</title>
      <description>&lt;p&gt;Redhat recently released a set of virtualized I/O devices for KVM, the kernel virtual machine.  This short post will outline a method of converting a Windows Vista install (on KVM) to the new drivers using Virt-Manager.  It has been tested on Fedora 11.&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;&lt;p&gt;Make sure Vista VM is up to date on patches and the disk is error free.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;Download drivers from Redhat network or &lt;a href="http://www.linux-kvm.com/sites/default/files/virtio-setup-200908.iso"&gt;here&lt;/a&gt;.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;Mount the .iso file as a CD-ROM device.&lt;/p&gt;&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Now you might think you can use the &amp;#8216;Add Hardware Wizard&amp;#8217; here and add the drivers, add the hardware, and be good.  I did.  I wound up with an unbootable disk.  Apparently Vista&amp;#8217;s autodetection is required in this process.  So&amp;#8230;&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;&lt;p&gt;Add a new network device of type &amp;#8216;virtio&amp;#8217;.  Vista will do its &amp;#8220;you&amp;#8217;ve got hardware&amp;#8221; routine and run you through all of its wizards.  When it asks you for drivers, point it at the i386/2008 directory on the driver disc image.  Yes, Yes, OK, Yes, Really, Continue, etc.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;Shutdown the VM and remove the old ethernet controller.  Boot up Vista and make sure the network works.  You can conceivably skip this step for now if you want to make troubleshooting harder.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;Add a new Storage controller.  Leave the existing one as-is for now.  You&amp;#8217;ll have to pick a disk image you&amp;#8217;re not using right now, or make a new one.  Anything is fine, we&amp;#8217;re not going to ever use it inside Vista.  Do the driver dance again.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;Shutdown Windows.  Remove the storage controllers, and add a new one, type &amp;#8216;virtio&amp;#8217;, with your normal hard drive image.  Take care of the old ethernet controller here too, if you ignored my previous advice.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;Boot Windows normally.  It should now be coming up on VirtIO disk and network drivers.  If you get a bluescreen or a plea to use the RepairCD, something went wrong.  Use the repair CD to restore to a previous restore-point and try again.&lt;/p&gt;&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;If anybody knows where to find a sound driver, please leave a comment!&lt;/p&gt;</description>
      <pubDate>Mon, 14 Sep 2009 16:23:00 -0400</pubDate>
      <guid isPermaLink="false">urn:uuid:d5d1e89b-6320-4a01-9288-55d7864309c2</guid>
      <author>Bill McGonigle</author>
      <link>http://blog.bfccomputing.com/articles/2009/09/14/converting-a-windows-vista-kvm-virtual-machine-to-redhat-virtio-drivers</link>
      <category>Hardware</category>
      <category>Open Source</category>
      <category>Linux</category>
      <trackback:ping>http://blog.bfccomputing.com/articles/trackback/4809</trackback:ping>
    </item>
    <item>
      <title>Firefox Crashes on Fedora 11</title>
      <description>&lt;p&gt;For folks who are running the current development, or soon-to-be-just-released Fedora 11, you might find Firefox to be very crashy.  It's not because it's the semi-controversial 3.5b4 version (which is excellent), it's because of a buggy library.&lt;/p&gt;

&lt;p&gt;I'm running it with the Tree Style Tab and NoScript extensions, and can get a crash half the time when Session Restore is running, and almost all the time when I allow a site in NoScript.&lt;/p&gt;

&lt;p&gt;If you run firefox from the console, so you get the debug messages, you'll see:&lt;/p&gt;

&lt;pre&gt;&lt;code&gt;cairo-ft-font.c:554: _cairo_ft_unscaled_font_lock_face: Assertion `!unscaled-&gt;from_face' failed &lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;when the crash happens.  I tracked this down through the Mozilla and Freedesktop bug systems to a problem with the Cairo graphics engine improperly disposing of fonts which it didn't own, for which a fix was incorporated last December.  However, the version of Cairo shipping in Fedora 11 is older than that.&lt;/p&gt;

&lt;p&gt;So, I applied the simple patch, fixed up the .spec, and put up some new &lt;a href="http://swdist.bfccomputing.com/f11-i386-bfc/i386/os/"&gt;RPM's&lt;/a&gt; for i386 and an &lt;a href="http://swdist.bfccomputing.com/f11-i386-bfc/source/SRPMS/cairo-1.8.6-3.fc11.src.rpm"&gt;SRPM&lt;/a&gt; for hackers and x86_64 users to build (&lt;code&gt;rpmbuild --rebuild cairo-1.8.6-3.fc11.src.rpm&lt;/code&gt;).&lt;/p&gt;

&lt;p&gt;I haven't tried cross-compiling from i386 to x86_64 before, and --target=x86_64 doesn't work, so if anybody can tell me how to do that short of learning mock, please leave a comment and I'll put up RPM's for that too.&lt;/p&gt;

&lt;p&gt;The Redhat bug is &lt;a href="https://bugzilla.redhat.com/show_bug.cgi?id=502274"&gt;here&lt;/a&gt;.  Hopefully it gets accepted soon.&lt;/p&gt;</description>
      <pubDate>Thu, 28 May 2009 21:38:00 -0400</pubDate>
      <guid isPermaLink="false">urn:uuid:44cceb84-195c-4ba4-ac74-7506a71d4266</guid>
      <author>Bill McGonigle</author>
      <link>http://blog.bfccomputing.com/articles/2009/05/28/firefox-crashes-on-fedora-11</link>
      <category>Web</category>
      <category>Internet</category>
      <category>Open Source</category>
      <category>Linux</category>
      <trackback:ping>http://blog.bfccomputing.com/articles/trackback/4808</trackback:ping>
    </item>
    <item>
      <title>Reducing Spam with SMTP Validation on Postfix</title>
      <description>&lt;p&gt;This is a neat enhancement to postfix for reducing spam by attacking its economics: making sure it speaks SMTP properly.&lt;/p&gt;

&lt;p&gt;A spammer gets paid by the message delivered. So, it's in his interest to flood them out as quickly as possible.  Because of this, they rarely implement mailers which negotiate the SMTP connection politely - they simply open the TCP connection and start sending.&lt;/p&gt;

&lt;p&gt;When an SMTP client doesn't respect the proper-back-and forth postfix expects, it'll flag it as unauthorized 'pipelining' - for example when multiple messages are sent in succession, but which would otherwise be OK.&lt;/p&gt;

&lt;p&gt;We can take advantage of this by forcing the issue, and increasing the odds a spammer will make this mistake by waiting just a second between establishing the TCP connection and telling the spammer we're ready to take mail.  A loaded mail server may behave this way anyway, so it's not outside the norm and the resource consumption is minimal, but it attacks the economics of spamming.&lt;/p&gt;

&lt;p&gt;In your main.cf file, you would add to &lt;code&gt;smtpd_client_restrictions&lt;/code&gt; something like this:&lt;/p&gt;

&lt;pre&gt;
&lt;code&gt;smtpd_client_restrictions =
        permit_sasl_authenticated,
        permit_mynetworks,
        check_client_access hash:/etc/postfix/access-client,
        sleep 1,
        reject_unauth_pipelining
&lt;/code&gt;
&lt;/pre&gt;

&lt;p&gt;We accept all of our own users' connections (interactive ones, perhaps) right away, and if the sender is totally unknown to us, we wait for just a second.  Then we reject any unauthorized pipelining.  The log will show something like this:&lt;/p&gt;

&lt;p&gt;&lt;code&gt;May  6 10:49:00 mailhub postfix/smtpd[8965]: NOQUEUE: reject: RCPT from unknown[10.1.2.3]: 403 4.5.0 &lt;a href="&amp;#109;&amp;#097;&amp;#105;&amp;#108;&amp;#x74;o:&amp;#115;&amp;#112;&amp;#097;&amp;#x6D;&amp;#116;&amp;#x61;&amp;#114;&amp;#x67;&amp;#x65;t&amp;#064;&amp;#x65;x&amp;#x61;&amp;#109;&amp;#112;&amp;#x6C;&amp;#x65;&amp;#046;&amp;#099;&amp;#111;&amp;#109;"&gt;&amp;#115;&amp;#112;&amp;#097;&amp;#x6D;&amp;#116;&amp;#x61;&amp;#114;&amp;#x67;&amp;#x65;t&amp;#064;&amp;#x65;x&amp;#x61;&amp;#109;&amp;#112;&amp;#x6C;&amp;#x65;&amp;#046;&amp;#099;&amp;#111;&amp;#109;&lt;/a&gt;: Recipient address rejected: Improper use of SMTP command pipelining&lt;/code&gt;&lt;/p&gt;

&lt;p&gt;when the spammer attempts to just send.&lt;/p&gt;

&lt;p&gt;It's worth noting that this method may not scale to very large installations, as those one second delays may be too much.  But for the average-sized postfix install, it can make yet another dent in the spam deluge.  Where it does consume 'too many' resources, one must weight the cost of computing resources vs. the time cost of dealing with yet another spam.&lt;/p&gt;</description>
      <pubDate>Wed, 06 May 2009 10:50:00 -0400</pubDate>
      <guid isPermaLink="false">urn:uuid:8d2b1675-60f9-473c-b48a-9b9d317add3d</guid>
      <author>Bill McGonigle</author>
      <link>http://blog.bfccomputing.com/articles/2009/05/06/reducing-spam-with-smtp-validation-on-postfix</link>
      <category>Internet</category>
      <category>Open Source</category>
      <category>Security</category>
      <trackback:ping>http://blog.bfccomputing.com/articles/trackback/4806</trackback:ping>
    </item>
    <item>
      <title>Mac OS X Keychain Export Tool</title>
      <description>&lt;p&gt;A Mac user might want to export his Keychain passwords and notes for several reasons - using a third-party password manager on Mac OS X, creating a time-resistant backup of passwords, printouts of passwords for the safe-deposit box or attorney, or switching to another operating system.&lt;/p&gt;

&lt;p&gt;There's no easy way to do this.  Keychain Access only allows you to export certificates, and Apple recommends backing up the Keychain database files, which accomplishes none of the above goals and promotes lock-in.&lt;/p&gt;

&lt;p&gt;The keychain code is itself open source, but I couldn't find it compiled for another platform anywhere.  I assume that enough of the OSX toolchain is required to make this infeasible, though likely not impossible.  Still, it's not there.&lt;/p&gt;

&lt;p&gt;Fortunately, I ran across an Applescript that uses Keychain Scripting to create a text file from a user's login Keychain.  Unfortunately, it didn't do a bunch of things I thought were required for moving my passwords to a Linux machine, so here's the delta:&lt;/p&gt;

&lt;p&gt;version 2009030201: &lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;handle all keychains&lt;/li&gt;
&lt;li&gt;handle all key types&lt;/li&gt;
&lt;li&gt;handle comments and descriptions&lt;/li&gt;
&lt;li&gt;handle errors&lt;/li&gt;
&lt;li&gt;trim dangling whitespace&lt;/li&gt;
&lt;li&gt;write to tab delimited format&lt;/li&gt;
&lt;li&gt;unlock all keychains first, so the mad tapping won't hit 'cancel'&lt;/li&gt;
&lt;li&gt;add username to filename&lt;/li&gt;
&lt;li&gt;replace carriage returns/newlines in text fields with spaces&lt;/li&gt;
&lt;li&gt;use unix line endings in output file&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;and some general code cleanup.  I'm assuming the sample code is in the public domain and releasing this version under GPLv2+.  Please improve this and comment here when you do or send changes back.  If you own the original code and feel this is improperly licensed, let me know ASAP.&lt;/p&gt;

&lt;p&gt;I've run this out of Script Editor - the advantage there is it's easy; the disadvantage is double-confirming every keychain access, one for Script Editor, one for Keychain Scripting.  Terribly time consuming.  I suspect if you compile this it'll eliminate the first half.&lt;/p&gt;

&lt;p&gt;I've set this to open all the keychains first.  Otherwise when hitting "allow, allow, allow" you might hit 'cancel' if it asks to unlock a keychain.  If your keychain is big enough you might not get through the whole thing before the keychain unlock times out, so be careful.&lt;/p&gt;

&lt;p&gt;Your minutes of tapping on the mouse button like a human waiting for a treat will be rewarded with a ~/Desktop/Passwords-yourusername file.  It'll be easy to then process with other scripts, importable into databases or spreadsheets for further manipulation.  I'll leave it up to you to be smart and not leave this password file sitting around in some unencrypted/unprotected location for any longer than absolutely necessary.  If it gets stolen you're probably up a creek, right?  So, be careful, only aim at what you intend to kill.&lt;/p&gt;

&lt;p&gt;Download &lt;a href="/files/KeychainExport.scpt"&gt;KeychainExport&lt;/a&gt;.&lt;/p&gt;</description>
      <pubDate>Mon, 02 Mar 2009 23:34:00 -0500</pubDate>
      <guid isPermaLink="false">urn:uuid:83d47a5b-6947-4b1c-915e-4afed6fd261d</guid>
      <author>Bill McGonigle</author>
      <link>http://blog.bfccomputing.com/articles/2009/03/02/mac-os-x-keychain-export-tool</link>
      <category>BFC Computing</category>
      <category>Development</category>
      <category>Open Source</category>
      <category>Security</category>
      <category>Mac</category>
      <trackback:ping>http://blog.bfccomputing.com/articles/trackback/4805</trackback:ping>
    </item>
    <item>
      <title>Portable Computer States</title>
      <description>&lt;p&gt;Here's a technology idea:  combine a solid-state flash drive, a synchronization engine, advanced virtual memory techniques, and a portable hardware abstraction layer to create a portable computer state device.&lt;/p&gt;

&lt;p&gt;The idea would be like this:  you have a small hardware device that you bring with your anywhere.  When you plug it into one of your computers, it would synchronize the filesystem states, restore memory images, and resume your computing environment the way you left it at the last location.&lt;/p&gt;

&lt;p&gt;It's roughly equivalent to the idea of network computers, except you don't need the ubiquitous ultra-high-speed Internet that doesn't really exist (when wireless gigabit is pervasive, this would become passe).&lt;/p&gt;

&lt;p&gt;Current reasons this can't work, using linux as the obvious OS to start with, include the lack of an abstract HAL (root drive, home drive, etc) and the lack of virtual-memory restore on a per-process basis.  Lots of the other parts exist already.&lt;/p&gt;

&lt;p&gt;Initial limitations would probably be a restriction to the same hardware architecture (x86, AMD64, ARM, etc), inability to deal with filesystem changes greater than the capacity of the SSD, and an inability to restore stateful network connections (an IP proxy might work around the last one).&lt;/p&gt;

&lt;p&gt;One company has made an approach at this experience by running the environment directly on the portable device, but this forfeits local resources and demands power draws unachievable on an external bus (for simple connectivity).  That approach may gain viability over time, though, but not yet.&lt;/p&gt;

&lt;p&gt;Would you, gentle reader, use such a device?&lt;/p&gt;</description>
      <pubDate>Tue, 17 Feb 2009 12:15:00 -0500</pubDate>
      <guid isPermaLink="false">urn:uuid:4ec5f82f-b5c8-4ba5-80f8-cb045cabcef1</guid>
      <author>Bill McGonigle</author>
      <link>http://blog.bfccomputing.com/articles/2009/02/17/portable-computer-states</link>
      <category>Hardware</category>
      <category>Development</category>
      <category>Open Source</category>
      <category>Linux</category>
      <trackback:ping>http://blog.bfccomputing.com/articles/trackback/4804</trackback:ping>
    </item>
  </channel>
</rss>
