Menu V2 : V2: general - l'API Web-AlternD - Les specs logicielles - Template et Bureau - Les specs, v2

AlternC software infrastructure

Architecture big picture here : /alternd/trunk/doc/dev/alternc_v2_spec_v0.1.png (dia version here : alternc_v2_spec_v0.1.dia)

AlternC aim is to become a modular hosting software infrastructure.

It contains :

  • A core of code
    • it knows how to handle basic software configuration and user rights management (unix accounts stored in a local or remote database).
    • it knows how to access a MySQL services database
    • it knows where to put puppetmaster manifests, templates and files, and give indirect access to those files to the service modules
    • it provides a xml rpc service with high-level functions (the AlternC Core API)
    • it knows how to configure puppetmaster basics : just tell which node (machine) will provide which service (and therefore be connected to relevants service modules) and accept puppetd certificate requests.
    • it provides service modules with Hook management : each service module export hooks that other modules can use. The services can require that a hook (therefore a service) must be present, or just ask for it if the corresponding service module is installed.

  • Service modules,
    • each service module knows how to configure a specific service (bind, dovecot, proftpd etc.)
    • each service module provides a service-specific API (dns_api or db_api or pop_api etc.) It may provide multiple api at the same time (eg pop_api+imap_api).
    • each service module creates puppet recipes, files & templates that will configure the services it depends on. The dependencies are not package-based, but they are written as puppet recipes using the "package" object, (and required debconf preseeding).
    • each service module has configuration variables that may be different among unix distributions.

See below for the api documentations.

  • Interface modules
    • each interface module make a synthesis of services to show a complete web, shell or RPC control panel, with user right managements.
    • They provide interface for as much services as possible with a "usable" (ideally multilingual) interface.
    • They talk to the core using the AlternC Core API.
  • Sample configurations modules
    • they just depends on a minimum or maximum set of packages. (eg : alternc-base will be an empty pacakge depending on alternc-core, alternc-service-bind, alternc-service-apache, alternc-service-postfixdovecot, alternc-interface-web.)
  • Each service module service instance is bound to a user id (each user id is a UNIX user account. They may not have shell access though)
    • a bind zone is bound to a user id
    • a mysql database is "mainly owned" by a user id (even if another user may get access to it)
    • etc.

Packages examples

here are some examples of service packages :

  • alternc-service-bind, alternc-service-maradns, alternc-service-postfix, alternc-service-mysql, alternc-service-postgresql, alternc-service-squirrelmail ...

examples of api virtual packages :

  • alternc-api-dns is a virtual package provided by alternc-service-bind | alternc-service-maradns
  • alternc-api-popimap is a virtual package provided by alternc-service-cyrus | alternc-service-dovecot

example of interface modules :

  • alternc-interface-web, alternc-interface-ajax, alternc-interface-shell, alternc-interface-xmlrpc

example of configuration packages :

  • alternc-base can be a recommended minimum dependencies list that create a small hosting service.
  • alternc-full can be a full dependencies list of software that implement all available api & interfaces.

Software Communication and rights

The communication between the modules is as follow :

  • The interfaces use XML/RPC over HTTP to talk to the core using the AlternC core API. they send commands and receive data or error messages.
  • The core receive commands from its XML/RPC server, check them, and convert them to multiple Service Module API calls (php function calls) The XML/RPC server (the core) runs as an AlternC unprivileged Unix user.
  • The service modules implement API calls and execute them.
  • Service modules (running under AlternC unix user account) have read/write access to a puppetmaster manifests repository, where they can store files, recipes and templates.
  • Puppetmaster runs under puppet user. Puppetd (on each and every machine who is a member of the hosting cluster) run as root.

Documentation

  • A documentation is provided for each API :
    • AlternC Core API
    • DNS Service API
    • Web Service API
    • SMTP Mail Service API
    • etc.

The APIs are implemented by service module (eg: alternc-service-bind9 implements the DNS Service API). A module may use a hook provided by another module to influence its treatment. Hooks are documented in the service API. APIs doc contains functions, structures and hooks definitions.

APIs

The following APIs are currently in discussion :