Packaging NMap 4.0

shilo · 02-01-2006, 11:48 AM

NMap 4.0 was recently released. Figured I'd check it out. I wanted to package it up for myself with all the "bells-and whistles." So far, I have everything figured out except two things. I'll start by posting the files I am using to package, then get to the issues to see if anyone has an idea how to resolve them. These files should be pretty straight-forward, so...

nmap.SlackBuild
This is the main script I use. Nothing amazing, but you will want to note:

1) I add my initials to the build. Feel free to change.

2) I added the configure option "--enable-ipv6". I didn't see this documented, but when compiling I noted there was a check for it. Hopefully, it does what I think it does and enables both ipv4 and ipv6.

3) I use $ARCH and $PARCH. Hopefully these make sense. I use them both because I am compiling for athlon-4 (not so good for the package name). I've left other archs in the script, so you can change $ARCH to i686 and $PARCH to $ARCH if you want/need. Ishould probably change $PARCH to be ath4 if $ARCH is athlon-4, else $PARCH=$ARCH , but this works for now.

4) I am using gcc 3.4.5, so I use -mtune instead of -mcpu

Feel free to comment on any changes you think shoukd be made.

Code:

#!/bin/sh

########################
# NOTES:
#
########################
#
#
#
#
#
#
#
########################

# Set initial variables:

NAME=nmap		# Program name
PNAME=$NAME		# Package name (Useful for changing case, removing "-"s, etc.)
VERSION=4.00		# Program version
PVERSION=$VERSION	# Package version (Useful for removing "-"s, CVS builds, etc.)
ARCH=${ARCH:-athlon-4}	# Package architecture
PARCH=ath4		# Package architecture abbreviation (Useful for removing "-"s)
BUILD=${BUILD:-1seb}	# Build number plus packager initials (use your own)

CWD=`pwd`
TMP=${TMP:-/tmp}	# Location to compile the source
PKG=$TMP/package-$NAME	# Location to build the package (use "package-$NAME" to avoid poss. conflicts)

PDOCS="CHANGELOG COPYING COPYING.OpenSSL HACKING INSTALL docs/README docs/*.txt"

# Define compiler flags based on intended architecture:
# Can easily expand this for alternate compilations

if [ "$ARCH" = "i386" ]; then
  SLKCFLAGS="-O2 -march=i386 -mtune=i686"
elif [ "$ARCH" = "i486" ]; then
  SLKCFLAGS="-O2 -march=i486 -mtune=i686"
elif [ "$ARCH" = "i686" ]; then
  SLKCFLAGS="-O2 -march=i686 -mtune=i686"
elif [ "$ARCH" = "athlon-4" ]; then
  SLKCFLAGS="-O2 -march=athlon-4 -mtune=athlon-4"
elif [ "$ARCH" = "s390" ]; then
  SLKCFLAGS="-O2"
elif [ "$ARCH" = "x86_64" ]; then
  SLKCFLAGS="-O2"
fi

rm -rf $PKG		# Get rid of any leftovers
mkdir -p $PKG		# Make sure $PKG and $TMP (-p switch) exist

cd $TMP
rm -rf $NAME-$VERSION
tar xvjf $CWD/$NAME-$VERSION.tar.bz2 # Should consider changing to check for tar.gz or tar.bz2
cd $NAME-$VERSION

# Correct general permissions/ownership:

chown -R root.root .
find . -perm 777 -exec chmod 755 {} \;
find . -perm 775 -exec chmod 755 {} \;
find . -perm 711 -exec chmod 755 {} \;
find . -perm 666 -exec chmod 644 {} \;
find . -perm 664 -exec chmod 644 {} \;
find . -perm 600 -exec chmod 644 {} \;
find . -perm 555 -exec chmod 755 {} \;
find . -perm 511 -exec chmod 755 {} \;
find . -perm 444 -exec chmod 644 {} \;
find . -perm 440 -exec chmod 644 {} \;
find . -perm 400 -exec chmod 644 {} \;

# Classic "./configure && make && make install":

CFLAGS="$SLKCFLAGS" \
./configure \
  --prefix=/usr \
  --sysconfdir=/etc \
  --localstatedir=/var/lib \
  --enable-ipv6 \
  --build=i486-slackware-linux
make -j3
make install DESTDIR=$PKG

# Correct binaries ownership:

if ls $PKG/bin &> /dev/null; then
  chown -R root.bin $PKG/bin
fi

if ls $PKG/usr/bin &> /dev/null; then
  chown -R root.bin $PKG/usr/bin
fi

if ls $PKG/sbin &> /dev/null; then
  chown -R root.bin $PKG/sbin
fi

if ls $PKG/usr/sbin &> /dev/null; then
  chown -R root.bin $PKG/usr/sbin
fi

if ls $PKG/usr/X11R6/bin &> /dev/null; then
  chown -R root.bin $PKG/usr/X11R6/bin
fi

# Strip binaries and libs:

( cd $PKG
  find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null
  find . | xargs file | grep "shared object" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null
)

# Compress man pages:

find $PKG/usr/man -type f -exec gzip -9 {} \;

# Create package docs:

mkdir -p $PKG/usr/doc/$PNAME-$PVERSION
cp -a \
  $PDOCS \
  $PKG/usr/doc/$PNAME-$PVERSION
chmod 644 $PKG/usr/doc/$PNAME-$PVERSION/*

# Add package description:

if [ -e $CWD/slack-desc ]; then
  mkdir -p $PKG/install
  cat $CWD/slack-desc > $PKG/install/slack-desc
fi

# Add install script:

if [ -e $CWD/doinst.sh ]; then
  cat $CWD/doinst.sh > $PKG/install/doinst.sh
fi

# Add desktop file:

if [ -e $CWD/$PNAME.desktop ]; then
  mkdir -p $PKG/usr/share/applications
  cat $CWD/$PNAME.desktop > $PKG/usr/share/applications/$PNAME.desktop
fi

# Build the package:

cd $PKG
makepkg -l y -c n $TMP/$PNAME-$PVERSION-$PARCH-$BUILD.tgz

# Clean up the extra stuff:

if [ "$1" = "--cleanup" ]; then
  rm -rf $PKG
fi

slack-desc
Description taken straight from the spec file in source.

Code:

# HOW TO EDIT THIS FILE:
# The "handy ruler" below makes it easier to edit a package description.  Line
# up the first '|' above the ':' following the base package name, and the '|' on
# the right side marks the last column you can put a character in.  You must make
# exactly 11 lines for the formatting to be correct.  It's also customary to
# leave one space after the ':'.

    |-----handy-ruler------------------------------------------------------|
nmap: nmap (Network exploration tool and security scanner)
nmap:
nmap: Nmap is a utility for network exploration or security auditing. It
nmap: supports ping scanning (determine which hosts are up), many port
nmap: scanning techniques, version detection (determine service protocols
nmap: and application versions listening behind ports), and TCP/IP
nmap: fingerprinting (remote host OS or device identification). Nmap also
nmap: offers flexible target and port specification, decoy/stealth scanning,
nmap: sunRPC scanning, and more. Most Unix and Windows platforms are
nmap: supported in both GUI and commandline modes. Several popular handheld
nmap: devices are also supported, including the Sharp Zaurus and the iPAQ.

doinst.sh
There is a .desktop file included for nmapfe. This updates the desktop database so the menu entry will appear correctly.

Code:

if [ -x usr/bin/update-desktop-database -a -x usr/bin/chroot ]; then
  usr/bin/chroot /$ROOT /usr/bin/update-desktop-database &> /dev/null
fi

ISSUES
1 First issue is a small one. I see in docs/README a reference to nmap-manpage.html. This file does not exist in source. I do see a file docs/nmap-man.xml, but it does not packaged when I compile per above. I'm guessing that docs/nmap-man.xml is supposed to be converted to nmap-manpage.html and installed in /usr/doc/nmap-4.00. I'd also guess that this is easy (maybe a simple make command?). Just don't know.

2 Second issue is a little bigger. When compiling, I get the message:

Code:

checking linux/netfilter_ipv4/ipchains_core.h usability... no
checking linux/netfilter_ipv4/ipchains_core.h presence... yes
configure: WARNING: linux/netfilter_ipv4/ipchains_core.h: present but cannot be compiled
configure: WARNING: linux/netfilter_ipv4/ipchains_core.h:     check for missing prerequisite headers?
configure: WARNING: linux/netfilter_ipv4/ipchains_core.h: see the Autoconf documentation
configure: WARNING: linux/netfilter_ipv4/ipchains_core.h:     section "Present But Cannot Be Compiled"
configure: WARNING: linux/netfilter_ipv4/ipchains_core.h: proceeding with the preprocessor's result
configure: WARNING: linux/netfilter_ipv4/ipchains_core.h: in the future, the compiler will take precedence
configure: WARNING:     ## ------------------------------------------ ##
configure: WARNING:     ## Report this to the AC_PACKAGE_NAME lists.  ##
configure: WARNING:     ## ------------------------------------------ ##
checking for linux/netfilter_ipv4/ipchains_core.h... yes

While I am not sure what this means, I would wager a guess that it means that nmap wants 2.6 kernel headers. Any EASY solution to this?

Possibly important, I am running kernel 2.6.15 for this. Also, in the 2.6.15 kernel source, I don't see an ipchains_core.h. Maybe this message is just saying, "Hey, ipchains_core.h isn't used with the kernel you are running"?

Note that the program still compiles without error. Haven't bothered to actually install the package, since I am more interested in getting it packaged/built correctly than I am in actually using it.

dunric · 02-01-2006, 12:48 PM

ad 2) Check if there is not left contents of 2.4.x kernel-headers package in your system by a chance. Configuration script looks for kernel headers in /usr/include/linux so it may ignore these from source tree.
If this is the reason, build and install own kernel-headers package by tweaking original SlackBuild script or if too complicated for you upgrading to the one from testing/ subdir should be enough.

shilo · 02-01-2006, 01:44 PM

I am confused as to what you are suggesting. I have the 2.4 kernel headers package installed. So is what you are sugeesting that I install 2.6 headers, install the package, and revert to the proper 2.4 headers?

I am thinking that since ipchains_core.h is a part of the 2.4 headers (/usr/include/linux/netfilter_ipv4/ipchains_core.h), but is not a part of the 2.6 headers, it is not needed. Installing 2.6 headers may remove the warning, but it would remove the warning because:

Code:

checking linux/netfilter_ipv4/ipchains_core.h usability... no
checking linux/netfilter_ipv4/ipchains_core.h presence... yes

Would become:

Code:

checking linux/netfilter_ipv4/ipchains_core.h usability... no
checking linux/netfilter_ipv4/ipchains_core.h presence... no

I guess what I am wondering is, does the error message really MEAN anything? In other words, is the package still compiling as a fully functional program?

dunric · 02-01-2006, 04:54 PM

The application (Nmap in this case) may compile and run without problems even without my suggestions. But on the other side it's not too wise to confuse some (not so smart written) configuration/compliation scipts by running different kernel version then the installed kernel headers are. F.E. I wouldn't be able to compile my wifi kernel modules with different headers version without a hack.

shilo · 02-01-2006, 07:26 PM

Quote:

Originally Posted by dunric

it's not too wise to confuse some (not so smart written) configuration/compliation scipts by running different kernel version then the installed kernel headers are.

This is a debatable point, but I am not trying to debate it. I am asking about this specific instance. There is a warning in regards to a kernel header (ipchains_core.h). That header is non-existant in 2.6 kernels. As it is, the compile says the header is un-usable. If I were to have a 2.6 kernel and install 2.6 headers, that header would not be usable, either, as it wouldn't exist.

My point here is this, changing to 2.6 headers seems to be USELESS in this case. All that it would do is supress a warning, it seems. The warning would be supressed because instead of an un-usable header, I would have a non-existant header. Either way, the header (ipchains_core.h) is not used.

Can anyone offer a clear explaination on this?

dunric · 02-02-2006, 04:00 AM

All software directly using kernel interface API may have troubles when including different headers version. The header can be in the same place, the types, macros or structures can keep the same name but in definitions they may differ. In the worst case a program may be successfuly compiled but it will run with unexpectable results. In the better and more common case it will just fail to compile - I've experienced some cases when autoconf scipt or Makefile just digs kernel version by `uname -r` and everything else in following compilation conforms to this value. You may imagine what will happen when parts of sources for one kernel version are built with headers included from incompatible version. More smart builds just look for headers in /lib/modules/`uname -r`/source.