wiki:Projects/OpenLDAP

Version 39 (modified by C Rempel, on 06/24/12 at 04:51:30) (diff)

/* leaf.cfg */

OpenLDAP

Status: Exploratory Light Weight Directory Access Protocol (LDAP) is used to manage distributed directories over a network.

According to Wikipedia: Historically the OpenLDAP server (slapd, the Standalone LDAP Daemon) architecture was split between a frontend which handles network access and protocol processing, and a backend which deals strictly with data storage. The architecture is modular and many different backends are available for interfacing to other technologies, not just traditional databases.

OpenLDAP has been identified by Dr. Sherrill as a "high-priority" for RTEMS. According to Beyond Linux from Scratch The OpenLDAP package provides an open source implementation of the Lightweight Directory Access Protocol,.

In addition to helping me learn valuable porting skills, this project serves as a first step towards adding needed modern protocols to RTEMS, so that RTEMS can use LDAP.

Goal

Concise statement of the overall goal of the project. Refine this initial statement to include: project deliverable (code, docs, testing), required/suggested methodology, standards of quality, possible goal extensions beyond the main objective.

C Rempel's main goal for porting OpenLDAP to RTEMS is to develop a method of porting semi-complex existing open source packages to RTEMS that is efficient, elegant and complete. Efficient meaning the person porting the software can do so in a matter of days or weeks. Elegant meaning the essence of the original source package, and the RTEMS source are preserved: as few lines of code are modified as possible in both the original source package and the RTEMS source as possible, as well as libraries, programs, and executable are installed in the same locations as they would be if they were built in the RTEMS source tree. Completeness meaning not only the libraries are ported, but the programs and tests as well.

Deliverables

Just some ideas from C Rempel:

= RTEMS Webkit Port =

# A Makefile.openldap that builds the SlapD libraries for RTEMS applications # A Makefile that builds the programs. # A program that will run the LDAP testing suite provided by OpenLDAP. Should be automated, as additional tests will be used in the future.== = RTEMS Source Tree Port (6 months to 2 years away) ===

# The method used to transform the OpenLDAP Makefiles and RTEMS Addon Packages oriented Makefiles to RTEMS source Makefile.am's # A patch making the the needed configurations defaults in the OpenLDAP's configure.in and Makefile.am. # In an ideal world this would be based upon other libraries installed on RTEMS, for example: SSL HAS to be optional, as encryption is illegal in some countries.

Suggested Methodology

Start by porting to RTEMS Addon Packages, then port to RTEMS Source tree.

Standards of Quality

As this is currently a hobby project to identify a porting methodology for existing open source packages for C Rempel, the standards of quality are the OpenLDAP developer tests run as the OpenLDAP developers would expect them to run.

Possible Goal Extensions

Explore and (possibly port to RTEMS) the additional packages used by OpenLDAP: # Database (such as Berkely DB) # Authentication (such as Cyrus SASL) # Additional encryption

Explore and (possibly port to RTEMS) the additional packages that use OpenLDAP: # Apache (did this already, but could be ported more efficiently, elegantly, and completely) # Others

Add an OpenLDAP test to the RTEMS Networking Demos

Requirements

List the requirements and level of expertise you estimate are required by the developer tackling this project will have to have: Required level of programming language(s), specific areas of RTEMS or tools, level of familiarity with RTEMS, cross-development, GNU/Linux, etx., development/documentation/testing tools, mathematical/algorithmic background, other desirable skills.

Required Programming Languages

C, Bash, Makefile, Autoconf m4, Makefile.am

Specific Areas of RTEMS or tools

# RTEMS Addon Packages # RTEMS Cpu-kit

Level of Familiarity of RTEMS

For the RTEMS Addon Packages port: ability to start the Hello, World RTEMS Application from the Examples v2. For the RTEMS Source Tree port: some experience with modifying configure.ac and Makefile.am.

Cross-development

For the RTEMS Addon Packages port: experience using Makefiles and using configurations for cross development. For the RTEMS Source Tree port: some experience with modifying configure.ac and Makefile.am.

Gnu/Linux?

For the RTEMS Addon Packages port: ability to use the command line, and modify Makefiles. Knowing "grep -r", "find -name", and a text search feature REALLY helpful.

For the RTEMS Source Tree port: in addition to configure.ac and Makefile.am, knowing the legal differences between a Berkely and Gnu style license.

Development / Documentation / Testing Tools

Development Tools: RTEMS Addon Packages, RTEMS Source Tree, RTEMS Toolset, Qemu

Documentation Tools: RTEMS Wiki, comments

Testing Tools: Tests provided by GCC and OpenLDAP, possibly other third party open source LDAP testing software...

Mathematical/algorithmic background

None: this is simply putting two pieces of existing software together.

Other Desirable Skills

An interest in reusing other developer's code, over writing one's own.

An interest in perusing the RTEMS git, and other projects, to find code maintained by other developers (to make this port successful after the developer moves on).

Resources

Current RTEMS developers, papers, etc that may help you in this project.

C Rempel is willing to help

Other sections

If you have more to say about the project that doesn't fit in the proposed sections of this template, feel free to add other sections at will.

Acknowledgements

  • who helped add did work

Miscellaneous Sections

A first stab at building Open LDAP

As the project progresses, you will need to add build instructions, etc and this page will evolve from a project description into a HOWTO.

I am building this package because it is simpler than the Apache Runtime, and so is a good way to gain needed experience. I started with using the RTEMS Addon Packages. How to use the RTEMS Addon Packages is outlined http://www.rtems.com/wiki/index.php/RTEMS_Add-On_Packages.

Makefile.openldap

I put the following in rtems-addon-packages/Makefile.openldap

# # Declare supported terminal types. # This value can be augmented/overridden by the site-configuration file #

include ../RTEMS_Makefiles/Makefile.common

# # The following will work only if you have the latest ncurses version # of infocmp installed before trying to build for an RTEMS target. # The cf_cv_type_of_bool hack works around a bug when configuring # for a cross-target. # all:

ac_cv_member_struct_msghdr_msg_control=no \ ac_cv_func_memcmp_working=yes \ ac_cv_func_initgroups=yes \ ac_cv_func_setuid=no \ ./configure \

--host=$(RTEMS_CPU)-rtems4.11 \ --prefix=$(exec_prefix) \ --libdir=$(exec_prefix)/$(RTEMS_BSP)/lib \ --includedir=$(exec_prefix)/$(RTEMS_BSP)/lib/include \ --without-tls \ --with-yielding_select=yes \ --disable-mdb \ --disable-hdb \ --disable-cleartext \ --disable-overlays \ --enable-proctitle \ --enable-debug \ --disable-shared

make make install

Next:

$ cd ~/rtems-addon-packages $ git clone git://git.openldap.org/openldap.git openldap $ cd openldap $ make -f RTEMS_Makefiles/Makefile.openldap

Note: Very insecure! But builds OK.

examples/openldap/BuildTests.sh

To perform a very basic "smoke" test on the build I modified the BuildTest?.sh and Makefile to build the programs needed to run the tests, not the tests themselves. I learned I how to link convenience libraries, and how to use BuildTests?.sh, Makefile.leaf and change leaf.cfg.

Interestingly, I found it necessary to symbolically link the slapd-common header and source to each test, as well as the libutil library.

### examples/openldap/BuildTests.sh ### #!/bin/sh

set -x rm -f rtems-grub.cfg

SRCDIR=../../openldap/tests/progs

Make the common source and header files available to all the test programs

ln -s $SRCDIR/slapd-common.h . ln -s $SRCDIR/slapd-common.c .

Make the lutility convenience library available to all the test programs

ln -s $SRCDIR/../../libraries/liblutil/liblutil.a .

For every test, delete the old link, make a new link, make the test, delete the link and the object file.

for TEST in \

slapd-tester \ slapd-search \ slapd-read \ slapd-addel \ slapd-modrdn \ slapd-modify \ slapd-bind \ slapd-mtread \ ldif-filter

do

rm -f $TEST.c ln -s $SRCDIR/$TEST.c . make TEST=$TEST SRCDIR=$SRCDIR rm -f $TEST.c $TEST.o

done

After making the test programs, remove the links to the common header, source, and lutility library.

rm -f slapd-common.h rm -f slapd-common.c rm -f liblutil.a

(Optional) Next, to make it easier for the end-user, automate building rtems-grub.cfg

# Generate rtems-grub.cfg

Add a comment of what grub is configured to load $(basename $PWD) prints the name of the directory.

echo \# RTEMS Grub configuration for $(basename $PWD) >> rtems-grub.cfg

This part was rather interesting... I've never used a pipe inside of a shell-script call before... list everything in o-optimize, that ends with .exe and count them.

# The number of executables

echo set default = $(ls o-optimize | \ grep '\.'exe | wc -l) >> rtems-grub.cfg

Used the & to use the name of the executable more than once. Note that sed"s/[a-zA-Z\-]/... has to be all on one line

# The menuentries ls o-optimize | \ grep '\.'exe | \ sed "s/[a-zA-Z\-]/menuentry \"RTEMS \-\" \{\n

set root=(hd1,1)\n multiboot (hd1,1)\/o-optimize\/&/" | \

sed "s/\.exe/\.exe\n\}\n/" >> rtems-grub.cfg

List everything in o-optimize... that is an executable... select text composed of letters and format it ... add a line a right brace, and another line after any .exe ...

examples/openldap/Makefile

I modified the rtems-addon-packages/examples/ncurses/Makefile to turn openldap programs used to test openldap into stand-alone executables.

I had to add slapd-common.c to the C_PIECES, and slapd-common.h to the headers.

Also, to link the liblutil.a convienience library, I had to add liblutil.a to C_O_FILES (it's an object file after-all :), I linked the ldap libraries using LD_LIBS, and increased the HeapSize? by a factor of ten (because it said networking required more -- online research is needed to get an exact size required).

Finally, it's worth noting the $(TEST) parameter is used to identify which test to build, and PGMS stands for programs.

# # $Id$ # # Templates/Makefile?.leaf # Template leaf node Makefile # SRCDIR=../../openldap/tests/progs

# C source names, if any, go here -- minus the .c C_PIECES=slapd-common $(TEST)

C_FILES=$(C_PIECES:%=%.c) C_O_FILES=$(C_PIECES:%=${ARCH}/%.o) liblutil.a

# C++ source names, if any, go here -- minus the .cc CC_PIECES=

CC_FILES=$(CC_PIECES:%=%.cc) CC_O_FILES=$(CC_PIECES:%=${ARCH}/%.o)

H_FILES= slapd-common.h

# Assembly source names, if any, go here -- minus the .s S_PIECES=

S_FILES=$(S_PIECES:%=%.s) S_O_FILES=$(S_FILES:%.s=${ARCH}/%.o)

SRCS=$(C_FILES) $(CC_FILES) $(H_FILES) $(S_FILES) OBJS=$(C_O_FILES) $(CC_O_FILES) $(S_O_FILES)

PGMS=${ARCH}/$(TEST)

# # RTEMS managers go here # MANAGERS=io event message semaphore

include $(RTEMS_MAKEFILE_PATH)/Makefile.inc include $(RTEMS_CUSTOM) include $(PROJECT_ROOT)/make/leaf.cfg

# # (OPTIONAL) Add local stuff here using +=

#

DEFINES +=

CPPFLAGS += -I$(SRCDIR)/../../include CFLAGS +=

LD_PATHS +=

LD_LIBS += -lldap -llber -lldap_r CFLAGS_LD += -Wl,--defsym -Wl,HeapSize?=0x200000 # network needs more space CFLAGS_DEBUG_V +=

# # Add your list of files to delete here. The config files # already know how to delete some stuff, so you may want # to just run 'make clean' first to see what gets missed. # 'make clobber' already includes 'make clean' #

CLEAN_ADDITIONS += CLOBBER_ADDITIONS +=

all: ${ARCH} $(SRCS) $(PGMS)

${ARCH}/$(TEST): ${OBJS} ${LINK_FILES}

$(make-exe)

# Install the program(s), appending _g or _p as appropriate. # for include files, just use $(INSTALL) install: all

$(INSTALL_VARIANT) -m 555 ${PGMS} /usr/local/tftpboot/bootfiles/m68360/

leaf.cfg

To build the executables without errors, I had to change some lines in /opt/rtems-4.11/make/leaf.cfg. nm and size work on object files, with the below changes the build process not only gives fewer errors, but generates .bin and .ralf files in examples/openldap/o-optimize!

define default-bsp-post-link

  • $(NM) -g -n $@ > $(basename $@).num
  • $(SIZE) $@ endef

nm and size work on executables, the RTEMS 4.11 development tree was updated in June 2012 to correctly configure the RTEMS Addon Packages.

define default-bsp-post-link + $(NM) -g -n $@.exe > $(basename $@).num + $(SIZE) $@.exe endef

Then, I ran BuildTests?.sh

~/rtems-addon-packages/examples/openldap$ ./BuildTests?.sh

Again this only built the programs used to run the tests as stand-alone executables... I'm currently trying to find an existing RTEMS application + tutorial that uses the RTEMS shell.

For a short-term goal of getting a shell up-and-running, the File IO example looks the most promising http://www.rtems.org/wiki/index.php/File_Systems. In the medium-term, networking will need to be tested, the Milky Mist site has a promising example for opening a shell over TFTP.

The next steps I will be exploring are: # how to use the File IO sample application # if using putting a copy of network-demos inside of the RTEMS Addon Packages might make more sense as example tests for software like OpenLDAP, and # how to use pattern recognition to automatically generate openLDAP specific RTEMS shell commands.

Still looking at how to build the tests -- they're in shell script :)... Hope this helps!

References