September 5th, 2007
The last remaining problem for the F7 upgrade was a conflict between getweb cgi and selinux. I fixed it by allowing the transgression that was reported in the log. There is quite a bit of conflicting information on the web for how to make a local policy change.
First I found out what would allow the action that was being defeated using audit2allow
# echo "avc: denied { read } for pid=3736 comm="gitweb.cgi" name="cgi-bin" dev=md7 ino=5079272 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:object_r:httpd_sys_script_exec_t:s0 tclass=dir" | audit2allow
#============= httpd_sys_script_t ==============
allow httpd_sys_script_t httpd_sys_script_exec_t:dir read;
Basically the gitweb cgi calls some perl that does the equivalent of getcwd(), and this was being disallowed. The advice that was correct for setting local policy on F7 was found here. In short I did
# mkdir /root/tmp; cd /root/tmp
# touch local.te local.if local.fc
# yum install selinux-policy-devel
# vi local.te
policy_module(local, 1.0)
require {
attribute httpdcontent;
type httpd_sys_script_t;
type httpd_sys_script_exec_t;
}
allow httpd_sys_script_t httpd_sys_script_exec_t:dir read;
# make -f /usr/share/selinux/devel/Makefile
# semodule -i local.pp
Immediately after doing this gitweb was back working normally again.
Posted in Desktop Linux | No Comments »
September 5th, 2007
The new server at 1&1 has been showing signs of unreliability, it has crashed and died mysteriously three times, the last while I was away for a couple of days. Late at night when I got back, I decided it was time to actually make it into a Fedora box with a kernel later than 2.6.16 and to get rid of the xfs-formatted partitions, which I suspect of causing the instability. So here are my notes on how to force-upgrade the weird FC4-based OS on those boxes to fully true Fedora 7, grub, ext3 and selinux. The notes might not be complete, but they contain all the major steps and will be useful for anyone contemplating changing their server over to “Genuine Fedora”.
Don’t embark on this unless you have some Linux-fu and know how to get yourself out of trouble, because at every step you can easily trash your server and lose all your data. We are literally going to format the main filesystems and install a new bootloader on a remote server… we can call that “not a beginner project”.
Read the rest of this entry »
Posted in Desktop Linux | No Comments »
July 30th, 2007
Pretty strange version of Fedora running on 1&1 dedicated Linux servers.
First it is FC4, which is out of security update coverage, and Fedora Legacy has gone away too. I update it to FC6 via yum (worried about the libata change in the F7 kernels making it unbootable… needn’t've worried since I can make it unbootable all by myself). After the update the /boot/grub/grub.conf looks a bit strange, grubby did not make an entry for the FC6 kernel so I add it by hand.
On reboot, it ignores the new kernel and boots the old one. Further digging reveals that it is set up to use LILO, not grub. They provide and cook their own 2.6.17 kernel which was built on a Debian box and does not use an initrd: it has all the drivers it needs built into the monolithic kernel. Hm.
Read the rest of this entry »
Posted in Desktop Linux | No Comments »
July 16th, 2007
After getting on for four months, my mac80211 injection patches have been accepted by the powers-that-be and have made their way into the Linus git repo, the crucible from which vanilla kernel versions are forged, and the upstream from which all major distros are ultimately basing their kernels on. (Edit: they are present in 2.6.23-rc1 also).
Assuming nothing bad happens in the next few weeks leading to their being reverted (unlikely I would think, since they don’t interfere with much existing code), then a standardized driver-independent ieee80211 packet injection methodology will soon be available by default in all major distro kernels. Currently if you want to perform packet injection, you enter into a dark underworld of individual driver patching, having to cook custom kernels and make animal sacrifices to forgotten Gods. But now with the injection patches, for the devices with mac80211 drivers all that crap is blown away and every 2.6.23 kernel will offer the capability built-in.
Here are the list of mac80211 drivers and whether I have actually seen good injection. All of the drivers are expected to work, but I don’t have all the hardware.
| mac80211 driver |
Personally Tested |
| adm8211 |
no |
| bcm43xx |
yes |
| iwl3945 |
yes |
| iwl4965 |
no |
| p54 |
no |
| rt2×00 |
no (pending) |
| zd1211rw |
yes |
I have also provided the Packetspammer commandline applet to show how to use the injection API from userspace, this provides a simple, GPL2 tested base for making your own injection code for your own apps.
Work started on it in Dec 2006 by providing the old Linux stack driver patches. The real reason for the sustained effort is to enable Penumbra to work “out of of the box” on not only Linux desktops and laptops but generic embedded devices as well.
Posted in Embedded Linux | 1 Comment »
June 8th, 2007
Well I already knew that Jamendo allowed you to download their catalogue in Ogg, but by itself it was just an interesting side-note. (Jamendo being the primary site to get liberally licensed music, often biased towards francophone nymphs)
But to my surprise I tried Fedora 7 Rhythmbox a few minutes ago, expecting nothing much but the pile of Gnomic crud that assaulted me last time I tried it. Ah no, mashed up with Jamendo (but apparently not as planned Magnatune) Rhythmbox has become more than the sum of the parts and has crashed uninvited into iTunes territory.
It has become a native client app you can start up and listen to a big catalogue of liberally licensed music, not only without the expectation of having money sucked from your living veins but even with the expectation of being moved to voluntarily donate to the people sending you their hard work for free, when you especially appreciated what they offered.
And there on the menu bar is the legal, sanctioned, intentional “download album” button. In the face of this must you go and give money to the lawyer loving corporate coke snorting beast-creatures for mainstream crud? Or should you not set out to make a direct connection with the artists and show them your appreciation in a direct and personal way?
An extraordinary advance for standard Linux media players!
Posted in Desktop Linux | No Comments »
May 25th, 2007
Currently I am working on an embedded Linux ISDN-2 device I have designed… the hardware works fine but it’s clear that the challenges lie in the software stack. ISDN uses a cryptic, stateful protocol called LAPD to manage call state and features many layers of protocol stacks to get the job done. You know you are dealing with the old school when they refer to 64kbps log coded PCM as “3.1kHz voice”, meaning the audio bandwidth.
Naturally at this.. mature… stage of ISDN development (ie, I am plundering the ancient dusty tombs of a dead protocol that happens to be in wide use) I am not anxious to become a guru capable of winning arguments at the bar on ISDN protocol trivia, instead I need the freaking thing to work. If it’s a new technology, exploring the byways and understanding it closely can often pay off in the future, but there is much less chance of that when dealing with something old and basically deprecated (cf ADSL). So I chose to use mISDN, an attractive proposition with a driver for the chipset I am using and capable of working in both NT and TE modes — basically allowing acting as the exchange and the customer.
mISDN is getting some reasonable use as part of Asterisk via chan_mISDN, so I hoped for an easy ride. However it is clear that mISDN has not had much of a life outside of x86. The Makefile is not set up for crosscompile and indeed the thing from git when I started on it would not compile against a current kernel source. In fact the thing caused a segfault in the kernel build process on contemporary kernels, the two-line fix for which represents my first contribution to the actual Linux kernel tree. (Rather a weird bug… the text CONFIG_MODULE appearing in any source file will cause the build to fail with a segfault in a script. This text appeared accidentally in mISDN — CONFIG_MODULES was meant which did not trigger the bug)
Read the rest of this entry »
Posted in Software design | No Comments »
March 31st, 2007
The last few months I have been working on the Penumbra project. I started off patching wireless drivers in and out of the kernel tree to achieve the anonymous broadcast action that the project needs, but it became clear this would be completely unworkable for general use… getting wireless up in Linux can still be a struggle and hoping people will patch their driver or kernel in addition isn’t going to happen. After trying a couple of other methods in the end I created a radiotap-based packet injection patch for the mac80211 stack (formerly dscape / d80211), and bound it together with a patch from Michael Wu that provides radiotap-based Monitor mode. At the moment it is still in front of the linux-wireless folks and it’s not clear what the result will be. If the patch is accepted, then the code should make it into the mainline kernel and all mac80211-based wireless drivers will work with Penumbra out of the box in the future. The patchset provides generic radiotap monitoring injection that “just works” with libpcap both ways, so I am hoping it will get accepted without people having to form an opinion about Penumbra.
But one of the biggest hurdles in creating the patch was not technical, since I already had the core functionality working, but in fact the Linux kernel coding style. In some ways the coding style fits well with my own personal style (formed over 20 years of writing C and C++), we basically use the same K&R style. There are some spacing and commenting rules that are actually better than my style and I will adopt them wholesale. But that’s where the fun stops and the recrimination begins!
Read the rest of this entry »
Posted in Embedded Linux | No Comments »
March 4th, 2007
Makes no sense to have a license to Mordor for each of the hundreds of plasma displays at Luton Airport. It sparked a conversation with my stepson about why it was chosen: presumably because the devs didn’t know anything else than Windows, they will spend the rest of their working life acting as agents for Microsoft. This is the fruit of the Jesuit priest Ballmer’s creed of “give me a developer until he has 7 months in the industry and I will give you a Microsoft Trained Monkey”.
Using the same or cheaper hardware, an embedded Linux implementation would have had at least the same performance and much more flexibility. Ogg Matroska is a patent-free high quality video solution that plays back out of the box on Fedora for example. And if you wanted a hundred or a thousand displays your software licensing costs would stay at exactly $0.
Posted in Embedded Linux | No Comments »
March 3rd, 2007
The willingness of the kernel devs to refactor stuff is both a huge strength and weakness for the kernel. The strength is in the extraordinary continual optimization and improvement in the codebase, not just locally to an area of code but for cross-kernel concepts, like the recent workqueue changes.
But this has a pretty harsh cost for people writing or maintaining code that is outside the kernel tree and which therefore does not get the reworking applied to it as part of the core kernel. Whatever code they put out is invalidated and broken again and again sometimes in just the space of a few weeks.
The freedom to refactor despite breaking external code is a huge luxury for the devs seldom seen elsewhere in the coding world. Some projects take some care to allow compilation of their drivers for all recent kernels, using conditional compilation based on the kernel tree it is being compiled against, but other projects have an attitude that it will only compile against the current Linus tree.
The foaming churn of change makes for pretty hard work trying to make any kernel code that is not in the main tree work for any length of time. Greg KH at least is on record that his concept of the solution is to bring everything inside the kernel tree, but I don’t know how that will ever scale, and it loads the devs with having to understand a work with an ever growing amount of device-specific code. Aside from that, it makes the kernel devs gatekeepers for what will be accepted, and since not everything that can exist will be deemed acceptable, there will always be a class of device driver that is living out of the comforts of the main tree.
Anyway the end result is that for many projects that people need drivers for, the shelf-life of any instance of the driver sources is extremely narrowly defined. A Wifi driver for example touches many subsections of the kernel that have a history of changes in the recent past, yet requires a pretty recent kernel to compile at all with the stuff that it actually needs. So each driver tree has a quite narrow slot of kernel versions that it will work with, annoyingly current CVS from many drivers will not compile against current kernel source, not -git either but -rc versions. It means that out of tree drivers are a lottery for any recent kernel any kind of driver is a high commitment project, that needs constant revisiting to keep it alive.
There doesn’t seem to be an answer except that over time more and more critical subsystems in the kernel will surely mature to the point that they get fiddled with less and less, and things should therefore die down on the breakage front. But in truth the adolescent codebase of Linux shows no signs at the moment of slowing down its crazed foaming froth of reinvention and massive damage and breakage to the code around it.
Posted in Linux peripherals | No Comments »
January 27th, 2007
For the last couple of years I have been working with the AT91RM9200 ARM9 chip from Atmel. This is a very nice, fast, cheap CPU when combined with some SDRAM and NOR flash. One of the bigger problems I faced getting started with it was managing the sheer amount of sources that go into a modern Linux implementation. Many embedded folk just generate a giant tarball which is their whole root filesystem, they don’t track what versions are where and as a result providing sources for their magic tarballs can be a pain in the ass for them.
I knew I didn’t want to repeat this method from the start, so I began to work towards being able to use the RPM packaging system even with my crosscompiled stuff. Having the full RPM app and database doesn’t make sense for an Embedded system though, for example our standard AT91RM9200 platform only has 8MB of flash for all nonvolatile storage. I found that the excellent busybox had the start of an rpm implementation already, but although the code was really well-written, the implementation was not complete enough to do anything useful: it did not keep a database and there was therefore no possibility to erase packages, for example.
Over a few months I added more functionality to the busybox applet, including keeping a “database” of installed RPM headers down /var/lib to emulate most of the capabilities of real RPM. With this in place, I then went on to package all of the apps that I was interested to run on my distro. There are numerous advantages to formalizing the management of code into packages once you accept that you will only place packaged stuff on the device.
Creating an RPM binary also creates a source RPM (SRPM) that is contains all of the sources and build specification for that binary, and both the binary and source are versioned. Therefore so long as you offer the matching SRPM at the same time as you give someone the binary RPM, your GPL requirements for giving sources are solved in one stroke.
The patchlevel of any device can now be interrogated and used to select updates as well, in a formal manner. You can also express the need in a package to have “required” dependent packages of specific versions, reflecting a common situation where after some release you need a library of a certain version for it to work.
The “cost” for this level of control over your device boil down to: no more ad-hoc building. Even development builds are done through rpm packages. We provide a script that will remotely install over scp and ssh the latest version of a given package from the host commandline, even one that rebuilds the package before installing it remotely, and for every single edit you can be certain the sources are captured in the SRPM. We found a typical system is using only 100K of uncompressed data (typ 50K on jffs2) to maintain the RPM headers that make the packaging work. That is not significant even on a box with only 8MBytes of Flash.
Check out the Wiki at http://octotux.org for more details and the repository which contains the packages.
Posted in Embedded Linux | 2 Comments »
I'm