No worries, I’m the great four eyed accountant!!

I’m here to save you from your financial crisis misery… (Or not quite)

The great four eyed accountant

Too sad that I’m both not good with money, and an ICT geek… Funny to become an accountant :)

Create your own hero at: the hero factory

As it is, the time is constantly more limited. I need more time, lots and lots of more time (and I need to stay away from the stargate episodes ^^)

In the PySM story, I’ve been assigned with developing the system core on the system. That core will (or should) organize the processes, system resources, communication between other cores, etc… I’ve thought some things through, but as it is, I’m stuck. Writing this might open op some items (and spice up this boring blog)

Communication!

For starters. The entire PySM packet will be designed from the ground up to be decentralized and preferably 100% scalable. Albeit the scalability isn’t the easy, nor the hard part. Thanks to the decentralization, scalability will rise bunch already.

So with decentalization comes communication, otherwise the different parts would be nothing more but meaningless pieces of code fooling other parts :D

After a little while of thinking, we decided to go with XMPP for communication. We know it’s not meant to be a protocol for managing _anything_, but the stanza system works in our advantage, and being capable of seeing “who” is online would get the front-end to see whether or not certain systems are online, etc… Basically, it gets a bunch of the work (thinking-wize) of the grid.

Downside is that we want (or would like to) create a 100% python project. The clients (which would reside in all cores) have got libraries in sleekxmpp, pyxmpp, etc… Choice all the same, and a choice we will make.
The server however we don’t have any libraries that we know of. So we figured we’d create one of our own ^^

Long live insanity

So, bottomline, that server would reside in the part I’m assigned with. It’ll basically become very hard. And I hope I’m up to the challenge :)

Starting to write an XMPP server is not simple. Although there’s a lot of projects online, I figured I’d stay away from that code as much as possible (most of it seems to be C and Java anyway) Working up from the RFC seems to be the best option imho.
I rather call myself idiot and insane for doing so, but I can’t help myself.

Basics

To start, we don’t want to create an entire XMPP server to start with. We only need a server to suffice our needs, being (for starters) basic query / response communication, as well as presence stanza capability. It’s going to be really cool, but identifying users will be yet another story. Perhaps we’ll go configure those systems a bit.

Not that I want to explain the entire XMPP protocol, but since it works the way it does, I’m thinking of using a simple [program_name]@[ip]/[configured_string] , I figured that would identify every program to be an ip, and the string can be used to tie rights, possibilities, etc… to users. To enable more scalability, we shouldn’t be using ip’s, because those can change, and when they do, there should not be a need for reconfiguration. The only configuration should be when the system is deployed, and even then configs should be dummy-size easy :)

Therapy

And to close in totally unrelated matters. I find blogging like this really relaxing. Gets my thoughts together by putting them randomly on a post (and the best thing is I won’t ever lose those thoughts… Ever…)

So, thanks for the session, and I’ll come over on a more regular meeting preferably :)

In light of a school project, we (me, Tim and Michel) decided to undertake a python project called the Python Server Managment.

The pySM goal

In pySM we aim to achieve a robust, easy-to-use and easy-to-deploy server management application. Our goals are nicely summed up as:

• Easy to maintain
• Modular
• Free and Open Source
• At least similar functionality as plesk (And better!)
• File based configuration (vs the database way)

We also intend to give the community (that’s all you guys out there) full support and modules interfaces. We want to unleash the true potential of online server management. To keep things fowing.

Why?

Why we would want to do that will take us back some time. When a lot of annoyances started building up in another (commercial) server management software called plesk.

1. In plesk, the actual server admin does not have the rights to add services on their own, and try to get plesk support for it. This is something we intend to break!
2. In the same plesk issues, when changing configuration of any plesk-supported service, without going through plesk, will nullify that change. Which is rediculous at best! We will use a file configuration system, instead of the database system plesk uses.
3. Needless to say, the fact that plesk is (in our eyes) limited. We intend to get our system the true unlimited key to this world. We intend to make the core, and module API so that people won’t need too much skills to configure basic to intermediate services. For that, we would love your help! :)

So, as you all might’ve noticed, plesk will be our measurement of success. If we come near plesk in the field of technical capabilities, we’re already happy. We’re not trying to break records though… Needless to say, we’ll attempt to test our efforts using plesk, and we _will_ run the software ourselves when we’ve got decent binaries. Thereby we’re telling you we want to give a good product, not only because we have to for school, but because we intend to use it ourselves.

Now, I have jabbled enough, I’m going to code some, I hope to announce more soon! :)

This is a call to everyone out there! As it is, software patents are limiting the development (and quite honestly, all patents in my eyes, but that’s another issue…)

Innovation is being blocked, every open source project will eventually have some patent infrigements out there.

Therefore, stop the eu software patents, it’s innovations only hope in the forseeable future, sign the petition now!

And, yes, undoubtedly, I’m going to fosdem next year (2009).

Therefore, the next banner will be present on the website during all that time.

Be there, or stop visiting codercpf.be!

As I’m all about python, and pythonic is the way I speak any coding language, I had a challenge in finding a way to dynamically implement new variables in a class.

Unlike python, in which this is very simply done by:

class MyClass:
    def __init__(self):
        self.newvar = 'value'
        self.newvar2 = 'bla'

It’s quite the challenge doing something similar in PHP. In fact, even after finding a partial solution, it’s plain _impossible_…
One way, though, to make it seem like you succeeded in that fact, is by using the __get and __set function definitions in PHP. Quite similar to __getitem__ and __setitem__ in python. Especially in its implementation.

The solution

Now, as to explain whatever I was brabbling earlier into clear, simple code, and testing code:

class MyExplainerClass {
    private $data;

    public function MyExplainerClass() {
        $this -> data = array(); // Initialization
    }

    public __get($name) {
        if (array_key_exists($name, $this -> data))
            return $this -> data[$name];
        // Here you can put debugging, error showing, etc...
    }

    public __set($name, $value) {
        $this -> data[$name] = $value;
    }
}

$myTester = new MyExplainerClass();
$myTester -> newvar = 'value';
echo $myTester -> newvar; // value

Now, that’s about everything here to explain. I think it’s clear enough for even the simpelest out there.

So, you’re here on some quest to solve an issue where you do any amount of insert queries through MySQLdb but it doesn’t appear in the database?

Well, I had exactly that issue. Took me ages to figure out why after moving an app to another server (with by design the same database, except for a small difference explained later), the app didn’t insert anything (!!), but didn’t give any errors either.
Thinking to myself: “Weird stuff, can’t be happening!”

So, I went on that quest myself.

Solution is quite simple:

import MySQLdb
db = MySQLdb.connect([...])
c = db.cursor()
[ Couple of insert statements ]
db.commit()

This commit is the key. The reason you’re having the issue is probably because you’re using innoDB as the database engine…

So, as the title says, we’re going to install trac on apache using mod_fastcgi.
Now, before we get off, some explanation on why I write this:

As it is, I tried to follow the documentation on the official trac website. But it was unclear, and made me very confused. In the end, someone had to tell me how simple it was before I wanted to believe it in the first place…

In this small post, I’ll assume you have a trac environment configured.

Two steps

Yes indeed, just two steps are required. In here, I’m going to assume you either have a website running already, or you are going to create a virtualhost for trac.

In the end, I’ll post my own virtualhost, so that everyone can reference on that.

Step one

First, you have to “deploy” the trac environment. This is done with the following command:

trac-admin /path/to/env deploy /path/to/apache/htdocs

Now, one thing to really keep in mind is that you cannot deploy in the env directory (or by my experience anywhere near it) It’s best to simply use the /var/www/htdocs most apache setups use.

Step two

Now, we configure apache. In the virtualhost section you want trac to run in, you add the following:

ScriptAlias /trac /path/to/apache/www/cgi-bin/trac.fcgi/

The trailing slash is really important, otherwise the cgi app won’t see the page as argument!

Also, you can alias straight to / if you want, it will work too (if you don’t share this virtualhost with another app)

Note: If you’re running (or going to run) multiple trac instances through apache, you should go to /path/to/apache/htdocs/cgi-bin/ and edit trac.fcgi to change TRAC_ENV to TRAC_ENV_PARENT_DIR:

os.environ['TRAC_ENV'] -> os.environ['TRAC_ENV_PARENT_DIR']

Test it

Albeit this is not the third step (there is no third step), it’s best to take a look and test. But you should see the trac pages coming up pretty quickly, and you should be pleased, for it is the simpelest thing to configure.

As I promised, this is my own virtualhost, just to make sure people might learn from it:

<VirtualHost *:80>
        FastCGIExternalServer /home/user/project/fcgi.fcgi -socket /home/user/project/scgi.sock
        ServerName project.com
        DocumentRoot /home/user/project/
        Alias /media /home/user/project/media/
        ScriptAlias /trac /var/www/htdocs/cgi-bin/trac.fcgi/
        RewriteEngine On
        RewriteRule ^/(media.*)$ /$1 [QSA,L,PT]
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_URI} !^/trac.*$
        RewriteRule ^/(.*)$ /fcgi.fcgi/$1 [QSA,L]
</VirtualHost>

Note that this virtualhost is also hosting a django config, and I have added a RewriteRule to make sure /trac isn’t handled by it. Which was a huge stumble point before, and therefore I thank the great people at the #trac channel on irc.freenode.net !

As always, any comments, improvements, or even thanks are welcomed!

Today I was configuring apache(2) under mod_fastcgi to get my django project working on it. It was requested since the testing would go on a similar-to-deployment method.

So, I followed the guides at djangoproject but, as it seemed, I had some issues. Some were my own problem, some were not.
After fixing them, I decided to write a little “tutorial” to help other people perhaps having the same issues.

First things first

Before digging in to this tutorial, I advice trying to do the guidelines of django itself. In the end, if you follow as strictly as possible, it should work.
What will be discussed here will look very (and I mean very) similar to the guidelines of django, but with some notes on what I met on the process.

What is assumed?

During this, I’ll just simply assume you’ve got apache, and tested it to work (the way you installed it), I’m not going to explain how to install apache in any way, it’s useless, pointless, and there’s a whole bunch of tutorials covering it way better than I possibly could! GOOGLE it if you don’t have apache yet!

Step one.

So, as for the tutorial itself, we’re going to start of with running your django project in fcgi modus. As it is, the basic usage is very simple, and you can’t possibly go wrong in this.

Got from the official documentation:

./manage.py runfcgi [options]

Where [Options] is mandatory. The simplest way would be to use the socket option (as I’ll describe below), and a pid file is highly recommended!

In the end, you might want to configure your own protocol too (django supports all protocols supported by flup. And I chose for scgi (for unknown reasons really…)

So, knowing those things, the basic best-use would be to use the command:

./manage.py runfcgi socket=/path/to/socket/file pidfile=/path/to/pid/file [protocol=your_protocol]

To make things easier, I put those things straight in my project directory. Although one might opt-in for the approach of having a subdirectory, or using a completely different directory.

However, to start, which will help anyone having trouble setting things up properly, you should try to stop deamonizing the script, eventually you’ll see whatever happens…

To do so, just add daemonize=false to the string of options. Note that we’ll only use this during the test of the setup, if you don’t have any issues, I even wonder why you’re still reading this…

One might also be interested in auto-starting some script, but I’ll leave that shizzle up to you, although I strongly recommend, I can’t cover most auto-start script here (and since I’m used to archlinux, it was a hassle to do so on debian!)

Apache is next.

So, we don’t have to look back to the project anymore, we’re going to start of configuring apache.

Now, on this, I find the documentation of django a bit unclear, but depending on your OS, you’d be editing httpd.conf (or similar, e.g. on my debian it was called apache2.conf)
For clarity I’ll just keep refering to httpd.conf from here on!

After (obviously) installing and activating mod_fastcgi, you’d have to get one line in the httpd.conf file to enable the apache server to communicate with your project.

httpd.conf:
FastCGIExternalServer /path/to/fcgi/file -socket /path/to/socket/file

NOTE: The fcgi file can exist, but it is no requirement.
NOTE2: If you’re later on testing get “Permission denied: FastCGI: failed to connect to server blabla: connect() failed” you’ll need to make sure the user apache uses (mostly www-data) has access to the fcgi file. The simpelest way to solve this is a chmod 777 /path/to/fcgi/file

Next thing would be to configure your website. Note that here you’ll have to use the proper syntax to get your /media/ online. I used /media/ too for my own media files (in the end seeing that it isn’t the proper/best method, I’ll change that when I got the guts)

httpd.conf:
<VirtualHost 0.0.0.0>
  ServerName example.com
  DocumentRoot /path/to/document/root
  Alias /media /home/user/python/django/contrib/admin/media # Note that this may differ per setup
  RewriteEngine On
  RewriteRule ^/(media.*)$ /$1 [QSA,L,PT] # This one will NOT get django to deliver the media files
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule ^/(.*)$ /fcgi_file.fcgi/$1 [QSA,L] # Note that you'll have to use the proper filename
</VirtualHost>

To end

Now, restart (or start) apache, and best tail -f the error file (just in case), pay attention to your (if you did what I suggested) non-daemonized django project. If nothing happens, and you can visit your website without an 500 internal server error, or anything similar, you can get the daemonized django project in the running!

Congratulations, you just configured and installed apache + mod_fastcgi to use in your django project. Next would be to actually get things running the way YOU want it.

Before I leave you guys to never visit me again, I’d like to thank the guys at irc.freenode.org#django for the help, and the django developers for getting such a great framework online!

With the past project, I’ve been using django all the way.
Given the requirements for that project, I judged that we were going to be needing a lot of AJAX, and I immediatelly started looking around for ways to do this. Luckily, it was found pretty quickly.
The is_ajax method

Conveniently enough: django provides a method inside the request, is_ajax, it’s pretty straight forward to  what I was looking to: A method to figure out simply and quickly whether or not a request is indeed originating from my AJAX platform.

There are -however- several items to take in account when using is_ajax:

1. is_ajax checks the HTTP_X_REQUESTED_WITH header to varify the source to be AJAX or not. This is being used by most of the javascript frameworks, including prototype (which I opted for).
2. In the current form, the CSRF (Cross Site Reference Forgery) middleware won’t work with AJAX, I have submitted a patch for that, but it has not yet been included in the svn. If you are using (or going to use) the CSRF middleware, you might consider changing the source.

Using is_ajax

To use is_ajax inside your view is a very straight forward and easy thing. However, considering several items, I would advice several things:

1. I never use AJAX GET requests, ever. Because of that, I’m always checking whether or not the request was indeed a POST request. I advice using the same method (only allow one of both per page you’re requesting). Take in mind though the common sense: POST should be used when you’re intending to change values, GET whenever you’re just going to get some data and return it (get_or_404 e.g.) Even though we’re talking AJAX, we should still be on guard.
2. NEVER, EVER trust anything coming from an AJAX request. Albeit you should never ever trust any request, I find the AJAX requests still more dubious. Especially since people are discovering ways to misuse the trust in AJAX more quickly. As a rule, anything coming from outside should be checked, and anything coming from the inside should be looked at in suspicion.
3. When you’re using AJAX in a user authenticated area, always check for that user. It might sound as if I’m saying stupid things, but even though you expect the user to be there (it being a user area after all), it might just as well be something else.

Those things being pressed, this is how I use is_ajax fully:

if request.method != 'POST' or not request.is_ajax() or not request.user.is_authenticated():
    return HttpResponseForbidden('')

Simply put, it follows my method of thinking. First of all, the request should be POST, than, it should be an AJAX request for this function.
Those are the 2 basic “technical” items of the request. The third being the user authentication check, is actually only because it’s more secure and I need to use that user data later on.

If at any of those three the check fails, and goes to the return statement below, I follow the correct way of webdevelopment in telling the user/program the request is forbidden. Because it is, since it didn’t go through the checks. I was tempted to return a 404 document, it being a bit more cryptic, but it won’t change a darn thing after all.

As this concludes my little lecture, I’m going to let you guys play with the django framework some more!
References to the things I spawned at your face:

• Request Response documentation
• CSRF middleware
• The CSRF + AJAX ticket