view release on metacpan or  search on metacpan

extra/Configuration.pod  view on Meta::CPAN

  FORCELOCK=ClearCase::ForceLockSudo

This is so its use would not penalize functions which do not require
locking.  Two other versions are provided for now, one for unix, and
one for Windows (and cygwin):

  FORCELOCK=ClearCase::ForceLockUnix #Unix
  FORCELOCK=ClearCase::ForceLock     #Windows

These can be used as examples or a templates. They require some
customization.  The two latter build upon I<locklbtype>, a standalone
script, to be installed suid enabled, owned by an account, which is
itself authorized in the configurations of the respective vob owners
of all vobs in the local region, to run locking commands. It acts as a
switch, allowing to simplify the maintainance of the authorization
setup.

Two variants are proposed: one using ssh, the other using sudo. Only
the most suitable one needs to be installed, as I<locklbtype>.  The
appropriate setup will have to be performed respectively in the vob
owner accounts' I<~/.ssh/authorized_keys> files, or in the host based
or system-wide I</etc/sudoers> file.

Both variants require a minimal customization.

For ssh, one needs to set the name of the host running an sshd daemon
Note that one needs to avoid using I<localhost> here, so that
different host keys do not overwrite each other in the
I<~/.ssh/known_hosts> files.

For both, one may also set the name of the log used to save the
identity of the unlocking users (for lock events, this is saved in a
comment of the locks).  The paths to ssh or sudo, cleartool and perl
are likely to be satisfying.

In order to use this script, we needed to define a pair of functions,
for locking and unlocking.

The unix version of the I<ClearCase::ForceLock> module, is meant to
invoke locklbtype via a system call, therefore using the suid bit
mechanism offered by unix shells.  The only customization is the path
to the locklbtype utility.

In a Windows environment, the related module fills the same role, but
invokes the suid script on a unix host, via ssh.
As perl is found in a vob on my unix environment, I need to customize
a view tag in addition to the host name and the path to the script.

Ssh is accessed with the Net::SSH::Perl module.

It depends on a long list of modules, which I could successfully
install on:
I<cygwin 1.7 / perl 5.10 / libgmp-devel 4.3.1-1, libssh2, pari-gp 2.3.5>
and on I<Windows Vista / Strawberry perl 5.12 / GMP-4.1.2>:

  Digest-SHA1-2.1
  Digest-HMAC-1.01
  Class-ErrorHandler-0.01
  Convert-ASN1-0.22
  Crypt-CBC-2.30
  Crypt-DES-2.05
  Crypt-Blowfish-2.10
  Crypt-DES_EDE3-0.01
  Convert-PEM-0.07
  Data-Buffer-0.04
  Class-Loader-2.03
  Convert-ASCII-Armour-1.4
  Digest-MD2-2.03
  Sort-Versions-1.5
  Tie-EncryptedHash-1.24
  Digest-BubbleBabble-0.01
  String-CRC32-1.4
  Math::GMP-2.05
  Math::BigInt::GMP-1.24
  Math::BigInt-1.89
  Net::SSH::Perl-1.34

On cygwin, I had in addition to install:

  Crypt-DH-0.06
  Crypt-DSA-0.14
  Crypt-IDEA-1.08
  Math-Pari-2.01080604
  Crypt-Random-1.25
  Crypt-Primes-0.50
  Crypt-RSA-1.98

Note that these are just the versions I use, and which work for me.
I cannot claim that this list is a minimal requirement.

=head2 .clearcase_profile.pl

This file is meant to be found in the user home directory.
It is common to all possible wrappers derived from ClearCase::Wrapper.
It may be symlinked from a shared version, for sitewise configuration.

An example of I<.clearcase_profile.pl> sets the ipc mode for all
commands apart for setview (unavailable then, assuming the wrapper
itself is used from a vob).

An other setting for this file is:

  $ClearCase::Wrapper::MGi::global = 1;

This setting drives I<mklbtype> and I<mkbrtype> to create I<global>
types (including the metadata types) in vobs having an admin vob.

This used to be the default with I<ClearCase::Wrapper::DSB>.

Next possible setting:

  $ClearCase::Wrapper::MGi::lockbl = 1;

If this is set, the baseline type is locked in the end of a rollout.
Conversely, a next rollout is aborted if the baselin is found unlocked on
entry, in order to prevent possible collisions of independent rollouts.
This would be the default if locking/unlocking by group members was
supported natively by ClearCase, instead of depending on user configuration.

Note that one might e.g. add there code such as: