Re: Proposal: testing

[Rory Toma]

The reason I say non-default ports is that one could conceivably run the
test on a production system.

On Thu, 2003-08-14 at 19:12, Jan-Henrik Haukeland wrote:
> Rory Toma <address@hidden> writes:
> 
> > That's what I'm thinking.
> 
> Good thinking!
> 
> > I'd like a three process monitrc file (so we can have dependancy).
> >
> > I propose:
> >
> > apache (on non default port)
> > sshd (on non default port)
> 
> Agree, but why on non default port?
> 
> > some other process that is easy to set up.
> 
> How about this one? It's a dummy which pops up an xterm.
> 
> check xterm with pidfile /tmp/tst.pid
>  start program = "/home/hauk/bin/tst start -bg blue -fn 7x13eurobold"
>  # Testing arguments, above
>  stop program  = "/home/hauk/bin/tst stop"
>  # These two cheats and test an external server
>  if failed host nettvenn.sol.no port 80 proto http 
>     request "/index.jhtml?action=user_create" then alert
>  if failed host shop.sol.no port 443 type TCPSSL proto http then alert
>  alert address@hidden 
>  if 3 restarts within 3 cycles then timeout
> 
> It's visual and it is easy to add several if-tests to this one and
> it's also easy to kill the xterm so you can test various error
> conditions.
> 
> The tst script looks like this:
> ----------------------------------------------------------------8<-------
> #!/bin/bash
> exec 2>&1
> exec 1>/tmp/out
> /usr/bin/env > /tmp/myenv
> echo "Got $# argument(s): $*" > /tmp/myargs
> 
> /usr/X11R6/bin/xhost +localhost
> export DISPLAY=localhost:0.
> 
> case $1 in
>  start) shift;
>       echo $$ > /tmp/tst.pid
>       exec /usr/X11R6/bin/xterm $*;;
>  stop)        shift;
>       kill `cat /tmp/tst.pid`;;
>  *)     echo "usage: tst {start|stop}";;
> esac
> ----------------------------------------------------------------8<-------
> 
> > Once we nail down the processes, I'll take a stab at the monitrc file,
> > and try to add all the features.
> 
> Great!!
> 
> > On another note, I think for 4.x we can consolidate the
> > process/sysdep_*.c files into a single file. In the process of fixing
> > the FreeBSD/OpenBSD files, I've run into a lot of stuff that I think can
> > be commonized, if the right interfaces are used. (as a matter of fact,
> > OpenBSD, FreeBSD 5 and RH 9 kind of force you to use these interfaces
> > anyway...)
> 
> Everything that can make stuff easier always gets my +1 vote.
-- 
Rory Toma               address@hidden
VP of Run Level 9       http://www.trs80.net
Digeo Digital           http://www.digeo.com

signature.asc
Description: This is a digitally signed message part