Good answer, but the boss man wants to use TCP/IP - SNMP is right out. Most of the time and effort I spend on this is helping me understand networking in general - so I don't mind - at least not yet! ;)

Yeah, I gotta one up this. jeffa and I chatted about this on the phone (welcome to Louisville, Jeff =) and I pointed out that he was lucky merlyn was infiltrating the Java types. Normally we leave it to him to shout HTTP eq instant_solution in these cases.

To add to what tilly is saying here when you are simply invoking a process on a remote box with real simple arguements or none at all why throw IPC and the like at the problem? And as he said, the benefit of HTTP is that you can use all kinds of handy toys with it. And most, if you want a slightly more strict data-markup, throw XML::Simple into the mix.

--
$you = new YOU;
honk() if $you->love(perl)

Thanks for the input tilly and extremely - I totally agree, and at some point I will probably drop this RPC solution and use HTTP. I think the boss-man wanted to give me a project to help me understand how networking and sockets work in general, while at the same time helping me to understand how our servers are set up (and get on the good side of the sysadmins).

my  @CMDS = ("ps", "top", "df", "vmstat", "blah");
my  @FILES = ( "/etc/running.cfg", "/home/me/lastchecked.txt", "/var/l
+og/httpd/error_log");

my ($cmd, @ARGS) = split(/\s/, $input);
my $ok;
for(@CMDS) {
    if($cmd eq $_) { $ok=1; }
}
if(!$ok) { die "tried to do something that wasn't cool: $input\n"; }
# then check for files in args
my $ok=0;
my $arg;
foreach $arg (@ARGS)
    if(-e $arg) { 
        # we have a file
        $file=true;
        for(@FILES) {
            if($arg eq $_) {
                $ok=1;
            }
        }
    }
}
if($file && !$ok) { die "tried to access a bad thing: $input\n"; }
# We're pretty much safe to continue
[download]

Done and done!

I went overboard on this issue. The server has a config file that it reads the actual *nix commands from, along with a pneumonic name (i.e. inodes='df -i') and stores the key-value pairs in a hash. When a client connects to the server, the server sends the pneumonics, so the client never sees the actual command.

# from server
sub get_commands() {
    open CONF, 'query.conf' or die "No config file found: $!\n";
    while (<CONF>) {
        next if /^#/;
        chomp;
        my ($command, $query) = split(/\t/, $_);
        $commands{$command} = $query;
    }
    close CONF;
}

sub send_commands {
    my $rhost = shift;
    my @commands = sort keys %commands;
    &log_msg("Request for command list from $rhost");
    return join(":", @commands);
}

# and from the client
sub get_commands {
    my $answer;
    my $i = 'a';
    eval { $answer = $conn->rpc('send_commands', $host) };
    die "Server $rhost not responding\n" if $@;
    map { $commands{$i++} = $_ } split(":", $answer);
}

sub print_menu {
    print '#' x 30, "\n";
    map { print "# $_) $commands{$_}\n" } sort keys %commands;
    print "# q) quit\n";
    print '#' x 30, "\n";
    print "Enter choice: ";
}

# the main processing loop for the client
$SIG{ALRM} = sub { die "TIMEOUT" };
&print_menu;
while (my $arg = <>) {
    last if $arg =~ /q/;
    chomp $arg;
    
    my $answer;
    eval {
        alarm(10);
        $answer = $conn->rpc('run', $commands{$arg}, $host) };
        alarm(0);
    };
    warn "$queries{$arg} timed out - $host could be down\n" if $@ =~ /
+TIMEOUT/;
    
    print $answer;
    &print_menu;
}
[download]

Of course the major limitation at this point is only 'a' thru 'p' commands will be available.

errors in the process running remotely are captured w/ Open3.

i'd also suggest SNMP, but if that's not an option. . .