Re: On Demand Nmap Build Testing

[jrf <jay.fink () gmail com>]

On Wed, Jun 02, 2010 at 06:37:16PM -0700, Fyodor wrote:
> On Tue, Jun 01, 2010 at 09:50:52AM -0400, jrf wrote:

I agree with this but for my part, I am limited. My mac is a pro and
it is for work so there is not a simple way to integrate it into a
farm. Otherwise, I replied in kind...


> o Include numerous different systems, including Linux, Mac, and Windows

At this point in time I can reasonably do Linux, FreeBSD and NetBSD
which are my focus. At some later point I might be able to free(time)
to slap OpenSolaris in there.

> o Do an Nmap checkout every X hours (like once per day or more), and if
>   anything has changed, do the builds, and email nmap-dev an alert if
>   they fail.

I cannot do this myself (out of my house) but I can write in the
functionality so it can be used elsewhere (just do local deliveries to
myself).

> o Provide daily build snapshots for the various platforms that users
>   can download.

I think I could at least proof this via a vm webserver out of my flat.
But eventually it would have to be lifted to a permanent hosted
system somewhere.

> o It could do tests, as has been discussed on this thread, rather than
>   just building.  For example, Ncat already has a great test harness
>   system.

Excellent, I will check that out. So far I had only looked at npings.

> o Allow users to "push" a test through, like if they have just checked
>   some code in and want to make sure Windows compilation isn't broken.
>   Maybe for self-requested scans like that you could just give results
>   in their browser or to an email address specified when you request
>   the build rather than sending results to all nmap-dev.  Ideally
>   someone could get at the build snapshots after doing this, so they
>   could (for example) test the new Windows binaries.
>
> o Ideally it could all be run in VMs on one machine (or Linode
>   VMs or whatever) with good instructions for setting it up.

Done correctly, it shouldn't matter. For instance the external wrapper
which boots the systems *only* boots them, then calls the build script
remotely. So in theory the same could be done via ipmi etc.

> Anyway, I hope my "dream list" doesn't hurt progress on a simpler
> initial system.  It sounds like you've been making solid progress!

Nope, it is call good and all of it - excepting the windows and mac
builds (which I am sure could be dovetailed later) I can do myself and
stage then release all the bits to be setup on some hosted system
somewhere.

My approach is going to be pretty straightforward, I have back peddled
a little bit but I think it makes sense to do it in this order:

- get a build/test harness working locally that is common
- add on mail notification from the local system
- binary build (DESTDIR will be a build runtime)
- build a webserver vm :)
- transport binaries (scp) to a webserver
- get the test harness to work via a remote call (ssh for me); this is
  harder than one might think (I've dealt with this on HPC) due to the
  fun of subshells.
- write a thin wrapper to do them on demand and schedule

To address pushing a test through, wherever it resides, the logic
would have to be such that tests cannot be scheduled during the build
window *or* alternative build systems could be used that otherwise are
not used for the automated build. The alternative is writing a
scheduler or using something like LSF which I don't think (I know I
don't want to) we want get into :)

So the key is the build/test script really. The rest is kind of making
plates :D

I'll keep everyone posted as to my progress and when the webserver is
up I'll send a link (it will be DYNDNS so YMMV :D

thanks!
 j
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/