App-CamelPKI

 view release on metacpan or  search on metacpan

inc/My/Module/Build.pm  view on Meta::CPAN

   make your time

=for My::Tests::Below "great justice" end

produces a helpful message in packages that have a Makefile.PL (see
L<Module::Build/create_makefile_pl> for how to do that). You won't get
signal if you use a "traditional" style Makefile.PL (but on the other
hand the rest of I<My::Module::Build> will not work either, so don't
do that).

This easter egg was a feature of an old GNU-make based build framework
that I created in a former life.  So there.

=cut

sub do_create_makefile_pl {
  my ($self, %args) = @_;
  warn("Cannot take off any Zig, sorry"),
      return $self->SUPER::do_create_makefile_pl(%args) if ($args{fh});
  $args{file} ||= 'Makefile.PL';
  my $retval = $self->SUPER::do_create_makefile_pl(%args);

inc/My/Tests/Below.pm  view on Meta::CPAN

=head2 How it works

The test code is written in L<perlmodlib> style, that is, at the
bottom of the Perl module to test, after an __END__ marker. This way
of organizing test code is not unlike L<Test::Inline>, by Adam Kennedy
et al, in that it keeps code, documentation and tests in the same
place, encouraging developers to modify all three at once.

I like to use L<Test::Group> for the unit perlmodlib-style unit tests,
because counting and recounting my tests drives me camel :-). However
C<My::Tests::Below> itself is testing-framework agnostic (its own
self-test suite, for instance, uses only plain old L<Test::More>).

Invoking C<require My::Tests::Below> from anywhere (the idiomatic form
is shown in L</SYNOPSIS>) results in the block of code after the
__END__ marker being run at once. Due to the way this construct abuses
the Perl module mechanism, My::Tests::Below cannot be require()d or
use()d for any other purpose, hence the funny name.

=head3 Why not use Test::Inline then?

lib/App/CamelPKI/SysV/Apache.pm  view on Meta::CPAN

    my $keyfile   = $self->_key_filename;
    my $ca_bundle = $self->_ca_bundle_filename;
    my $error_log = $self->_error_log_filename;

    # Propagate -Iblib/lib to the Apache server, so that it can load
    # Camel-PKI from the build directory if needed.
    my $perlswitches;
    if (my @blibs = grep { m/\bblib\W+lib\b/ } @INC) {
        my $perlincs = join(" ", map { "-I$_" } @blibs);
        $perlswitches = <<"PERLSWITCHES";
# As seen on http://www.catalystframework.org/calendar/2005/7:
PerlSwitches $perlincs
PERLSWITCHES
    }

    # FIXME: this is Gentoo- and  Edgy-specific.
    #TODO : refactor for using the App::Info::HTTP :)
    my %module_paths =
        (alias => "/usr/lib/apache2/modules/mod_alias.so",
         perl => "/usr/lib/apache2/modules/mod_perl.so",
         php5 => "/usr/lib/apache2/modules/libphp5.so",

root/src/welcome.tt2  view on Meta::CPAN

[% META title = 'CamelPKI' %]
<h3>A Perl PKI</h3>
<p>CamelPKI is a Public Key Infrastructure (PKI) developed with the Catalyst Web framework, and so written in Perl.
You'll find more info on the code documentation: <a href="http://search.cpan.org/~grm/" title="CPAN">CPAN</a></p>

<h3>Features</h3>
<p> Regarding some of its capabilities, you can :</p>
<ul>
<li>Issue Certificates</li>
<li>Revoke Certificates<li>
<li>Manage Certificates Revocation Lists (CRL)<li>
</ul>
<p>You are not forced to use the present CA webserver with forms. You can use