GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages


Manual Reference Pages  -  OPENXPKI::SERVER::INIT (3)

.ds Aq ’

Name

OpenXPKI::Server::Init - daemon initialization

CONTENTS

Description

This class is used to initialize all the objects which are required. The code is not in the server class itself to get a clean interface for the initialization and to avoid any magic stuff. We hope that this makes the customization of the code more easier.

Functions

    Basic Initialization

init

Initialization must be done ONCE by the server process. Expects the XML configuration file via the named parameter CONFIG.

Usage:



  use OpenXPKI::Server::Init;

  OpenXPKI::Server::Init::init({
         CONFIG => t/config.xml,
     });



If called this way, the init code processes all initialization steps. You may split the initialization sequence in order to do stuff in between steps by providing an array reference TASKS as a named argument:



  OpenXPKI::Server::Init::init({
         CONFIG => t/config.xml,
         TASKS  => [ config, i18n, log ],
     });



and later simply call



  OpenXPKI::Server::Init::init({
         CONFIG => t/config.xml,
     });



to initialize the remaining tasks.

If called without the TASKS argument the function will perform all steps that were not already executed before.

If called with the named argument SILENT set to a true value the init method does not log successful initialization steps.

get_remaining_init_tasks

Returns an array of all remaining initialization task names (i. e. all tasks that have not yet been executed) in the order they would normally be processed.

get_workflow_factory

Returns a workflow factory which already has the configuration added from the configuration files and is ready for use.

get_config

expects as only parameter the option CONFIG. This must be a filename of an XML configuration file which is compliant with OpenXPKI’s schema definition in openxpki.xsd. We support local xinclude so please do not be surprised if you habe a configuration file which looks a little bit small. It returns an instance of OpenXPKI::XML::Config.

init_i18n

Initializes the code for internationalization. It requires an instance of OpenXPKI::XML::Config in the parameter CONFIG.

    Cryptographic Initialization

get_crypto_layer

Return an instance of the TokenManager class which handles all configured cryptographic tokens.

get_pki_realms

Prepares a hash which has the following structure.

$hash{PKI_REALM_NAME}->{crypto}->{default}

Requires ’config’, ’log’ and ’crypto_layer’ in the Server Context.

The hash also includes validity information as defined in the configuration in the following sample format:



  $hash{PKI_REALM_NAME} = {
      endentity => {
          id => {
              User => {
                  validity => {
                      notafter => {
                          format => relativedate,
                          validity => +0006,
                      },
                  },
              },
          },
      },
      crl => {
          id => {
              default => {
                  validity => {
                      notafter => {
                          format => relativedate,
                          validity => +000014,
                      },
                  },
              },
          },
      },
      ca => {
          id => {
              CA1 => {
                  status = 1,    # (0: unavailable, 1: available)
                  identifier => ABCDEFGHIJK,
                  crypto => OpenXPKI::Crypto::TokenManager->new(...),
                  cacert => OpenXPKI::Crypto::X509->new(...),
                  notbefore => DateTime->new(),
                  notafter => DateTime->new(),
              },
          },
      },
  };



See OpenXPKI::DateTime for more information about the various time formats used here. Undefined ’notbefore’ dates are interpreted as ’now’ during issuance. Relative notafter dates relate to the corresponding notbefore date.

Two sections are contained in the hash: ’endentity’ and ’crl’ The ID of endentity validities is the corresponding role (profile). The ID of CRL validities is the internal CA name.

    Non-Cryptographic Object Initialization

get_dbi

Initializes the database interface and returns the database object reference.

Requires ’log’ and ’config’ in the Server Context.

If database type is SQLite and the named parameter ’PURPOSE’ exists, this parameter is appended to the SQLite database name. This is necessary because of a limitation in SQLite that prevents multiple open transactions on the same database.

get_log

Returns an instance of the module OpenXPKI::Log.

Requires ’config’ in the Server Context.

get_log

requires no arguments. It returns an instance of the module OpenXPKI::Server::Authentication. The context must be already established because OpenXPKI::XML::Config is loaded from the context.

redirect_stderr

requires no arguments and is a simple function to send STDERR to configured file. This is useful to track all warnings and errors.

Search for    or go to Top of page |  Section 3 |  Main Index


perl v5.20.3 OPENXPKI::SERVER::INIT (3) 2016-04-03

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.