[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Plans for the next release

From: Rory Toma
Subject: Re: Plans for the next release
Date: 01 Jul 2002 16:06:45 -0700

I'm just thinking out loud.

I'm trying to think of a good way to do remote commands and not give out
browser access. I'd think this would involve some kind of key exchange.

Ideally, I have machine A and B, and machine B is dependant on machine
A. Machine A gives users generic browser access, but I don't want
somebody to be able to use the browser on machine A to see/set stuff on
machine A or B. However, other programs on machine A must be able to
start/stop stuff on machine B.

On Mon, 2002-07-01 at 15:47, Jan-Henrik Haukeland wrote:
> Rory Toma <address@hidden> writes:
> > I use the http interface as a command channel, and will have apps
> > write w/o a browser directly (over the VPN) to start/stop stuff. I
> > do not want stuff visible from a browser.
> > 
> > Perhaps the answer to this question (and the multiple interface ?)
> > is to add a non-webserver interface that just implements remote
> > commands?
> And there I thought I was pretty clever to use HTTP for this :) That
> way you can have apps talking directly to the monit server and even
> use a browser.
> For example here is an app for starting apache:
>   perl -MIO::Socket -e '
>    $s= IO::Socket::INET->new(PeerAddr => localhost, PeerPort => 2812) 
>    or die "monit http is down\n";
>    print($s "GET /apache?action=start HTTP/1.0\r\n\r\n"); 
>    printf("%s\n", <$s>=~/200/?"Apache started":"Error staring apache");'
> Actually using HTTP for remote control _is_ clever if I have to say it
> myself :)
> --
> Jan-Henrik Haukeland
> --
> To unsubscribe:
Rory Toma               address@hidden
VP of Run Level 5
Digeo Digital 

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]