Today Fedora and the Seneca Centre for Development of Open Technology (CDOT) are announcing the release of Pidora 18 (pidora.ca), an optimized Fedora remix for the Raspberry Pi. It’s based on a brand new build of Fedora for the ARMv6 architecture with greater speed and includes packages from the Fedora 18 package set. It’s also the launch of the Pidora name.
Features
Almost all of the Fedora 18 package set available via yum (thousands of packages were built from the official Fedora repository and made available online)
Compiled specifically to take advantage of the hardware already built into the Raspberry Pi
Graphical first-boot configuration (with additional modules specifically made for the Raspberry Pi)
Compact initial image size (for fast downloads) and auto-resize (for maximum storage afterwards)
Auto-swap creation available to allow for larger memory usage
C, Python, & Perl programming languages available & included in the SD card image
Initial release of headless mode can be used with setups lacking a monitor or display
IP address information can be read over the speakers and flashed with the LED light
For graphical operation, Gedit text editor can be used with plugins (python console, file manager, syntax highlighting) to serve as a mini-graphical IDE
For console operation, easy-to-use text editors are included (nled, nano, vi) plus Midnight Commander for file management
Includes libraries capable of supporting external hardware such as motors and robotics (via GPIO, I2C, SPI)
For further documentation, downloads, faq’s, read-me’s, how-to’s, tutorials, or videos, visit: http://pidora.ca/
When do you trust open source? With so many recent attacks using insecure software as a vector–thousands upon thousands of attacks–the reliance on the vigilance of others seems almost foolhardy.
Open source has an answer for the lack of security, in that the code is presumably visible to all. However, few actually read the source code of the applications they rely on; there are simply too many of them, their codebases are too large, and chances are that most people reading the source code couldn’t do a proper security analysis anyway.
Doesn’t this mean that open source and closed source end up being on an even playing field with respect to security? If nobody reads the source code, open or closed, where’s the difference in security between the two licensed codebases?
With the aid of Josh Bressers, lead of Red Hat’s Product Security Team, let’s look at a process by which one can gain some reassurance concerning open source security, along with a pointed look at one more way in which Red Hat contributes to the entire Linux community.
The basic argument, in simplified straw man form, looks like this:
Open source is no more secure than closed source.
You don’t review every line of open source code; you trust the projects.
Since you don’t review every line of code, trusting your closed source vendor is the same as trusting an open source project.
This almost makes sense–but according to Josh, this is what actually happens:
You probably haven’t reviewed the source code to your web browser (how you’re reading this page). Even if you did review the code, you need to trust whomever built the source code. Up to this point, open source is on par with closed source.
If you have a closed source product, you have to trust the vendor. There’s zero choice. If they make a claim, you probably can’t prove them wrong. Many closed source vendors have been caught doing silly things, but security isn’t trivial, and people easily forget the sins of the past.
Open source and closed source diverge when you consider the people who do review your source code. Red Hat has a number of security teams who do actually conduct source code audits. Do they catch everything? Certainly not, but they are essentially an independent third party looking at public source code. Even if you don’t like what they find, you can go look and verify security for yourself. You don’t have to trust the third party; you can still conduct your own analysis.
There are also other groups doing third-party security verification. That’s the amplification power of open source.
All of this is what makes open source more secure. We can’t lie, we can’t cheat, we can’t steal. The emperor is naked and knows it. More than once Red Hat has hit security issues where we wish we could have weaselled out of them, but at the end of the day, open source kept us honest.
We think open source is more secure than closed source. Every time.
GlusterFest Test Day and the Gluster Test Framework
The first beta of glusterfs 3.4 is scheduled for release tomorrow, and the project plans to greet this new beta with GlusterFest: a 24-hour test day, starting at 8pm PDT May 7/03:00 UTC May 8.
Since I plan on participating in the testing, I thought it’d be a good idea to study up on Gluster’s new test framework. You can learn all about the test framework in the video below, but I’ll also walk you through a brief testing experience of my own using the pre-beta code running on my Fedora 18 test machine.
The Gluster framework makes use of the app “prove” which is provided, for Fedora and related OSes, by the package “perl-Test-Harness.” (note: to figure out which package to install, I used the command “yum provides prove”)
sudo yum install -y perl-Test-Harness
To get the test framework itself, I headed over to the shiny new Gluster Forge to grab the source code, pull it down, to my test machine, and check out the 3.4 release branch:
When Gluster Fest commences, there will be new glusterfs 3.4 beta 1 packages to install and test out, but for my pre ‘Fest test, I built new packages from the source I pulled down from git.
With my freshly-built glusterfs, glusterfs-server & glusterfs-fuse packages installed, I entered the glusterfs source directory and ran one of the “basic” tests. Note: before you run any of these tests, be aware that they delete “/var/lib/glusterd/*” in the course of creating test volumes and data and cleaning up after themselves. For more README-type information, see the README.
cd glusterfs
sudo prove ./tests/basic/bd.t
The test returned a passing result, which is great, but kind of boring. More interestingly, the second test I ran did not run successfully:
sudo prove ./tests/basic/mount.t
This test returned an error while attempting to mount a test volume over the NFS protocol, which is one of the ways you can consume Gluster storage.
mount.nfs: access denied by server while mounting MY_HOSTNAME:/patchy
Debugging time! Following guidance gleaned from the #gluster irc channel, I edited the mount.t test file to add a line containing “set -x” following the first instance of “cleanup;” in the file. I ran the test again, and it spit out a good deal more output, including the command being run to try and mount the volume:
mount -t nfs -o vers=3,nolock,soft,intr MY_HOSTNAME:/patchy /mnt/nfs/0
I could see that the test was, rightly, attempting to mount the volume with NFS version 3 (Gluster’s built-in NFS server doesn’t support version 4), so that wasn’t the problem. I also checked my SELinux log for denials (sudo tail -f /var/log/audit/audit.log | grep denied) and didn’t find any issues. I consulted my /var/log/messages as well, and found the following error message:
rpc.mountd[5465]: refused mount request from MY_IP_ADDRESS for /patchy (/patchy): unmatched host
After a little while Googling around, I remembered something I’d encountered while tangling with Gluster / oVirt integration last year: Gluster’s NFS server doesn’t play nice with another running NFS server. I checked to see if I had an NFS server running on my test machine (sudo service nfs-server status), and, sure enough, I did.
I shut the server down (sudo service nfs-server stop), re-ran my mount.t test, and — hooray — it completed successfully.
That’s perhaps not the most exciting example of Gluster’s test framework in action, but it should give you a sense of how to use it, and, when tests fail, how to go about figuring out why.
I hope to see you, virtually, at the GlusterFest this week. I’m jbrooks in the #gluster irc room — please drop in on Wednesday (or any time) and say hello.
