The main difference in running this and the webserver is the unprivileged user account. Your account has other access rights, a tty and is able to authenticate interactively, the webserver does not as it's not used for that kind of thing. So as far as I can see it's not the CGI itself but the retrieval method. Ofcourse you could set up your webserver with for it and use a remote ssh account that is limited to running a script but that's not that scalable and requires more overhead than is strictly necessary (IMHO). Reinventing the wheel depends on if this is just a testbed exercise in scripting or what other details you want to get from that or other systems later on and if you got admin access to those. For instance having SNMP running would make things easier (as in efficient, scalable) or say Nagios if you're about to handle stats on more systems. If you have admin access on the remote machine and Xinetd is running and you don't want SNMP or Nagios then you could try this on the system to monitor:
Code:
# default: off
# description: /etc/xinet.d/xinetd_sysstats_df: output of 'df'.
service xinetd_sysstats_df
{
disable = no
type = UNLISTED
protocol = tcp
port = 30002
socket_type = stream
wait = no
user = root
log_on_failure += HOST
server = /bin/df
server_args = -k
# Activate ctrls wrt your used subnet:
# only_from = 127.0.0.1 10.0.0.0/24
}
Then if instead of ssh you use curl, wget, nc, telnet or even Bash on the monitoring station to fetch "http://serveraddress:30002" you avoid most complications.