Category:Making Modules

From OWASP Live CD 2008

Below is the general process for making modules for the OWASP Live CD 2008 (and SLAX for that matter). The specific steps used to create individual modules are outlined in the links below.

Contents 1 Get the program's source or package 2 Create the necessary directories in the fakeroot directory 3 Create and put the module's files into the fakeroot directory 4 Generate the .lzm module 5 Add the modules to the ISO build directory 6 Clean up and archive 7 Updating a module where the version number doesn't change 8 Final Notes

Get the program's source or package

This could be the actual source code, an existing SLAX module, or a package from a distribution (Slackware or .deb). The preferred method is to use the actual source code since updates will be easier in future and won't depend on a distribution's updating time line.

Create the necessary directories in the fakeroot directory

For the OWASP live CD, I'm placing everything in /opt/owasp of ./fakeroot. This will avoid accidentally stomping on any SLAX module and vise versa.

The exception for this is the program's menu item as well as the program's icon. Menu items are called .desktop files and are located in /usr/share/applications of ./fakeroot. Icons should be in .png format (at least that worked for me) and are located in /usr/share/pixmaps of ./fakeroot.

The commands to create these are:

 $ mkdir -p ./fakeroot/opt/owasp
 $ mkdir -p ./fakeroot/usr/share/aplications
 $ mkdir -p ./fakeroot/usr/share/pixmaps

Create and put the module's files into the fakeroot directory

This is where the great deal of variability comes in. If you're using a package, you can use the Linux Live tools to directly create the lzm module such as tgz2lzm and deb2lzm. Save the ./fakeroot for the next module you create ; ) You can also skip the next step.

At a high level, the things you'll need to gather are:

1. The binary for the program its support files/libraries
2. An icon for the program
3. A .desktop file for the program so it will show up in the desktop's menu
4. Any configuration or other files needed to run the program

If you are building from source, you'll have to do whatever is needed to create the necessary binaries. This can include making a module to satisfy a dependency. Generally, I run the OWASP Live CD in a VM and get the source onto the VM instance. Then, I try to build the software as usual (configure, make, make install). One hint, you can "watch" what gets installed by using find. That is:

1. ./configure
2. make
3. find / > /root/pre-program
4. make install
5. find / > /root/post-program
6. diff pre-program post-program > install-program
7. vi install-program and remove things like the /proc enteries

Now you have a list of everything installed during 'make install'. I'm also thinking about using checkinstall for future modules. [after a bit of experimentation]

Generate the .lzm module

Assuming you didn't go straight from a distributions package (.tgz or .deb) to a SLAX module (.lzm), its now time to run dir2lzm on the fakeroot directory. The command is:

 $ ./dir2lzm ./fakeroot module-name-here.lzm

and a SLAX module will be created in the current directory.

Add the modules to the ISO build directory

Now that you have an .lzm module, its time to move it to the directory which you'll use to build the new ISO image.

 $ cp module-name-here.lzm ../contents/slax/base/

Note: The command above assumes you're using my file system layout as described in How I created the live CD

Clean up and archive

I like to keep track of what I've done since I'll likely forget shortly after the work is complete. To that end, I also do the following when I've got the module completed:

• Create a directory in completed_modules so I can store my working files
• Move the new module into the program's completed_modules directory.
• Create a tarball of the current ./fakeroot directory and move it to the program's completed_modules directory.
• Move the source files used to create the module into the program's completed_modules directory.
• Move any sundry files used to create the module into the program's completed_modules directory.
• Update the OWASP Live CD Wiki (well, I was writing stuff as I created the module, right, so this is done already)

For our fake example above, this might look something like

 $ mkdir ./completed_modules/module-name-here
 $ mv module-name-here.lzm ./completed_modules/module-name-here/
 $ tar -cjvf ./completed_modules/module-name-here/fakeroot-modules-name-here.tar.bz fakeroot/
 $ mv temp/module-name-here_source.tar.gz ./completed_modules/module-name-here/
 $ mv temp/cleanup-module-install.sh ./completed_modules/module-name-here/

Updating a module where the version number doesn't change

This concerns the situation when releasing an module and there isn't a version change in the actual program in the module. Instead there is some change in a supporting piece of the module such as a startup script or the like. To designate an update to a module which is not a version bump of the software, append "-cdr-#" before .lzm where # is the number of the revision for the CD. So the first update to say nmap-4.60.lzm would be nmap-4.60-cdr-1.lzm representing the first CD revision of nmap version 4.60. The second would be nmap-4.60-cdr-2.lzm. This allows one to determine that a fix has been applied to a module which didn't rev the actual version of the software.

Final Notes

For the most part, I tried to follow the advice / guidance given in the documentation for creating SLAX modules, specifically How to create Slax modules the right way. General documentation for SLAX can be found here.