oriolrius.cat

Des del 2000 compartiendo sobre…

Category: System administration, Databases, Messaging and Security

Waiting for IO

Reading time: < 1 minute What processes are waiting for IO interrupts:

while true; do date; ps auxf | awk ‘{if($8==”D”) print $0;}’; sleep 1; done

timegrep: Very useful grep tool

Reading time: < 1 minute Specially when you have to look up inside Postfix logs or Syslog in general it could be the swiss knife tool you need: timegrep.

You have to know that the tool is developed using Python. And is very easy to upgrade or fork the code.

Changing Ubuntu CLI language

Reading time: < 1 minute My mother tongue is Catalan and of course I speak and understand Spanish very well, but when I'm using a Linux CLI it's impossible to be agile if the interface is not in English. Then when I need to change Ubuntu interface to English I modify the file /etc/default/locale: 

LANG=en_US.UTF-8
LANGUAGE="en_US:en"

Deep inside AMQP

Reading time: 5 – 8 minutes

In the next lines I’ll describe with more details the properties and features of AMQP elements. It won’t be an exhaustive description but in my opinion more than enough to start playing with AMQP queues.

Channels

When producers and consumers connects to the broker using a TCP socket after authenticating the connection they establish a channel where AMQP commands are sent. The channel is a virtual path inside a TCP connection between this is very useful because there can be multiple channels inside the TCP connection each channels is identified using an unique ID.

An interesting parameter of a channel is confirmation mode if this is set to true when messages delivered to a exchange finally gets their queues the producer receives an acknowledge message with an UID of the message. This kind of messages are asynchronous and permits to a producer send the next message when it is still waiting the ACK message. Of course if the message cannot be stored and it is lost the producer receives a NACK (not acknowledged) message.

Producers

Maybe this is the most simple part of the system. Producers only need to negotiate the authentication across a TCP connection create a channel and then publish all messages that want with its corresponding routing key. Of course, producers can create exchanges, queues and then bind them. But usually this is not a good idea is much more secure do this from consumers. Because when a producers try to send a message to a broker and doesn’t have the needed exchange then message will be lost. Usually consumers are connected all time and subscribed to queues and producers only connect to brokers when they need to send messages.

Consumers

When a consumer connects to a queue usually uses a command called basic.consume to subscribe the channel to a queue, then every time subscribed queue has a new message it is sent to consumer after last message is consumed, or rejected.

If consumer only want to receive one message without a subscription it can use the command basic.get.This is like a poll method. In fact, the consumer only gets a message each time it sends the command.

You can get the best throughput using basic.consume command because is more efficient than poll every time the consumer wants another message.

When more than one consumer was connected to a queue, messages are distributed in a round-robin. After the message is delivered to a consumer this send an acknowledge message and then queue send another message to next consumer. If the consumer sends a reject message the same message is sent to next consumer.

There are two types of acknowledgements:

  • basic.ack: this is the message that sends consumer to queue to acknowledge the reception of a message
  • auto_ack: this is a parameter we can set when consumer subscribes to a queue. The setting assumes ACK message from consumer and then queue sends next message without waiting the ACK message.

The message basic.reject is sent when the consumer wants to reject a received message. This message discards the message and it is lost. If we want to requeue the message we can set the parameter requeue=true when sent a reject message.

When the queue is created there can be a parameter called dead letter set to true, then consumer rejects a message with the parameter requeue=false the message is queued to a new queue called  dead letter. This is very useful because after all we can go tho that queue an inspect the message rejection reason.

Queues

Both consumers and producers can create a queue using queue.declare command. The most natural way is create queues from consumers and then bind it to an exchange. The consumers needs a free channel to create a queue, if a channel is subscribed to a queue, the channel is busy and cannot create new queues. When a queue is created usually we use a name to identify the queue, if the name is not specified it’s randomly generated. This is useful when create temporary and anonymous queues for RPC-over-AMQP.

Parameters we can set when create a new queue:

  • exclusive – this setting makes a queue private and is only accessible from your application. Only one consumer can connect to a queue.
  • auto-delete – when last consumer unsubscribes from queue the queue is removed.
  • passive – when create a queue that exists the server returns successfully or returns fail if parameters don’t match. If passive parameter is set and we create a queue that exists always returns success but if the queue doesn’t exist it is not created.
  • durable – the queue can persist when the services reboots.

Exchange and binding

In the first post of the serie we talked about different exchange types as you can remember these types are: direct, fanout and topic. And the most important parameter to set when producer sends a message is the routing key this is used to route the message to a queue.

Once we have declared an exchange this can be related with a queue using a binding command: queue_bind. The relation between them is made using the routing key or a pattern based in routing key. When exchange has type fanout the routing key or patterns are not needed.

Some pattern examples can be: log.*, message.* and #.

The most important exchange parameters are:

  • type: direct, fanout and topic.
  • durable: makes an exchange persistent to reboots.

Broker and virtual hosts

A broker is a container where exhanges, bindings and queues are created. Usually we can define more than one virtual brokers in the same server. Virtual brokers are also called virtual hosts. The users, permissions and something else related to a Broker cannot be used from another one. This is very useful because we can create multiple brokers in the same physical server like multi-domain web server and when some of this virtual hosts is too big it can be migrated to another physical server and it can be clustered if it is required.

Messages

An AMQP message is a binary without a fixed size and format. Each application can set it’s own messages. The AMQP broker only will add small headers to be routed among different queues as fast as possible.

Messages are not persistent inside a broker unless the producer sets the parameter persistent=true. In the other way the messages needs to be stored in durable exchanges and durable queues to persist in the broker when it is restarted. Of course when the messages are persistent these must be wrote to disk and the throughput will fall down. Then maybe sometimes create persistent messages is not a good idea.

 

 

What is AMQP? and the architecture

Reading time: 3 – 4 minutes

What is AMQP? (Advanced Message Queuing Protocol)

When two applications need to communicate there are a lot of solutions like IPC, if these applications are remote we can use RPC. When two or more applications communicate with each other we can use ESB. And there are many more solutions. But when more than two applications communicate and the systems need to be scalable the problem is a bit more complicated. In fact, when we need to send a call to a remote process or distribute object processing among different servers we start to think about queues.

Typical examples are rendering farms, massive mail sending, publish/subscriptions solutions like news systems. At that time we start to consider a queue-based solution. In my case the first approach to these types of solutions was Gearman; that is a very simple queue system where workers connect to a central service where producers have to call the methods published by workers; the messages are queued and delivered to workers in a simple queue.

Another interesting solution can be use Redis like a queue service using their features like publish/subscribe. Anyway always you can develop your own queue system. Maybe there a lot of solutions like that but when you are interested in develop in standard way and want a long-run solution with scalability and high availability then you need to think in use AMQP-based solutions.

The most simple definition of AMQP is: “message-oriented middleware”. Behind this simple definition there are a lot of features available. Before AMQP there was some message-oriented middlewares, for example, JMS. But AMQP is the standard protocol to keep when you choice a queue-based solution.

AMQP have features like queuing, routing, reliability and security. And most of the implementations of AMQP have a really scalable architectures and high availability solutions.

The architecture

The basic architecture is simple, there are a client applications called producers that create messages and deliver it to a AMQP server also called broker. Inside the broker the messages are routed and filtered until arrive to queues where another applications called consumers are connected and get the messages to be processed.

When we have understood this maybe is the time to deep inside the broker where there are AMQP magic. The broker has three parts:

  1. Exchange: where the producer applications delivers the messages,  messages have a routing key and exchange uses it to route messages.
  2. Queues: where messages are stored and then consumers get the messages from queues.
  3. Bindings: makes relations between exchanges and queues.

When exchange have a message uses their routing key and three different exchange methods to choose where the message goes:

    1. Direct Exchange:  routing key matches the queue name.
    2. Fanout Exchange: the message is cloned and sent to all queues connected to this exchange.
    3. Topic Exchange: using wildcards the message can be routed to some of connected queues.

This is the internal schema of a broker:

ssh-copy-id

Reading time: < 1 minute Really useful command of ssh package to add public key of your user account to a remote SSH server and then access there with passwordless authentication method. ssh-copy-id [-i [identity_file]] [user@]machine

In the past I wrote a simple cookbook to explain this process but now this is as simple as possible. Don’t forget ssh-copy-id is the most easy way to add your ssh public key in remote servers.

AMQP and RabbitMQ [TOC]

Reading time: 1 – 2 minutes

After reading the book ‘RabbitMQ in action‘ I’m working on series of posts  that will include the following subjects:

  1. What is AMQP? and the architecure
  2. Deep inside AMQP
  3. RabbitMQ CLI quick reference
  4. Hello World using ‘kombu’ library and python
  5. Parallel programming
  6. Events example
  7. RPC
  8. Clustering fundamentals
  9. Managing RabbitMQ from administration web interface
  10. Managing RabbitMQ from REST API

Please let me know if you are interested in this series of posts. Because in my opinion this is very interesting and it always comes in handy to know if someone has been working on those subjects.

Getting help to configure spamassassin.conf

Reading time: < 1 minute Configure spamassassin is never easy to do. But when you look for information in Google usually you will be mad . The most common help method in linux is use 'man command' but it doesn't work or information is not enough usually. After a lucky search I found this command to get an extended information about how to configure spamassassin.conf file.

perldoc Mail::SpamAssassin::Conf

Prey – rastrejar el portàtil i el lladre

Reading time: 2 – 4 minutes

prey logoQuan ens roben el portàtil l’únic que ens queda fer és resar perquè siguem realistes, és molt poc provable que la policia el trobi. Així doncs, el que preten fer prey és enviar-nos tota la informació possible del portàtil després de que ens l’hagin robat.

El seu funcionament és força simple, però al mateix temps s’ha de dir que la idea sembla força eficient. En la versió per linux es tracta d’un script fet amb perl que es col·loca al crontab, de forma que cada x’s minuts es connecta a una URL del servidor de prey o del nostre propi servidor. Aquest URL sovint respon dient que tot va bé, és a dir, que el portàtil no ha estat marcat com a robat. En cas contrari, el servidor respon via HTTP dient que el dispositiu ha estat robat. En aquest moment és quan l’script es posa a treballar i es posa a recollir tot tipus d’informació per reportar-la a la pàgina web:

  • geolocalització per GPS o Wifi, si no disposem de GPS. He provat la localització per wifi i va força bé.
  • fa fotos amb la webcam del portàtil i captures de pantalla
  • reporta tota la informació que pot sobre processos que hi ha corrent al sistema, rutes, informació de les wifis veïnes, etc.
  • també podem fer sonar alarmes, borrar informació remotament, que ens enviï alguns arxius abans de ser borrats,etc.
  • a més els reports que es van reben queden arxivats en una interficie força amigable i molt senzilla d’usar
  • a més el software d’auto-actualitza

La compte gratuïta que ofereix la pàgina web permet tracejar fins a 3 dispositius, obviament si usem el nostre propi servidor HTTP podrem tracejar tots els dispositius que volem. Si volem usar més dispositius haurem d’adquirir una compte professional que tampoc sembla massa cara: per exemple, la més econòmica és la de 12€/mes que permet controlar fins a 10 dispositius amb un màxim de 25 informes per cada dispositiu.

Jo he provat la versió de Windows i la de Linux i ambdues m’han funcionat força bé a la primera, però pel que posa a la web també tenen la versió de Mac i la d’Android. Aquest última diria que és molt nova. Malgrat això en els meus dos Androids no uso prey sinó que uso WaveSecure. Pensat especialment per a dispostius mòbils, ja que tenen versions per: Blackberry, Symbian, Windows phone, Java i Android, és clar.

PAM (Pluggable Authentication Modules)

Reading time: 2 – 2 minutes

Amb les quatre notes que adjunto en aquest article es preten tenir una guia per tal de poder seguir i entendre els fitxers de configuració associats a PAM.

Quan PAM va associat a un servei aquest té un fitxer de configuració dins de /etc/pam.d sovint amb el mateix nom del servei o quelcom que ens el recorda. Dins de cada fitxer d’aquests es defineixen quatre categories pel procés d’autenticació:

  • auth – autenticació
  • account – gestió d’accés
  • password – quan i com es pot canviar la paraula de pas
  • session – entorn de configuració de l’usuari, accés al seu perfil

No és obligatori definir les quatre categories per tots els serveis, hi ha serveis que amb la categoria auth, en tenen prou. O d’altres que les requereixen totes.
PAM té una selecció de diferents models per cada categoria que s’organitzen en una pila. Cada mòdul esta etiquetat amb el que s’anomena una bandera de control. A través d’aquestes eines és com l’administrador controla el procés d’autenticació dels usuaris sobre els serveis.

Les banderes de control suportades per PAM són:

  • required
  • requisite
  • sufficient
  • optional

Si un mòdul marcat amb required, requisite o sufficient respon de forma negativa es deté l’execusió de la pila de forma inmediata.
Si la resposta és positiva en un mòdul: required, requisite o optional llavors PAM seguirà examinant la resta de mòduls.
Si un mòdul sufficient respon positivament es considera positiva la resposta a tota la categoria que s’esta examinant.