Wsgid is a generic handler for the mongrel2 web server. It acts as a bridge between WSGI and mongrel2 and makes it possible to run any WSGI python application using mongrel2 as the front end. To know more about both projects visit their official websites at: http://wsgid.com and http://mongrel2.org

In this post we will see how to configure mongrel2 and wsgid so your application will be able to handle arbitrary sized requests very easily and with a low memory usage.

TL;DR

In this post you will learn how to configure mongrel2 and wsgid to run your WSGI appalication. If you are interested in web servers, web application deployment and system administration, read on!

Mongrel2

Mongrel2 is a different webserver. At least different from all web servers I’ve seen until I found it. This difference stands on the fact that mongrel2 is language agnostic, that is, it does not matter in which language your application is written. You will understand why very soon, keep reading!

Mongrel2 decouples application from web server in a very simple yet powerful and intelligent way. It uses a high performance queue to talk to your application. The queue used here is zeromq. So everything your applications needs to have mongrel2 as its front-end is to know how to speak zeromq. Fortunately there are already 30+ zeromq bindings, so if your language of choice has a zeromq binding you are ready to plug your app into mongrel2 infrastructure.

This decoupling means that your app and mongrel2 runs on different operating system processes, in fact nothing forbids them to run of different machines. To accomplish this mongrel2 uses a pair of sockets to communicate to back-end handlers. These are two zeromq sockets: One to push messages to back-end handlers and another to get the responses. And why is this great? Because the zeromq socket (PUSH/PULL) mongrel2 uses to push messages comes for free with round robin load balancing, this means that if you have 32 connected handlers to this socket each one of them will receive one message at a time in a round robin fashion. Cool, isn’t it?

Another big advantage of this load balancing is that it’s different from other load balancing setups and I will explain why. Usually when we see a load balancing setup, it uses the proxy technique. That’s nothing wrong with it, but one thing that you must know beforehand is the IP:PORT of all your back-end servers, the servers that you will proxy requests to. It happens like this: The front-end receives a new request, connects to one of the back-end proxies and delivers the just received request. If you want to add a new back-end server, you need to edit your front-end config, introduce this new server to it and tell your front-end to reload.

With mongrel2 you don’t need to do this, yes you don’t. That’s because of how zeromq works. What mongrel2 does is: It opens one zeromq PUSH socket on localhost (This is chosen on mongrel2 configuration, more on this later) and here is the magic: The back-end workers are the ones who connects to this socket. So who needs to know where to connect is the back-end handler, not the front-end! See? Because of this sort of inversion you can add/remove new handlers without mongrel2 even knowing you did it, without touching any config files and the best: without the need to restart/reload mongrel2 config values. This  was the functionality that blew my mind, by the way.

You may be thinking: “Alright, so I have to write my own mongrel2 handler to run my apps on it?” The answer is Yes and No. If you are interested on running python WSGI applications with mongrel2 you won’t have to write a handler, in fact your WSGI app won’t even need to know it is running with mongrel2. That’s when wsgid comes in to rescue you (more on this later), it is the bridge between mongrel2 and your WSGI app.

So let’s see how to configure our mongrel2 instance and then we will see how to use wsgid to run our web app.

Configuration files

I said files because mongrel2 reads its configuration from a database. Yes, from a database! Breathe…., still with me? Alright! At first you may think: “What? From a database? WTF!? This is crazy!”. But when you think clearly you start to see some advantages, and the most important is that it becomes absolutelly easy to change any config you want, and to do this all you need is a sqlite client. Even better, you can build your own tool to manage this config database yourself (no need to write nay kind of file parser). Note: Mongrel2 already have internal infrastructure to be able to load its config values from anywhere, see more at this blog post.

One disadvantage that probably you thought about was: “It is very non optimal to read config values from a database”, and you are not completely wrong here, but there is one thing that changes it all: Mongrel2 does not keep reading the database during its run. It reads the configs only when starting up, so what you end up with is one read from the database against one read/parse from the config files. Maybe some additional milliseconds to read the database, but honestly, not that bad, right? Also mongrel2 has a hot reload functionality, you just SIGHUP it and all config values will be reloaded on the next request.

Installing mongrel2

Installing is pretty usual, as awlays it’s a matter of:

$ make
# make install

If you happen do use Gentoo linux, there is an overlay that conatins mongrel2 ebuilds, It’s here: https://github.com/daltonmatos/gentoo-overlay. Just add it to your Gentoo installation and you will be able to do an emerge mongrel2 to install it. If you are installing manually remember to install also zeromq and sqlite3.

Configuring mongrel2

As said before, mongrel2 uses a database to store its configurations. So we need a database schema to start with. Mongrel2 ships with a tool names m2sh that can build your database schema for the first time. There are some example config files that m2sh understands inside mongrel2 source code, they are inside examples/configs. All you have to do is:

$ m2sh load -config <your-config-file.conf>

this will build a file named config.sqlite. That’s your database! Rather than learning the syntax that m2sh understands (because if we work with the files that m2sh understands, we will lose all the advantages of having a database as a source of our settings) we will focus on the database it creates for us. You not always need m2sh, mongrel2 comes with one SQL file that re-creates the schema for you, it’s the src/config/config.sql and can be seen here: https://github.com/zedshaw/mongrel2/blob/master/src/config/config.sql. So let’s see what do we get with m2sh load command:

$ sqlite3 config.sqlite
SQLite version 3.7.7.1 2011-06-28 17:39:05
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .tables
directory  host       mimetype   route      setting
handler    log        proxy      server     statistic
sqlite>

So here are the tables mongrel2 needs to store all your configuration. The tables we will see are:

• server – Stores all servers we have, here we have the port that this server is listening to;
• host – Here are all virtual hosts, each host is attached to one server;
• route – Here are our routes, each route is attached to one host and to one target (more on this later) that can be a handler, proxy or directory;
• handler – Here we define our backends;
• directory – Here are all our directories that contains static data.

The server table

Here is the schema of this table:

sqlite> .schema server
CREATE TABLE server (id INTEGER PRIMARY KEY,
    uuid TEXT,
    access_log TEXT,
    error_log TEXT,
    chroot TEXT DEFAULT '/var/www',
    pid_file TEXT,
    default_host TEXT,
    name TEXT DEFAULT '',
    bind_addr TEXT DEFAULT "0.0.0.0",
    port INTEGER,
    use_ssl INTEGER default 0);
sqlite>

And here is some data from my personal deployment:

sqlite> select * from server;
          id = 1
        uuid = f400bf85-4538-4f7a-8908-67e313d515c2
  access_log = /logs/access.log
   error_log = /logs/error.log
      chroot = /var/mongrel2
    pid_File = /run/mongrel2.pid
        name = mainserver
   bind_addr = 0.0.0.0
        port = 80
     use_ssl = 0
default_host = wsgid.com
sqlite>

I used one value per line for clarity. So here we have one typical server deployed on port 80. One important thing to see here is the chroot field. Mongrel2 always chroots to one specified location before start serving requests. All paths at the directory table will be relative to this path, for example.

The host table

Here is the schema:

sqlite> .schema host
CREATE TABLE host (id INTEGER PRIMARY KEY,
    server_id INTEGER,
    maintenance BOOLEAN DEFAULT 0,
    name TEXT,
    matching TEXT);
sqlite>

The important parts are:  server_id is the server that this host belongs to. The name is just a name for this host, you use this value to refer tho this host inside you configuration. The matching field is what mongrel2 uses to match the Host header of the HTTP request. You can use some regular expression here, see more at mongrel2 docs.

Here are some data of my same deploy cited above:

sqlite> select * from host where name in ('daltonmatos.com', 'wsgid.com');
         id = 4
  server_id = 1
maintenance = 0
       name = wsgid.com
   matching = wsgid.com

         id = 6
  server_id = 1
maintenance = 0
       name = daltonmatos.com
   matching = daltonmatos.com
sqlite>

Here we have two deployed hosts. Until here mongrel2 is not useufl yet, because we are not serving any content. Now we start to configure our backends.

The route table

Here is the schema:

sqlite> .schema route
CREATE TABLE route (id INTEGER PRIMARY KEY,
    path TEXT,
    reversed BOOLEAN DEFAULT 0,
    host_id INTEGER,
    target_id INTEGER,
    target_type TEXT);
sqlite>

Here we put all routes we want mongrel2 to respond to and attach them either to a handler, proxy or directory. In this post we will see only handler and directory backends. Here is some real data:

sqlite> select * from route where host_id = 6;
         id = 12
       path = /static
   reversed = 0
    host_id = 6
  target_id = 5
target_type = dir

         id = 13
       path = /
   reversed = 0
    host_id = 6
  target_id = 2
target_type = handler

These two routes are attached to my personal website host: daltonmatos.com, and are respectively for the static content and for the main application (it’s a Django app). So let’s see how we configure our handlers:

The directory table, for static serving

Here is the schema:

sqlite> .schema directory
CREATE TABLE directory (id INTEGER PRIMARY KEY,
   base TEXT,   
   index_file TEXT,
   default_ctype TEXT,
   cache_ttl INTEGER DEFAULT 0);
sqlite>

And here is some real data from my deploy:

sqlite> select * from directory where id = 5;
           id = 5
         base = apps/daltonmatos.com/app/daltonmatosdotcom/static/
   index_file = index.html
default_ctype = text/html
    cache_ttl = 0
sqlite>

This is the target that the /static route is attached to. Remember the base path is always relative to the chroot path you choosed when creating your servers. Now, the final part where we present our application handlers to mongrel2

The handler table

Here is the schema:

sqlite> .schema handler
CREATE TABLE handler (id INTEGER PRIMARY KEY,
    send_spec TEXT, 
    send_ident TEXT,
    recv_spec TEXT,
    recv_ident TEXT,
   raw_payload INTEGER DEFAULT 0, protocol TEXT default 'json');
sqlite>

And the data for the daltonmatos.com host:

sqlite> select * from handler where id = 2;
         id = 2
  send_spec = tcp://127.0.0.1:5002
 send_ident = 35353f12-6a2a-11e0-b898-001fe149503a
  recv_spec = tcp://127.0.0.1:5003
 recv_ident = 35ad3ab2-6a2a-11e0-b898-001fe149503a
raw_payload = 0
   protocol = json
sqlite>

So here is the magic behind mongrel2. See these two IP:PORT configs? So these are the two sockets I talked about earlier at the beginning of this post. The send_spec is the socket used by mongrel2 to dispatch messages to the handlers. The recv_spec is the socket used to receive the responses.

Here is how mongrel2 decouples from you application. Since it talks to your app across the network, it does not matter in which language you write you apps, as long as your app speaks mongrel2 protocol language. And thats where wsgid enters the story. Lucky you, none of your already written django apps need to know about mongrel2 protocol because wsgid speaks both mongrel2 protocol and  WSGI. Let’s see how we can use wsgid to run ou apps with mongrel2 as the frontend.

So long story short, every request that comes to the root of daltonmatos.com, mongrel2 parses the HTTP requests and dispatches it to this send_spec socket, and from here on until the response comes back, is zeromq machinery. To know more about how mongrel2 handles this two sockets you can go to the official docs.

Starting your server

Now all you have to do is call mongrel2 on the command line to start it up. Since we may have multiple server on the same database config we must choose which server we will start and we do this passing the uuid of your sever on the command line , like this:

# mongrel2 <config.sqlite> <uuid>

This will start the server with uuid = <uuid>, reading from the config database passed as the first argument. From now on mongrel2 is ready to receive requests. Now it’s time to see how wsgid helps us on running our django app.

wsgid

Now that you know about mongrel2 handlers and all that, you can see wsgid as a generic WSGI handler for mongrel2 applications. With it you can run any WSGI app having mongrel2 as the front-end, and here is how we do it.

Installing Wsgid

You can install wsgid downloading it from the official website: http://wsgid.com. After downloading, extract it to one location of your choice and run:

# python setup.py install

from inside this folder. To check your instalation, you can run:

$ wsgid --version

and you should see the current installed version.

Creating a wsgid app folder

Since wsgid runs your app as a *nix daemon, it needs a special location with some specific folders inside. Let’s call it application folder (app folder). There is where you will put the source-code of you Django app. To create a new app folder you can run:

$ wsgid init --app-path=/path/to/my/app/folder

Wsgid will create this folder if it does not exists and initialize all needed sub folders for you. In this example, let’s use /tmp/myapp. So an initialized folder looks like this:

daltonmatos@jetta /tmp/myapp [13]$ ls
app  logs  pid
daltonmatos@jetta /tmp/myapp [14]$

Deploying you Django app

All our app source-code lives inside the app/ folder. So we just need to cd to /tmp/myapp/app and create our brand new django project:

daltonmatos@jetta /tmp/myapp/app [16]$ django-admin.py startproject myproj
daltonmatos@jetta /tmp/myapp/app [17]$ ls
myproj
daltonmatos@jetta /tmp/myapp/app [18]$

Ok, so this is a common django project. Of course that when deploying your already written django project you will just copy the project folder to this location, it will have the very same effect.

Starting wsgid instance to run your django app

Now it’s time to start wsgid so we can send requests to our app. Remember that two sockets we saw earlier on this post? Remember that the back-end handler is who needs to know where to connetc? Here is how we do it.

Let’s use the same handlers we saw earlier:

• send_spec = tcp://127.0.0.1:5002
• recv_spec = tcp://127.0.0.1:5003

So here is how we pass this to wsgid:

$ wsgid --app-path=/tmp/myapp --recv=tcp://127.0.0.1:5002 --send=tcp://127.0.0.1:5003 --workers=4

Now we have one instance of wsgid running and calling our django app when a new request arrives. You can confirm that wsgid started successfully looking at the logs:

$ tail -f /tmp/myapp/logs/wsgid.log
2011-11-06 18:06:56,115 - wsgid [pid=27900] - INFO - Master process started
2011-11-06 18:06:56,116 - wsgid [pid=27900] - INFO - New wsgid worker created pid=27903
2011-11-06 18:06:56,117 - wsgid [pid=27900] - INFO - New wsgid worker created pid=27904
2011-11-06 18:06:56,118 - wsgid [pid=27900] - INFO - New wsgid worker created pid=27905
2011-11-06 18:06:56,119 - wsgid [pid=27900] - INFO - New wsgid worker created pid=27906
2011-11-06 18:06:56,145 - wsgid [pid=27903] - INFO - Using AppLoader: DjangoAppLoader
2011-11-06 18:06:56,145 - wsgid [pid=27904] - INFO - Using AppLoader: DjangoAppLoader
2011-11-06 18:06:56,150 - wsgid [pid=27905] - INFO - Using AppLoader: DjangoAppLoader
2011-11-06 18:06:56,168 - wsgid [pid=27906] - INFO - Using AppLoader: DjangoAppLoader
2011-11-06 18:06:56,223 - wsgid [pid=27903] - INFO - All set, ready to serve requests...
2011-11-06 18:06:56,228 - wsgid [pid=27904] - INFO - All set, ready to serve requests...
2011-11-06 18:06:56,231 - wsgid [pid=27905] - INFO - All set, ready to serve requests...
2011-11-06 18:06:56,238 - wsgid [pid=27906] - INFO - All set, ready to serve requests...

Wsgid automatically detects what kind of application it is loading and uses the appropriately AppLoader. Considering that you have a localhost registered on your host table, just hit http://localhost in your browser and see your running Django application.

daltonmatos@jetta ~ [2]$ curl -i http://localhost/
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 2051

daltonmatos@jetta ~ [3]$

To know more about wsgid command line options, try wsgid –help.

Using wsgid config  files

You don’t need to call a complete command line, full of arguments every time you want to start a new wsgid instance. You can tell wsgid to create a simple JSON config file inside your app folder. Just add config as the first command line argument:

$ wsgid config --app-path=/tmp/myapp --recv=tcp://127.0.0.1:5002 --send=tcp://127.0.0.1:5003 --workers=4

Wsgid now created a /tmp/myapp/wsgid.json file with all these options:

daltonmatos@jetta /tmp/myapp [41]$ cat wsgid.json
{
  "debug": "False",
  "workers": 4,
  "keep_alive": "True",
  "recv": "tcp://127.0.0.1:5002",
  "send": "tcp://127.0.0.1:5003"
}
daltonmatos@jetta /tmp/myapp [42]$

From now on you can start this same instance just with wsgid –app-path=/tmp/myapp. If you want to change any value inside the config file just re-run the command with the new values and wsgid will update the config file accordingly.

Now if you want to run more instances of you app on different machines (considering that you have a copy of your app there) all you have to do is to access that machine a run:

$ wsgid --app-path=/tmp/myapp --recv=tcp://MONGREL2_IP:5002 --send=tcp://MONGREL2_IP:5003 --workers=4

And you are done! No need to tell mongrel2 about it. Just run this and you will have 4 more processes added to the zeromq round robin load balancing logic.

Wsgid has others usfeul command line options, such as: wsgid reload to reload your app code on the fly, wsgid status to show you the PID number of all your processes and many more. See all of them ad the official docs: http://wsgid.com/docs.

Final words

So what you just saw here is another way to deploy and scale your app. There is nothing brand new here, just a known technique applied with smart tools to make your life a lot easier! I’ve been using this setup for a couple of months now and I can say that I’m absolutely happy with it. I even ran a blitz.io (this is my blitz.io invite link) rush against wsgid.com and mongrel2+wsgid handled all requests pretty well!

So let me know what you think! Give this setup a try and share your thoughts. What can we do the make it even better?

Thanks for reading!

Some time ago, I started writing wsgid. It is a project that brings to you the ability to run any WSGI application with mongrel2 web server. Some time ago I had this idea of writing a web application that could help me test wsgid on a real production environment. Both wsgid’ official website and my personal website are hosted using wsgid and mongrel2 as the backend, but none of them even uses a database (and maybe won’t for a long time) and since they are very simple and low traffic websites, I think they aren’t good enough to test wsgid.

I thought about some type of applications that would be better to test wsgid and end up with the decision to write my own blog engine. This same engine will soon power my own blog, self hosted and managed by me.

Wait, another blog engine? Why?

Yes, it will be a blog engine, another one! =) Before you think about NIH, I will try to explain why I decided to start this project. The very first thing I did when I thought about writing one more blog engine was to find some existing ones. But it could not be any blog engine, they must obey some rules:

• Written in python
• Used a WSGI framework
• Bonus points for engines written in Django

These rules are obvious. If I’m trying to test wsgid (that is a WSGI gateway) the application must be written in Python and be compliant to the WSGI specification. The last one was a bonus point because I’m currently learning Django. I found that are there plenty of Django blog engines, but one decision made me not choose any of them: I want to learn something new, and I think the best way to do this is having a project. And not any one, but one that you will really use. And writing the code of my own blog is a good way to maintain the project alive, evolving and getting better and better.

Another point that helped me on this decision was the willing to self host my applications. This will give me very important knowledge and experience on system administration, servers, deployment, clusters and may more. Recently I had two amazing opportunities to work with these topics and I’m sure that if I were already managing my own infra-structure for a while I could have done much better on these two interviews.

Until the day of witting this blog post, my blog is still hosted on wordpress.com. I  plan to migrate to my own servers as soon as this new project becomes minimally usable. This will be good for many reasons that I already said and one more is that I will be able to have my own domain name and not pay any more money for this, since I already own daltonmatos.com.

Starting a new project is always a great responsibility, first with yourself, second with the people that follow your projects and more important: with who uses your project. So today I decided to start this new project: The blog engine. It has no name yet, the only certainty is that I will create this project and host my own blog. The code will be hosted on github, where I publish all my codes. So if you are intersted follow me there and stay tuned!

Thank you for reading!

Visibility

Sometimes you just want to learn something new, and one of the greatest ways to do this is having a project. You don’t need to have a project that is used by many people. That’s not what measures whether a project is good or not, a project is good when you care about it. More important, a project is really good when you learn something useful during its development.

Other than that, your project can be your showcase, so use it also to show others what you are capable of doing. There are other ways to show yourself to the world, and one of them is be part of the community around someone else’s project. But you can’t just choose a random project, the project must be important to you, either because you are interested or because you use it to solve an important problem. And remember, always give valuable feed backs, don’t just make noise. If you have nothing to say, so just don’t say it.

First, the Projects

I always try to convince who is near me that having side projects are a great idea! I’m always trying  to help my friends with their projects, sending patches, doing pair programming or whatever I can do to help. Until 1 year ago I didn’t have any side project, but not because I didn’t want to, it was just because none of them were such a big deal. And then when I started to study python I saw the first opportunity to have one project. At that time I was deploying a Trac instance and because of this I started to read its source-code. When I realized how amazing Trac’s internal component management was I decided to create my first project, and then plugnplay was born. This project gave me the knowledge about the python language and at this time I already had chosen python as my language of choice.

The idea for the second one came when I found out about another project named mongrel2. Actually I don’t remember how I came across mongrel2, but as soon as I realized that it lacked python support, added the fact that I had just chosen python as my language, I decided to start wsgid. Wsgid provides WSGI support for mongrel2. As I wanted this project to be more presentable I also bought a domain name (wsgid.com) and made an official website (that runs using wsgid itself!). Over time, wsgid earned its place on mongrel2 official site, where it shows all supported languages. This was, with no doubt, a big move for the project and gave me even more motivation to move further.

The first contact, Google

So there I was, developing my projects as always when suddenly I see in my inbox an email from a @google.com address. At that exact moment I thought: “Ok, Gmail spam filter has failed. Let me mark this and go on with my life.” But then I decided to just do a little research about that message. I looked at the original communication between the smtp servers, and all that seemed real. The email talked about my contributions to the open source community and my blog, and the recruiter was asking if I was interested in a full-time opportunity at Google.

So I decided to reply to that message and two things could happen. Or I would be eternally without response, and then I would confirm that it was spam. Or I would receive another response and realize that is was real! And that’s what happened. I was absolutely happy and proud to know that Google was offering me the opportunity to be part of its hiring process.

This was January this year, and then I started chatting with the recruiter. I had two phone calls. The first was not technical, was just to know a bit more about me, my background, my time in college, my current work and some other things. After this we scheduled the first technical interview. I, obviously, was very nervous before and during the interviews, mainly because all them was made in English, that is not my mother language.

The second phone call (first technical) was ~20min chat with general questions about system administration, network, etc. I tried my best, considering the poor call audio quality. I had to ask the interviewer to repeat several times, some of them he didn’t. Some weeks later I received another call telling me that we were not moving forward with the process, and so my chances with Google were finished.

The second, Facebook

Some weeks ago, around end August, it happened again. And this time was from a Facebook recruiter. Same story, and this time they saw my blog and since one of my projects was server related (wsgid), they contacted me about a full-time sysops position. This time the domain of the sender was unusual to me, it was @fb.com. But a simple DNS query was able to show me that fb.com was in fact controlled by facebook. This made me feel more confident about all that story.

And, again, I decided to accept the challenge. So I started chatting with the recruiter and on the next week I was already with a scheduled phone interview. This first interview was an elimitaory one, just to know if they would continue with the process or stop right there. Again, the audio quality of the call was awful, but different from Google interview, every time I asked the person to repeat the question I was attended. This first call was very quick (~20min) and some of the questions were about protocols, command line tools and system administration in general. I answered right almost all the questions, and then the interviewer finished the call with a compliment. Saying that I was pretty good at Linux. =)

The next week was time for another phone call, this time a non-technical one. The recruiter just wanted to give me valuable tips about the overall process and specifically about the interview that was to come, the first really technical one. And the day has come, I already knew that the interview would be a ~45min call with 2 or 3 problems to be solved. They used collabedit.com to see the code I was writing.

During the one week I had to prepare myself, I studied algorithms, data structures, grabbed some problems from programming competitions and solved them. As I was focused on algorithms, during the interview I got stuck trying to solve the problem with an algorithm written in python. The position was to sysops, that is, heavy linux server users with great command line powers. Even though I simply didn’t try to use bash during the call. After almost 20 min trying to solve this with python code, the call was finished by one of the interviewers and he said that soon they would contact me again. As soon as I hang up the phone, a one-line bash solution came into my mind!

What I learned about all this?

Even not being selected on both opportunities, something good comes out of it. When all this ended and I started to think about it, I realized that my simple projects, started mainly to learn something new, went beyond all my expectations! All my projects are published on my personal website: daltonmatos.com. What all this taught me is that is all the effort put on my own projects, the contributions I made to other projects, all these worth it!

I also realized that big companies are always looking for good developers out there and one of these could be you, the same way these two times it was me.

So what can you do about this?

What I would like you to understand is that whenever you have some code that solves a specific problem for you, publish it! You can be sure that this your solution can be useful for many others. I already saw some friends not publishing their code because of many weird reasons, from “the code is still too bad, let me evolve it a bit” to “This is a super-secret project, somebody will end up stealing my super-coll idea”. If you also think like this, I hope that the story I just told you changes your mind, at least a little bit!

So go start your projects or publish an already written one!

Hoje é um dia muito importante. Finalmente depois de muito tempo consegui lançar meu próprio site. Já tinha comprado o domínio há bastante tempo mas não tinha ainda parado pra escrever os textos e o código do site.

O site é uma aplicação django e roda com o auxílio de um projeo meu já citado aqui no blog, o wsgid. Por enquanto o blog continua aqui no wordpress.com mas pretendo migrá-lo pra lá, pois assim terei tudo centralizado. Ainda tenho que encontrar uma blog engine para que possa migrar o blog.

Bem, é isso aí! Vai lá e dá uma olhada: http://daltonmatos.com

Recentemente comprei um novo  notebook e por isso tive a oportunidade de instalar um novo S.O do zero, afinal já estava com uma mesma instalação desde 2008 (quando comprei meu primeiro notebook). Até poderia transferir uma instalação de um notebook para o outro, mas daria um trabalho parecido (ou maior) do que instalar novamente.

Nesse momento surgiu a mesma dúvida de sempre: Instalar a versão 64 bits ou 32 bits? Em 2008 tentei instalar uma versão totalmente 64 bits e tive problemas com plugin do flash, cheguei a ter um firefox 32 bits só para poder ver vídeos usando flash. Pouco tempo depois desisti do sistema 64 bits por esses e outros motivos e acabei instalando 32 bits mesmo.

Dessa vez a mesma dúvida. Achei que 3 anos depois as coisas estariam melhores, mas já de cara tive problemas com o driver de vídeo. A tela simplesmente não dava refresh corretamente. Um ls no terminal não retornava nenhum resultado, a não ser que a janela do terminal fosse movida de lugar, aí sim acontecia o refresh e o resultado do ls (já executado) aparecia. Isso significa que estava simplesmente impossível de usar o sistema.

Percebi que no live-DVD que estava usando, o driver de vídeo funcionava perfeitamente, então comecei a estudar o que o sistema do live-DVD tinha de diferente. Percebi que ele era userland 32 bits, apesar de reconhecer os 4GB do novo notebook. Nesse momento tive a idéia de tentar uma instalação mista: Kernel 64 bits e userland 32 bits.

Crosscompiling

O termo crosscompiling é usado quando temos um compilador rodando em um sistema e gerando código para outro. Por exemplo, você tem um notebook (intel x86) e consegue compilar um código em C que roda no seu celular (processador ARM, por exemplo). Mas o crosscompiling não serve apenas para gerar código entre máquinas diferentes, pode ser usado também para gerar código para a mesma máquinas, apenas escolhendo se o resultado será um binário de 32 bits ou 64 bits.

Foi exatamente isso que fiz nesse caso. Para fazer o que estava querendo precisava ter dois compiladores. Primeiro usei o gcc que é instalado no gentoo para compilar um outro gcc, esse último gerando código 64 bits. Ou seja, tenho agora um compilador que roda em um ambiente 32 bits mas que gera código 64 bits. E esse compilador foi gerado por um outro compilador que roda em 32 bits e também gera código 32 bits, entendeu? Ainda comigo? Ok, vamos lá.

Toda a mágica desse processo é feita pelo pacote sys-devel/crossdev, que faz parte da árvore principal do Gentoo. O que esse script faz é construir todo o toolkit necessário para gerar o cross compiler que precisamos. O que precisamos fazer é muito simples:

# emerge crosdevv
# crossdev -t x86_64-pc-linux-gnu

E isso é suficiente. Quando vi que realmente funcionava lembrei de 2004, quando ainda estava usando slackware e tive que fazer isso “na unha“. Cheguei até a postar no twitter um agradecimento a quem quer que tenha escrito esse script. Merecido!

Compilando o novo kernel

Agora, com tudo pronto, temos dois compiladores: O que gera código 32 bits, que podemos chamar apenas digitando gcc, e o que gera código 64 bits que podemos chamar com o comando x86_64-pc-linux-gnu-gcc. O que temos que fazer agora é configurar nosso kernel para que use o compilador correto. Felizmente alguém já precisou fazer o que estou fazendo e existe uma maneira fácil de escolher o compilador que vai gerar nosso kernel.

Escolhendo compilador customizado para nosso kernel

Para isso basta irmos ao menu General setup/ e escolher o valor correto para a opção Cross-compiler tool prefix. Isso fará com que nosso novo compilador seja usado no momento de compilar nosso kernel. Agora o que temos que fazer é compilar nosso kernel como fazemos normalmente, o de sempre:

# make
# make modules
# make modules_install

Agora é só copiar nosso novo 64 bit kernel para o lugar certo, adicionar uma nova entrada no boot loader e bootar nosso novo kernel. E isso é o que temos depois de um boot com sucesso:

Kernel 64 bits com userland 32 bits

Exatamente o que queríamos:

• Kernel 64 bits (X86_64)
• Userland 32 bits (todos os binários são ELF 32-bit)
• Os 4 GB RAM corretamente sendo usados

Um ponto negativo da abordagem que vou apresentar é que fica praticamente impossível recuperar seu laptop com programas como preyproject. A idéia nesse caso é proteger seus dados, não o aparelho. Esse último, bem ou mal, pode-se juntar dinheiro (mesmo que por muito tempo) e comprar outro, mas seus dados pessoais em mãos erradas, pode ser fatal. Lembrem-se sempre de manter seus backups atualizados. Bem, chega de papo e vamos ao que interessa.

Preparando as partições

Antes de começar a instalação, precisamos particionar nosso disco de forma correta. Repare que o que teremos encriptado será somente a partição raiz onde o S.O estará inslatado, tudo bem que isso corresponderá a quase 100% do disco, mas precisamos dexar claro que uma pequena parte do disco permanecerá sem encriptação, e você entenderá porque mais a frente.

Essas são as partções originais do notebook onde fiz essa instalação:

Particoes originais

Preciasmos, basciamente, criar duas partições:

• Uma onde guardaremos as imagens dos kernels que vamos usar (/boot, 256MB)
• Outra contendo o restande do disco, onde o S.O estará instalado

O motivo pelo qual temos que ter essa partição não encriptada é que nosso boot loader (grub) não é capaz de ler uma partição que esteja encriptada, se isso fosse possível poderíamos encriptar 100% do disco, inclusive a partição onde estão os kernels. Feito isso, nosso disco agora tem apenas duas partições:

Novas particoes criadas

Encriptando a partição principal

Agora o que precisamos fazer é efetivamente encriptar a partição onde vamos instalar o gentoo, para isso usaremos o cryptsetup:

Formatando com cryptsetup luksformat

Agora temos que fazer com que essa partição encriptada fique disponível como um block device.

Destravando crypt root

A partir desse momento já poderíamos formatar esse block device (mke2fs -j), mas como vamos usar LVM2 em cima da encriptação, precisamos fazer mais algumas coisas antes de começar a instalação. O comando acima cria um block device em /dev/mapper/crypt-root.

Configurando o LVM2

Agora que já temos toda a partição encripada é hora de configurar o LVM2. Vamos criar apenas um volume físico (physical volume) que ocupará toda a partição que acabamos de encriptar. Depois criaremos um Volume Group e dois Logical Volumes.

Criando volumes lvm2

Agora é hora de formatar os volumes que acabamos de criar:

Formatando volume lógico que será a partição raiz do S.O

Formatando o volume lógico que será o /home

Agora que temos dois volumes prontos, podemos começar a instalar o gentoo. Basta montar o block device /dev/vg01/root em /mnt/gentoo (como recomenda o gentoo handbook) e podemos continuar a partir do passo 5.

Configurando o kernel

No momento de configurar o kernel (handbook, passo 7) que usaremos, precisamos adicionar opções especiais para que tudo dê certo. Basicamente essas opções são:

• Suporte a Device mapper, com suporte a encripatação
• Suporte ao algoritmo de encriptação usado

Kernel option: device mapper

Kernel Option: Algoritmo de encriptação

Kernel Option: Sha 256 support

Essa última opção só foi necessária pois usamos –cipher twofish-cbc-essiv:sha256 no momento de encriptar a partição /dev/sda2.

Para podermos compilar esse kernel, o melhor é usarmos o utilitário genkernel. Basta instalar usando emerge normal. Antes de efetivamente compilar esse kernel, precisamos instalar dois pacotes. Atenção para as USE flags específicas de cada um deles:

• sys-fs/lvm2 USE: +static
• sys-fs/cryptsetup USE: +static-libs

Isso é necessário pois o ramdisk que será criado daqui a pouco precisará deles. O genkernel é uma mão na roda e é quem fará o trabalho duro de adicionar suporte para que seja possível bootar esse sistema com do disco encriptado. Como o genkernel já salva automaticamente os arquivos em /boot, temos que montar nossa partição (aquela que não é encriptada) no lugar certo:

# mount /dev/sda1 /boot

Agora poderemos usar o genkernel para preparar tudo:

# genkernel --menuconfig --luks --lvm all

Isso vai fazer com que o menu de configuração do kernel seja chamado (onde teremos que adicionar as opções citadas acima) e depois que salvarmos a configuração já começará a compilar nosso novo kernel. No final da compilação, teremos em /boot dois arquivos: O kernel e o initramfs criados pelo genkernel.

Configurando o boot loader

Nesse momento, o que falta é configurar o boot loader, nesse caso o Grub.

# emerge grub
# grub
grub> root (hd0,0)
gurb> setup (hd0)
quit

Repare que estamos instalando o grub no MBR, isso é válido pois nesse caso temos apenas um S.O instalado. Se estivéssemos fazendo dual-boot e já tivéssemos um outro S.O rodando, teríamos que instalar o grub na partição sda1, nesse caso em (hd0,0).

Como estamos preparando um sistema e um kernel especiais, precisamos passar opções especiais para o Grub, só assim ele poderá carregar nosso novo S.O. As linhas do /boot/grub/menu.lst ficam assim:

title Gentoo Linux 2.6.38-gentoo-r6
root (hd0,0)
kernel /boot/kernel-genkernel-x86_64-2.6.38-gentoo-r6 dolvm root=/dev/ram0 crypt_root=/dev/sda2 real_root=/dev/vg01/root
initrd /boot/initramfs-genkernel-x86_64-2.6.38-gentoo-r6

Ajustando o /etc/fstab

O último passo é ajustar o arquivo /etc/fstab para que as partições corretas sejam montadas. Temos que adicionar o /boot e o /, ficando assim:

Como fica o /etc/fstab

Nesse arquivo temos o /home, que no meu caso foi necessário pois sempre deixo a home separada. Não esqueça de retirar a linha do SWAP, pois não criamos uma.

Agora é dar reboot e curtir o novo sistema com os dados totalmente encriptados. Como estamos usando LVM2, qualquer partição adicional que você criar no futuro, já estará encriptada.

Considerações finais

É bem verdade que pelo fato de ter seu disco encriptado você terá uma perda de performance. Eu sei disso. A questão é que já uso essa configuração há 3 anos (usei desde o primeiro notebook) e como nunca tive um notebook sem ter o disco encriptado acabo não sabendo qual é a real perda de performance.

Usei o primeiro notebook durante todo o tempo, sem achar que ele estava lento por qualquer motivo. O notebook novo já é naturalmente mais rápido (Processador melhor, disco melhor, etc) então mesmo tendo novamente o disco encriptado, já percebi uma melhoria considerável na performance do novo aparelho. Então, diante disso, tá tudo bem! =)

O interesse por software de código aberto

Desde muito tempo tive interesse no desenvolvimento de software, especialmente em softwares de código aberto. Um interesse especial é o fato de você ter a oportunidade de ver códigos escritos por outras pessoas. Ler código de outras pessoas nos faz aprender muito, pois vemos abordagens diferentes para um mesmo problema e podemos aprender hacks que não fazíamos idéia que seriam possíveis.

Sempre publiquei meus códigos para quem quisesse ver e defendo a idéia de que as pessoas deveriam também sempre publicar seus códigos. A unica situação em que faz sentido não publicar algum código é quando esse código é crucial para um negócio qualquer. Nesse caso não faz sentido entregar o ouro, claro.

Primeiras contribuições

O primeiro passo para ter seu projeto de código aberto é fazer parte de algum outro projeto. Fazendo isso você pode ter contato com outros desenvolvedores, aprender como funciona o projeto especificamente, como é o processo para que você possa contribuir, além de ganhar experiência para que um dia possa tocar seu próprio projeto de código aberto.

Minha participação em projetos de código aberto teve início quando comecei a estudar python, há pouco mais de um ano atrás.  Antes de escrever código em python, lia bastante sobre a linguagem. Aprendi lendo o próprio site da linguagem e sempre que tinha alguma dúvida específica sobre alguma sintaxe, ia direto ler a gramática. Acho essa forma mais eficiente do que ler hello worlds por aí.

Em uma dessas pesquisas, estava tentando encontrar um framework web que fosse bem simples de entender, afinal eu estava começando a estudar a linguagem. Apesar de já ter experiência com sistemas web, conhecer sobre HTTP, requisições e etc. Web + python era, naquela época, algo novo.

Foi então que encontrei um framework chamado pyroutes. Pois bem, desde o início gostei da implementação pois ela faz uso dos decorators, que é uma coisa que acho fantástica na linguagem. Então comecei a estudar o código desse projeto, fiz meu fork no github e comecei a enviar pull requests. Comecei simples, apenas corrigindo erros triviais nos testes automatizados: 2d921fa91 e 22a3211. Pouco depois, já estava corrigindo bugs e fazendo implementações menos triviais: 44d1708.

O que ganhei com tudo isso? Bastante experiência! Contato com pessoas de outras nacionalidades, conhecimento na linguagem que estava aprendendo e o mais importante: A oportunidade de outras pessoas me conhecerem e saberem das minhas habilidades e conhecimentos. Nesse projeto especificamente ganhei outra coisa também muito impotante: permissão de commit no repositório oficial!

A hora de começar meu próprio projeto

Depois de ter colaborado por algum tempo com esse projeto decidi que tinha chegado a hora de tentar uma nova empreitada: Tocar meu próprio projeto de código aberto. A idéia desse projeto apareceu ainda quando estava estudando sobre a linguagem. Como já disse aqui, acho muito importante ler código de outras pessoas e foi lendo o código do Trac que tive a idéia para o meu primeiro projeto: plugnplay.

O desenvolvimento desse projeto foi bem legal, foi meu primeiro código publicado que realmente tinha chance de ser útil para alguém além de mim, e isso é fantástico. Foi desenvolvido em apenas uma semana (de acordo com o histórico de commits).

O projeto é bem pequeno e fiquei bem feliz quando vi que ele já tinha 3 watchers!

O Segundo projeto

É claro que não parei por aí! Continuei com minhas pesquisas até que surgiu a idéia para o segundo projeto: wsgid. Essa idéia surgiu quando me deparei com um outro projeto: mongrel2. O objetivo do wsgid é me ajudar a ter uma infra-estrutura totalmente automatizada para fazer o deploy de minhas aplicações, e esse é o primeiro passo para que consiga chegar a esse objetivo.

Ao contráio do plugnplay, para esse projeto fiz um website, uma documentação completa e até comprei o domínio (wsgid.com), ou seja, coisa séria! =) E isso se mostrou muito importante. Querendo ou não, um projeto que apresenta um site oficial e uma documentação completa de suas funcionalidades atrai muito mais a atenção das pessoas, pois passa uma credibilidade maior. Uma coisa interessante é que o site oficial do wsgid roda usando o próprio wsgid!

A questão da documentação é especialmente importante pois temos que lembrar que nem todo mundo (mesmo desenvolvedores) terá curiosidade suficiente para ler o código-fonte para poder aprender a usar seu projeto, então ter uma forma fácil de começar a usar o projeto se mostra muito importante.

Visibilidade do projeto

O projeto wsgid teve uma visibilidade muito maior do que o plugnplay, e acho que isso se deve a alguns fatores. Em primeiro lugar ele é um projeto satélite de um projeto grande, o mongrel2. Só isso já te dá mais visibilidade. Outra coisa é que como eu estava participando da lista de desenvolvimento do mongrel2, mandei emails para essa lista divulgando o projeto e recebi feedbacks importantes. O fato da URL do site oficial estar na assinatura de todos os meus emails também ajuda. Novamente, isso só é possível pois o projeto possui um website.

Durante o desenvolvimento do projeto (até hoje, na verdade) ainda recebo notificações por email quando o projeto ganha mais um watcher em seu repositório. Hoje o projeto está com 13 watchers, o que é fantástico! Esse tipo de coisa te dá mais gás para continuar escrevendo o código, pois você vê que existem pessoas que acharam seu projeto interessante a ponto de decidirem acompanhar sua evolução. E isso é muito bom! Outra coisa ainda melhor é o número de forks que o projeto recebeu, até agora já são 5 em 6 meses de projeto.

Novamente, durante o desenvolvimento desse projeto tive a oportunidade de me comunicar com outras pessoas. Como já disse, entrei para a lista de desenvolveores do projeto mongrel2 e novamente comecei a submeter patches com pequenas correções. Depois, quando já estava com um domínio maior sobre o código já comecei a enviar códigos menos triviais, participei de várias discussões na lista até que, novamente, ganhei permissões de commit no repositório oficial. Essa é a lista de commits que fiz no repositório oficial, até o momento.

Conclusão

Minha conclusão disso tudo é que é muito divertido contribuir com algum projeto, melhor ainda é ter seus próprios e receber contribuições de outras pessoas  (já recebi um patch para o wsgid). Ter um side-project te dá mais conhecimento, faz com que as pessoas possam te conhecer (e isso é muito importante!) e te permite aprimorar suas habilidades.

Se você ainda não posui um projeto, comece um! Os dois que tenho surgiram para resolver problemas que eu tinha no dia-a-dia, tenho certeza que você também já viveu situações onde um programa poderia te ajudar ou até mesmo resolver seu problema. Pense que outras pessoas certamente já tiveram o mesmo problema e também poderiam ser ajudadas pelo seu projeto.

Quase sempre quando pensamos em aplicações web (eu inclusive), pensamos na apache stack. Esse post apresenta uma forma diferente de fazer o deploy de sua aplicação, começando pelo fato de usarmos o servidor web apache.

Primeiro de tudo, precisamos conhecer uma peça chave diso tudo:

Mongrel2

Mongrel2 é um servidor web escrito por Zed A. Shaw. Esse é um servidor que simplismente não se importa em que linguagem sua aplicação foi escrita, tudo que você precisa fazer é seguir algumas regras bem simples para conseguir juntar mongrel2 e sua aplicação.

A primeira regra é que sua aplicação precisa saber se comunicar através de uma fila, nesse caso ØMQ (http://zeromq.org) e a segunda regra é que sua aplicação precisa entender o protocolo definido pelo mongrel2. Você pode (e deve!) saber mais sobre o mongrel2 no site oficial: http://mongrel2.org.

A grande sacada do mongrel2 é que, o fato dele usar uma fila para se comunicar com sua aplicação faz com que sua aplicação possa rodar de forma desacoplada do servidor, isso significa que sua aplicação não roda com a ajuda de um mod_algumacoisa ou como um processo filho do servidor web. Uma outra vantagem é que o ØMQ permite enviar mensagem por TCP, isso significa que sua aplicação pode estar rodando em uma máquina diferente de onde o mongrel2 está rodando.

Poder rodar sua aplicação em máquinas diferentes é fantástico pois sempre que necessário você pode adicionar mais uma máquina ao seu cluster e startar mais instâncias da sua apliação, todas as instâncias vão se comunicar com o mesmo mongrel2, que vai balancear as requisições entre todas as instâncias conectadas, usando uma politica round-robin.

wsgid

wsgid é o projeto que desenvolvi para tornar possível rodar suas aplicações WSGI usando como servidor web o mongrel2. O wsgid é a ponte entre o mongrel2 e a especificação WSGI (PEP-333), isso significa que basta a sua aplicação obedecer à especificação WSGI para já estar pronta para rodar com o mongrel2.

O wsgid entende tanto a língua do mongrel2 (zeromq + protocolo) quanto a especificação WSGI. Além disso, sua aplicação agora é um processo separado, com PID e tudo mais. Isso te traz algumas vantagens, como:

• Pode rodar com permissões de qualquer usuário, a sua escolha;
• Por ser um processo do sistema operacional, está automaticamente sujeito a quaisquer configurações que o S.O possa oferecer, como por exemplo: limite de banda, memória, CPU e etc;
• Pode ser rodado dentro de um chroot, caso você precise rodar código não confiável;
• Entre outras.

Iniciar uma nova instância de sua aplicação é tão fácil quanto:

   $ wsgid --app-path=/path/to/wsgid-app-folder/ --recv=tcp://127.0.0.1:8888 --send=tcp://127.0.0.1:8889
      --workers=4

Nesse exemplo simples estamos conectando ao endpoint 0MQ que está na mesma máquna em que nossa aplicação, mas nada impede de usarmos –recv=tcp://129.168.0.2:8888, sendo esse IP o de uma máquina qualquer em seu cluster. Ainda nesse exemplo a opção –workers=4 cria 4 processos que vão ser responsáveis por atender requisições de sua aplicação.

wsgid, principais funcionalidades

Além de facilitar o deploy de aplicações WSGI com o mongrel2, o wsgid possui ainda outras funcionalidades importantes:

workers

Com a opção workers você pode iniciar quantos processos desejar, de uma só vez. Isso significa que você não precisa rodar o comando 4 vezes caso queira 4 instâncias, apesar de você poder fazer isso, sem problema nenhum. Mas essa opção te dá a possibilidade de fazer –workers=4, que te dará o mesmo resultado.

keep alive

Com a opção keep-alive o wsgid reinicia automaticamente qualquer processo que tenha terminado sua execução. Isso significa que uma chamada ao wsgid com –workers=4 –keep-alive manterá sempre 4 workers trabalhando para sua aplicação.

hot deploy

Sempre que o wsgid restarta um dos processos, o código de sua aplicação é recarregado, afinal é um novo processo que está sendo criado. Isso significa que você pode atualizar o código-fonte de sua aplicação e apenas mandar um SIGTERM para todos os seus workers, isso fará com que o wsgid restarte cada um deles, mas dessa vez já rodando o novo código-fonte.

chroot

O wsgid já pode, automaticamente, fazer o chroot para uma localidade onde a aplicação está. Isso faz com que essa aplicação possa rodar de forma isolada, criando assim um ambiente um pouco mais seguro (não totalmente) caso você esteja rodando códigos não confiáveis.

Sistema plugável para carregar diferentes aplicações

O wsgid conta com um sistema de plugins muito simples porém bem poderoso. Com ele você pode escrever seu próprio Application Loader, caso o wsgid não consiga carregar sua aplicação. Com isso será muito simples adicionar suporte a outros frameworks WSGI para que mais aplicações possam fazer uso desse projeto.

Espero que tenha gostado do projeto, qualquer feedback é bem vindo. Para saber mais sobre o projeto visite o site oficial: http://wsgid.com e saiba mais.

Mas lembre-se, use o que for melhor para você, use o que te atende melhor. Não estou dizendo que a solução mongrel2+wsgid é a melhor sempre, estou apenas dizendo que essa combinação é fantástica, e deve ser considerada no momento de publicar uma nova aplicação WSGI.

Apenas por curiosidade, o site wsgid.com é uma aplicação django e está rodado usando o próprio wsgid.

Running your WSGI app as a *nix daemon

Almost every time we think about web apps (at least me) we think about the apache stack. This post will show you a different method to deploy your aps, starting by not using apache as the web server.

First of all, we need to know a key piece of all this:

Mongrel2

Mongrel2 is a webserver written by Zed A. Shaw. The server is language agnostic, which means that it just doesn’t care which language you wrote you app, all you have to do is follow some very simple rules and you will be able to plug mongrel2 and your app together.

The first rule is that your app must know how to communicate through a queue, in this case ØMQ (http://zeromq.org) and the second one is that you must follow the very simple protocol specified by mongrel2. You can (and must!) know more about mongre2 on the official website: http://mongrel2.org.

The key feature of mongrel2 is that, that fact of using a queue to communicate with the applications makes it possible to run the apps decoupled from the server, this means that your app doesn’t run with a mod_something or as a child process of the webserver. Another advantage is that ØMQ allows you to communicate over TCP, that’s how you can run your app on a machine other than where mongrel2 is running.

The ability to run your app this way, that is, on different machines is fantastic, because whenever needed you can add a new node to your cluster and start new instances of your app. All these instances will connect to the same mongrel2, and the requests will be load-balanced among all instances in a round-robin policy.

wsgid

wsgid is a project I developed to make possible to run your WSGI apps with mongrel2 webserver. wsgid is the brifge between mongrel2 and the WSGI specification (PEP-333), this means that just by conforming with the WSGI spec your app is ready to run with mongrel2+wsgid.

wsgid talks both mongrel2 and WSGI, also from now on your app will be a separated process, with it’s own PID and everything a process has. This brings you some advantages:

• Can run as any user on your operating system;
• As being a O.S process, is automatically submitted to all characteristcs and O.S process has, eg: bandwith limit, memory limits, CPU scheduling, etc;
• Can run inside a chroot, in caso you are running untrusted code;
• Many others.

Start new instances of your app is as easy as:

   $ wsgid --app-path=/path/to/wsgid-app-folder/ --recv=tcp://127.0.0.1:8888 --send=tcp://127.0.0.1:8889
      --workers=4

I this very simple example we are connecting to a ØMQ endponit in same machine that the app will be running, but nothing prevents us from using –recv=tcp://192.168.0.2:8888, being this IP the address of another node on the cluster. Still in this example, the option –worker=4 starts 4 processes that will respond to requests for your app.

wsgid, key features

Besides facilitating the deployment of WSGI applications with mongrel2, wsgid also has other important features:

workers

With this option you will be able to start any number of processes you want at once. That means you don’t need to run the same wsgid command 4 times if you want four instances, although you can do this without any problem. But this option gives you the possibility to do –workers=4, which gives you the same result.

keep alive

With the keep-alive option wsgid automatically restarts any process which has finished its execution. This means that with a call to wsgid with –workers=4 –keep-alive, wsgid will always keep 4 processes working for your application.

hot deploy

Whenever wsgid re-starts one of the processes, the code of your application is reloaded, after all is a new process being created. That means you can update the source code of your application and just SIGTERM all its workers, it will make  wsgid restart all workers, but this time already running the new source code.

chroot

wsgid can chroot to the location where the application is. This makes such application run in isolated, thus creating an environment a little safer (not entirely) if you are running untrusted code.

Plugable system for Application Loading

wsgid has a very simple but very powerful plugin sub-system . With it you can write your own application loader, in case wsgid is not able to load your WSGI app. With such a sub-system, it will be very simple to add support for other WSGI frameworks so that more applications can make use of this project.

That’s it! Hope you enjoyed the project, any feedback is more than welcome. To learn more about the project visit the official website: http://wsgid.com.

But remember, use what works best for you, use what best serves you. I’m not saying that the solution mongrel2+wsgid is the best ever, I’m just saying that this combination is fantastic and should be considered whenever you are thinking of publishing a new WSGI application.

Just out of curiosity, the wsgid.com website is a django application and runs with wsgid.

Muitas vezes nos deparamos com a desagradável situação em que precisamos acessar um site qualquer mas em vez disso recebemos uma página dizendo que não podemos prosseguir. Pois então, sabemos que esse tipo de bloqueio nem sempre é eficiente, muito menos quando é mal executado (o que geralmente acontece!) =)

A idéia de escrever esse post veio depois que li uma mensagem de um amigo:  http://twitter.com/#!/fjleite/status/9923497178435584. Achei que essa dica serviria para muitas outras pessoas, que estão na mesma situação.

A técnica é muito simples e, na verdade, é a mesma técnica usada em um post anterior, mas agora o propósito é outro. Naquele caso era apenas para manter uma conexão aberta, já que o servidor não destruia conexões já estabelecidas no momento em que seu cartão de internet expirava. Nesse caso, usaremos a técnica para tunelar todo o tráfego que entra/sai de nosso computador.

Antes de continuar, pense um pouco

Só escrevi esse post pois acho que esse tipo de bloqueio é totalmente idiota e ineficiente! É muito ingênuo pensar que um funcionário vai trabalhar mais porque não consegue acessar determinados sites na internet. Se o cara não quer trabalhar ele vai fazer isso independente de poder ou não acessar livremente a rede.

Não que eu esteja querendo que todos fiquem acessando sites durante o expediente, não é isso. Apenas acredito que cada um deve saber qual é seu limite e deve ter bom senso ao acessar conteúdos não relacionado ao trabalho do dia-a-dia.

Portanto se você for usar essa téncnica, use-a com moderação. Pode seguir!

Detectando uma rede vulnerável

É muito fácil saber se essa técnica vai funcionar ou não na rede em que estamos, para saber disso basta abrir um terminal e tentar acessar qualquer servidor ssh fora de sua rede.

usuario@maquina ~: ssh servidor-externo

Se aparecer o promtp pedindo sua senha, você está na vantagem! Poderá acessar o que quiser em muito pouco tempo. =)

Executando a técnica

Para que tudo comece a funcionar basta passar um parametro especial para o seu cliente ssh, que é o -D <porta>. Onde <porta> deve ser uma porta que não está sendo usada em seu computador.

usuario@maquina ~: ssh -D 9999 servidor-externo

Após isso, apenas entre com sua senha, certifique-se que o login no servidor remoto foi feito com sucesso e deixe esse terminal aberto.

Agora é hora de mexer nas configurações do seu browser. Precisamos apenas configurá-lo para usar um servidor Proxy Socks5 para todos os acessos a sites da web. Qualquer browser moderno é capaz de fazer isso e aqui darei o exemplo usando o Firefox.

Vá em Preferências (geralmente no menu Editar/Preferências), acesse a aba Avançado e depois aba Rede.

Tela de Preferências do Firefox

Depois clique em Configurar conexão e preencha as informações para que o FF use o Proxy Socks5 para acessar os sites.

Firefox configurado para usar Proxy Socks5

Apenas clique OK e curta sua navegação sem limites. Percebeu que o servidor proxy é sua própria máquina (127.0.0.1)? Pois é, explico isso logo abaixo.

Como tudo funciona

O que fazemos é uma coisa muito simples. Na verdade não fazemos muita coisa, quem faz é o cliente ssh! E o que ele faz é o seguinte:

Ele abre um túnel entre nossa máquina e o servidor remoto, na porta que escolhemos. Mas um detalhe importante é que do lado de lá existe um servidor proxy socks5 esperando nossas conexões. Isso significa que sempre que acessamos um site na internet usando esse túnel, na visão do site, quem fez o acesso foi o servidor remoto e não nossa máquina, onde o site está sendo exibido.

Esse detalhe pode ser útil em outras situações como por exemplo quando estamos baixando arquivos de sites que só permitem um download de cada vez. Nesse caso podemos abrir um proxy para um servidor externo e baixar o arquivo normalmente, pois na visão do site de download o acesso está sendo feito a partir do servidor remoto e não de nossa máquina. Então acabamos conseguindo baixar dois arquivos: Um acessando diretamente de nosso computador e outro fazendo o acesso pelo proxy socks5.

Um double bônus é que todo o tráfego entre nossa máquina e o servidor remoto está encriptado, ou seja, nem se o administrador da rede tiver monitorando os pacotes ele vai conseguir ver alguma coisa. O máximo que ele verá serão pacotes ssh passando pra lá e pra cá.

Lembre-se que essa situação será sempre uma corrida entre gato e rato. Você descobre uma falha, alguém que não quer que você explore essa falha descobre que você sabe do problema e corrige a falha. Esse mesmo alguém fica na vantagem até você descobrir outra falha e aí começa tudo outra vez.