Monthly Archives: March 2013

mongoDB v2.4.1 and pymongo 2.5 released

10gen released a critical update for mongoDB 2.4.0 which affected queries on secondaries, you should upgrade asap. The python mongo driver followed the 2.4.x releases and got bumped to 2.5 this week-end. I am pleased to announce that I took the chance to add the kerberos authentication support to both ebuilds while bumping them.

pymongo-2.5

  • GSSAPI (Kerberos) authentication
  • SSL certificate validation with hostname matching
  • Delegated and role based authentication

Python : writing a proper setup for your project

For an open-source project to be adopted, it must be easy to install and test it. Before publicly releasing py3status I thus had to figure out how to get my python project installed properly for every user who would be interested in it.

The common and most efficient way of writing a setup process in python is by using the setuptools package and writing your own setup.py file. Doing so is not hard at all as there are quite a bunch of examples you can start from but my challenge was that py3status is not a library you install and then import on your python code, instead it must be seen and used as an executable available for all users (something like /usr/bin/py3status). I’ll cover the steps I used to achieve this kind of installation.

setup.py basics

You can see the setup.py file just like any other python program you write where you import the functions you need from setuptools.

import os
from setuptools import find_packages, setup

Basically, a setup.py file is just a call to setup with a fair amount of parameters depending on the size and complexity of your project. Let’s see a basic usage with no real magic.

setup(
	name='py3status',
	version='0.5',
	url='https://github.com/ultrabug/py3status/wiki',
	download_url='https://github.com/ultrabug/py3status',
	license='BSD',
	author='Ultrabug',
	author_email='ultrabug@sikritdomain.com',
	description='py3status is an extensible i3status wrapper written in python',
	long_description='this is a very long description which im writing for example',
	platforms='any',
	)

As you can see those parameters are just fields describing your project but there are of course more parameters you can use to become more specific about it such as which other packages it depends from or special operations to be made upon installation.

classifiers

As with a literal description, you must categorize your project so that it will be correctly understood by automatic classifiers for example. The classifiers parameter is a list of those categories which you can find a list here.

	classifiers=[
		'License :: OSI Approved :: BSD License',
		'Operating System :: POSIX :: Linux',
		'Programming Language :: Python',
		'Programming Language :: Python :: 2.5',
		'Programming Language :: Python :: 2.6',
		'Programming Language :: Python :: 2.7',
		'Programming Language :: Python :: 3',
		'Programming Language :: Python :: 3.2',
		'Topic :: Software Development :: Libraries :: Python Modules',
		'Topic :: Desktop Environment :: Window Managers :: i3wm',
		],

getting an executable from your python program

As I explained earlier, py3status must be used as an executable available in the users’ PATH just like any other binary or commands on the system. I was thrilled to discover that achieving this is a piece of cake using setuptools, you just have to use the entry_points parameter and it will be taken care of for you.

entry_points={
		'console_scripts': [
			'py3status = py3status:main',
			]
		},

So here I’m asking setuptools to create a script which will execute py3status’ main function. It will generate a python program that just does that, call it py3status, place it in /usr/bin and make it executable. Et voilà ! An important thing to note is that it also works in Windows and that’s how you’ll get a .exe from your python code !

Learn more on this subject by reading the excellent documentation on how to get started with setuptools.

mongoDB : v2.4.0 released

A few months ago, I pointed out what was coming with this release and did an update of this cooking 2.4.0 later. Yesterday, 10gen announced the release of the new stable branch of mongoDB v2.4.0. Instead of talking about it again, I’ll focus on what this release brings to Gentoo users as I’m glad to announce that it’s already available in portage.

SSL support

First of all, I think it was a good time to close bug #421289 and finally enable the SSL support via the ssl USE flag. I’ll support it as much as upstream does, so don’t expect some big magic about it.

Shared client library

Since this has always been a mess, I also added the sharedclient USE flag so that users who really need the client shared library can toggle its installation easily. This also permits me to isolate possible problems from the main ebuild.

Upgrading to 2.4

This is seamless unless you’re running a sharded cluster ! In this case, take great care of what you do and note that the upgrade is only possible if your cluster is running v2.2 ! Please read with care the upgrade plan.

py3status v0.5

Since the first release of py3status, quite a bunch of bugfixes and features came such as python3 support and SIGUSR1 signal handling to force an update of the bar.

changelog

  • bugfix : fix delta variable declaration
  • examples : add GLPI open tickets counter module example
  • python3 compatibility inspired by waaaaargh (Johannes Firlefanz)
  • improvement : iterate over user classes in a sorted manner to allow a predictive ordering of outputs
  • bugfix : dont fail if i3status output comes slower than py3status message polling interval
  • feature : signal SIGUSR1 forces i3status and i3bar refresh, feature request by Michael Schaefer

rabbitMQ : v3.0.4 released

Within a week, rabbitMQ got bumped twice. I’m happy to quickly post about those recent bumps so here is a highlight of 3.0.3 and 3.0.4 changelogs.

highlights

  • fix connection failure to start reading again in rare circumstances when coming out of flow control
  • ensure invocation of “rabbitmqctl stop_app” during server startup on a fresh node does not leave a corrupted Mnesia schema
  • ensure messages expire immediately when reaching the head of a queue after basic.get
  • ensure parameters and policies for a vhost are removed with that vhost
  • do not log spurious errors for connections that close very early
  • ensure “rabbitmqctl forget_cluster_node” removes durable queue records for unmirrored queues on the forgotten node
  • clean up connection and channel records from nodes that have crashed
  • do not show 404 errors when rabbitmq_federation_management is installed and rabbitmq_federation is not
  • ensure the reader process hibernates when idle
  • prevent x-received-from header from leaking upstream credentials

Follow-up on pacemaker v1.1.9 and updated pacemaker-gui

In my previous post I talked about a permission problem introduced in pacemaker-1.1.9 which requires root to be a member of the haclient group. I’ve been helping @beekhof to investigate on this and I’m glad he found and fixed both the problem and a memory leak ! We’re still investigating on another issue but we should be seeing a new version bump pretty soon, thank you Andrew !

pacemaker-gui v2.1.2

One of my colleagues recently complained that pacemaker-gui-2.1.1 was not compatible with newer pacemaker releases (>=1.1.8) so he had to install pacemaker-1.1.7 if he wanted to benefit from the GUI. I contacted @gao-yan from SUSE who’s the main upstream for this package and asked him for a tag bump. Here comes pacemaker-gui-2.1.2 which is compatible with all newer pacemaker releases ! Thanks again mate.

Pacemaker vulnerability and v1.1.9 release

A security vulnerability (CVE-2013-0281) was found on pacemaker which permitted attackers to prevent your cluster from serving more CIB requests. Although this issue was quickly fixed by upstream, they didn’t add a new tag to pacemaker so I did ask Andrew Beekhof for one so I could take care of bug #457572. Gentoo users, here comes pacemaker-1.1.9 !

important

While packaging and testing pacemaker-1.1.9, I ran into some weird permission issues which I debugged with @beekhof and @asalkeld (thx again guys). Turns out that when enabling ACL support on pacemaker, you now need to add root to the haclient group ! The reason is that pacemaker now uses shared memory IPC sockets from libqb to communicate with corosync (on /dev/shm/).

v1.1.9 changelog

  • corosync: Allow cman and corosync 2.0 nodes to use a name other than uname()
  • corosync: Use queues to avoid blocking when sending CPG messages
  • Drop per-user core directories
  • ipc: Compress messages that exceed the configured IPC message limit
  • ipc: Use queues to prevent slow clients from blocking the server
  • ipc: Use shared memory by default
  • lrmd: Support nagios remote monitoring
  • lrmd: Pacemaker Remote Daemon for extending pacemaker functionality outside corosync cluster.
  • pengine: Check for master/slave resources that are not OCF agents
  • pengine: Support a ‘requires’ resource meta-attribute for controlling whether it needs quorum, fencing or nothing
  • pengine: Support for resource container
  • pengine: Support resources that require unfencing before start

Since the main focus of the bump was to fix a security issue, I didn’t add the new nagios feature to the ebuild. If you’re interested in it, just say so and I’ll do my best to add it asap.

uWSGI : v1.4.9 released

Yet another version bump for this very active package.

highlights

  • avoid crashing carbon on master shutdown
  • call ERR_clear_error after each https session close
  • fixed broodlord mode
  • removed broken JVM and JWSGI plugins (stable versions are in 1.9)
  • backported cache_update for lua and fixed its lock handling

Full changelog is here.

Switching from Xchat to HexChat

As polynomial-c announced last year, xchat upstream is dead for some time now. Fortunately for us the fork hexchat is taking over and is compatible with your current xchat configuration so it’s really easy to migrate.

migrating to hexchat

$ mv .xchat2/ .config/hexchat/
$ mv .config/hexchat/xchat.conf .config/hexchat/hexchat.conf

As mentioned in the comments by Louis Tim Larsen, if you have some servers configured with more than one channel make sure to run this command as well :

sed -i 's/,#/\nJ=#/g' ~/.config/hexchat/servlist.conf

Then run hexchat as you would xchat.

theme your IRC

If like me you’re a fan of Solarized, you can get hexchat to use these colors thanks to some contributed themes. Here’s the quick hack to have it done, for the Solarized Light theme.

$ cd .config/hexchat
$ wget http://dl.hexchat.org/themes/Solarized%20Light.hct
$ unzip -o Solarized\ Light.hct

Restart hexchat and enjoy your up to date and colorized IRC client.