view release on metacpan or  search on metacpan

lib/Arc/Command.pod  view on Meta::CPAN

    logfileprefix => "command",
  );
  $object->Execute(@a);
  $cmderr = $object->IsError();

  return -1;
 };
 
When everything went alright, the command will be executed. The command runs
in a separate process. Therefore STDIN, STDOUT and STDERR are duped to two
pipes, one for the in, one for the out direction. In the parent process data
from the encrypted network command connection is read from and written to these pipes.
Same situation on the client side, STDIN and STDOUT are used to put and get the 
data through the network.
 
                   encrypted
          /--->>---| net- |--->>-----\   
        / /---<<---| work |---<<-----\ \
      / /                              \ \
     | |     in                         | |    p2
  |--------|->>--\                  |--------|->>--\ 
  | Client | out   \                | Server | p1    \
  |--------|-<<-\    \              |--------|-<<-\    \ 
                /|\  \|/                          /|\  \|/
               |--------|                       |-----------|
               |  User  |                       |  Command  |
               |--------|                       |-----------|
 
This design makes it easy for ARCv2 Commands to get input and produce output.

B<Example>:
 sub Execute 
 {
  while ($_ = <STDIN>) { # ends on EOF
     s/a/b/g; print;
  }
 }
 
If you want to implement a new Command for ARCv2 you have to derive from 
Arc::Command and override the sub C<Execute>. See existing Arc::Command::* 
classes for examples. To get your Command recognised you have to assign a 
B<Command Name> to your command class. ARCv2 ignores the return code of
B<Execute>. If your command runs into an error use the _SetError function 
and return immediately. This is what ARCv2 will evaluate and send to the
client.

B<Example>:
 sub Execute
 {
  my $this = shift;
  my $pw = <>;
  if ($pw ne "klaus") {
	  return $this->_SetError("Wrong password.");
  }
 }
 
In ARCv2 some standard commands are already implemented: C<Arc::Command::Get>,
C<Arc::Command::Put>, C<Arc::Command::Uptime>, C<Arc::Command::Whoami>,
C<Arc::Command::Test>.

By default, these classes are mapped to B<Command Names> as follows (in the 
default arcxd.conf for arcxd):
  uptime => Arc::Command::Uptime,
  whoami => Arc::Command::Whoami,
  copy   => Arc::Command::Get,
  cp     => Arc::Command::Get,
  get    => Arc::Command::Get,
  put    => Arc::Command::Put,
  test   => Arc::Command::Test,
  help   => Arc::Command::Help,
 
B<Caution>: Especially take care of the C<Arc::Command::Get> and 
C<Arc::Command::Put> in production environment. As ARCv2 will probably
run as root and by default the Get and Put command do NOT have an access
control, everyone can get or put any files from/to your ARCv2 server.

There are some member variables, which contain information about the 
client. See 'Class VARIABLES' for a complete list of them. These values 
are filled by Arc::Connection::Server, when the client wants to run a command.


=head1 Class VARIABLES

=head3 PUBLIC MEMBERS

=over 2

=item logfileprefix I<reimplemented from Arc>

B<Default value>: "command"

=back 

=over 2

=item logdestination I<inherited from Arc>

B<Description>: Where should all the log output go to ('stderr','syslog')

B<Default value>: 'syslog'

=item loglevel I<inherited from Arc>

B<Description>: loglevel is combination of bits (1=AUTH,2=USER,4=ERR,8=CMDDEBUG,16=VERBSIDE,32=DEBUG) see _Log method

B<Default value>: 7

=back 

=over 2

=back 

=head3 PROTECTED MEMBERS

=over 2

=item _cmd 

B<Description>: user runs this command

B<Default value>: undef

=item _commands 

B<Description>: the "available commands"-hash from the server, 

B<Default value>: {}

=item _mech 

B<Description>: user uses this authentication mechanism (e.g. GSSAPI)

B<Default value>: undef