Thursday, October 7, 2010

ec2-download-bundle issues

I’m trying to download a bundle I recently uploaded to the S3 bucket I created, but am getting some fun/interesting errors from $EC2_HOME/lib/ec2/commons/curl.rb:

Curl without verbose enabled:
./download-bundle.sh (this is a simple script I created to make sure variables are set and such)
Downloading manifest osol-2009.6.manifest.xml from srepetsk to /mnt/downloaded/osol-2009.6.manifest.xml ...
Failed to download "osol-2009.6.manifest.xml": Curl.Error(77): error setting certificate verify locations:
CAfile: /etc/curl/curlCA
CApath: none.
ERROR: Failed to download "osol-2009.6.manifest.xml": Curl.Error(77): error setting certificate verify locations:
CAfile: /etc/curl/curlCA
CApath: none.
Curl with verbose enabled:
./download-bundle.sh
Downloading manifest osol-2009.6.manifest.xml from srepetsk to /mnt/downloaded/osol-2009.6.manifest.xml ...
Failed to download "osol-2009.6.manifest.xml": undefined method `<<' for nil:NilClass
ERROR: Failed to download "osol-2009.6.manifest.xml": undefined method `<<' for nil:NilClass
Trying to download the bundle to an OpenSolaris 2009.06 64-bit instance created not long ago. Has anybody else had experience with this kind of thing? I’m passing ec2-download-bundle what I think are all the options it needs:
ec2-download-bundle -b $MANIFEST_PATH -a $EC2_KEYID -s $EC2_KEY -k $PRIVKEY  -p $MANIFEST_PREFIX -d /mnt/downloaded
The thing I’m most unsure about is whether the –k parmaeter is correct, since that’s what it seems to be complaining about the most. The CA file (which the *.pem file should accomplish) that it’s looking for should be passed in from the –k parameter I’d think, but I’m wondering if this is a bug in the ec2 commands? or if I’m just doing something wrong. I’m still trying a couple things, but this has got me puzzled at the moment.

Wednesday, September 29, 2010

debian-main

 dpkg: error processing package (--purge): subprocess pre-removal script returned error exit 163: OH_GOD_THEYRE_INSIDE_MY_CLOTHES

Tuesday, September 28, 2010

Another ZFS departure

Another ZFS departure
Jeff Bonwick is leaving Oracle.This is a huge event, because Jeff has been one of the main innovators in operating system technology during his tenure at Sun. While you may know him best for ZFS, he's also the inventor of the slab allocator, which revolutionized memory management when it was created. (And now, pretty much every modern system uses some variation of the slab allocator.)And he's not just an Oracle VP. Jeff has made integrations into Solaris' ZFS code base on an ongoing basis. This is a guy that has led with actual actions and innovation, backed by code, rather than some boffin who's risen to management and no longer contributes. At some level, he's the model for the kind of technologist I aspire to be.With so many innovators leaving (and yes, there are other key players in flight), its going to be very interesting to see how Oracle is able to continue to be a thought leader in the OS technology that they've acquired.One the one hand, its really a shame to see to much of the heart and soul of the Solaris engineer core slowly disintegrating.On the other hand, I think illumos may be the place where Solaris innovation happens, more so than at Oracle, even sooner than I previously expected.
[Planet Illumos]

Friday, August 27, 2010

Sun RPC Licensing Change

I never imagine I’d be linking to a LiveJournal article ever, but today seems to be an outlier.

The long, sordid tale of Sun RPC, abbreviated somewhat, to protect the guily and the irresponsible.
Once upon a time (1984), Sun created an RPC implementation for Unix, with the intent of implementing RFC 707 (High-level framework for network-based resource sharing). Now, in those days, a good way to ensure that people used code that you wrote was to upload it to usenet, and in 1985, Sun did that. (Google has one of the posts archived here: Sun RPC part 8 of 10)
Keep in mind the following: the first formal definition of free software was published by the FSF in February 1986, so there were technically no "free software" licenses when Sun RPC was written. For that era, the licensing of Sun RPC was remarkably permissive, it said:
/*
* Sun RPC is a product of Sun Microsystems, Inc. and is provided for
* unrestricted use provided that this legend is included on all tape
* media and as a part of the software program in whole or part. Users
* may copy or modify Sun RPC without charge, but are not authorized
* to license or distribute it to anyone else except as part of a product or
* program developed by the user.
*
* SUN RPC IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND INCLUDING THE
* WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS FOR A PARTICULAR
* PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE.
*
* Sun RPC is provided with no support and without any obligation on the
* part of Sun Microsystems, Inc. to assist in its use, correction,
* modification or enhancement.
*
* SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO THE
* INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY SUN RPC
* OR ANY PART THEREOF.
*
* In no event will Sun Microsystems, Inc. be liable for any lost revenue
* or profits or other special, indirect and consequential damages, even if
* Sun has been advised of the possibility of such damages.
*
* Sun Microsystems, Inc.
* 2550 Garcia Avenue
* Mountain View, California 94043
*/
People wanted to be able to support RPC, so this code was used all over the place. Notably, it is a core component of how NFS works on Unix (and since Linux is Unix-y, there too). Over time, this code was ported to Linux, and added, most notably, to glibc, all along, inheriting the same license Sun wrote for it in 1984.
The problem is that this license is clearly non-free, it places restrictions on distribution. Now, Debian has known about this concern for a while now, since 2002, to be precise, as you can see here: Debian Bug 181493 
Fedora caught this when we first started doing serious license audits, circa 2005.

[Keep Reading]

Monday, August 23, 2010

Atheros AR8131 Support Under OpenSolaris?

I recently bought parts to create an on-the-cheap storage server for myself, which will hopefully do things like web serving, DNS, lots and lots of file storage, and much more. Due to the benefits of OpenSolaris (zones, ZFS, crossbow networking, etc.) I decided to use it for my base system. However, due to the end of life of OpenSolaris through Oracle, I shifted elsewhere to Nexenta 3, which builds on OpenSolaris (snv_134) to be a command-line-driven ZFS storage server – exactly what I need.

My server is built around my MSI 785GM-P45 mATX Motherboard and AMD Athlon II X4 620 Processor. Per Murphy’s Law, the network driver on the motherboard – the Atheros AR8131 chipset – is not included in OpenSolaris or built by anyone (as of this writing). The closest on the Internet is a set of directions to build the driver for the AR8121 chipset, available here; I used version 2.6.5. Using the AR8121 directions, a semi-working driver for OpenSolaris is able to be built by modifying the adddrv.sh file and adding the line ‘set DEVLIST = ($DEVLIST '"pci1969,1063"') ‘ under the current DEVLIST items, as this is what the network adapter identifies itself as. Using this slight modification, I was able to get the driver added and the module listed (`modinfo|grep atge`). However, even though I can bring the interface up and assign an IP and everything shows that it works, dmesg shows a different story with warnings constantly being thrown:
Aug 23 19:27:48 washington atge: [ID 397352 kern.warning] WARNING: atge0: gem_tx_timeout: tx timeout: tx_active: 0[0] 3[3] (+3), intr 0[0], tx_softq: 3[3] 3[3] (+0), tx_free: 3[3] 64[0] (+61), tx_desc: 0[0] 3[3] (+3), intr: 2[2] (+2),
Aug 23 19:57:43 washington atge: [ID 397352 kern.warning] WARNING: atge0: gem_tx_timeout: tx timeout: tx_active: 0[0] 3[3] (+3), intr 0[0], tx_softq: 3[3] 3[3] (+0), tx_free: 3[3] 64[0] (+61), tx_desc: 0[0] 3[3] (+3), intr: 2[2] (+2),
Aug 23 19:57:47 washington atge: [ID 397352 kern.warning] WARNING: atge0: gem_tx_timeout: tx timeout: tx_active: 0[0] 2[2] (+2), intr 0[0], tx_softq: 2[2] 2[2] (+0), tx_free: 2[2] 64[0] (+62), tx_desc: 0[0] 2[2] (+2), intr: 2[2] (+2),
Aug 23 19:57:55 washington atge: [ID 397352 kern.warning] WARNING: atge0: gem_tx_timeout: tx timeout: tx_active: 0[0] 1[1] (+1), intr 0[0], tx_softq: 1[1] 1[1] (+0), tx_free: 1[1] 64[0] (+63), tx_desc: 0[0] 1[1] (+1), intr: 0[0] (+0),
This bit of fun gets repeated about every 5 seconds while the interface is activated, and stops when unplumbed. Hopefully this might be fixed in the next version(s) of Masayuki’s driver, which I would love to have support the AR8131 chipset :D

Saturday, August 21, 2010

RIT Welcomes Students Back to School Aug. 30

RIT Welcomes Students Back to School Aug. 30
Rochester Institute of Technology is preparing to welcome back returning students to campus on Aug. 30. Beginning at 8 a.m., approximately 414 students are expected to move in to the newly constructed Global Village complex, the campus’ $54.5 million residential and commercial space.
Global Village residences feature 70 suites and aims...
[RIT News Releases]

Thursday, June 24, 2010

Arlington Diocese Workcamp

It’s that time of year again! This weekend marks the beginning of the first of two weeks of workcamp put on by the Arlington Diocese.

Here’s a quick description of what workcamp is:
WorkCamp is a week-long intentional Christian community for high-school aged youth. We begin each day with the celebration of Mass before going to work sites where we serve those in need by making their homes safer, warmer, and drier. The evening program consists of Christian entertainment, songs, and speakers. A reconciliation service is always a part of the week and Eucharistic adoration is frequently the way we close the day.
It’s basically a week of fun, hard work, and getting to know some awesome individuals. While personally as a member of St. Mark’s I haven’t been to the Diocesan workcamp before, I’m already more than ready for it to begin and prepared to have a fantastic time during the week. We (volunteers) will be arriving at the location tomorrow morning and getting it all set up for the students graciously giving up a week of their summer to help those in need!

It should be a fantastic week, and perhaps I’ll even update the blog during the week – who knows.