mkdir ~/rpmbuild \
    ~/rpmbuild/BUILD \
    ~/rpmbuild/RPMS \
    ~/rpmbuild/SOURCES \
    ~/rpmbuild/SPECS \
    ~/rpmbuild/SRPMS

Now, create the file ~/.rpmmacros and put the following basic macros in it:

%_topdir      %(echo $HOME)/rpmbuild
%_smp_mflags  -j3
%__arch_install_post   /usr/lib/rpm/check-rpaths   /usr/lib/rpm/check-buildroot

The %_topdir macro is set to the path of the root directory of your RPM building environment, /home/[user]/rpmbuild in this case.

The %_smp_mflags macro usually contains only the -j (–jobs) option for the make command, which defines the number of jobs (make commands) that may run simultaneously. Usually, this is set to the number of CPU cores plus one. So, on a dual core CPU, the smp flags are set to -j3.

The %__arch_install_post macro contains various checks that should be run on the files in the BUILDROOT location. I trust Fedora guys and use the defaults check-rpaths and check-buildroot on Fedora and CentOS. This macro is optional.

All macros that are set in ~/.rpmmacros override the system-wide macros that have been set in other locations. To check which paths are checked for macro files, enter the following command:

rpm --showrc | grep macrofiles

The following command shows the current configuration for RPM building:

rpm --showrc

All the available macros can be found in /usr/lib/rpm/macros.

Related Articles

• How To Build RPM Packages on Fedora
• chroot Environment Howto
• Build a single native kernel module
• Get my kernel headers script
• SPEC File Directory

Introduction

Searching the web for mod_gnutls binary distribution packages or information on how to set it up returned very few relevant results. This was a surprise, as, at this moment, the only implementation that supports SNI is mod_gnutls. So, I decided to write a tutorial on how to set things up for a test. I hope you find it useful.

The test that is described in this guide includes:

1. The compilation of the mod_gnutls module.
2. The generation of SSL certificates.
3. The configuration of the SSL-enabled name-based virtual hosts.

This test was performed on a server that runs Fedora 7.

Installation

In order to compile mod_gnutls, you will need the development tools for Fedora:

# yum groupinstall "Development Tools"

Install the mod_gnutls dependencies:

# yum install httpd-devel gnutls-devel

As an unprivileged user, download the mod_gnutls distribution and compile it.

$ wget http://www.outoforder.cc/downloads/mod_gnutls/mod_gnutls-0.2.0.tar.bz2
$ tar -xjvf mod_gnutls-0.2.0.tar.bz2
$ cd mod_gnutls-0.2.0
$ ./configure --prefix=/usr
$ make

Do not use the ‘make install‘ script, but perform the installation manually – it is only one library.

As root, copy libmod_gnutls.so to the directory that holds the Apache modules (usually /usr/lib/httpd/modules) and rename it to mod_gnutls.so for consistency:

# cp mod_gnutls-0.2.0/src/.libs/libmod_gnutls.so /usr/lib/httpd/modules/mod_gnutls.so

During the compilation, two keys, dhfile and rsafile, have been generated in the mod_gnutls-0.2.0/data/ directory. It is absolutely important to copy these files in httpd’s configuration directory (usually /etc/httpd/conf/), otherwise mod_gnutls will never work. This is undocumented, and I found out about it after some trial&error.

As root:

# cp mod_gnutls-0.2.0/data/{dh,rsa}file /etc/httpd/conf/

Installation is complete.

SSL certificates

In this test installation, two virtual hosts will be used. Thus, two SSL certificates will be required. Please read my article on how to generate SSL certificates for your servers, as this information is beyond the scope of this document. Alternatively, you may use a ready-made script which will create those certificates for you quickly. Such scripts are shipped will almost all Linux distributions. Please consult your distribution’s documentation for more information.

HTTPd Configuration

The configuration of the Apache web server includes two phases:

1. The configuration of the main server.
2. The configuration of the virtual hosts.

In the following instructions, some brief notes about what each directive does is included. For more detailed information, please consult the mod_gnutls documentation.

Main Server Configuration

This includes setting some general mod_gnutls options, which will be inherited by all virtual hosts.

But, first of all, httpd needs to be set to listen on port 443 (in addition to port 80). Instead of specifying the SSL port only (Listen 443) which will lead httpd to listen to all the available network interfaces, you may specify the exact network interface on which the server will listen. For example:

Listen 192.168.0.1:443

Next, load mod_gnutls:

LoadModule gnutls_module modules/mod_gnutls.so

Add some MIME-types for downloading Certificates and CRLs from your web sites (taken from the mod_ssl configuration):

AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl    .crl

It is suggested that you use a session cache for mod_gnutls. This will increase its performance. In this example, the dbm cache type is used. This cache type requires a directory where mod_gnutls will actually save SSL session data. So, creating a directory for this purpose and giving ownership to the user that runs Apache (usually apache or www-data) is needed. Assuming that the Apache user is apache, as root issue the commands:

# mkdir -m 0700 /var/cache/mod_gnutls_cache
# chown apache:apache /var/cache/mod_gnutls_cache

Now, back to the Apache configuration. The following directive sets the dbm SSL Session Cache for mod_gnutls:

GnuTLSCache dbm "/var/cache/mod_gnutls_cache"

Set a timeout for the SSL Session Cache entries. Usually, this is set to 300 seconds:

GnuTLSCacheTimeout 300

Finally, specify that on the 192.168.0.1:443 interface and port there will be name-based virtual hosts; that is vhosts that share the specified interface and port:

NameVirtualHost 192.168.0.1:443

Virtual Host Configuration

The example virtual hosts are: v1.example.org and v2.example.org. It is assumed that two SSL certificates with the canonical name (CN) correctly set to each of the aforementioned vhost domains have been generated.

In the following vhost configs, only the absolutely required directives have been used. The rest of the options are inherited from the main server.

<VirtualHost 192.168.0.1:443>
    ServerName v1.example.org:443
    GnuTLSEnable on
    GnuTLSCertificateFile /etc/pki_custom/certs/v1.example.org.crt
    GnuTLSKeyFile /etc/pki_custom/private/v1.example.org.key
    DocumentRoot "/var/www/v1/public_html"
</VirtualHost>

<VirtualHost 192.168.0.1:443>
    ServerName v2.example.org:443
    GnuTLSEnable on
    GnuTLSCertificateFile /etc/pki_custom/certs/v2.example.org.crt
    GnuTLSKeyFile /etc/pki_custom/private/v2.example.org.key
    DocumentRoot "/var/www/v2/public_html"
</VirtualHost>

Testing the setup

Having finished with the configuration, review the changes, restart the server and check the error logs for any errors.

Use a web browser to visit each of the virtual hosts by using the HTTPS protocol:

https://v1.example.org/

https://v2.example.org/

Until now, the web server did not support the SNI TLS extension. Therefore, when visiting the v2.example.org virtual host, you would see two warnings in your browser. The first one would be because the vhost’s certificate has not been issued by a trusted Certificate Authority – this is normal as it was you who issued that certificate – and the other one because on a server without SNI support it is actually the V1 vhost’s certificate that is used when visiting V2 vhost over https. Remember the limitation with SSL and name-based virtual hosts?

With mod_gnutls, the server supports the SNI TLS extension. Although the virtual hosts are name-based, no matter which one you visit, the relevant certificate for each vhost is used and the only warning you see is the one about the certificates being self-signed. You can get rid of these by purchasing a certificate that is issued by a trusted Certificate Authority.

Conclusion

mod_gnutls works. Actually, it was a real pleasure to see SNI work!

It is important to note though that mod_gnutls is still in experimental phase. Therefore, performance issues should be considered as normal when using it.

At the moment of writing, my server uses Fedora 7 as an operating system. As I haven’t upgraded my desktop to F7 yet and my server does not have any development tools installed, I compiled mod_gnutls on a Fedora 6 system and used it on Fedora 7. I do not know if that was the reason – and I did not have the necessary free time to investigate – or anything else, but, during the use of mod_gnutls, my server’s load average increased significantly.

I will test mod_gnutls again soon and post the new results, if they are different than the ones I present in this article. I highly recommend that you try it, as it is currently the only way to easily achieve SSL-enabled name-based virtual hosts using the SNI TLS extension. Note, that this extension will be supported by openssl 0.99, so the moment that SNI goes mainstream and such a setup becomes easy and cheap to implement with any Linux distribution is close.

One last thing that has not been mentioned at all is about SNI support in web browsers. Currently, with the exception of Safari (this is unconfirmed, please correct me if I am wrong), the latest versions of all major web browsers, Firefox and other Mozilla-based browsers, Internet Explorer, Opera, support SNI.

Related Articles

• mod_gnutls binary for Apache
• Assign Virtual IPs to your NIC
• Use mod_deflate to Compress Web Content delivered by Apache
• Be your own Certificate Authority (CA)
• Script for Apache Error Report

Related Articles

• Encrypt devices using dm-crypt and LUKS
• Creative Commons v3.0 Licenses Launched
• The Complete Fedora Kernel Headers
• Using SSH for networking
• Best Practices of Software Licensing

Anyway, I still package a bunch of RPMs for my systems. I decided to upload some of the spec files. These are available in this directory. There are many more, but they need a bit of polishing.

Some notes:

• The nvidia-legacy spec file generates RPMs for the OpenGL libraries and the NVidia Legacy driver (for GF2 for example). These packages do not replace any core Fedora files. The official installation script from NVidia replaces some files and it should not be used.
• These spec files are completely unsupported. Don’t send me emails about them, unless you find any mistakes in them. For information about building RPMs on Fedora refer to my relevant small article.
• The spec files are for software that does not exist in the repos mentioned above (except for kernel modules, for which I don’t wish to wait until Livna releases new versions). I haven’t submitted any of them to Extras or Livna because I don’t have the time to update them in time. The files comply with the Fedora packaging guidelines and naming schemes.
• Dependencies in the alexandria and ruby-related spec files were updated by Leeksoup for FC5. I don’t use this software anymore, so I appreciate it :-)

Packaging is art :-)

Related Articles

• Fedora Core 5
• File and Directory diff in color in Midnight Commander
• How To Build RPM Packages on Fedora
• GNOME 2.14, Rawhide, SUSE and more…
• The road to Alexandria…

--- drivers/lirc_gpio/lirc_gpio.c.original      2006-01-01 15:43:46.000000000 +0200
+++ drivers/lirc_gpio/lirc_gpio.c       2006-09-08 20:03:34.000000000 +0300
@@ -49,8 +49,8 @@
 #include "../drivers/char/bttv.h"
 #include "../drivers/char/bttvp.h"
 #else
-#include "../drivers/media/video/bttv.h"
-#include "../drivers/media/video/bttvp.h"
+#include "../drivers/media/video/bt8xx/bttv.h"
+#include "../drivers/media/video/bt8xx/bttvp.h"
 #endif

 #if BTTV_VERSION_CODE < KERNEL_VERSION(0,7,45)

While lirc_gpio should now be compiled without problems, there is one more issue, which seems to be a kernel-source bug. The bttvp.h “includes” another header (btcx-risc.h), which should exist in the same directory. But, this file actually exists in the parent directory (drivers/media/video/). So, until this kernel source issue is resolved, the only way to build lirc_gpio succesfully is to:

1. patch LIRC sources with the above patch,
2. copy the btcx-risc.h kernel header from location: drivers/media/video/ to location: drivers/media/video/bt8xx/ within the kernel source tree.

I have already filed a bug about this in the Fedora Bugzilla. If there is anything I have missed, drop me a line.

Further Reading

• The Complete Fedora Kernel Headers – all the required actions in order to compile lirc_gpio in Fedora.
• How to configure and use LIRC

Related Articles

• Build a single native kernel module
• The Complete Fedora Kernel Headers
• Get my kernel headers script
• How to configure and use LIRC
• Creative PC-CAM Series webcams in linux

So, a custom compilation of the extensions is needed. Just keep in mind that in order to also compile the sample plugins you ‘ll need to add the following option when configuring:

--with-extensions=really-all

The --with-extensions option can take a comma separated list of the extentions that will be built, or the value “all“, which is supposed to build all the available extentions except for the samples, or it can be “really_all” which builds everything. Finally, this option can be completely omitted, which leads to the compilation of the default extentions.

Some of the extensions that do not exist in the default RPM package and I definitely wish they were there, are a feed subscription extension, an almost efficient ad-blocker and of course a Python Console. I do not really know why they are missing, perhaps due to some bugs, but I use them for a long time now and they seem to work fine.

PS: And, by the way, non Epiphany users, just give this browser a shot.

Related Articles

• Some thoughts about Epiphany extensions
• Featured Epiphany Plugins
• Tab Session Management extension for Epiphany
• Tab Links extension for the Epiphany browser
• Epiphany Python Console – Documentation

What Is An RPM Package?

In simple terms, an RPM package is an advanced form of a container for other files. Generally, it includes:

1. The program to be installed plus all the necessary files that accompany this program.
2. Information about the program and the RPM package itself.
3. Information about the program’s dependencies, which means info about what other software needs to be installed, so your program to function correctly in the system.
4. Information about potential conflicts between the program and other software that is currently installed in the system.
5. Actions that need to be performed when the program is installed/upgraded/removed.

But, this is enough with the theory. For more information, refer to the links at the Further Reading section of this article.

Prerequisites

The following are needed in order to build RPM Packages.

• The development tools. All the utilities that are needed to compile a program, including the compiler itself.
• A SPEC file for the particular program you want to create an RPM package for. A SPEC file contains all the information regarding the program’s details, its dependencies, the compilation options etc. For more info on writing SPEC files, refer to the links at the Further Reading section of this article.

Things You Need To Do Once

There are a couple of thing you need to do before starting building your RPMs. These mainly include the installation of the core development tools and the creation of the building environment for your user.

Install the core development tools using YUM. As root:

# yum groupinstall "Development Tools"

Next, create the building environment for your user. Fortunately, Fedora includes some neat utilities that greatly simplify this procedure. First, use YUM to install them (as root):

# yum install rpmdevtools

Then, create the directory structure in your home directory by issuing the command (as a user):

$ rpmdev-setuptree

That’s it.

Build That RPM!

Provided that you have a SPEC file for your program, you can build the binary RPM package by issuing the command:

$ rpmbuild -bb --clean myprogram.spec

If you need to build the package for a different architecture, you can set the --target option, like in the example below:

$ rpmbuild -bb --clean --target i686 myprogram.spec

Please note that you should never build RPM packages using root.

Dependencies

Some programs may need additional development libraries in order to be compiled. You can use YUM to install these needed libraries (-devel packages) or programs. If the operation finishes succesfully, you’ll find your RPM package in the ~/rpmbuild/RPMS/ directory.

Further Reading

This small article’s goal was to get you started with art of RPM packaging by setting up the environment for RPM building. It’s a "Batteries Not Included!" article though. Information about how to write SPEC files is not available here. It would be pointless, as there are some excellent resources for this purpose. So, prepare for some real reading ladies and gentlemen:

1. Chapter 4. Building RPM Packages of the Fedora Core Developer’s Guide by Tammy Fox, Havoc Pennington – General information about the SPEC file sections.
2. Chapter 8. Creating RPMs: An Overview of the RPM Guide by Eric Foster-Johnson – In depth information about SPEC files.
3. Packaging Guidelines by Tom ‘spot’ Callaway – Information specific to writing SPEC files for Fedora Core.
4. Package Naming Guidelines by Tom ‘spot’ Callaway – Information specific to Fedora RPM naming scheme.
5. RPM scriptlet recipes – Some extremely useful notes regarding the actions that need to be performed when a package is installed/upgraded/removed from the system, which should be included in the relevant sections of the SPEC file.
6. Maximum RPM – Taking the RPM Package Manager to the Limit – An excellent book about the RPM Package Manager, by Edward C. Bailey, Paul Nasrat, Matthias Saou, Ville Skyttä.

Changes

Wed 23 Jan, 2008

This article has been updated to reflect the changes in the package names for rpmdevtools. The old package, named fedora-rpmdevtools, is now known as rpmdevtools. Also, the utility that sets up the initial rpmbuild directory tree is now called rpmdev-setuptree (old name was: fedora-buildrpmtree).

Related Articles

• Build a single native kernel module
• SPEC File Directory
• The road to Alexandria…
• The Complete Fedora Kernel Headers
• Manually Prepare the RPM Building Environment

Prerequisites

In order to use LIRC you will need the necessary hardware components, a remote control and an infrared receiver. LIRC supports a lengthy list of such devices. You can check if your equipment is supported at this page.

Next thing is to download the latest stable LIRC package from the project page and configure it properly for your equipment. For this article I’ll use the traditional way of compiling and installing software, so some such experience is required from your part. Of course, if you are into package building, you can build your own RPM or DEB package.

Configure, Compile, Install

Extract the LIRC package in a temporary directory (~/tmp/):

# tar -xzvf lirc-X.X.X.tar.gz -C ~/tmp/

The most important part of the LIRC pre-compilation configuration is the choice of the appropriate driver for your hardware. For more info check the LIRC Documentation. Normally, if you know your hardware, change to the directory where you have extracted the LIRC package and issue the following command in order to check which driver name you should use:

# ./configure --help

Next, configure the package for your system. Because some kernel modules are built together with LIRC, you will need to have the kernel development package (eg kernel-devel) for your running kernel installed. To configure LIRC issue the command:

# ./configure \
--prefix=/usr \
--with-x \
--with-transmitter \
--enable-sandboxed \
--with-moduledir=/lib/modules/$(uname -r)/extra/lirc \
--with-kerneldir=/path/to/kernel/headers \
--with-driver=DRIVER

Substitute DRIVER with the appropriate driver name and edit the path to your kernel headers/sources in the --with-kerneldir option. Note that the --with-kerneldir option can be safely omitted.
We use the --enable-sandboxed option, so that the installation script does not try to create any device nodes for LIRC. An UDEV rule, that we will create later on, will take care of this.

If the configuration script fails due to missing dependencies, make sure you have all the necessary development tools, libraries and kernel headers installed in your system. Just read carefully the on-screen error messages to see what is missing.

After this configuration is finished, you will see a message in your terminal about which LIRC module will be used. Take a note of the module name, as you will need it later on.

NOTE: On Fedora, I was not able to build the required lirc_gpio module. My IR receiver is attached on my KWorld TV tuner card, so this module was absolutely needed. In such a case you will probably want to read my post about the The Complete Fedora Kernel Headers.

Next, proceed to the LIRC compilation:

# make

and installation. This step is needed to be done as root:

# make install

If for any reason you want to uninstall all LIRC files, from within our current directory, issue the command:

# make uninstall

Special Note: Before you update your system kernel at some later time, you will need to uninstall LIRC. After the kernel upgrade, you will have to repeat the previous configuration, compilation and installation steps, so that the LIRC module is built for your new kernel.

The final step is to create an UDEV rule, so that the LIRC devices are created properly and with appropriate permissions.

Create a text file, named 10-lirc.rules, in the /etc/udev/rules.d/ directory and add the following to it:

KERNEL=="lirc[0-9]*", NAME=="lirc%n", GROUP=="disk", MODE=="0660"
KERNEL=="lirc0", SYMLINK=="lirc"

Finally, make sure you add the users you want to have access to the LIRC server to the group disk. Alternatively, if you want all the users to be able to access LIRC, then modify the MODE in the UDEV rule above from MODE=="0660" to MODE=="0666".

That’s it.

The LIRC Server Configuration

It seems that the LIRC daemon (lircd) does not load the default module (driver) automatically when it starts, so this module should be loaded manually.

To load the appropriate module and the LIRC server at boot time, all you have to do is to add the following lines to the /etc/rc.d/rc.local file. As root:

modprobe MODULE_NAME
lircd

Substitute MODULE_NAME with the module name you had taken a note of when configuring LIRC. For me, it would be lirc_gpio. The LIRC daemon, by default, uses the driver that was defined during the LIRC pre-compilation configuration.

The LIRC daemon also needs a configuration file (/etc/lircd.conf), which contains the proper addresses of your remote control’s buttons. The LIRC package contains some ready made remote configs, but I suggest you create your own. Read on…

The Remote Control Configuration file

In this section we will create a configuration file for our remote control by using an utility named irrecord, which was built together with the rest of the LIRC components. Since irrecord is a lircd client, the LIRC daemon needs to be running prior to using this tool.

So, as root, load the appropriate LIRC module and start the daemon:

# modprobe MODULE_NAME
# lircd

Now, change to a temporary directory and start irrecord:

# irrecord REMOTE_NAME

REMOTE_NAME is the remote control config file that will be created in the current directory. This will also be the name of your remote control that will be used within the created file. If you need to change it, do it by hand after this operation is finished. All you have to do is to follow the on-screen instructions. Generally, you will be asked to give names for the remote control buttons and to press each one of them.

After you are finished, copy the REMOTE_NAME file into /etc/, naming it lircd.conf. As root:

# cp REMOTE_NAME /etc/lircd.conf

Kill the running lircd instance and start the daemon again, so that it uses the new configuration:

# killall lircd
# lircd

Applications and LIRC Support

There are three kinds of applications:

1. Those which could and actually have been built with LIRC support. These act as LIRC clients when there is a running LIRC daemon.
2. Those which do support LIRC, but have not been compiled with the LIRC support enabled.
3. Those which do not support LIRC at all.

Generally, most multimedia applications, video and audio players, TV viewers and FM tuner applications, support LIRC. Also, many applications provide a method (separate utility or options) to send commands to a running instance of the application. This is particularly useful for programs that belong to the 2nd and 3rd categories. LIRC provides an utility, called irexec (LIRC client), which can be used to execute any command we want. This way, those applications can be controlled with the remote control through LIRC.

In order to use our remote control with a certain application, we have to create a configuration file that contains the mappings between the remote control’s buttons and the commands that will be executed when each button is pressed.

This file can be:

• named .lircrc and placed in the user’s home directory.
• named lircrc (without the period in front of the name) and placed in the /etc/ directory for system-wide configuration.

Information about this file’s format can be found in the relevant section of the LIRC Documentation.

Quick Tests

Here are some sample .lircrc files, so that you can test your installation. Make sure you have loaded the proper LIRC module and you have started the LIRC daemon. Save one of them as .lircrc and place it in your home directory.

Special Note: In the following sample config files, substitute the remote control name with the name you have used for your own remote control and the button name with a name of any of your own remote control’s buttons.

The first two samples will work with Xine and MPlayer respectively. These two players are usually built with LIRC support and, when launched, they act as LIRC clients.

Load Xine and press the specified button on your remote control. It should toggle between full-screen and window-mode.

# .lircrc - XINE sample test
begin
    prog = xine
    remote = KWTV878RF
    button = ZOOM
    config = ToggleFullscreen
    repeat = 0
end

Use the following config with MPlayer.

# .lircrc - MPLAYER sample test
begin
    prog = mplayer
    remote = KWTV878RF
    button = ZOOM
    config = vo_fullscreen
    repeat = 0
end

For applications that are not LIRC clients themselves, but which provide a method to send commands to a running instance of the application, the configuration is a bit different. The LIRC client irexec is used in these cases. When you press a button on the remote control, irexec executes the specified command. This requires that irexec is running. Start it as a user:

# irexec

Save the following as .lircrc and launch TVtime. The specified button on the remote control should toggle between full-screen and window-mode.

# .lircrc - TVtime sample test
begin
    prog = irexec
    remote = KWTV878RF
    button = ZOOM
    config = tvtime-command TOGGLE_FULLSCREEN
    repeat = 0
end

To start irexec and have it run in the background, start it as shown below:

# irexec &

To kill it:

# killall irexec

Some hints for more complicated configurations

Here are some hints for those of you who need complicated setups.

Toggle Buttons

You can create toggle buttons, for example you can set the same button to Play or Pause a video stream, by setting two config = command directives. They will be executed in turns. For example:

# Toggle button example
begin
    prog = irexec
    remote = remoteA
    button = buttonA
    config = play_command
    config = pause_command
    repeat = 0
end

Using this configuration, when buttonA is pressed for the first time, the play_command is executed. The second time buttonA is pressed, the pause_command is executed.

Modes

Let’s assume that you want to control many applications with your remote control. Some of them are LIRC clients and some are controlled through irexec. You can define various modes (groups of button to command mappings), one for each application.

First of all, read the .lircrc format page from the LIRC Documentation very carefully.

Keep in mind the following rule:

Each time you start a LIRC client and there is a mode within your configuration with a name equal to the application’s name, then this mode is automatically entered.

This means that if there is a mode named mplayer inside .lircrc and you start the mplayer program, which is a LIRC client, then the mplayer mode is automatically entered and only the button mappings that exist within this mode are functional.

Save the following as ~/.lircrc, substitute the remote control name and button names with your own, and start irexec:

# Example with modes

# MAIN BEGIN (irexec mode) - Application Selection Mode
# ---------------

begin irexec

    begin
        prog   = irexec
        remote = KWTV878RF
        button = 1
        # Start TVtime
        config = tvtime --window &
        # Enter tvtime mode
        mode = tvtime
    end

    begin
        prog   = irexec
        remote = KWTV878RF
        button = 2
        # Start Totem player and play DVD
        config = totem dvd:/ &
        # Enter totem mode
        mode = totem
    end

    begin
        prog   = irexec
        remote = KWTV878RF
        button = 3
        # Start Xine and play DVD
        config = xine dvd:/ --hide-gui &
        # Enter xine mode
        mode = xine
    end

end irexec

# ---------------
# MAIN END (irexec mode end)

# APP MODES BEGIN
# ---------------

# tvtime mode
begin tvtime
    begin
        prog = irexec
        button = POWER
        config = tvtime-command QUIT
        # Enter irexec mode
        mode = irexec
    end
    begin
        prog = irexec
        button = ZOOM
        config = tvtime-command TOGGLE_FULLSCREEN
    end
end tvtime

# totem mode
begin totem
    begin
        prog = irexec
        button = POWER
        config = totem --quit
        # Enter irexec mode
        mode = irexec
    end
    begin
        prog = irexec
        button = ZOOM
        config = totem --fullscreen
    end
end totem

# xine mode
begin xine
    begin
        prog = xine
        button = POWER
        config = Quit
        # Enter irexec mode
        mode = irexec
    end
    begin
        prog = xine
        button = ZOOM
        config = ToggleFullscreen
    end
end xine

# ---------------
# APP MODES END

I hope this example is clear enough. What is going on here is that when irexec (LIRC client) is executed, then the irexec mode is entered. When you press button "1", then TVtime is launched and the tvtime mode is entered. When you press the "POWER" button, TVtime quits and the irexec mode is entered etc. etc.

Furthermore, even if you do not start irexec, when you launch any LIRC enabled application, like Xine, MPlayer, Gnomeradio etc, then the appropriate mode will be entered automatically and you will be able to control this application remotely.

As you have probably already read in the LIRC Documentation, you can modularize this configuration by keeping each application mode in a separate file. Just don’t forget to include those separate files by adding a line like the following in ~/.lircrc. For example:

include ~/.lirc/tvtime.lircrc

Final Notes

Maybe you will need some time to familiarize yourself with the .lircrc format and probably more time reading the LIRC documentation, but you will be satisfied with the result.

For information about what commands are available for each application, please refer to the application’s documentation, project web site or support forum.

Also, if you need more information or support for LIRC, please ask your questions in relevant web forums. I have written all I know in this guide, so I am afraid I cannot help you more.

LIRC can do more things, for example it can be used to transmit IR signals or to connect to other LIRC servers accross the network. These have not been covered, not only because I consider such info as "too much" for a new user, but also because I have not been able to devote any time to experiment with these features.

This guide was written while using a Fedora 4 system.

Further Reading

You should read:

1. The LIRC Manual (Documentation)

Related Articles

• Kernel 2.6.17 and lirc_gpio driver
• How to Disable IPv6 in Fedora and CentOS
• Build a single native kernel module
• The Complete Fedora Kernel Headers
• Creative PC-CAM Series webcams in linux

Prerequisites

In order to build a module this way, you will need two things:

1. The complete Fedora kernel sources, which are provided by the kernel SRPM.
2. Knowledge of the module’s configuration options.

The "Qconf Graphical Kernel Configuration Tool" can be of great help in determining which are the configuration options for a certain module. You can launch this tool, by issuing the following command in the root directory of your kernel sources:

# make xconfig

Furthermore, this article assumes that we want to keep the default kernel configuration.

I would also recommend that you read another document of mine, named "The Complete Fedora Kernel Headers" or the Fedora Core Release Notes, which describe among other things how to get the fedora kernel sources.

Gathering the needed information

I will use the linux ntfs driver as an example. This is not enabled in the default Fedora kernel configuration, but we want to create this module, so that our system can recognize NTFS volumes.

Using the "Qconf Graphical Kernel Configuration Tool", we see that this module’s configuration options’ names are the following:

1. CONFIG_NTFS_FS
2. CONFIG_NTFS_DEBUG
3. CONFIG_NTFS_RW

Actually, the previously mentioned tool omits the "CONFIG_" part of the option’s name. You should keep this in mind.

The first of these options, determins if the kernel will have support for this feature or not. The possible values are "y", "m" or "n". As we want to create a module, the proper value for this is the "m".

The other two options are actually specific to the module itself. The values they can take are "y" or "n". You decide which of these you want enabled. For this example, I’ll set both of these to "n".

Building the module

In order to build this module, we change to the root directory of our kernel sources and issue the following command:

# make CONFIG_NTFS_FS=m CONFIG_NTFS_DEBUG=n CONFIG_NTFS_RW=n M=fs/ntfs

We pass the proper kernel configuration options to make, but also specify the relative path to the module’s Makefile and source code with the M option.

This way, we can build a native kernel module which is not enabled in the kernel configuration. The compiled module, ntfs.ko in this case, can be perfectly added to our system’s kernel modules either manually or by using an RPM file, but this is beyond this article.

In order to clean the module’s directory from the compilation’s products, we can issue the following command:

# make M=fs/ntfs clean

Further Reading

I strongly suggest that you create RPM packages to add or remove software from your system, so I recommend the Chapter 4. Building RPM Packages from the Fedora Core Developer’s Guide.

Related Articles

• The Complete Fedora Kernel Headers
• Kernel 2.6.17 and lirc_gpio driver
• How To Build RPM Packages on Fedora
• Creative PC-CAM Series webcams in linux
• Get my kernel headers script