Mongodb. NoSQL data bases replication.

(versión español)

The subject that concerns us today is MongoDB. It is a NoSQL database that is based on a model document oriented.
Today we’ll explain how to install it and how to enable replication of data across multiple servers.

Mongodb installation.

Although each distribution has its own packages ready to be installed with the appropriate package manager, it is best to install the packages from 10gen, which are MongoDB developers.

Installing on Ubuntu.

To import the 10gen GPG public key, run the following:
$ sudo apt-key adv –keyserver –recv 7F0CEB10

Create the /etc/apt/sources.list.d/10gen.list file and include the following line to the 10gen repository.
:$ deb dist 10gen

Upgrade the repository with:
$: sudo apt-get update

And install the package:
:$ sudo apt-get install mongodb-10gen

You can start the daemon with the command:
:$ service mongodb start

Installing on Cenos.

Create the /etc/yum.repos.d/10gen.repo file. To store information about the repository, add the following lines:
name=10gen Repository

If your operating system is 64-bit, add these lines:
name=10gen Repository

To install MongoDB, run this command:
:$ yum install mongo-10gen mongo-10gen-server

You can start the daemon with the command:
:$ service mongodb start

Configuring replication.

The configuration file of Mongodb is in the path /etc/mongodb.conf (in Ubuntu) or /etc/ mongod.conf (in Centos).

In this practical example, we will implement a replication system of three Mongodb servers using the method «Replica set». This method consists of an asynchronous type of «master/slave» replication, which allows automatic failover and recovery of member nodes in the system.

Servidor 1:

Servidor 2

Servidor 3

Edit the /etc/mongodb.conf (Ubuntu) or /etc/mongod.conf (Centos), and change or add the following lines to make it like this:

port = 27017
bind_ip =
fork = true
replSet = rs0

To add a bit of security, you can force MongoDB to listen in an specific interface, and not in all (as the default). To do this add to the configuration file the following line:

bind_ip =
In this directive put the ip of the network interface for which you want to listen to the MongoDB daemon.

Restart MongoDB in each of the servers.

Now go to the «» server and run this command:
:$ mongo

With this command you enter MongoDB console. Now we have to start replication with the following command:
MongoDB shell version: 2.2.0
connecting to: test
> rs.initiate();

At this time «mongo_server1» is the primary server.

Then add the other 2 servers:
MongoDB shell version: 2.2.0
connecting to: test
> rs.add(«»);
> rs.add(«»);

You can check the status of data replication system with rs.status() command.

For production environments with a replica set of 2 members, which is not recommended, or with an even number of them, you must create an arbiter.

Arbiters are mongod instances that do not receive a copy of the data. They are only participating in the elections, when the primary server goes down, to choose a new primary.

An arbiter do not manage copies of data, so it does not need a lot of resources and require no additional hardware. So you can install the arbiter on any other server you want, but never in the primary or the secondary.
To create an arbiter, connect to the primary Mongodb server shell, as you did above and run this:
MongoDB shell version: 2.2.0
connecting to: test
> rs.addArb(«[hostname]:[port]»)

As that is used to add nodes to the replication system are the hostnames, each server in the group must be able to get the ip of the other two, so you should use a DNS server to resolve the IP of each server or use the /etc/hosts file.

Install your own virtual machine

(versión en español)

This article opens a section dedicated to virtualization of a server to host virtual machines. Now is very popular in the world of hosting to use a virtual machine as a virtual private server (VPS). Thus, from a server with high processing power, memory, hard disk, multiple virtual private servers can be created.

In this first article I will try libvirt with kvm hypervisor,

Sigue leyendo

fail2ban – Improving the security of your server.

(versión en español)

You know how important it is to have your dedicated server or virtual server with a good security policy that makes it difficult the entry of attacking it.

In addition to correctly configure your dedicated server services to add security, we have tools that add an extra layer that potential attackers must overcome if they want to access your system.

Today am going to focus on fail2ban. Fail2ban basically looks at the logs of web service (apache), ssl, imap, smtp, etc,  seeking access attempts that may be malicious, as repeated failures of passwords, searches for exploits on the server, etc …, and it adds the origin ip addresses of the accesses to the firewall (iptables) in order to block access.

In Ubuntu its installation is simple because it is the Ubuntu repositories. Just run the following command line:

$: aptitude install fail2ban

In Centos, fail2ban is not in the default repositories, therefore a repository that contains it (as EPEL) must be added in yum repositories, or download it from here (32 bit). If you add the repository, you should run:

$: yum install fail2ban

or if you download the appropriate rpm file, the command would be:

$: rpm -ivh fail2ban-0.8.4-29.el5.noarch.rpm

Once installed, you have to take a look at 2 main configuration files to make sure everything is in order.

One of them is / etc/fail2ban/fail2ban.conf, in which the configuration parameters of fail2ban are, such as:

  • loglevel -> it sets the log level to be stored in the log file of fail2ban.
  • logtarget -> it specifies the path to the log file of fail2ban.
  • socket -> it sets the file socket for fail2ban.

In / etc/fail2ban/jail.conf is where you specify the services of your server along with the ports and the log file path for the service you want to check. By default, many services are already configured and all you have to do is check if the path of the log is correct.

Once this is done it just remains starting (or restarting your) service:

$: service fail2ban restart

Although there are some more, this is just another layer of protection for your server powerful enough to put a little more difficult to illegal access to your server.


Amazon listed in anti spam black lists.

(Versión en español)

Since a few months, it is increasingly common to add anti-spam blacklisting  whole ranges of IP addresses of Amazon, with the consequent damage that can lead whom has  their mail servers in those ip address ranges.

Sigue leyendo

Change user SMTP IMAP / POP of an email account in plesk 10.4

(versión en español)

Plesk is a friendly panel for inexperienced users, but when you want to customize something it gives many problems. One of them is often used older versions of software modified by them, which prevents customers to change things and thus charge them for customization, if they make it, or any type of poblem with software (vendor lock-in).

Changing the SMTP and IMAP user is extremely complex, because you have to modify the MTA software source  and several important configuration files in the system. This has a number of disadvantages. The main one is that any microupdate of plesk will overwrite most customizations we make.

If you want to change the username of an account in Plesk 10.3 or 10.4 you can not :-(. At least, without removing the software Plesk. Plesj has an owner demon that authenticates the username from a sqlite3 database  in a specific way and it is not allowed change the format type ‘email’ ( as username. However, we can skip the demon to make an alias (with the name you want) of a real account. In this way you could authenticate yourself with that alias for both sending and receiving 🙂 If you’re going to put to the task we can give some clues to get to your goal, as there are several ways to do:

Sigue leyendo

Server management

(versión en español)

To anyone who bases his business on the Internet, either online stores or any other SaaS, server maintenance helps greatly to the service be active the mostof the time.

If we do not take the time to regularly review our server we may be engaged in a series of nasty problems such as:

  • Attackers who obtain root privileges on the server or privileges that scale.
  • Theft or deleting of data stored on the server (eg databases).
  • Failures in hard drives with the consequent loss of information if you do not have a good backup policy.
  • Sending spam scripts uploaded by vulnerable applications.
  • Denial of service.
  • The server becomes part of a botnet.
  • etc. ..

The server management arises to avoid all these problems and can include the following:

Sigue leyendo

DNS direct and reverse lookup

(versión en español)
Since humans, the vast majority, we are given quite bad to remember IP addresses anyone developed a way to associate names to those addresses, so that we could access the service behind that address, either a web service of email, etc. And therein lies the DNS (Domain name System), a distributed database that associates names (<a href="http://labs le viagra»>domains or domain names) to iP addresses. Sigue leyendo

Django South, listing, merge and fixing several messes

(versión en español)

In a Django project in which several people working under a repository, it is common you do changes in the database more or less simultaneously and when in “pre” / staging, or worse, directly in production you make the “. / migrate app” and get the following Traceback, is when you start to get sick.

(the app in this example is called “main”)

Running migrations for main:  ! Migration main:0048_auto__add_field_reseller_cdn_css__add_field_reseller_cdn_js__add_field should not have been applied before main:0047_auto__add_securitylevelfile but was. Traceback (most recent call last):  File "./", line 11, in <module>  execute_manager(settings)  File "/usr/lib/python2.5/site-packages/django/core/management/", line 438, in execute_manager  utility.execute()  File "/usr/lib/python2.5/site-packages/django/core/management/", line 379, in execute  self.fetch_command(subcommand).run_from_argv(self.argv)  File "/usr/lib/python2.5/site-packages/django/core/management/", line 191, in run_from_argv  self.execute(*args, **options.__dict__)  File "/usr/lib/python2.5/site-packages/django/core/management/", line 220, in execute  output = self.handle(*args, **options)  File "/usr/lib/python2.5/site-packages/South-0.7.3-py2.5.egg/south/management/commands/", line 105, in handle  ignore_ghosts = ignore_ghosts,  File "/usr/lib/python2.5/site-packages/South-0.7.3-py2.5.egg/south/migration/", line 185, in migrate_app  raise exceptions.InconsistentMigrationHistory(problems) south.exceptions.InconsistentMigrationHistory: Inconsistent migration history The following options are available:  --merge: will just attempt the migration ignoring any potential dependency conflicts. aloja:/var/www/virtual/ ./ migrate 0054 main Traceback (most recent call last):  File "./", line 11, in <module>  execute_manager(settings)  File "/usr/lib/python2.5/site-packages/django/core/management/", line 438, in execute_manager  utility.execute()  File "/usr/lib/python2 achat de viagra quebec.5/site-packages/django/core/management/", line 379, in execute  self.fetch_command(subcommand).run_from_argv(self.argv)  File "/usr/lib/python2.5/site-packages/django/core/management/", line 191, in run_from_argv  self.execute(*args, **options.__dict__)  File "/usr/lib/python2.5/site-packages/django/core/management/", line 220, in execute  output = self.handle(*args, **options)  File "/usr/lib/python2.5/site-packages/South-0.7.3-py2.5.egg/south/management/commands/", line 78, in handle  apps = [Migrations(app)]  File "/usr/lib/python2.5/site-packages/South-0.7.3-py2.5.egg/south/migration/", line 60, in __call__  self.instances[app_label] = super(MigrationsMetaclass, self).__call__(app_label_to_app_module(app_label), **kwds)  File "/usr/lib/python2.5/site-packages/South-0.7.3-py2.5.egg/south/migration/", line 41, in app_label_to_app_module  app = models.get_app(app_label)  File "/usr/lib/python2.5/site-packages/django/db/models/", line 140, in get_app  raise ImproperlyConfigured("App with label %s could not be found" % app_label) django.core.exceptions.ImproperlyConfigured: App with label 0054 could not be found

Do not run the “–merge” that is recomended. What you need to do is show a list of historical migrations and see which ones have been left hanging:

( ) 0047_auto__add_securitylevelfile (*) 0048_auto__add_field_reseller_cdn_css__add_field_reseller_cdn_js__add_field (*) 0049_auto__add_field_orders_admin (*) 0050_auto__del_field_orders_admin () 0051_auto__add_field_customer_notify_reseller

As we see the 0047 is that we are breaking consistency. What we do is mark it as already done this migration, since in the past and effectively carry out the 0047;-)

./ migrate main --fake 0047_auto__add_securitylevelfile

We run list to see the result:

./ migrate --list
(*) 0047_auto__add_securitylevelfile
 (*) 0048_auto__add_field_reseller_cdn_css__add_field_reseller_cdn_js__add_field
 (*) 0049_auto__add_field_orders_admin
 (*) 0050_auto__del_field_orders_admin
 () 0051_auto__add_field_customer_notify_reseller

and we run migrate at the end

./ migrate main

You can also go a little further, resetting completely  South