App-DocKnot

 view release on metacpan or  search on metacpan

lib/App/DocKnot/Command.pm  view on Meta::CPAN

#     (which must be named new) will be passed as its sole argument a
#     reference to the hash containing the results of parsing any options.
#
# options
#     A reference to an array of Getopt::Long option specifications defining
#     the arguments that can be passed to this subcommand.
#
# required
#     A reference to an array of required option names (the part before any |
#     in the option specification for that option).  If any of these options
#     are not set, an error will be thrown.
our %COMMANDS = (
    dist => {
        method  => 'make_distribution',
        module  => 'App::DocKnot::Dist',
        options => ['distdir|d=s', 'metadata|m=s', 'pgp-key|p=s'],
        maximum => 0,
    },
    generate => {
        method  => 'generate_output',
        module  => 'App::DocKnot::Generate',

lib/App/DocKnot/Dist.pm  view on Meta::CPAN

to remove an existing directory.  For security reasons, the C<distdir>
parameter of this module should therefore only be pointed to a trusted
directory, not one where an attacker could have written files.

If the native distribution tarball generation commands for the package
generate a gzip-compressed tarball but not an xz-compressed tarball, an
xz-compressed tarball will be created.

After the distribution is created, check_dist() will be run on it.  If any
files are missing from the distribution, they will be reported to standard
output and then an exception will be thrown.

If the C<pgp_key> constructor parameter or global configuration option is set,
the generated tarballs will then be signed with that key, using B<gpg>.  The
generated signature will be armored and stored in a file named by appending
C<.asc> to the name of the tarball.

=back

=head1 AUTHOR

lib/App/DocKnot/Util.pm  view on Meta::CPAN

The list of files found for that version.

=item version

The version number extracted from this set of files.

=back

=item print_checked(ARG[, ARG ...])

The same as print (without a file handle argument), except that it throws a
text exception on failure as if autodie affected print (which it unfortunately
doesn't because print cannot be prototyped).

=item print_fh(FH, NAME, DATA[, DATA ...])

Writes the concatenation of the DATA elements (interpreted as scalar strings)
to the file handle FH.  NAME should be the name of (or Path::Tiny object for)
the file open as FH, and is used for error reporting.

This is mostly equivalent to C<print {fh}> but throws a text exception in the
event of a failure.

=back

=head1 AUTHOR

Russ Allbery <rra@cpan.org>

=head1 COPYRIGHT AND LICENSE

t/data/generate/pam-krb5/docknot.yaml  view on Meta::CPAN

      the account name).  This can be customized with several options
      documented in the pam_krb5(5) man page.

      pam-krb5 treats `pam_open_session` and `pam_setcred(PAM_ESTABLISH_CRED)`
      as synonymous, as some applications call one and some call the other.
      Both copy the initial credentials from the temporary cache into a
      permanent cache for this session and set `KRB5CCNAME` in the
      environment.  It will remember when the credential cache has been
      established and then avoid doing any duplicate work afterwards, since
      some applications call `pam_setcred` or `pam_open_session` multiple
      times (most notably X.Org 7 and earlier xdm, which also throws away the
      module settings the last time it calls them).

      `pam_acct_mgmt` finds the ticket cache, reads it in to obtain the
      authenticated principal, and then does is another authorization check
      against `.k5login` or the local account name as described above.

      After the call to `pam_setcred` or `pam_open_session`, the ticket cache
      will be destroyed whenever the calling application either destroys the
      PAM environment or calls `pam_close_session`, which it should do on user
      logout.

t/data/generate/pam-krb5/output/readme  view on Meta::CPAN

  name).  This can be customized with several options documented in the
  pam_krb5(5) man page.

  pam-krb5 treats pam_open_session and pam_setcred(PAM_ESTABLISH_CRED) as
  synonymous, as some applications call one and some call the other.  Both
  copy the initial credentials from the temporary cache into a permanent
  cache for this session and set KRB5CCNAME in the environment.  It will
  remember when the credential cache has been established and then avoid
  doing any duplicate work afterwards, since some applications call
  pam_setcred or pam_open_session multiple times (most notably X.Org 7 and
  earlier xdm, which also throws away the module settings the last time it
  calls them).

  pam_acct_mgmt finds the ticket cache, reads it in to obtain the
  authenticated principal, and then does is another authorization check
  against .k5login or the local account name as described above.

  After the call to pam_setcred or pam_open_session, the ticket cache will
  be destroyed whenever the calling application either destroys the PAM
  environment or calls pam_close_session, which it should do on user
  logout.

t/data/generate/pam-krb5/output/readme-md  view on Meta::CPAN

account name).  This can be customized with several options documented in
the pam_krb5(5) man page.

pam-krb5 treats `pam_open_session` and `pam_setcred(PAM_ESTABLISH_CRED)`
as synonymous, as some applications call one and some call the other.
Both copy the initial credentials from the temporary cache into a
permanent cache for this session and set `KRB5CCNAME` in the environment.
It will remember when the credential cache has been established and then
avoid doing any duplicate work afterwards, since some applications call
`pam_setcred` or `pam_open_session` multiple times (most notably X.Org 7
and earlier xdm, which also throws away the module settings the last time
it calls them).

`pam_acct_mgmt` finds the ticket cache, reads it in to obtain the
authenticated principal, and then does is another authorization check
against `.k5login` or the local account name as described above.

After the call to `pam_setcred` or `pam_open_session`, the ticket cache
will be destroyed whenever the calling application either destroys the PAM
environment or calls `pam_close_session`, which it should do on user
logout.

t/data/update/pam-krb5/docknot.yaml  view on Meta::CPAN

    account name).  This can be customized with several options documented in
    the pam_krb5(5) man page.

    pam-krb5 treats `pam_open_session` and `pam_setcred(PAM_ESTABLISH_CRED)`
    as synonymous, as some applications call one and some call the other.
    Both copy the initial credentials from the temporary cache into a
    permanent cache for this session and set `KRB5CCNAME` in the environment.
    It will remember when the credential cache has been established and then
    avoid doing any duplicate work afterwards, since some applications call
    `pam_setcred` or `pam_open_session` multiple times (most notably X.Org 7
    and earlier xdm, which also throws away the module settings the last time
    it calls them).

    `pam_acct_mgmt` finds the ticket cache, reads it in to obtain the
    authenticated principal, and then does is another authorization check
    against `.k5login` or the local account name as described above.

    After the call to `pam_setcred` or `pam_open_session`, the ticket cache
    will be destroyed whenever the calling application either destroys the PAM
    environment or calls `pam_close_session`, which it should do on user
    logout.

t/data/update/pam-krb5/old/sections/implementation-notes  view on Meta::CPAN

account name).  This can be customized with several options documented in
the pam_krb5(5) man page.

pam-krb5 treats `pam_open_session` and `pam_setcred(PAM_ESTABLISH_CRED)`
as synonymous, as some applications call one and some call the other.
Both copy the initial credentials from the temporary cache into a
permanent cache for this session and set `KRB5CCNAME` in the environment.
It will remember when the credential cache has been established and then
avoid doing any duplicate work afterwards, since some applications call
`pam_setcred` or `pam_open_session` multiple times (most notably X.Org 7
and earlier xdm, which also throws away the module settings the last time
it calls them).

`pam_acct_mgmt` finds the ticket cache, reads it in to obtain the
authenticated principal, and then does is another authorization check
against `.k5login` or the local account name as described above.

After the call to `pam_setcred` or `pam_open_session`, the ticket cache
will be destroyed whenever the calling application either destroys the PAM
environment or calls `pam_close_session`, which it should do on user
logout.