The Information Systems and Computer Applications examination covers material that is usually taught in an introductory college-level business information systems course.

Archive for November 16, 2010

Introducción a SystemTap

 

Al hilo de una antigua entrada de nuestro compañero Antonio Villalón acerca de Dtrace y Solaris, me propuse encontrar algo parecido para sistemas Linux. Dtrace te permitia recolectar información del sistema a muy bajo nivel para detectar anomalías en su funcionamiento y en algunos casos poder prevenir futuros problemas.

Tras un tiempo de búsqueda, y después de descartar varias opciones que no me parecían todo lo completas que deberían, me encontré con SystemTap, una maravillosa herramienta que nos permite monitorizar la actividad del kernel mediante scripts sin tener que compilar y reiniciar cada vez que se requiera ejecutar una prueba.

Es crítico para un administrador de sistemas tener un control total sobre que ocurre en el sistema y herramientas como SystemTap, que te permiten obtener datos precisos del funcionamiento del sistema son de gran ayuda. También aporta seguridad el hecho de poder tener controlado cualquier evento del sistema, ya no a nivel de aplicación, sino de kernel. Conocer qué procesos están abriendo cierto fichero, el consumo de red de cualquier proceso o la ejecución de X función dentro del kernel por Y proceso nos proporciona una ingente cantidad de información que puede resultar necesaria en caso de una detectar una intrusión.

Por el propósito que tiene, SystemTap no es sencillo. Aunque la base es fácil de comprender, su programación requiere conocimientos avanzados de los diferentes módulos del kernel de Linux, aparte de conocimientos de su propia sintaxis. Por suerte para nosotros, existe abundante documentación, y para facilitarnos la tarea y reducir la barrera de entrada existen ya multitud de scripts de ejemplo que nos permitirán ver su funcionamiento e imaginar las posibilidades que tiene SytemTap.

Su instalación es bastante sencilla. En una distribución Fedora basta con instarlo mediante Yum y luego usar un comando propio para que descargue e instale el paquete kernel-debug correspondiente a nuestra versión actual del kernel:

#yum install systemtap
#stap-prep

Como breve introducción, en SystemTap tenemos “events” y “handlers”. La construcción habitual en SystamTap suele ser la siguiente

#codigo#
probe event {statements}

En lo que respecta a los “events” existen dos tipos, síncronos y asíncronos. Un evento síncrono ocurre cuando cualquier proceso ejecuta una operación en el kernel. Como ejemplos de este tipo de eventos tenemos:

  • Entradas a syscalls.
  • Operaciones en el VFS (Virtual File System).
  • Entradas en funciones del kernel, por ejemplo “sys_open”.
  • Entradas en funciones de cierto modulo.
  • etc.

Los eventos asíncronos, por contra, son aquellos que no están ligados a ninguna instrucción particular en el código. Consisten principalmente en contadores y temporizadores.

Los “handlers” es la parte del código llamada cuando ocurre un “event”. Este código, una mezcla entre C y AWK, nos permite tratar la información del evento, almacenarla y en general, utilizar cualquier función disponible en cualquier lenguaje moderno (salida por pantalla, uso de vectores, funciones,…). Vamos a ver un ejemplo básico de “probe”, el cual almacenaremos en un fichero denominado probe.stp, y ejecutaremos con la orden stap probe.stp

####código####
probe syscall.open
{
printf ("%s(%d) open\n", execname(), pid())
}

En este ejemplo, cuando se realice cualquier llamada a la función open() el script escribirá por pantalla el nombre y el PID del proceso que ha ejecutado la llamada.

A partir de aquí, el asunto se puede complicar todo lo que queramos. Se pueden declarar funciones para factorizar el código, variables globales para compartir información entre handlers, timers, etc., y como con cualquier lenguaje nuevo hay que aprender la sintaxis. Por si esto no fuera suficiente, hay que conocer los eventos que podemos registrar en el kernel. Lo más recomendable para no desanimarnos es comenzar probando los scripts de prueba, ver como trabajan, y adaptarlos a nuestras necesidades, leyendo la documentación correspondiente en cada caso. En el wiki del proyecto encontrareis abundante información, y en Fedora, además, podemos instalar el paquete systemtap-testsuite el cual nos copiará en /usr/share/systemtap/testsuite/systemtap.examples/ multitud de ejemplos.

Por último, me gustaría compartir un script que me gustó mucho (está en el paquete de testsuite que hemos mencionado) y que nos permite conocer el consumo de red de cada proceso del sistema en tiempo real. Os invito a que lo reviséis, veáis como se programa un script un poco complejo y las posibilidades de la herramienta. El script tan sólo almacena en cada llamada a las funciones transmit y receive la información en vectores para luego, en función de un timer, mostrarla por pantalla. Aquí esta:

#! /usr/bin/env stap
global ifxmit, ifrecv
global ifmerged 

probe netdev.transmit
{
  ifxmit[pid(), dev_name, execname(), uid()] < << length
}

probe netdev.receive
{
  ifrecv[pid(), dev_name, execname(), uid()] <<< length
} 

function print_activity()
{
  printf("%5s %5s %-7s %7s %7s %7s %7s %-15s\n",
          "PID", "UID", "DEV", "XMIT_PK", "RECV_PK",
          "XMIT_KB", "RECV_KB", "COMMAND") 

  foreach ([pid, dev, exec, uid] in ifrecv) {
    ifmerged[pid, dev, exec, uid] += @count(ifrecv[pid,dev,exec,uid]);
  } 

  foreach ([pid, dev, exec, uid] in ifxmit) {
    ifmerged[pid, dev, exec, uid] += @count(ifxmit[pid,dev,exec,uid]);
  } 

  foreach ([pid, dev, exec, uid] in ifmerged-) {
     n_xmit = @count(ifxmit[pid, dev, exec, uid])
     n_recv = @count(ifrecv[pid, dev, exec, uid])
     printf("%5d %5d %-7s %7d %7d %7d %7d %-15s\n",
            pid, uid, dev, n_xmit, n_recv,
            n_xmit ? @sum(ifxmit[pid, dev, exec, uid])/1024 : 0,
            n_recv ? @sum(ifrecv[pid, dev, exec, uid])/1024 : 0,
            exec)
  } 

  print("\n") 

  delete ifxmit
  delete ifrecv
  delete ifmerged
} 

probe timer.ms(5000), end, error
{
  print_activity()
}
Advertisements

 

Multiple Dropbox Instances on UNIX systems (Linux, Mac OS X)

Warning: These tricks have been tested on a Mac OS X so far (including Snow Leopard), with version 0.6.570 of Dropbox.

 

General idea

The basic idea is to just start Dropbox from the command-line using an alternate home-dir. This will create another Dropbox icon, and another Dropbox folder, which has to be in some other place from the original one. One way to distinguish the two menu bar icons is to change one to Leopard style (black and white) in its Preferences. The two Dropbox folders will both be called Dropbox (this cannot be changed), but you can distinguish them by their location, precisely. Each instance can be used with a different Dropbox account. For instance, I have a personnal Dropbox account and one for professional use. On my laptop, there are separated on two different user accounts, but at home, I would like both on the same user account. Hence, at home, I use the trick below. Technically speaking, this trick could be made an unlimited number of times.

 

On Mac OS X

 

Set Up

Launch /Applications/Utilities/Terminal.app. Make sure you are running a “bash” shell. If needed, just type:

 

bash

Then paste the following command:

 

HOME=$HOME/.dropbox-alt /Applications/Dropbox.app/Contents/MacOS/Dropbox &

Now, you should entering a new Dropbox setup wizard window. A second Dropbox icon should appear on the status bar. Choose an existing account if you have one (different from the original one!) or create a new one. Make sure you choose an alternate location for your new Dropbox folder. If you quit the terminal, the new alternate Dropbox process will also quit. But do not worry! It is set up, and the remaining part of the trick below explains how to restart it with a dedicated little app bundle.

 

Start automatically on login

There are two methods for this. One method is to create a small app bundle that you then add to startup items. Alternatively, you can use Automator to create an application that runs the bash command above in Terminal.

 

Automator Method

1. Open Automator from your Applications folder

2. Choose the ‘Application’ template from the template chooser

3. In the Actions Pane on the right side, Choose ‘Library > Utilities’

4. From the next pane choose ‘Run Shell Script’ and drag it into your workflow.

5. In the Run Shell Script text box, paste the command you used above:

bash
HOME=$HOME/.dropbox-alt /Applications/Dropbox.app/Contents/MacOS/Dropbox &

6. Make sure to include the linebreak.

7. Run the script (button on the top right) to make sure it works.

8. Go to File > Save As and save anywhere.

9. Add the resulting application to your Login items.

 

App Bundle Method

In order to run the second instance automatically on login, you’ll have to create a small app bundle, which you will later add to startup items in the System Preferences “Accounts” pane. Starts by pasting the following command into Terminal. Again, do not include the initial dollar sign of each block:

 

mkdir -p ~/<whaveter place you like>/DropboxAltStarter.app/Contents/MacOS/

This will create recursively, if they do not exist, the folders “DropboxAltStarter.app”, “Contents” and “MacOS”. If you change the name “DropboxAltStarter” for something else, make sure you change it everywhere relevant in the next lines.

Now, open a text editor, and paste the following code:

 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>CFBundlePackageType</key>
    <string>APPL</string>
    <key>CFBundleExecutable</key>
    <string>DropboxAltStarter</string>
    <key>LSUIElement</key>
    <string>1</string>
</dict>
</plist>

And save it with the name “Info.plist” (this is crucial, do not choose another name) and save the file inside “DropboxAltStarter.app/Contents”! Now, open a new text file in the text editor, and paste the following text (warning: make sure you remove the leading whitespaces – I had to put one because of wiki formatting):

 

 #!/bin/bash
 HOME=/Users/$USER/.dropbox-alt /Applications/Dropbox.app/Contents/MacOS/Dropbox

and save it with the same name as specified in the Info.plist file (i.e. look at the string just below “<key>CFBundleExecutable</key>”). And save the file inside “DropboxAltStarter.app/Contents/MacOS”! (Yes, with “MacOS” this time). You can close your text editor.

Make sure that your script is executable, by typing the following command in a terminal:

 

chmod 755 ~/<whatever place you like>/DropboxAltStarter.app/Contents/MacOS/DropboxAltStarter

Now, in the “<whaveter place you like>” directory, you have a small Mas OS X app bundle. You can add it to your login items in the System Preferences->Accounts. You can also double-click on it everytime you need to start this second instance of Dropbox (i.e. if it crashed).

 

On Ubuntu

Note: It doesn’t seem to work with version of 0.7.110 on Ubuntu 9.10

 

Set Up

Open a terminal or whatever shell. Then paste the following commands:

 

mkdir $HOME/.dropbox-alt
HOME=$HOME/.dropbox-alt /usr/bin/dropbox start -i

Now, you should entering a new Dropbox setup wizard window. A second Dropbox icon should appear on the status bar. Choose an existing account if you have one (different from the original one!) or create a new one. Make sure you choose an alternate location for your new Dropbox folder. If you quit the terminal, the new alternate Dropbox process will also quit. But do not worry! It is set up, and the remaining part of the trick below explains how to restart it with a dedicated script.

 

Start automatically at boot

edit /etc/rc.local as root, then add the following line:

 

su <user> -c "/home/<user>/.dropbox-alt/.dropbox-dist/dropboxd &"

Where <user> is the username under which you want to run Dropbox.

This can be done for as many users as you like, provided that they actually exists and that they have Dropbox installed/symlinked in their home folder. You’ll also need to set it up manually the first time, as it requires a graphical interface to link to an account. The above can also be used to auto-start Dropbox on systems which are not running Nautilus as the file manager. Mac-How

TipsAndTricks/MultipleInstancesOnUnix (last edited 2010-08-29 07:33:05 by swanD)