Search Results: "will"

14 October 2008

Joey Hess: electic bike

I decided to get an electic bike when my car died. Couldn't quite stomach buying a new gasoline vehicle at this point in time, didn't really feel like another used car, and the available electic cars are still too new/expensive/hard to find. While there are some neat NEVs that are not too expensive, they're too limited to be worth my money, and electic bikes fit into the same general niche. (So do electic scooters, but I didn't want to spend that much money on an experiment..) My first try was a disaster. I was thinking that a large cargo capacity would be a good thing, so I gravitated toward trikes. However, the one I tried turned out to be a lemon in several ways, and suffered a catastropic and dangerous controller burnout. So I learned that this electic bike industry is pretty rough and ready with a lot of junk to avoid. I also learned that I don't enjoy riding trikes. The second try was a R Martin LX1, which my dad had researched. I got it yesterday, and have ridden it some now, and I agree that it's a good one. As a bike, it's well built, has a good back disc brake and decent front brake (will be better once I bring it to a bike shop to adjust it better), has a good derailer, and rides well. I'm no expert but it seems about as good as the bike I used to commute with, though the frame is a bit heavier. (IIRC, it was also at least $200 cheaper than that bike!) On the electic side, it has a relatively small and light lithium ion battery; the motor is mounted in the hub. It's strong enough to go up hills on its own if you really want it to, but you will end up pedaling to assist, which is good. I'm undecided whether the six gears are enough ... Seems like I might want a faster gear, to be able to assist the motor more at high speed. I haven't wanted a lower gear yet, but I've not tried to do any hills without the motor's help. The electic controls are ok, but not perfect. I worry about accidentially twisting the throttle, although it has to be turned quite far to engage the motor. Ideally, the pedal assist would turn the motor on exactly when you pedal, and porportionally to how hard. Instead, there'a a lag, and doesn't care how hard you pedal. This can present problems coming up to an intersection or other hazard, where pedal assist kicking in can unexpectedly be more speed than is needed. Seems a waste to have to brake to cut the assist off. The motor is audible when accellerating, and especially complains when trying to get me up a hill on its own. At speed, or if given a human power assist, it's quieter than the chain, if not silent. So there's room for improvement (and this would be a fun thing to do some hacking on to improve its response), but it's still a lot of fun. I'd forgotten how much I enjoy riding a bike and getting a nice workout. And it's especially nice to go up a hill pedaling only as hard as you like, to be able to accellerate quickly without standing on the pedals, and to be able to "coast" a long, long, way.

Bdale Garbee: YikStik

As some of you know, the first weekend in October was a big deal for me, because it was NCR's Oktoberfest launch event. My son and I spent the weekend camped out on the prairie with Keith Packard and many of our other friends. Keith successfully went from nothing to a "level 2" high power certification, which was pretty cool. I wasn't quite so lucky. On Saturday morning, I flew my custom-designed rocket YikStik for a "level 3" certification attempt. The name comes from the word my wife uses to describe lipstick. The rocket was built from a mixture of custom and Giant Leap parts, including 98mm Dyna Wind airframe, a 98-75mm tail cone retainer, and a Pinnacle nose cone. All the centering rings were cut on my 3-axis CNC milling machine, and the fins were custom 7-layer composite layups using plywood, carbon fiber, fiberglass, and epoxy... all vacuum bagged using a kitchen food saver appliance. Painted red, gold, and black, with a custom 8 foot main parachute sewn by my wife Karen from the Team Vatsaas design in red and black rip-stop nylon. The motor selected was an Aerotech M1297W reload. This is a 75mm diameter motor 66.5cm in length with 2722 grams of propellant yielding 5417 Newton-seconds of total impulse. It was also on sale earlier this year for cert attempts. My simulations said YikStik should have flown to about 14,800 feet above ground level at the NCR north site on this motor. The launch went perfectly, and the rocket was stunningly beautiful under boost. It disappeared into some high clouds, but we continued to have strong signals from the two tracking transmitters installed in the payload bay behind the nose cone. About the anticipated time after launch, we saw a rocket descending under chute in the distance, and headed in that direction. A few minutes later, we abruptly lost both tracking signals, and that's when things took a turn for the weird. In hindsight, I think we suffered an apogee deployment of the main chute, and the rocket we saw descending was someone else's. YikStik was designed to deploy a streamer at apogee, then descend fairly quickly to about 1500 feet above ground where a second set of ejection charges would fire to separate the nose cone on a 3 foot drogue parachute that would pull a deployment bag containing the main chute out of the airframe and then pull the bag off the chute. The nose cone, payload bay with the tracking transmitters, and deployment bag would then descend under the drogue chute and the remainder of the rocket would descend under the big chute. In the world of deployment bags, this is called a 'free bag' configuration. With deployment at 1500 feet, the two bits should have landed within sight of each other. But that didn't happen. It wasn't until late Sunday afternoon, after we had to leave to get Keith to the airport, that some friends finally located the nose cone assembly about 3.5 miles down range from the launch site, over a couple rises and past an area of rough terrain. By then it was cold, windy, and rainy, and so I really appreciated the effort they put in locating the nose, and wasn't too surprised that they didn't immediately see the rest. Since the bulk of the rocket under the main should have had a slightly higher descent rate than the nose cone, I expected to find the rest of the rocket somewhere near a line between the launch rail and where the nose cone was discovered. So last Wednesday I spent about 5.5 hours walking around the area searching... but no luck. Since then, several other people have been out looking for my rocket, including two friends who flew over the area today in a light plane looking down into all the washes. Still nothing. I posted some signs in the area with a photo of the rocket and my contact info, I hope someone calls eventually. In the meantime, the bulk of YikStik remains missing, and of course I did not achieve a successful level 3 certification. Lessons learned for next time are that tethering the deployment bag to the main chute instead of flying in a "free bag" configuration might have been a better choice, and it's kind of silly having two tracking transmitters in one of the two pieces of your rocket and none in the other... Ray LaPanse took some stunning photos of the launch. He will likely post better versions with color correction and so forth at some point, but in the meantime, I've put a few up on my Garbee Rockets web site. She sure was a beauty!

Patrick Schoenfeld: Extending Debian with customizable packages

In my previous post I drafted a rough idea how to add a feature to Debian that would bridge the gap between Debian as a Binary Distribution and any Source Distribution. The feature in question is giving users the chance to build customized Debian packages for specific feature sets. The possible use cases are simple:

Lets say Anthony User needs super-duper-tool with postgresql support. However this is a not so common use case and so the archive only has postgresql support. If he now wants to build a custom package, the process is "as simple" as:

apt-get source super-duper-tool
cd super-duper-tool-*
apt-get build-dep super-duper-tool OR sudo mk-build-deps -r -i
(possibly try out which ./configure options are supported by super-duper-tool)
vi debian/rules
edit debian/rules
dpkg-buildpackage -us -uc
sudo debi

That is, to be honest lot of work. And the biggest problem about it is that you need to know all this, which is not really user knowledge.

The basic idea is that Anthony can do something like
export DEB_BUILD_OPTIONS=nomysql,postgresql
deb-build-tool build super-duper-tool

and is done.
So the question is how could this be achieved?

  1. Define a set of common options (options should be consistent through all source packages, otherwise it makes not that much sense) that every package should support, if it is a supported feature by the package in question. This includes flags like mysql, postgresql, ldap and its no-equivalents (nomysql, nopostgresql) to negate it.
  2. Enable use of this common options in the package build process and that is really the hardest part. Defining a lot of ifneq..findstring constructs for 2-10 options per source package in any available source package is.... not.... a good approach. Luckily a lot of packages uses autoconf where enabling and disabling features is as easy as adding a --with-foo or --enable-foo option to the ./configure parameters. So we could write a wrapper that would handle these options. The debhelper scripts already have dh_auto_configure: Maybe this could get enhanced.
  3. If it does not exist: Write a tool to auto-build packages with DEB_BUILD_OPTIONS set by the user. Should automatically get the source, (optional: setup/update a pbuilder environment) and build it and optional install/upload it (to a user repository for example) .
Still, the idea is only a rough draft. There are still a lot of open questions/issues, for example:
Is anybody interested in pushing this idea forward? I'm happily interested in it and I know people who like the idea, too. But I can't push this forward on my own all alone. Certainly the work won't affect Lenny anymore, but considerable the time frame that is planned for Lenny+1 by the release team, this could be a feature for Lenny+1.

Junichi Uekawa: I wonder if lintian can be used for flymake.

I wonder if lintian can be used for flymake. I would like to have some more on-the-fly checking capability of debian/ dirs. lintian is a good candidate, but I don't know of a good way to run lintian on a source directory. I posted a mail in debian-lint-maint mailing list, hoping someone will note.

Martin Michlmayr: Conceptronic CH3SNAS and the D-Link DNS-323 revision B1

Conceptronic kindly sent me a CH3SNAS for my Debian porting efforts. The Conceptronic CH3SNAS is reported to be basically the same hardware as the D-Link DNS-323 but it costs slightly less. There were some reports that the CH3SNAS uses a 88F5182 chip whereas the D-Link DNS-323 uses a 88F5181 but nobody was able to confirm this for sure. As it turns out, there are two revisions of the DNS-323. Revision A1 uses a 88F5181 chip along with a separate SATA chip. Revision B2 on the other hand uses a 88F5182 which integrates SATA into the SoC itself. The CH3SNAS is equivalent to a D-Link DNS-323 revision B1. In fact, the mainboard of the CH3SNAS even says DNS-323 rev B1. The Linux kernel from mainline only works on the DNS-323 revision A1 at the moment. Adding support for revision B1 should be trivial since you basically just need to initialize the SATA chip on the SoC and possibly adapt some other values. Unfortunately, the DNS-323 uses a very small serial connector so none of my serial cables work. If I can find someone who will make a serial cable for me, I'll fix up the kernel.

Kartik Mistry: See you in KDE 4.2!


* Since, We have done translation of kdebase > 75% for KDE. Gujarati will be include in KDE 4.2. We still have time to do more work. Thanks a lot to Pragnesh and Sweta for very hard work and hidden thanks to dear Pradeepto for encouraging me :P My .gu blog entry for this news.       

Sune Vuorela: Skolelinux/Debian-edu gathering infiltrated by Gnash people

Gathering
I spent this weekend at a Skolelinux/Debian-edu gathering in Oslo. 8.5 hours by bus each way. I got to meet some of the people shipping a customized Debian for schools. As it was a gathering related to educational software, looking at the KDE4 kdeedu packages seemed most appropriate. I’ve tested step packaging and hopefully it is going to end up on your local debian archive one day, along with some fixes to where kvtml files are packaged, much awaited by Annma and others. Apparantly, in Brazil, they have their own debian based kde distribution and 130 GB of free as in public domain free educational movies. Some people discussed an application to view, tag and search the movies. I quickly thought of a mixup of nepomuk and phonon in a nice userinterface. So if anyone feels like implementing that, you are more than welcome. Gnash
The gathering was together with a Gnash hackathon, and apart from gnash getting more and more usable, the gnash people are also thinking about integration with the desktop environments. For KDE 4 they have plans of a KPart easy embeddable anywhere, including in KHTML. (Maybe another use of the KPartLoader dfaure wrote recently). The gnash team are unfortunately quite short on KDE knowledge and they asked for help. I’m probably not myself the right one to help here, but maybe some of you out there feel like helping. There is already a patch set around that some people claims works, but others haven’t figured out to make it work. Feel free to comment here and I will forward to the Gnash people - or just contact them directly on the gnash-dev@gnu.org maillist. Trolls
I left the gathering a bit early to get to a Troll picnic in a Oslo park and got stuffed with p lse and lompar. (sausages and pancake like bread) I was by bus all night back home and then a shower and straight to work. After work, I slept for 14 hours or so.

13 October 2008

Mike Hommey: Iceweasel display corruptions, maybe a real fix?

Thanks for the feedback on the xulrunner-1.9 packages I posted yesterday. They led me to find a possible fix for the issue. Wasn’t the package fixed? will you ask. Well, yes and no. Actually, it was built using the internal copy of cairo in the mozilla source tree. And this internal copy is (guess what) not vanilla. And we don’t want to be using the internal copy because it’s hell for stable security. I took a deeper look into the changes and spotted something that looks like a workaround for exactly this corruption issue. So if people having the corruptions before installing the test package could downgrade to the current version in unstable (apt-get install xulrunner-1.9=1.9.0.3-1 should do), install the following cairo package: for i386 and for amd64, and tell me if the corruptions are gone, that would be very helpful :).

Russell Coker: Some RAID Issues

I just read an interesting paper titled An Analysis of Data Corruption in the Storage Stack [1]. It contains an analysis of the data from 1,530,000 disks running at NetApp customer sites. The amount of corruption is worrying, as is the amount of effort that is needed to detect them. NetApp devices have regular “RAID scrubbing” which involves reading all data on all disks at some quiet time and making sure that the checksums match. They also store checksums of all written data. For “Enterprise” disks each sector stores 520 bytes, which means that a 4K data block is comprised of 8 sectors and has 64 bytes of storage for a checksum. For “Nearline” disks 9 sectors of 512 bytes are used to store a 4K data block and it’s checksum. These 64byte checksum includes the identity of the block in question, the NetApp WAFL filesystem writes a block in a different location every time, this allows the storage of snapshots of old versions and also means that when reading file data if the location that is read has data from a different file (or a different version of the same file) then it is known to be corrupt (sometimes writes don’t make it to disk). Page 3 of the document describes this. Page 13 has an analysis of error location and the fact that some disks are more likely to have errors at certain locations. They suggest configuring RAID stripes to be staggered so that you don’t have an entire stripe covering the bad spots on all disks in the array. One thing that was not directly stated in the article is the connection between the different layers. On a Unix system with software RAID you have a RAID device and a filesystem layer on top of that, and (in Linux at least) there is no way for a filesystem driver to say “you gave me a bad version of that block, please give me a different one”. Block checksum errors at the filesystem level are going to be often caused by corruption that leaves the rest of the RAID array intact, this means that the RAID stripe will have a mismatching checksum. But the RAID driver won’t know which disk has the error. If a filesystem did checksums on metadata (or data) blocks and the chunk size of the RAID was greater than the filesystem block size then when the filesystem detected an error a different version of the block could be generated from the parity. NetApp produced an interesting guest-post on the StorageMojo blog [2]. One point that they make is that Nearline disks try harder to re-read corrupt data from the disk. This means that a bad sector error will result in longer timeouts, but hopefully the data will be returned eventually. This is good if you only have a single disk, but if you have a RAID array it’s often better to just return an error and allow the data to be retrieved quickly from another disk. NetApp also claim that “Given the realities of today’s drives (plus all the trends indicating what we can expect from electro-mechanical storage devices in the near future) - protecting online data only via RAID 5 today verges on professional malpractice“, it’s a strong claim but they provide evidence to support it. Another relevant issue is the size of the RAID device. Here is a post that describes the issue of the Unrecoverable Error Rate (UER) and how it can impact large RAID-5 arrays [3]. The implication is that the larger the array (in GB/TB) the greater the need for RAID-6. It has been regarded for a long time that a larger number of disks in the array drove a greater need for RAID-6, but the idea that larger disks in a RAID array gives a greater need for RAID-6 is a new idea (to me at least). Now I am strongly advising all my clients to use RAID-6. Currently the only servers that I run which don’t have RAID-6 are legacy servers (some of which can be upgraded to RAID-6 - HP hardware RAID is really good in this regard) and small servers with two disks in a RAID-1 array.

Decklin Foster: What's sup?

After some weeks of final testing, I've just uploaded packages for sup-mail to NEW. I'm pretty excited about this. Sup is a console-based MUA, like mutt (which I have used for many years). A few things distinguish it from most mail readers targeted at geeks like us:
  • Sup has no folders, a la Gmail. After watching many friends and even fellow hackers switch to Gmail, I have to admit: this literal hierarchical organization thing doesn't scale. I was planning to totally redo my mail folder system Any Day Now for about six months prior to starting on this. It was never going to happen.
  • Sup uses a Ferret full-text index to make this approach plausible. Search is super fast and beats (for me) both any kind of "organization" I could have disciplined myself into and the fine-grained control of something like mutt's search. It's sort of like git: until you do it, you don't realize how much more productive you can be when previously-expensive operations become instantaneous.
  • Sup works with threads, not messages; this is another thing Gmail got right. I used to waste brain cells thinking about which messages in a thread were worthwhile enough to save or not. Given the absurdly cheap price of disk relative to what we can type out in plain text since, like, a decade ago, this is crazy. In the index, I only have to look at whether a thread has new chatter or not, not its size, shape, or where the new messages are relative to it. All that's in the thread-view buffer where I actually read content.
  • Sup is written in Ruby. Back in the dawn of time, I used Gnus, and while I wasn't very good at elisp, the hackability afforded by being written in a high-level language was very nice compared to programs mostly implemented in C (even if they had a tacked-on scripting language). Plus, I love Ruby right now.
Despite all of those wins, sup currently has many drawbacks, and I don't recommend it for everyone. (And I mean everyone who thinks that the above are good ideas and are interested in using it; plenty of people, I'm sure, already think everything about this is idiotic, not new, or inferior to their preferred MUA. That's fine! You can ignore it all.) Here's what's still problematic:
  • At version 0.6, sup is very much not-yet-1.0. While it handles insanely large amounts of email without breaking a sweat, I still keep an additional backup of everything. (If Ferret crashes, the original copies of mail will be untouched, but it never hurts to be paranoid.)
  • The flow of data from your physical mail store to the sup index is currently one-way only. Actually removing deleted/spam messages is a big hack (if it works at all), and labels/flags/etc live entirely in Ferret-land. If you want to manipulate an actual mailbox, mutt is still the tool for the job (and then, you need to re-sync sup). This is probably the deal-breaker for most of us. I jumped in anyway because I feel like it can be solved (or more likely, made irrelevant) later.
  • William (upstream) is currently re-designing the whole thing from scratch, replacing the index library with Sphinx, and decoupling the index from the console frontend. As a result, the previous item is pretty much a non-priority (and bugs in general are not going to get the same amount of love as usual). I am hoping that we end up dumping mail into the index directly, then writing more frontends to write to Maildir backup, serve as webmail/whatever, but this is a long way off. On the plus side, thanks to Thrift, they will not be limited to Ruby.
  • Ruby's ncurses library still doesn't handle Unicode correctly. It can be patched (still doesn't work totally right), but I'm trying to find a more permanent solution for Debian.
So, if you're interested enough that you want to deal with these warts for now, apt-get install sup-mail (as soon as it hits the archive) and join us! Hopefully being in Debian will increase the userbase and get things fixed faster. If you're unsure, stay tuned for the next-generation version later. (There are screenshots and a few introductory docs over at Rubyforge that illustrate and explain all this in more depth, which I recommend checking out if you're still saying, "...huh." Me, I'm a sucker for any piece of software with a manifesto.)

Steve Kemp: I think I did pretty well under the circumstances

Procmail This will be the last time I talk about this, but here's my anti-rubbish procmail filter. It correctly copes with: Obviously edit to suit your tastes. Especially with regard to character sets - it is a wide brush which is tarring a group unfairly. That said in practise it works for me. If you want real antispam filtering then you should probably be looking at externalising it, or having a layered approach. ObQuote: Citizen Kane

Ben Armstrong: Bits from the Debian Eee PC team, autumn 2008

Some brief highlights of the last three months of Debian Eee PC development. Thermal and ACPI breakage resolved in 2.6.26-7 We’re pleased to see that in the upload to Sid of linux-image-2.6.26-1-686 version 2.6.26-7, the pair of 2.6.26 bugs we’ve been tracking that have made it difficult for Eee users to upgrade their systems have been resolved. Since then 2.6.26-8 has been uploaded and is expected to enter Lenny this week due to a freeze exception. Once the new kernel has migrated we will move quickly to build and release a new installer that includes it. Ath5k wifi works on Eee PC in Linux 2.6.27 Jean-Christophe reports that ath5k works in Linux 2.6.27 on the Eee PC 701, and just needs a small patch to work with our eeepc-acpi-scripts package. This is good news for those of us with models 701, 900, 900A and 1000HD who have been wanting to get off of the non-free Madwifi drivers and onto DFSG free drivers. New Eee PC model 701SD wifi support in the works Users of the new Eee PC Model 701SD have just started showing up looking for support in mainstream Linux distros. Martin Filtenborg confirmed using our Eee PC Live image with the GPL’d rtl8187se driver from Realtek that we can at least use it to connect to an unencrypted AP, get an IP address and ping other hosts. Of course, it is one thing to have a working vendor-supplied driver and quite another to have mainstream support. We’ll make do with what we have now, but will be seeking a mainstream solution as soon as possible. We’re seeking more testers and developers to work on this. To date, an ITP has not been filed, as it is not yet clear who is going to carry this work forward. Chasing the 5 second boot An interesting discussion on Arjan van de Ven and Auke Kok’s work to get an Eee 901 to boot in 5 seconds took place this month. While the Debian Eee PC team is not making work on this a priority, we’ll keep an eye on it to see if Debian can incorporate some or all of the techniques they used so that our users can benefit without making radical changes to their systems. Working towards mainstream support for rt2860 Our filing of an ITP for rt2860 (the wifi driver for models 901, 1000 and 1000H) was followed by discussion about how to separate out the GPL’d driver from the embedded non-free firmware so that it can at least go into contrib. Glenn Saberton has been working on rewriting the build system around kbuild and separating out the firmware. Numerous improvements to ACPI scripts Since my last progress report, there have been numerous improvements to the eeepc-acpi-scripts package to deal with all of the various models we now support and make the scripts more robust and flexible. Check out the changelog for details.

Alexander Reichle-Schmehl: release critical bug stats

The unofficial rc bug thingy currently lists: Ignoring bugs, which are marked pending, have a patch, have been reported multiple times or concern packages in contrib or non-free, that leaves 63 release critical bugs. That's quite impressive compared to the numbers from last week. Thanks for everyone helping! However 36 of them have been reported more than 30 days ago; maybe they are quite complicated, so please pay special attention to them. PS: Yes, I know, that the layout of my webpage breaks the nested lists above. Sorry; will fix it soon.

MJ Ray: Report on Listening to the Social Entrepreneur

Last Thursday, I was at a conference called Listening to the Social Entrepreneur. Here are some short notes about the plenary session, which were written at the time, along with thoughts on the workshops that I’ve just written up. HCT Group - credit crunch opportunity - business with ethics - transport - dislike 3rd sector term - difference between social enterprise and charity - optimism. Haley House - ex-soup kitchen staffed by ex-homeless, bakery, bank donated equipment, financial picture - catering grew 36% cafe grew 21% september, cooking classes; recipe for success: collaborate with experienced partner, secure enough capital or equivalent, align venture with mission; plan for sustainability; future… Roskilde university - relevance of academic research - why references for things I know - hard to have your feelings discussed. (meeting last Monday?) - don’t care what it’s called - too much jargon - several ways of learning, conceptual doesn’t seem useful but will later. CICs. Four flags of SEs - eship, er, e, econ. Bikeworks - practitioner and academic. Formation, setup, establishment, sustain. SE changes; viewpoint: academic, researchers, help us. Useless website. Then came three workshops of varying usefulness: Procurement Versus Marketplace was an interesting idea and reminded me why I avoided public-sector projects for years: I’m better at negotiated than at rules-based selling. I also was told (with a straight face) by a development trust worker that cooperatives are simply profit-sharing schemes, which was very disappointing. Social verses Business Goals seemed pretty ill-conceived. The reason why many people work in social enterprises is because we don’t believe we should choose between them. It’s an integrated, multi-faceted approach. Born or Made? was an interesting examination of the people powering social enterprises. Food for thought, but I’m not sure it really produced much. But I’m not that sure whether any of the workshops had much of a productive purpose. The final plenary session was confusing. I was sat further back, the sound system was intermittent and echoy and the talks seemed truncated and still, but maybe I was just tired. A lot of people had left by this point. I stayed on for the networking reception and met a few interesting people, but left earlyish to meet another TTLLP member on the light railway. The venue was OK (I think the main hall problems were more sound system and operation than the hall itself) and coffee, lunch and reception were well-catered. In conclusion, it was an interesting conference, but I don’t feel that we got much out of it, apart from some thoughts from a workshop session. I suspect it was more useful for the researchers than for the entrepreneurs. There weren’t many opportunities for professional development or sales or even putting things into consultations or . I’m not sure I’d spend best part of two days work (attending plus travel plus costs) on another similar event.

Jose Carlos Garcia Sogo: Back

Not much to say. Just that I am back, now with a mixed English-Spanish blog. I will try to keep entries written in Spanish out of syndicated feed on Planet Debian, but I won’t promise that some entry can slip. It has been long since I had no blog, so it will be a new challenge to try to update it somehow regularly. Regarding my Debian work, I have to admit that I have become mostly a ‘package and upload’ guy. I don’t have enough spare time to devote to other tasks, so I will mostly try to keep my packages as clean as I can.

Jose Carlos Garcia Sogo: Back

Not much to say. Just that I am back, now with a mixed English-Spanish blog. I will try to keep entries written in Spanish out of syndicated feed on Planet Debian, but I won’t promise that some entry can slip. It has been long since I had no blog, so it will be a new challenge to try to update it somehow regularly. Regarding my Debian work, I have to admit that I have become mostly a ‘package and upload’ guy. I don’t have enough spare time to devote to other tasks, so I will mostly try to keep my packages as clean as I can.

12 October 2008

Russell Coker: EC2 Security

One thing that concerns me about using any online service is the security. When that service is a virtual server running in another country the risks are greater than average. I’m currently investigating the Amazon EC2 service for some clients, and naturally I’m concerned about the security. Firstly they appear to have implemented a good range of Xen based security mechanisms, their documentation is worth reading by anyone who plans to run a Xen server for multiple users [1]. I think it would be a good thing if other providers would follow their example in documenting the ways that they protect their customers. Next they seem to have done a good job at securing the access to the service. You use public key encryption for all requests to the service and they generate the keypair. While later in this article I identify some areas that could be improved, I want to make it known that overall I think that EC2 is a good service and it seems generally better than average in every way. But it’s a high profile service which deserves a good deal of scrutiny and I’ve found some things that need to be improved. The first problem is when it comes to downloading anything of importance (kernel modules for use in a machine image, utility programs for managing AMIs, etc). All downloads are done via http (not https) and the files are not signed in any way. This is an obvious risk that anyone who controls a router could compromise EC2 instances by causing people to download hostile versions of the tools. The solution to this is to use https for the downloads AND to use GPG to sign the files, https is the most user-friendly way of authenticating the files (although it could be argued that anyone who lacks the skill needed to use GPG will never run a secure server anyway) and GPG allows end to end encryption and would allow me to verify files that a client is using if the signature was downloaded at the same time. More likely problems start when it comes to the machine images that they provide. They have images of Fedora Core 4, Fedora Core 6, and Fedora 8 available. Fedora releases are maintained until one month after the release of two subsequent versions [6], so Fedora 8 will end support one month after the release of Fedora 10 (which will be quite soon) and Fedora Core 6 and Fedora Core 4 have been out of support for a long time. I expect that someone who wanted to 0wn some servers that are well connected could get a list of exploits that work on FC4 or FC6 and try them out on machines running on EC2. While it is theoretically possible for Amazon staff to patch the FC4 images for all security holes that are discovered, it would be a lot of work, and it wouldn’t apply to all the repositories of FC4 software. So making FC4 usable as a secure base for an online service really isn’t a viable option. Amazon’s page on “Tips for Securing Your EC2 Instance” [3] mostly covers setting up ssh, I wonder whether anyone who needs advice on setting up ssh can ever hope to run a secure server on the net. It does have some useful information on managing the EC2 firewall that will be of general interest. One of the services that Amazon offers is to have “shared images” where any Amazon customer can share an image with the world. Amazon has a document about AMI security issues [4], but it seems to only be useful against clueless security mistakes by the person who creates an image not malice. If a hostile party creates a machine image you can expect that you won’t discover the problem by looking for open ports and checking for strange processes. The Amazon web page says “you should treat shared AMIs as you would any foreign code that you might consider deploying in your own data center and perform the appropriate due diligence“, the difference of course is that most foreign code that you might consider deploying comes from companies and is shipped in shrink-wrap packaging. I don’t count the high quality free software available in a typical Linux distribution in the same category as this “foreign code”. While some companies have accidentally shipped viruses on installation media in the past it has been quite rare. But I expect hostile AMIs on EC2 to be considerably more common. Amazon recommends that people know the source of the AMIs that they use. Of course there is a simple way of encouraging this, Amazon could refrain from providing a global directory of AMIs without descriptions (the output of “ec2dim -x all“) and instead force customers to subscribe to channels containing AMIs that have not been approved by Amazon staff (the images that purport to be from Oracle and Red Hat could easily have their sources verified and be listed as trusted images if they are what they appear to be). There seems to be no way of properly tracking the identity of the person who created a machine image within the Amazon service. The ec2dim command only gives an ID number for the creator (and there seems to be no API tool to get information on a user based on their ID). The web interface gives a name and an Amazon account name. The next issue is that of the kernel. Amazon notes that they include “vmsplice root exploit patch” in the 2.6.18 kernel image that they supply [2], however there have been a number of other Linux kernel security problems found since then and plenty of security issues for 2.6.18 were patched before the vmsplice bug was discovered - were they patched as well? The file date stamp on the kernel image and modules files of 20th Feb 2008 indicates that there are a few kernel security issues which are not patched in the Amazon kernel. To fix this the obvious solution is to use a modern distribution image. Of course without knowing what other patches they include (they mention a patch for better network performance) this is going to be difficult. It seems that we need some distribution packages of kernels designed for EC2, they would incorporate the Amazon patches and the Amazon configuration as well as all the latest security updates. I’ve started looking at the Amazon EC2 kernel image to see what I should incorporate from it to make a Debian kernel image. It would be good if we could get such a package included in an update to Debian/Lenny. Also Red Hat is partnering with Amazon to offer RHEL on EC2 [5], I’m sure that they provide good kernels as part of that service - but as the costs for RHEL on EC2 more than double the cost of the cheapest EC2 instance I expect that only the customers that need the the larger instances all the time will use it. The source for the RHEL kernels will of course be good for CentOS (binaries produced from such sources may be in CentOS already, I haven’t checked). This is not an exhaustive list of security issues related to EC2, I may end up writing a series of posts about this.

Jeff Bailey: Sometimes the downs follows the ups...

Partner to the up of posting about pregnancy is the down of posting about not being pregnant anymore.

Thursday evening, about 4:30am, Angie had a miscarriage. She was sent to the hospital for the usual checkups and all that. They kept her in the hospital for a couple of days with a uterine infection and is now back in the hotel with me and Leif in Quebec city. We're doing well, and will head back to Montreal tomorrow - probably flying back to California on Wednesday.

Y Giridhar Appaji Nag: te_IN translation for Debian Installer

My parents found it strange that I spend considerable time in the night doing "some Linux thing", so the other day I explained to them what Free software is and we talked about copyright and licensing. I was very happy that they were able to appreciate it. I also gave a Debian Installer demo. While there are a bunch of Indian languages supported in the Debian Installer, (Telugu) isn't one of them. They noticed it and motivated me to work on te_IN translation for d-i and promised to help me. So the three of us have been discussing translation strings. I have been committing changes slowly and intend to complete this activity in a few months. Lack of interest in translation meant that I never gave much thought to it but I see that translating software is rather difficult and it is an activity that would benefit a lot from two or three people doing it together. I found a glossary at swecha.org but there are a bunch of problems I am using these simple guidelines for translation: A few resources that I have been using: I will have to find a good quality comprehensive Telugu general knowledge book or an official A.P. govt. document to translate ISO 3166 codes etc. The Manorama yearbook would've been great, unfortunately Telugu is not one of the few languages it is published in. I will also bring my copy of Sankaranarayan's dictionary from my next month Hyderabad visit. If you have suggestions on any of these (pointers to guidelines, resources that are DFSG free and I could copy from etc.) that would make doing this easy for me, please do let me know. Naidu does good one-off Telugu string translations in Launchpad (so does [info]praveenkumarg, btw), and Naidu has promised to do some of the work as well as review. If all goes well, I will try and create a debian-10n-telugu sometime in the future.

Rob Taylor: Boston Awesome

I’m at the Boston GNOME summit right now. Yesterday a lot of work got done on gobject-introspection and AT-SPI D-Bus, which is completely awesome. I had a great discussion with Dan Williams about where we should go with gnome-phone-manager, NM’s new ModemManager and OpenMoko’s gpsd. My interest here is having a consistent place for getting GSM/CDMA cell location information. A lot of very interesting ideas have been flying around about new user experience ideas. It seems a lot of people have been thinking similar things but didn’t really know that others were also working/thinking on the same ideas. We’ve just started the future user experience hackfest, I hope out of this we can forge some common future direction and common projects. I’ll report more after the hackfest!

Next.

Previous.