Difference between revisions of "Deamon in Python"

Latest revision as of 23:07, 28 March 2010

oood.py - A simple daemon for OpenOffice.org

oood.py is a daemon, which controls a pool of 'anonymous' office instances (workers).

The workers can be used as backend for Java/python/C++ batch processes for document conversion, mail merges, etc. You don't need to rewrite your current scripts, a client connects to a daemon-controlled office just as if would connect to a normal office. Up to now, I only checked the functionality for batch clients, for server clients (e.g. a tomcat or zope), there may be some problems, you should simply try it.

The daemon ensures, that only one client at a time is connected to one OpenOffice instance (because one OOo instance in general can't cope with more than one scripter). Workers get restarted after a certain amount of uses or after office crashes.

A client can connect to a daemon as if it would connect to a normal 'non-daemoned' office, so you don't need to adapt your scripts.

oood.py has been implemented in pure python, but it uses some office components. This should make it easy to modify the daemon to your needs if desired.

Download: oood-0.1.0.zip (less than 10k):

Setup

The daemon comes in version 0.1.0. It is in a alpha state, it has currently only be tested on Linux x86. It may run on other Unix platforms, but it is definitely known not to run on windows. Simply try out to check if it is useful for you (after carefully reading this manual).

The daemon and this document is targeted at experienced OOo script developers.

Security

The daemon and its usage is in general INSECURE. Everyone, who can connect to the daemon can use the underlying office instances and thus has full access to the machine (with the daemon's user rights) and via socket communication to other machines accessible via sockets from the worker machine. All worker instances run under the same (= the daemon's userid) meaning that a menace user may spy other worker office instances.

However, some simple limitations can be done.

• Limiting the access to the daemon. You can use the connection string to limit the access to a certain network interface. E.g. using socket,host=localhost,port=2002;urp means, that the daemon (and the underlying office instances) can only be accessed from the same machine, where the daemon is running on. One may easily extend the daemon source to limit access e.g. to certain hosts. There is no user administration.
• User rights Create a special user for running the office instances. Limit the user's rights to the absolute minimum.

You should use this solution only in a trustworthy environments.

Installation

Office installation

It is assumed, that you use an office from the 1.1.x series. The office daemon works on an arbitrary number of office user installations, which must have been created from the same network installation with a single system user. Ideally you create a new system user (e.g. oood) therefor, but if you just want to try it out, you can use your normal system user. (The following description is more or less copied from a mail by J. Barfurth in dev@api.openoffice.org). First do a new multi-user installation ( start $ setup -net ) from the downloaded installation set. Afterwards, create multiple single user installations by starting

(use 01 instead of XX) [bash] $ setup -d /home/oood/ooo1.1_srvXX

from within the office/program directory. After the setup run, edit ~/.sversionrc file and replace "OpenOffice.org 1.1.0" with "OpenOffice.org 1.1.0_srvXX". . Repeat these steps with XX = 02, 03, ... . You need as many installations as you expect concurrent users. You may also start with a low number and add instances later on. Afterwards, your .sversionrc file should look like

OpenOffice.org 1.1 srv01=file:///home/oood/ooo1.1_srv01 OpenOffice.org 1.1 srv02=file:///home/oood/ooo1.1_srv02 OpenOffice.org 1.1 srv03=file:///home/oood/ooo1.1_srv03

Daemon installation

Switch to the OpenOffice.org's program directory and extract the oood-0.1.0.zip file. Open the oood-0.1.0/oood-config.xml file in a text editor and add the paths of every worker instances with a <user-installation url="file:///home/oood/ooo1.1_srv01" /> tag. For a start, just add one or two instances to see how the daemon is working. All other settings in oood-config.xml can be left untouched. The meaning of the other settings are documented in the comments.

Daemon administration

Starting

The daemon must be started with OpenOffice.org's python from within the OOo's program directory.

$ ./python oood-0.1.0/oood.py -c oood-0.1.0/oood-config.xml run

You get the log on the stdout blocking the shell. Depending on the number of workers you have configured, it may take quite a while to start. When you get a

Accepting on <your-connection-string>

the daemon is ready to serve requests.

Stopping

From a different shell, start $ ./python oood-0.1.0/bin/oood.py -c oood-0.1.0/config/oood-config.xml stop Signals the daemon to terminate all running workers and itself. The daemon can only be stopped this way after a successful startup.

Requesting status information

$ ./python oood-0.1.0/oood.py -c oood-0.1.0/oood-config.xml status Gives you a list of workers and their state.

Usage patterns

You can now connect to the daemon with an arbitrary (Java, C++, python) client program in exactly the same way as you connect to a normal OpenOffice.org.

The daemon delegates your request to one of its worker offices. For the time of usage, this worker office is exclusively used by your client program. The end of usage is detected by the daemon through a breakdown of the interprocess bridge (which occurs, when the last reference is gone, the client explicitly disposes the remote bridge or the client process terminates).

Performance

All requests to the office are tunneled through the daemon process. This means an additional load on the server machine and a performance overhead for every request. This is typically neglectable when your call frequency is low (say less than 10 Calls/s), but becomes a significant overhead for higher call frequencies.

Logging

Log level

There is 3 log levels.

• SERIOUS Only startup information and errors get written into the log
• INFO information about every connect and disconnect get logged (default)
• DETAIL Log level mostly sensible for debugging

Level INFO includes SERIOUS, DETAIL includes INFO and HIGH.