Gwadeloop.com

cherokee admin api

Project scope

The Goal of this project is to provide an easy way to programmatically, in python, create and manipulate a cherokee.conf. Cherokee-admin give us a wonderful UI to interactively setup and configure a cherokee web server but it does not cover the use case where you need to automate repetitive tasks. I have decided to explore what it would take to create such package. Since cherokee-admin is written in python I have extracted the parser that is used to read and write cherokee.conf and added some functions to create:

  • vserver
  • source
  • rule

Where to get it ?

You can access the code on my bitbucket account [here] (http://bitbucket.org/yml/cherokee-admin-api). It is not yet ready for production but I think it can give you an idea of what you could do with this kind of tool.

How to install it

1
2
3
4
 pip install -E cherokee-admin-api-demo -e hg+http://bitbucket.org/yml/cherokee-admin-api#egg=cherokee_admin_api
 pip install -E cherokee-admin-api-demo nose  #only required to easily run the test suite.
 cd cherokee-admin-api-demo/; . bin/activate
 cd src/cherokee-admin-api/

In order to check that everything is working fine on your end you can run the test suite.

1
2
3
4
5
nosetests -w tests/
.......
----------------------------------------------------------------------
Ran 7 tests in 0.660s
OK

This will confirm that you are all set and can now start to work with cherokee-admin-api.

Limitations

"cherokee-admin-api" does not address yet the validation of the generated cherokee.conf so it is your responsibility to make sure that the result of your manipulation is valid. In or der to do this you could use "cherokee" itself :

1
cherokee -C tests/cherokee.conf -t

Validations of the rules in cherokee-admin is per rule at the moment in admin/validation.py. Another issue is that this validation "import CTK" which make it hard to be reused in another context a first step that would enable to re-purpose this set of validation rules would be to explicitly pass the configuration.

1
2
3
4
5
6
7
def is_new_tcp_port (value):
    value    = is_tcp_port (value)
    bindings = CTK.cfg.keys ('server!bind')
    ports    = [CTK.cfg.get_val('server!bind!%s!port'%(x)) for x in bindings]
    if value in ports:
        raise ValueError, _('Port already in use')
    return value

The above should a accept the configuration as an argument.

1
2
3
4
5
6
7
def is_new_tcp_port (config, value):
    value    = is_tcp_port (value)
    bindings = config.keys ('server!bind')
    ports    = [config.get_val('server!bind!%s!port'%(x)) for x in bindings]
    if value in ports:
        raise ValueError, _('Port already in use')
    return value

This changes can be made backward incompatible if required.

"configured.py" is generated at installation time for the time being and in order to get going quickly I have copied this file over based on my ubuntu configuration. It might be possible to do something clever to generate it on the fly or to allow an easy configuration.

Conclusion of this exploration

I see a lot of synergy between this package and cherokee-admin both address different use cases and it would be great is they could rely on a common architecture. I would be glad to hear form you about your thought on this experiment. Did you also find yourself in a situation where you have to fire cherokee-admin UI to do the same modification over and over? Please do not hesitate to fork this project to experiment and suggest improvement back.

blog comments powered by Disqus

Détail du billet

Publié le : Mai 20, 2010 à 6:41 Après-midi

© 2009 - 2012 Yann Malet