Overview of Services Python applications

Services Python applications are all WSGI applications based on the same stack of tools:

NGinx <= TCP => Gunicorn <= WSGI => SyncServerApp <=> WebOb
  • NGinx : A high-speed HTTP Server/reverse proxy.
  • GUnicorn: A Python WSGI Server.
  • SyncServerApp: A base WSGI application for all Services apps. Located in the server-core repository.
  • WebOb: a Request and a Response object with a simple interface.

Services provides two base libraries to build WSGI applications:

  • cef: implements a CEF logger for ArcSight.
  • server-core: provides helpers to build Services applications.


Most Services applications need to generate CEF logs. A CEF Log is a formatted log that can be used by ArcSight, a central application used by the Infrasec team to manage application security.

The cef module provides a log_cef() function that can be used to emit CEF logs:

log_cef(message, severity, environ, config, [username, [signature]], **kw)

Creates a CEF record, and emits it in syslog or another file.

  • message: message to log
  • severity: integer from 0 to 10
  • environ: the WSGI environ object
  • config: configuration dict
  • username: user name, defaults to ‘none’
  • signature: CEF signature code, defaults to ‘AuthFail’
  • extra keywords: extra keys used in the CEF extension


>>> from cef import log_cef
>>> log_cef('SecurityAlert!', 5, environ, config,
...         msg='Someone has stolen my chocolate')

With environ and config provided by the web environment.

Note that the CEF library is published at PyPI:

See CEF for more info on this.


The server-core library provides helpers to build Services applications.

In server-core‘s philosophy, a WSGI application is a SyncServerApp instance which will contain a config attribute that’s a mapper containing all the configuration needed by the code. This configuration is loaded from a unique ini-like file.

When a request comes in, Routes is used to dispatch it to a controller method.

Controllers are simple classes whose methods receive the request and need to return a response.

Configuration files

The configuration files we use in Services applications are based on an extended version of Ini files. You can find a description of the file at

server-core provides a simple reader:

>>> from services.config import Config
>>> cfg = Config('/etc/keyexchange/keyexchange.conf')
>>> cfg.sections()
['keyexchange', 'filtering', 'cef']

>>> cfg.items('keyexchange')
[('max_gets', 10), ('root_redirect', ''),
 ('use_memory', False), ('ttl', 300),
 ('cache_servers', ['']), ('cid_len', 4)]

>>> cfg.get('keyexchange', 'cid_len')

Note that SyncServerApp will automatically create a Config instance over a central configuration file when it’s used to create a web application.

See Configuration file for more info on this.


The SyncServerApp is a base class that can be used to get a few automation and some useful helpers when you want to create an application for Services.

It provides:

  • a central configuration file
  • a pluggable authentication backend with an LDAP and an SQL plugin provided.
  • an overridable authentication process, defaulting to Basic Authentication.
  • a basic URL dispatcher based on Routes.
  • an error handler that ensures backend errors are logged and a 500 error is raised.
  • a heartbeat page useful for monitoring the server
  • a debug page to display useful information on the server
  • a few middlewares integrated: a profiler, an error catcher and a console logger.

To create an application using SyncServerApp, see Complete layout.