AFS-Command

 view release on metacpan or  search on metacpan

CONFIG  view on Meta::CPAN

#
AFS_COMMAND_VOLNAME_PREFIX	= afscmd.

#
# Two fileserver:/partition names in which to create volumes.  These
# must be in the same AFS cell as specified at the top of this file.
#
AFS_COMMAND_PARTITION_LIST	= server1:/vicepa server2:/vicepb

#
# The bos tests need the name of a database server to work with.
#
AFS_COMMAND_DBSERVER		= dbserver1

#
# We need a valid pathname (directory) in AFS that we can abuse (that
# is, we will be hacking the ACL on this directory, and a few other
# intrusive things, to test the FS API).  This directory must be in a
# RW volume, and system:administratoirs must have write access to it.
#
AFS_COMMAND_PATHNAME_AFS	= /afs/your.cell.name/home/you/hackmebaby

Changes  view on Meta::CPAN

=head1 Bugs

=head1 Changes in 1.5

=head1 Enhancements

=head2 Principal names, as user supplied arguments, are lowercased

As a convenience, when PTS names are passed to methods like
getUserByName(), they will be lower-cased before looking up the user,
or group.  Since PTS is a case-insensitive database, this will avoid
the need for applications to lc() some strings, although not in all
cases.

For example, you can pass a mixed case string to pts->creategroup(),
and then use the same string to query the resulting AFS::Object::Group
object using getGroupByName().

The object's "group" attribute, however, will be in lower case, since
that will be the value returned by the pts command itself.

README  view on Meta::CPAN

This module builds like almost everything else on CPAN:

  perl Makefile.PL
  make
  make test
  make install

Before running 'make test', edit the CONFIG file and follow the
instructions in the comments.  Minimally, you have to specify a couple
of AFS file servers and one AFS database server against which to run
the tests, as well as a pathname in AFS where we can create mount
points.

The test suite will require AFS super-user privileges, so you must
either be a member of the system:administrators protection group, or a
member of the super users list on the servers.  If you don't know what
that means, you shouldn't be testing this module, so consult your AFS
administrators.

See the CONFIG file for more details.  Its pretty verbosely

README.html  view on Meta::CPAN

<PRE>  perl Makefile.PL
  make
  make test
  make install
</PRE>

<P>

Before running 'make test', edit the CONFIG file and follow the
instructions in the comments. Minimally, you have to specify a couple of
AFS file servers and one AFS database server against which to run the
tests, as well as a pathname in AFS where we can create mount points.


<P>

The test suite will require AFS super-user privileges, so you must either
be a member of the system:administrators protection group, or a member of
the super users list on the servers. If you don't know what that means, you
shouldn't be testing this module, so consult your AFS administrators.

ToDo  view on Meta::CPAN

The problem is that each API method calls _save_stderr(), and then
later calls _restore_stderr(), and we leave stderr redirected for
longer than necessary.  The contents of the redirected output should
be *only* the output from the commands we run, and right now, some of
our own carping can creep in there.

Worse, its possible that a failure in the API can leave stderr
redirected, resulting in a lot of confusion.

Its possible we should just suck in *ALL* of the output, both
stdout/stderr, and drop that data into a couple of arrays.  Then,
method calls on the command object get gets individual rows of
stdout/stderr output.

  return unless $self->_exec_cmds();

  #
  # Process stdout
  #
  while ( defined($_ = $self->_stdout() ) ) {

  }

  #
  # Process stderr (in some cases, there's interesting data in here.
  # see the fs examine/diskfree and similar api calls)
  #
  while ( defined($_ = $self->_stderr() ) ) {

  }

Maybe something like that.  By the time _exec_cmds returns, we have
reaped the commands, and collected *ALL* of the output into arrays in
the object.

ToDo.html  view on Meta::CPAN

<P>

Worse, its possible that a failure in the API can leave stderr redirected,
resulting in a lot of confusion.


<P>

Its possible we should just suck in *ALL* of the output, both
stdout/stderr, and drop that data into a couple of arrays. Then, method
calls on the command object get gets individual rows of stdout/stderr
output.


<P>

<PRE>  return unless $self-&gt;_exec_cmds();
</PRE>

<P>

t/00vos_basic.t  view on Meta::CPAN

END {print "not ok 1\n" unless $Loaded;}
use AFS::Command::VOS 1.99;
$Loaded = 1;
$TestCounter = 1;
print "ok $TestCounter\n";
$TestCounter++;

exit 0 unless $TestTotal;

#
# First, let's get all the config data we need.
#
my $volname_prefix = $AFS::Command::Tests::Config{AFS_COMMAND_VOLNAME_PREFIX} || do {
    print "not ok $TestCounter..$TestTotal\n";
    die "Missing configuration variable AFS_COMMAND_VOLNAME_PREFIX\n";
};

my $cell = $AFS::Command::Tests::Config{AFS_COMMAND_CELLNAME} || do {
    print "not ok $TestCounter..$TestTotal\n";
    die "Missing configuration variable AFS_COMMAND_CELLNAME\n";
};

t/02vos_volserver.t  view on Meta::CPAN

END {print "not ok 1\n" unless $Loaded;}
use AFS::Command::VOS 1.99;
$Loaded = 1;
$TestCounter = 1;
print "ok $TestCounter\n";
$TestCounter++;

exit 0 unless $TestTotal;

#
# First, let's get all the config data we need.
#
my $volname_prefix = $AFS::Command::Tests::Config{AFS_COMMAND_VOLNAME_PREFIX} || do {
    print "not ok $TestCounter..$TestTotal\n";
    die "Missing configuration variable AFS_COMMAND_VOLNAME_PREFIX\n";
};

my $cell = $AFS::Command::Tests::Config{AFS_COMMAND_CELLNAME} || do {
    print "not ok $TestCounter..$TestTotal\n";
    die "Missing configuration variable AFS_COMMAND_CELLNAME\n";
};

 view all matches for this distribution
 view release on metacpan -  search on metacpan