Finding a webcam that will work under Linux has always been a bit of a lottery. Sure, things are slowly improving, and drivers for many webcams are finally starting to appear in the mainline kernel, but on an Enterprise-class distro such as CentOS like we use at Pendre, support for webcams isn't top of the priority list - afterall CentOS is primarily a server OS and not that many servers actually need a webcam.

So after doing plenty of research, I finally settled on a Logitech QuickCam Pro 9000. This is a high-end webcam with integrated microphone boasting HD resolution from it's 2 Megapixel sensor, and a high quality Carl Zeiss lens with autofocus. The Logitech QuickCam Pro 9000 can be found for around £45 ($80-100US).

The QuickCam Pro 9000 uses the UVC driver which has recently been introduced into the mainline kernel. Unfortunately this has yet to be backported into CentOS 5, so I built the driver from source. This was relatively easy - just grab the latest tarball from linuxtv.org, extract, build and install (make && make install). Once built, the driver can be inserted into the kernel by running modprobe uvcvideo.

I tested the camera out using Skype and although the higher resolutions available with this webcam under Windows are not available to Linux users, the camera produces a very crisp clear picture and is clearly superior to that produced by most entry-level and midrange webcams. Sound is equally impressive from the built in microphone. Overall, highly recommended and you really do get what you pay for.

Previously we have seen how we can build kernel modules for CentOS (or RHEL) out of tree (Part 1; May 30th, 2008) or as DKMS modules (Part 2; July 18th, 2008). In this final part we will look at building kmod kernel modules packaged in RPM format and again we will use the coretemp module as an example.

The first thing we need to do is make sure we have all the kernel-devel packages installed for the currect kernel, including any xen and PAE variants. Next create a working directory containing the project source code and Makefile and create the Kbuild file by copying the Makefile. Finally, create a bzip2 compressed tarball of the source directory and copy the compressed tarball to the /SOURCES directory within your build environment.

Now we make a copy the kmodtool script (located at /usr/lib/rpm/redhat/kmodtool) called kmodtool-coretemp in the SOURCES directory and edit it to include any dependencies for our kmod RPM package (thanks to Johnny Hughes for the tip). Creating a custom kmodtool script isn't strictly needed for building kmod packages if you don't need to specify any dependencies but I was unable to find a convenient way to pass package dependencies from the SPEC file to the kmodtool build script. Below is an excerpt of my kmodtool-coretemp script showing an additional dependency for lm_sensors >= 2.10.2 which may be obtained from ATrpms.

Finally we make a SPEC file for the project named coretemp-kmod.spec file in the /SPECS directory of our build environment:

Now we're ready to build our kmod packages using rpmbuild:

which will produce a set of kmod-coretemp RPMs in your /RPMS directory under the appropriate architecture. Additionally, our SPEC file allows us to specify from the command line at build time which kernel version to build against (e.g, --define 'kversion 2.6.18-92.el5') or which kernel-variant kmod packages to build (e.g, --define 'kvariants ""' would only build the base kernel package).

kmod coretemp packages for CentOS 5 may be downloaded below and installed with rpm:

Alan has kindly updated the CentOS Wiki page on building kernel modules and I'd like to thank both Alan Bartlett and Akemi Yagi for helpful discussions, testing and encouragement whilst preparing this series of articles.

In an earlier article (Part 1; May 30th, 2008) I described how to build kernel modules for CentOS (or RHEL) out of tree and used the coretemp module as an example. My good friend and colleague, Alan Bartlett, had persuaded me to investigate packaging kernel modules, so herein we are going to look at how to package kernel modules in RPM format using the coretemp module as an example. I'd like to thank Alan for his technical assistance and encouragement without which this article wouldn't have been written.

There are two methods we can employ to build kernel module RPMs - DKMS and kmod. In this article we will look at Dynamic Kernel Module Support (DKMS) and in part 3 we will use kmod.

DKMS must be installed from RPMForge together with the necessary development packages.

We start by creating the necessary directory structure and copying the module source code and Makefile to that directory:

Next create a dkms.conf file for the project and save it to /usr/src/coretemp-1.00/

Now we are ready to invoke DKMS to add the coretemp module to the DKMS tree and build our RPM package:

Finally copy the created RPMs to somewhere safe and remove the coretemp module from the DKMS tree:

Now we can install our newly created coretemp RPM as normal:

In part 3 I will describe how to build coretemp as a kmod kernel module RPM package for CentOS (or RHEL) and will make the RPMs available for download.

There are a number of reasons why you may wish to build Linux kernel modules. For example, you may need a driver that isn't present in the current kernel, or you may want to apply a patch to an existing driver that adds functionality or fixes an bug. There are a number of ways you can tackle such issues:

• Build a new kernel based on the upstream vanilla sources that contain the required driver version
• Rebuild your current distro kernel with a patch applied

Both of these methods require you to build a complete custom kernel which you then become responsible for maintaining. However, many drivers will build out of tree and may be loaded into your currently running kernel. This approach has a number of advantages in that you don't need to compile a complete kernel, you can continue to run your stable distro kernel and you don't have to worry about maintaining your own custom kernel.

Building modules out of tree

As an example, I'm going to build the coretemp module for CentOS 5 used for monitoring the core temperature from inside Intel Core series processors as this driver didn't make it into the 2.6.18 series kernel used in CentOS 5.

First we need to create a project directory and src directory in that:

and place your module source file in /src

Next we create a top level Makefile in the project directory ~/coretemp/

and a Makefile in ~/coretemp/src/

Since coretemp isn't a module provided in the CentOS 5 kernel it makes sense to install our newly built module to /lib/modules/{uname -r}/extra.

So now we can build our new kernel module (you can build the module as a regular user, but make install will need root privileges):

and finally run depmod, load the module with modprobe and check it's loaded:

So let's have a look at coretemp in action, shown here monitoring all 4 cores of an Intel Q6600 quad core processor:

In part 2 I'll describe how to build dkms enabled kernel modules for CentOS/RHEL and package these in RPM format for distribution.

A critical bug has been found in the Pseudo Random Number Generator (PRNG) used in OpenSSL in debian Linux and it's derivative (e.g, Ubuntu etc) that renders random numbers predictable. The bug was introduced into debin unstable on September 17th, 2006 and has since propogated into the stable branch. All keys generated on affected systems should be considered compromised.

http://www.debian.org/security/2008/dsa-1571

http://www.ubuntu.com/usn/USN-612-1

I don't use debian (or Ubuntu), so how does this affect me?

The impact of this vulnerability is far reaching and goes way beyond debian-based systems. The vulnerability directly affects all debian-based systems using OpenSSL generated keys (OpenSSH, OpenVPN, website and mail server authentication by SSL/TLS, etc) and potentially affects anyone using SSL-based security or encryption.

OpenSSH

If you have a Linux server, then you almost certainly have SSH configured by default for remote access. If you use public/private key authentication and users have generated keys on affected systems, then brute-forcing those keys to gain remote access is trivial and there are already scripts available in the wild. The same applies to OpenVPN. The important facor here is the system the keys were generated on, not whether your server is running debian or other affected Linux distribution.

Additionally, all DSA keys that were ever used on a vulnerable debian-based system for signing or authentication should also be considered compromized due to a known attack on DSA keys.

System administrators are advised to conduct a full audit of all key pairs and regenerate new keys where appropriate.

SSL-encrypted websites and mail servers

Users of debian-based systems running SSL encrypted websites or mail servers using SSL/TLS certificates generated on affected systems should generate new certificates immediately. Additionally, if you have had your certificates signed by Root Certificate Authorities (eg, Twarte, VeriSign etc), then you will need to generate new certificates and get these resigned.

By definition, the public key is publicly known, and therefore it is trivial to generate a matching private key. It then becomes trivial to launch man-in-the-middle style attacks against encrypted or secured transactions such as credit card or other banking transactions or to obtain users login credentials. The potential for exploitation is huge and has the potential to affected all users of the Internet.

If you are at all unsure about how to generate new keys or certificates, please do not hesitate to contact us and we will be happy to assist in generating new OpenSSL keys or certificates for you.

There is currently a local privilege escalation flaw in the current Linux Kernel, affecting all kernels from 2.6.17 to 2.6.24.1 inclusive.

Exploit code for this vulnerability is available in the wild:

This vulnerability is not remotely exploitable so an attacker would first have to gain local access, however this could present significant risks for system administrators in shared environments with multiple system accounts.

Patches should be available shortly from distribution vendors and system administrators are advised to upgrade their kernel as soon as these become available.