|
|
ELJonline: The CerfCube as an Embedded Linux Server
2003-06-03 Article Rating:  / 0
How to build and install web and FTP servers, plus some development tools, on the CerfCube.The CerfCube is an embedded system manufactured by Intrinsyc. It is based on an ARM processor, which is the processor used in many PDAs. In this article I first explain how to turn a CerfCube into an FTP and HTTP server.
In order to have a complete web server with the ability to run CGIs, we compile Perl and install all the necessary modules for CGI development under Perl. Then I explain how to update the OpenSSH tools in the CerfCube. This implies adding libraries to the cross compilation toolchain, patching source files and configuring the CerfCube.  PrerequisitesBefore beginning this project, one should have:
Disclaimer The steps shown here have been thoroughly tested and are known to work. I am not responsible for damage caused by misuse of the directions presented here. We do things as root in this exercise, which requires special attention. Building the Applications Before building the applications and libraries, it is a good idea to create one directory for storing the downloaded files and another for storing the files we will upload to the CerfCube. Don't forget to have your arm-linux tools available in your PATH: devsys# export BINS_DIR=~/develop/binaries Boa is a small HTTP server that also provides a CGI environment. We are using boa-0.94.13, which is easy to compile and offers good performance.
You may change your SERVER_ROOT (the parent directory of your server's file tree) by editing the variable in defines.h. The server root also can be set at the command line when invoking Boa or in the configuration file boa.conf. We use this last option: devsys# ac_cv_func_setvbuf_reversed=no ./configure --sysconfdir=/etc The assignment ac_cv_func_setvbuf_reversed=no precaches a configuration value; without it, configure would try to find the value by compiling and running a small program. This method fails because the program is generated by the arm-linux-gcc compiler for an ARM processor and it is run on the development system under a different processor. The arguments to the function setvbuf are not reversed in glibc, so we precache the value "no". We want the configuration file to reside in /etc in the target system, so we set this parameter for sysconfdir. In the CerfCube, create directories for the web server:
We use proftpd-1.2.7 as our FTP server. Proftpd is stable, safe and already the server of choice for most standard distributions.
Again, we precache a configuration value to avoid running a test that would fail. In glibc, setpgrp is declared as a void function. We need to create a configuration file for the FTP server (proftpd.conf) file:
Now, we need to build inetd to run proftpd. Inetd is a dæmon that checks incoming connections to ports and launches the application that handles the request to the specific port, as configured in inetd.conf. Inetd is part of the inetutils package, which also contains many other Internet utilities. We use inetutils-1.4.2. As we are interested only in inetd, all other clients and servers offered by the package should be disabled. Building the Secure Shell Utilities To build openssh-3.5p1, we need the presence of the zlib and OpenSSL libraries in the cross compilation toolchain.
SSH Client, Server and Utilities OpenSSH provides a set of secure utilities to establish encrypted connections. From all the utilities provided we use a secure shell client (ssh), a secure shell server (sshd), a secure copy utility (scp), a key generator (ssh-keygen) and configuration files for ssh (ssh-config) and for sshd (sshd_config). We use openssh-3.5p1.
OpenSSH is not ready for cross compilation out of the box. The configure.ac file has to be modified to prevent some tests from running with binaries generated for ARM. A patch is provided, but the purpose of the patch is to give the macro AC_TRY_RUN a third option with the result known for the test. Read Listing 1 to see this idea in action. Another change is to use file checking directly (with the construct of test -f Patch with the supplied file (openssh-3.5p1.diff) [see Listing 1] or change configure.ac by hand following the previous hints:
Now, run autoconf to generate the configure script. If autoconf complains it does not find configure.in, upgrade your version. (This is the case with Red Hat 7.2). Get the newer version from ftp.gnu.org/pub/gnu/autoconf/autoconf-2.57.tar.gz then compile and install it. Uploading the Applications In the first step we strip all binaries of unneeded symbols: Don't worry that some text formats will not be recognized; the binaries are stripped anyway. Transferring Files from the Development System to the CerfCube Having a password-less ssh (and scp) connection to the CerfCube is advantageous. Otherwise, the password is requested before every scp transfer. When we compile Perl, this could mean typing the same password more than 30 times. To achieve a password-less ssh connection to the CerfCube, type devsys# cd ~/.ssh. Then, check to see if you have the file id_dsa.pub in this directory. If not, generate it with devsys# ssh-keygen -t dsa -P "". Accept the default directory offered by pressing Enter, and copy this key to your CerfCube: Send your id_dsa.pub key from your development system. You should be asked for the root password in the CerfCube. I am assuming an address 192.168.2.7; change it to suit your configuration. In the CerfCube, append the id_dsa.pub key to the authorized keys file: Now, we can start transferring files with devsys# cd $BINS_DIR. We have to change the name of scp to transfer it, though. The running instance of scp does not let itself be replaced by another binary with the same name and complains about being busy. The same is valid for sshd. We register the new libraries in the CerfCube with CerfCube# ldconfig -v. Observe that libz appears as modified; actually, it was upgraded to the latest version. In the CerfCube we activate sshd and scp but leave the old versions just in case: Compiling Perl Perl 5.8 has a feature that tests made at configure time are run remotely in the CerfBoard. This implies, of course, the necessity of working ssh tools on both the CerfCube and the development system. For added comfort, a password-less ssh connection, as set before, is advantageous.
Configuration is done with sensible default values, thanks to the -des options. Remember to put the arm-linux utilities in your search path. At the end of the compilation, you should end up with an executable named miniperl--not so mini, considering it is about 1MB after stripping. As with some other cross compilation aware applications, this one tries to run cross compiled binaries in the wrong environment, generating some error messages. But, Perl is compiled. Upload to your board and enjoy.
Postconfiguration of the CerfCube To reflect the configuration of the FTP server, do the following on the CerfCube:
These are the steps necessary to configure the web server:
The CGI module is standard in the latest Perl distributions, but our Perl installation in the CerfCube does not include any libraries. The CGI module depends on other modules. Generating those modules in the CerfCube requires a working C compiler that, of course, does not fit in the CerfCube. The solution is to copy the necessary modules from the Perl installation on your development system. Perl 5.6 and 5.8 modules work fine; other Perl versions were not tested. Using the configuration values given when compiling Perl, modules are expected to reside in a directory under /usr/local/lib/perl5. This could be the directory 5.8.0. Create that directory first: If your development system has Perl 5.6, simply issue the following command from there: If your development system has Perl 5.8, you need some more files: Testing the Servers You can start your Boa HTTP server either manually or with a startup script. To test the server, create an index.html file in /home/httpd. Now, point a browser to http://192.168.2.7/index.html. You should see the page you created. If you type http://192.168.2.7/, the index.html file is interpreted as a directory listing, and the HTML contents are displayed as plain text in the browser. To test your CGI environment, use the following script (found in stein.cshl.org/WWW/CGI, as an example to the Perl module CGI.pm). Name it test.cgi and place it in /home/httpd/cgi-bin. Make it executable (chmod 700), and invoke it from a browser with the URL http://192.168.2.7/cgi-bin/test.cgi. It should display a form. When you press Submit Query, you should see the data you entered at the bottom. To use the FTP server, it is necessary to first run inetd. You can run it manually or from a startup script with CerfCube# inetd. Now, you can copy any file to /home/ftp/ and from your development system connect to your FTP server with devsys# ftp 192.168.2.7. Now you have a working FTP server. About the Author: Ricardo Restrepo has been working with Linux for seven years and with embedded systems under Linux for one year. He enjoys learning living and extinct human and computer languages, reading classics in their original languages when possible, listening to Bach and jogging. Copyright © 2003 Specialized Systems Consultants, Inc., publishers of the monthly magazine Linux Journal. All rights reserved. Embedded Linux Journal Online is a cooperative project of Linux Journal and LinuxDevices.com. Related stories:
|
Directory /
news feed
