Introduction

In this post I’m going to try to connect two processes in different machines through DBus. The method is a little bit complex, so be patient if you try.
Also is to advert that this has been the result of 3 days of tests (reference1). So maybe this method may be improved with time and use reference2.

Tools (The actors)

• dbus
• gabriel
  • socat
  • libssh
• SSH
• your apps

Debian official packages are dbus libssh-2 socat
gabriel is not part of Debian yet (but I’ve build one for myself)

Knowledge (Actors curriculum)

In this section I will describe the basics about the tools we are going to use.

DBus. Extracted from DBus page:

D-Bus is a message bus system, a simple way for applications to talk to one another. In addition to interprocess communication, D-Bus helps coordinate process lifecycle; it makes it simple and reliable to code a “single instance” application or daemon, and to launch applications and daemons on demand when their services are needed.

D-Bus supplies both a system daemon (for events such as “new hardware device added” or “printer queue changed”) and a per-user-login-session daemon (for general IPC needs among user applications). Also, the message bus is built on top of a general one-to-one message passing framework, which can be used by any two apps to communicate directly (without going through the message bus daemon). Currently the communicating applications are on one computer, or through unencrypted TCP/IP suitable for use behind a firewall with shared NFS home directories.

Gabriel is a simple utility to enable D-Bus clients to connect to a D-Bus daemon running on a remote machine, through SSH.
This is the main piece of this puzzle. If you are interested in understanding how it works you should take a look at socat and libssh. As I’ve had to take a look at code, and make some modifications, you should read it as a punishment.

Extracted from socat man page:

socat - Multipurpose relay (SOcket CAT)
socat is a command line based utility that establishes two bidirectional byte streams and transfers data between them. Because the streams can be constructed from a large set of different types of data sinks and sources (see address types), and because lots of address options may be applied to the streams, socat can be used for many different purposes. It might be one of the tools that one ‘has already needed´.

Libssh. Extracted from libssh page:

The SSH library was designed to be used by programmers needing a working SSH implementation by the mean of a library. The complete control of the client is made by the programmer. With libssh, you can remotely execute programs, transfer files, use a secure and transparent tunnel for your remote programs. With its Secure FTP implementation, you can play with remote files easily, without third-party programs others than libcrypto (from openssl).

You should know about SSH and about your application.

Architecture

Local host will run gabriel and your application.
Remove host will need a running SSH server, a running dbus server and will need socat installed and ready to use.
We need to run gabriel, that will act as a server that will connect our host to the remote host through SSH. After that gabriel will use this SSH connection to intercommunicate our local application with remote DBus applications by using socat.

Remote DBus communication

Howto (Main action)

At the moment I’ve only achieved to connect a process using session-bus, I’m still testing until I get connection through system-bus which was my initial purpose.
After reading next information, you will be able to connect using session bus and system bus.

As I commented somewhere else, I’ve made some modifications on gabriel code. I needed some common parameters as SSH port (my virtualbox testing environment ), better help explanations or add a verbose output.
Gabriel establish a connection with the remote SSH and by socat commands it communicates with the remote DBus “environment”. You should administrate SSH parameters and Dbus parameters to gabriel.

user@machine:~/svn/gabriel/gabriel$ src/gabriel –help
Usage:
gabriel [OPTION...] - Gabriel
Help Options:
-?, –help Show help options
Application Options:
-h, –host=HOSTNAME Hostname or IP of the remote host
-p, –port-ssh=PORT-SSH SSH port on the remote host
-u, –username=USERNAME SSH username on the remote host
-w, –password=PASSWORD SSH password on the remote host
-m, –method=DBUS_TRANSPORT_METHOD The D-Bus transport method to use (TCP, UNIX, abstract-UNIX)
-b, –bind=HOSTNAME The bind-address to listen for D-Bus client connections on
-d, –bus-address=BUS_ADDRESS The DBus session bus address of the remote D-Bus daemon
-t, –port-tcp=PORT-TCP The TCP port to listen for DBus client connections on
-v, –verbose=VERBOSE Set verbosity level (3, 2, 1, 0, -1)=(packet,protocol,functions,important,none)

We have to put special attention to -d, –bus-address=BUS_ADDRESS because this info must be gotten from the REMOTE machine.
That address is the one used by processes to communicate through DBUS. It’s something “internal” and automatically done when you use DBus API/library. I’m going to show you where to get it.

DBUS_SESSION_BUS_ADDRESS, DBUS_SYSTEM_BUS_ADDRESS, DBUS_SYSTEM_BUS_DEFAULT_ADDRESS

Again, this info should be gotten from REMOTE machine.
At the moment I don’t know any nice command where to get this info.
We have two main options of DBus buses. System and Session (more info in DBus page).
If you need SESSION bus address, you can choose what it better fits you:

• You can can get it from process environment
• You can stole it from any other process suspicious from being involved in DBus activities…
• You can create your own dbus-daemon (which, actually, I don’t know if it uses it’s own BUS_ADDRESS)

If you need SYSTEM bus address, you can choose what it better fits you:

• You can can get it from process environment. If it’s not defined, take a look at /etc/dbus-1/system.conf where you should locate a string like <listen>unix:path=/var/run/dbus/system_bus_socket</listen>
• You can stole it from any other process suspicious from being involved in DBus activities…

Examples:

// C++ code
#include <stdio.h>
#include <stdlib.h>
char * env;
// env = getenv (”DBUS_SESSION_BUS_ADDRESS”);
env = getenv (”DBUS_SYSTEM_BUS_ADDRESS”);
if (env!=NULL){
cout << env << endl;
}

user@REMOTE-machine:~ $ grep -z BUS_ADDRESS /proc/2047/environ
HALD_RUNNER_DBUS_ADDRESS=unix:abstract=/var/run/hald/dbus-bonbZtoykd,guid=8b5aff565de0dc7c467fef414832dd98

This command gives you a dbus-daemon in your session with the one you can contact.

user@REMOTE-machine:~ $ dbus-daemon –session –print-address
unix:abstract=/tmp/dbus-j2npbTXDwD,guid=d69f66d43e354de5733e4a1a48335bd6

user@REMOTE-machine:~ $ grep unix /etc/dbus-1/system.conf
<listen>unix:path=/var/run/dbus/system_bus_socket</listen>

Howto (Main action): Back to local host

Those ugly unix:stri:ngs/asdkaj/numbers we have seen is what we need for -d, –bus-address=BUS_ADDRESS.
See a session example:

user@machine:~/svn/gabriel/gabriel$ src/gabriel -h localhost -p 2222 -d unix:abstract=/tmp/dbus-j2npbTXDwD,guid=d69f66d43e354de5733e4a1a48335bd6
Listening to D-Bus clients on: “unix:abstract=/tmp/gabriel”
bla ble blu bla

See a system example:

user@machine:~/svn/gabriel/gabriel$ src/gabriel -h localhost -p 2222 -d unix:path=/var/run/dbus/system_bus_socket
Listening to D-Bus clients on: “unix:abstract=/tmp/gabriel”
bla ble blu bla

The moment we have or gabriel server running we (may have nothing) need to set DBUS_XXX_BUS_ADDRESS. Many apps would use, or have, this environment variable to connect to a DBus instance and intercommunicate with other process.
This is is easy, DBUS_XXX_BUS_ADDRESS should be the address gabriel shows few instants after being launched.
When we have defined this environment variable (in command line) we can execute our app, and it will happily communicate with the remote DBus world.
Example:

user@machine:~/svn/dbusmm/trunk/examples/glib$ export DBUS_SESSION_BUS_ADDRESS=”unix:abstract=/tmp/gabriel”
user@machine:~/svn/dbusmm/trunk/examples/glib$ ./dbus-browser

dbus-browser is a program that uses a session bus.

Curiosity: DBus protocol messages interchanged

Modifying a couple of lines in gabriel can let you see DBus raw protocol messages. It’s a didactic info.
If you enable verbose code at least at level 2, you will get raw DBus protocol messages.

My modifications and hacks

Code will be publish under GLKM project page.

Links and references

• dbus site
• gabriel site
• socat site
• libssh site
• reference 1. (informational note, it had implied jumping into gabriel, libssh, and dbus code and testing with a virtualbox machine)
• reference 2. (personal note, take a look at “Securing traffic between two socat instances using SSL” article in socat page)

This is not an original article (see references), it’s just an archived one “por si las moscas”.

Introduction

By default, the network connection in Virtualbox is set to NAT, that is every packet coming from the Guest machine is modified so that it seems as it has come from the Host machine. In this way it’s easy for the Guest machine to connect to all the rest of the network (the Internet included) but nobody can start a connection with the Guest Machine since it’s hidden behind the Host one.

So, if you want to use a server service in your Guest machine (i.e. Apache or SSH) you have two choices:

1. pass to Virtualbox Host network connection;
2. make Virtualbox forward all the packets arriving to a certain port of the Host machine.

This article will describe how to do the latter, in particular in the case of the SSH server. This is an interesting case because it allows you to simulate very well a quite common condition: connecting to a remote LINUX headless machine.

We have a guest machine with a running SSH server which accepts connections on the TCP port 22.
Our goal is to make any packet arriving at a given TCP port (i.e. 2222) of the host machine, to be forwarded to the TCP port 22 of the guest machine.
Fortunately, there is Virtualbox command which permits to do it almost instantly: VBoxManage.

Configuration needed

In our case we will use Debian as the guest machine name (quote in case guest machine name contains spaces), here are the commands that you have to type in the host machine (real one) console as your user (if you use another user it will try to look for its virtual machines):

user@machine $ VBoxManage list vms
VirtualBox Command Line Management Interface Version 1.5.6_OSE
(C) 2005-2008 innotek GmbH
All rights reserved.
Name: debian
Guest OS: LINUX 2.6
UUID: 814e25f4-451e-4582-8d34-71a1cd437cdd
Config file: /mnt/extra/virtualizacion/virtualbox/debian/debian.xml
Memory size: 195MB
[...]
user@machine $ VBoxManage setextradata debian “VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/HostPort” 2222
VirtualBox Command Line Management Interface Version 1.5.6_OSE
(C) 2005-2008 innotek GmbH
All rights reserved.
user@machine $ VBoxManage setextradata debian “VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/GuestPort” 22
VirtualBox Command Line Management Interface Version 1.5.6_OSE
(C) 2005-2008 innotek GmbH
All rights reserved.
user@machine$ VBoxManage setextradata debian “VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/Protocol” TCP
VirtualBox Command Line Management Interface Version 1.5.6_OSE
(C) 2005-2008 innotek GmbH
All rights reserved.

HostPort,GuestPort,Protocol are just string examples and can be changed without any consequence. Just remember your choices if you want to remove them later.
I guess you should be careful with pcnet substring, as maybe it should have something to see with your selected network card type.

Testing

Once you have typed the above commands, you need to close the guest machine (a reboot won’t be sufficient), restart it and then connect via SSH with:

anyuser@machine$ SSH -l >user< -p 2222 localhost

Replace localhost with the host machine IP address if you are connecting from another computer.

By the way, you can check which customizations have been already set for your Guest Machine with VBoxManage by typing:

user@machine$ VBoxManage getextradata debian enumerate
VirtualBox Command Line Management Interface Version 1.5.6_OSE
(C) 2005-2008 innotek GmbH
All rights reserved.
Key: GUI/LastWindowPostion, Value: 0,6,1028,820
Key: GUI/Fullscreen, Value: off
Key: GUI/AutoresizeGuest, Value: off
Key: GUI/LastCloseAction, Value: powerOff
Key: GUI/SaveMountedAtRuntime, Value: yes
Key: GUI/Seamless, Value: off
Key: VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/HostPort, Value: 2222
Key: VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/GuestPort, Value: 22
Key: VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/Protocol, Value: TCP

or remove one, for example “VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/GuestPort”, by setting it without any value:

user@machine$ VBoxManage setextradata “VBoxInternal/Devices/pcnet/0/LUN#0/Config/ssh/GuestPort”

Links and references

• an article about VirtualBox on doc.ubuntu-fr.org (which offers a slightly different solution)
• Howto access via SSH a Virtualbox guest machine.

Hello fellows.
My latest adventure was about moving a project (unmaintained) from its public subversion repository which of course I was not admin (which means no admin access) over to my own server.

Usually, to do this you’d dump the whole thing with svnadmin into one file (svnadmin dump > file_dump) and load it again at the new location (svnadmin load file_dump). After searching for any similar command without admin access into documentation I figured that something similar might exist for plain svn to svn migration.
I founded a ruby version and a python. I chose python one because it’s recent, it’s python and it’s under google code site.
There was other cause, the ruby version went through all revisions, from 1 till infinity, although many of them didn’t have any change. In the other hand, python version uses subversion logs and made a efficient use of it.

The real action

Create a repository in my server was easy:

root@aristoteles:/var/lib/svn$ rm -rf MY-PROJECT-PATH
root@aristoteles:/var/lib/svn$ svnadmin create MY-PROJECT-PATH
root@aristoteles:/var/lib/svn$ chgrp svn-user MY-PROJECT-PATH/ -R
root@aristoteles:/var/lib/svn$ chmod g+ws MY-PROJECT-PATH/ -R
root@aristoteles:/var/lib/svn$ chmod o-rx MY-PROJECT-PATH/ -R

After solving the problems I talk about, duplicating the repo was not so difficult.

user@othermachine:~$ mkdir tmp
user@othermachine:~$ cd tmp
user@othermachine:~$ svn co URL-DEST-MY-PROJECT-PATH
user@othermachine:~$ python svn2svn-0.1.1.py -r 7382 URL-ORIG URL-DEST-MY-PROJECT-PATH

This process took a while but the new directory was now ready for action.

Be careful with your subversion config files. It may cause conflicts with file in repositories.
As an example, I had some troubles because I use to ignore files like Makefile.in and so. The project I was trying to import did have files like that and svn2svn did bring svn errors because those files were not under revision. When I realized I modified my subversion config without that rules for a while.

References and links

• svn2svn

A simple command line tool called mpy-svn-stats give us nice graphics using svn XML output.

You can see an example GLKM project statistics

It’s quite easy to use, see:

user@machine:/var/www/svn-stats$ mpy-svn-stats -o ./ svn+ssh://localhost/var/lib/svn/glkm/
Will generate PIL graphs.
getting data
running command: “svn -v –XML log svn+ssh://localhost/var/lib/svn/glkm/”
[...ssh stuff...]
done
parsing data
done
calculating stats
done
writing data
done
Have 13 stats objects, 13 of them are wanted.
user@machine:/var/www/svn-stats$ ll
total 48
-rw-r–r– 1 user user 10379 2008-02-06 17:06 changed_paths_multi_author_graph.png
-rw-r–r– 1 user user 10268 2008-02-06 17:06 commits_group_multi_author_graph.png
-rw-r–r– 1 user user 11762 2008-02-06 17:06 index.html
-rw-r–r– 1 user user 10265 2008-02-06 17:06 log_message_length_group_multi_author_graph.png
user@machine:/var/www/svn-stats$

References and links

• project web page mpy-svn-stats

En esta entrada sólo me limito a escribir las principales funcionalidades/objetivos que ya pensé de dotar a mi PFC. Son un poco datos que debí haber publicado hace ya algún tiempo (para variar).
A priori no tengo porque implementarlo todo para poder terminar, ya que como se puede observar, terminan siendo muchas cosas.

Este futuro monitor gráfico de procesos del kernel LINUX será útil para depurar procesos tanto de la propia máquina como de una máquina remota.
La información monitorizada corresponde a las estructuras internas del sistema operativo, más concretamente, del sistema de ficheros con respecto a los procesos.

• Orientado a una interfaz gráfica.
• Monitorización en red.
• Monitorización de procesos. Específicamente atributos de ficheros Reiser. Por supuesto la arquitectura va encaminada a extensiones que permitan ampliar las estructuras a monitorizar
• Visualizar/Monitorizar grupos de procesos simultáneamente.
• Estadísticas del uso de ficheros (opcional)
• Tipos de monitorización: Tiempo real o asíncrona. En tiempo real se toman datos cada intervalo X de tiempo de forma constante. En el caso de monitorización asíncrona se toman datos en los instantes que se indiquen.
• Integración con DBUS/HAL. En la medida de lo posible quiero llevar la comunicación entre la interfaz gráfica y el módulo del kernel por DBUS. A ver como sale.

No cabe duda que no quiero perder de vista al dtrace para LINUX, systemtap. Systemtap realiza labores similares al fin y al cabo.
Para quien no conozca estas herramientas en los siguiente párrafos hago un breve resumen.
Dtrace y systemtap son muy similares, sólo que una está ligada a Solaris y la otra a LINUX. Como en mi caso, monitorizar el núcleo del sistema operativo te cierne (un poco por definición) a ser una herramienta monoplataforma. Ambas proveen unos “lenguajes” propios que permiten extraer/monitorizar variables del sistema operativo.
Con dicha información se pueden realizar estadísticas y depuración como objetivo primordial.

Minutes ago I was trying to compile hal++ a wrapper for libhal developed by beep-media-player team.
While executing configure I’ve got this error:

./configure: line XXXXX: PKG_PROG_PKG_CONFIG: command not found

It was not expected because I did have autotools and pkg-config already installed. And as incredible as I had compiled without any error hal++ in other Debian testing/unstable machine (I was in a Debian testing).
So I have investigated a bit with half success. I’ve found a peace of autotools code which have been useful:

# Check for pkg-config manually first, as if its not installed the
# PKG_PROG_PKG_CONFIG macro won’t be defined.
#
AC_CHECK_PROG(have_pkg_config, pkg-config, yes, no)
#
if test x”$have_pkg_config” == xno; then
AC_MSG_ERROR(pkg-config is required to install this program)
fi
#
PKG_PROG_PKG_CONFIG

It’s only a couple of verifications, which are not introducing anything new, but it was incredibly worked.

Now, I’ll try libhal++ to see if I can do what I want in C++.

Un pequeño problema para el que no he encontrado la solución por más que he buscado.
El problema ha surgido ahora que estoy usando las autotools para automatizar toda la compilación, linkado y distribución de GLKM.

El caso es que al ejecutar el autogen.sh que tengo preparado me salía un mensaje, entre la maraña que sueltan estas herramientas, del tipo:

user@einstein:~/svn/pfc/trunk/gui$ ./autogen.sh
…
cp: no se puede crear el fichero regular «po/Makefile.in.in»: No existe el fichero o el directorio
…

Acotando el comando que fallaba lo ejecuté en modo depuración, para saber que hacía exactamente.

user@einstein:~/svn/pfc/trunk/gui$ intltoolize –copy –force –automake –debug
intltoolize: enabling shell trace mode
+ test -f configure.ac
+ configure=configure.ac
+ files=’intltool-extract.in intltool-merge.in intltool-update.in po/Makefile.in.in’
+ auxdir=.
++ egrep ‘^AC_CONFIG_AUX_DIR’ configure.ac
+ auxdirline=’AC_CONFIG_AUX_DIR([build-aux])’
+ test -n ‘AC_CONFIG_AUX_DIR([build-aux])’
++ echo ‘AC_CONFIG_AUX_DIR([build-aux])’
++ sed ’s/^AC_CONFIG_AUX_DIR(\([^)]*\)).*$/\1/’
+ auxdir=’[build-aux]‘
+ test ‘[build-aux]‘ = ‘AC_CONFIG_AUX_DIR([build-aux])’
++ echo ‘[build-aux]‘
++ sed ’s/^\[\(.*\)\]$/\1/g’
+ auxdir=build-aux
+ case “$auxdir” in
+ test -z yes
++ pwd
+ cur=/home/user/svn/pfc/trunk/gui
+ test build-aux ‘!=’ .
+ test -z yes
+ cd build-aux
+ for file in ‘$files’
+ test -f intltool-extract.in
+ test -z yes
+ rm -f intltool-extract.in
+ test -n ”
++ basename intltool-extract.in
+ cp -f /usr/share/intltool/intltool-extract.in intltool-extract.in
+ :
+ for file in ‘$files’
+ test -f intltool-merge.in
+ test -z yes
+ rm -f intltool-merge.in
+ test -n ”
++ basename intltool-merge.in
+ cp -f /usr/share/intltool/intltool-merge.in intltool-merge.in
+ :
+ for file in ‘$files’
+ test -f intltool-update.in
+ test -z yes
+ rm -f intltool-update.in
+ test -n ”
++ basename intltool-update.in
+ cp -f /usr/share/intltool/intltool-update.in intltool-update.in
+ :
+ for file in ‘$files’
+ test -f po/Makefile.in.in
+ rm -f po/Makefile.in.in
+ test -n ”
++ basename po/Makefile.in.in
+ cp -f /usr/share/intltool/Makefile.in.in po/Makefile.in.in
cp: no se puede crear el fichero regular «po/Makefile.in.in»: No existe el fichero o el directorio
++ basename po/Makefile.in.in
+ echo ‘intltoolize: cannot copy ‘\”/usr/share/intltool/Makefile.in.in’\” to ‘\”po/Makefile.in.in’\”’
intltoolize: cannot copy ‘/usr/share/intltool/Makefile.in.in’ to ‘po/Makefile.in.in’
+ status=1
+ exit 1
+ exit 1

Estoy usando un directorio para guardar los archivos de autoconf (config-aux) y tener la estructura de directorios y archivos ordenadita.
Ahí radicaba el problema. Así que con crear un directorio llamado po bajo ese directorio ha desaparecido el error.

user@einstein:~/svn/pfc/trunk/gui$ cd config-aux/
user@einstein:~/svn/pfc/trunk/gui/config-aux$ mkdir po
user@einstein:~/svn/pfc/trunk/gui/config-aux$ ll
total 412K
-rwxr-xr-x 1 user user 44K 2007-04-20 04:09 config.guess*
-rwxr-xr-x 1 user user 32K 2007-04-20 04:09 config.sub*
-rwxr-xr-x 1 user user 18K 2007-06-07 21:28 depcomp*
-rwxr-xr-x 1 user user 13K 2007-06-07 21:28 install-sh*
-rw-r–r– 1 user user 23K 2007-06-14 16:53 intltool-extract.in
-rw-r–r– 1 user user 36K 2007-06-14 16:53 intltool-merge.in
-rw-r–r– 1 user user 28K 2007-06-14 16:53 intltool-update.in
-rw-r–r– 1 user user 193K 2006-03-11 19:49 ltmain.sh
-rwxr-xr-x 1 user user 11K 2007-06-07 21:28 missing*
-rwxr-xr-x 1 user user 2,0K 2007-06-14 16:52 mkinstalldirs*
drwxr-xr-x 2 user user 48 2007-06-14 17:51 po/

Si tras ejecutar subversion con un svn co, o un svn update el resultado de la operación os luce con un bonito:

user@machine:~/svn/pfc/trunk/gui/src$ svn update
svn: No se pudo leer el archivo ‘/var/lib/svn/glkm/db/revprops/5′: End of file found

El problema es que el archivo en cuestión, llamémosle forunculo, contiene algún error.
Hasta aquí todo esto lo puede haber pensado cualquier hijo de vecino.

En mi caso salía porque había tocado a mano ese archivo para modificar el log de subversion en ese commit/revision, número 5. Le había quitado algunas letras y lo había dejado tal cual.
Cuando intenté posteriormente obtener esa versión para hacer unas pruebas me encontré con el fallo.

Estos archivos de propiedades de cada versión (eso deduzco por el nombre) contienen unos campos de control de longitud, algo muy cutre, pero muy sencillo. Para arreglar el problema hay que contar de manera exacta los caracteres ocupados (yo resté, menos mal que eran pocos).

Un ejemplo similar al caso real (Ojo, antes del END deberían aparecer 2 líneas vacías, en el ejemplo no se muestran):

user@machine-svnserver:/var/lib/svn/glkm/db# cat revprops/5
K 10
K 10
svn:author
V 9
wodofredo
K 8
svn:date
V 27
2007-05-11T17:44:13.460401Z
K 7
svn:log
V 19
2007-05-11 Enrique
END

aristoteles:/var/lib/svn/glkm/db# diff revprops/5 revprops/5~
< V 24
< 2007-05-11 Enrique jdfgj
---
> V 19
> 2007-05-11 Enrique

Para que un proyecto software se lleve a cabo siempre van a hacer falta los mismos pasos. Quizás, según la experiencia o profesionalidad del equipo que lo lleve a cabo, se puedan omitir algunos pasos.

Los primeros pasos van encaminados a encontrar un problema a solucionar. A buscar una necesidad que necesita ser resuelta.
Es decir, lo que hay que hacer es definir que va a hacer el proyecto.

Otra parte que se da es la de documentación. Porque casi siempre que llevas a cabo un proyecto vas a necesitar saber cosas que desconoces. Tienes que

Ojo, muy importante, en el software, como en la vida, estamos sometidos continuamente a cambios, nuestros o del entorno y tienen una incidencia importantísima en el proyecto.
De nuevo, quiero decir que llevar a cabo un proyecto software no es lineal. No es:

1. escabar
2. cimientos
3. cemento
4. ladrillo
5. tubos
6. luz
7. ventanas
8. puertas
9. …

Se trata de:

• Documentarse. Adquirir conocimientos que no posees
• Definir funcionalidades
• Planificar proyecto
• Diseñar
• Implementar
• Probar
• Documentar. Que consiste en describir lo que estas haciendo.

Y cualquiera de estas directrices se puede tener que realizar, y se realizan, en mayor o menor medida, en cualquier momento del proyecto.

Concretamente estoy en fase de documentación desde hace unos cuantos meses ya. Pero es que me es muy fácil esparcirme y de repente ponerme a hacer otra cosa. Lo que se llama falta de concentración (o motivación, ni yo lo se).
Me estoy documentando para ver cómo se escriben interfaces gráficos usando las librerías GTK/GNOME. Además estoy intentado usar un IDE para GNOME llamado anjuta, pero entre que estoy usando la versión que esta en fase de desarrollo (y falla) y que no se manejarlo muy bien, me está costando. Es que no me apetece escribirlo yo todo.
Además me facilita el código para poder hacer la aplicación fácilmente traducible a cualquier idioma.
También me estoy leyendo un manual de C++, que casi no me acordaba de la última vez, a parte de que estoy aprendiendo cosas sobre las que no tenía ni idea de su existencia.

A la vez que me documento (y me disperso), me he ido informando de las herramientas con similares cometidos que ya existen, para ver que me podían aportar cada una de ellas.
Según sabía y descubría más o menos que quería hacer e ido indagando que cosas podía o no usar. Por ejemplo, si usar DBUS para comunicar ciertos eventos. Por ejemplo, si permitir trabajo en red.

Algunas de las características las busco porque un proyecto fin de carrera requiere manejar distintas tecnologías (o debería).
Por otra parte busco que las tecnologías del proyecto encajen y tengan sentido en el programa de forma que lo hagan más usable y útil.

Como veis todo este X se encuentra bajo que yo llamo el caos ordenado o el orden caótico. Muchas ideas y actividades aparentemente inconexas pero a su vez interrelacionadas y que se respetan mucho.

Con esta entrada anuncio el lanzamiento público del que va a ser mi proyecto Fin de Carrera.
El título es provisional.
Muchos estaban deseando obtener información sobre él. Pues ahora lo vais a poder seguir de cerca.

En las últimas dos semanas he estado configurando la página web y algunos de los servicios necesarios para tener en marcha la infraestructura mínima necesaria para llevar a cabo un proyecto de software libre.
De acuerdo con mi tutor no habría problema en que hiciera todo esto.

Lo que he hecho en concreto ha sido instalar y configurar un software para web que suministra herramientas muy útiles para el desarrollo de un proyecto software. En concreto trac, muy usado en proyectos de software libre.
Trac incluye wiki, navegador de código fuente, gestor de tickets. Además permite extender sus funcionalidades mediante un sistema de plugins.
Con el wiki puedo crear páginas web con la información que crea necesaria.
Con el navegador de código permito a cualquiera ojear el desarrollo del código fuente.
El gestor de tickets es una idea sencillamente genial. En base a esto puedes reportar fallos (bugs) y sugerir funcionalidades (features). Mezclando un poco todo esto puedes seguir cuánto falta para alcanzar cierta meta del proyecto (Roadmap).
El apartado de evolución (Timeline) también es muy útil porque en base a todo (repositorio de código, edición de wiki, gestión de tickets) puedes ver toda la evolución que tiene el proyecto. Es información útil para un desarrollador, para un aquel que no le interesen esto detalles iré narrando en la bitácora la evolución de todo.

La única cosa que me falta para cubrir todos los aspectos de un proyecto de software libre es una lista de correo o foro, pero cómo de momento el único desarrollador voy a ser yo, lo dejo para más adelante. El tiempo dirá.

Lo podéis seguir todo desde:

GNOME LINUX Kernel Monitor

Here you can find how to prepare a subversion repository and its integration with Apache 2.

You need apache with webDAV to access repository content using HTTP or HTTPS protocol. If you prefer not to use apache, then you should use svnserve (prefered in daemon mode). This will mean using svn protocol.
Be careful with firewalls (see ahead).
And, of course, always better with Debian.

Subversion for repository administrators (using Apache 2)

In order to create a repository you need to follow these steps (do it in a root shell).

Install the needed packages:

• apache2
• subversion
• libapache2-svn

Add next rules to your host in Apache 2. In Debian a mostly equal config (that you should modify) exists under /etc/apache2/mods-available/dav_svn.conf
Configuration sniplet:

< Location /svn>
# Uncomment this to enable the repository,
DAV svn
# Set this to the path to your repository
# SVNPath /var/lib/svn
# SVNParentPath /var/lib/svn/repository
SVNPath /var/lib/svn/repository
# The following allows for basic HTTP authentication. Basic authentication
# should not be considered secure for any particularly rigorous definition of
# secure.
# to create a passwd file
# # rm -f /etc/apache2/dav_svn.passwd
# # htpasswd2 -c /etc/apache2/dav_svn.passwd dwhedon
# New password:
# Re-type new password:
# Adding password for user dwhedon
# #
# http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html
# configuration for mixed authenticated/anonymous access
Satisfy Any
Require valid-user
# Uncomment the following 3 lines to enable Basic Authentication
AuthType Basic
AuthName “Subversion Repository”
AuthUserFile /etc/apache2/dav_svn.passwd
# Uncomment the following line to enable Authz Authentication
# AuthzSVNAccessFile /etc/apache2/dav_svn.authz
# The following three lines allow anonymous read, but make
# committers authenticate themselves.
< LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
< /LimitExcept>

(Important: Don’t use a DocumentRoot setting for this virtual host!”)

Restart apache with or reload apache configuration without finishing open connections with (prefered)

root@maquine:~ $ /etc/init.d/apache2 reload
or
root@maquine:~ $ apache2ctl graceful (prefered)

Create the repository and create a password file:

root@maquine:~ $ svnadmin create /var/lib/svn/repository
root@maquine:~ $ htpasswd2 -c /etc/subversion/passwd [username]
root@maquine:~ $ chown -R www-data:www-data /home/svn

Don’t forget to make the repository accessible for your web server:

To test it, try accessing it with a browser or try to check out the file:

user@maquine:~ $ lynx http://localhost/svn
user@maquine:~ $ svn co http://server/svn

(You will not be prompted for credentials. That’s normal.)

Worked?
Voila. The repository is set up.
You can check a ready setup in http://www.eldemonionegro.com/svn/.

Subversion for repository administrators (using subversion protocol)

You just need to put on work svn server.

user@maquine:~ $ ls -la /var/lib/svn/
total 1
drwxr-xr-x 4 root www-data 96 2005-06-06 00:45 .
drwxr-xr-x 56 root root 1480 2005-06-03 17:00 ..
drwxr-x— 7 root www-data 224 2003-02-20 00:37 project1
drwxr-x— 7 root www-data 224 2004-11-15 21:23 project2
user@maquine:~ $ svnserve -d -T -r REPOSITORY_DIR (Example 1: /var/lib/svn/project1/ - Example 2: /var/lib/svn/)

(-d: daemon, -T: spawn a thread instead of a process for each connection, -r root: root repository)

Try to check out the file:

user@maquine:~ $ svn co REPOSITORY_URL (Example 1: svn://server/ - Example 2: svn://server/project1/)

Worked?
Voila. The repository is set up.

Subversion for repository users

To checkout (=download) the files in the repository for the very first time run this command::

user@maquine:~ $ svn co http://server/svn

Don’t worry about other people working on the same files. Just do your changes to the files and when you seem to have a stable state (make sure everything works well enough so not everything will break for others) you should check in(=upload) your work:

user@maquine:~ $ svn ci

(Only when committing your changes you will be prompted for your username and password.)

Run the following command regularly to get the changes from other contributors::

user@maquine:~ $ svn update

If you want to add new files to the repository::

user@maquine:~ $ svn add [filename]

To get a status of which files have changed::

user@maquine:~ $ svn stat

Subversion for local repositories

This type of installation is used when you want subversion to track your local files but don’t want/need to put it on a host. You can create a local repository and access it directly. This repository is not password protected and it’s permissions depend on the filesystem’s permissions.

Install the needed packages (as root or with sudo) and create the repository (with your user):

root@maquine:~ $ apt-get install subversion
root@maquine:~ $ svnadmin create /home/joe/repositorie

The URL to your repository is it’s path preceeded with file://. For example to checkout you would do the following:

user@maquine:~ $ svn co file:///home/joe/repositorie

Subversion firewall rules

In order to acces your subversion repository using svn protocol you should reconfigure your firewall or update daemon config.
If you need to access subversion remotely, by default it runs on port 3690 using TCP.

Resources and comments

• Subversion’s Official Homepage
• Online free book: Version Control with Subversion
• http://workaround.org/moin/SubVersion
• subversion quick reference
• Any comments will be welcome.

Original Authors: Christoph Haas, Tiago Cogumbreiro
Modified by: Enrique Garcia

Right now viewcvs is the old version which is available under Debian. I recomend to install the latest viewvc from official website until package gets updated.
For more about it’s history, look up in http://www.viewvc.org/who.html
Instalation is really simple, it’s only complexity resides in the apache 2 configuration. Which is not really well documented and can cause some headache.

Installation

Download here latest stable version from viewvc

I will install everything under /opt because it’s my favourite place (and because it’s standar (LSB rules I think) to put extrange things there).

user@machine:~$ cd /opt
user@machine:~$ wget http://viewvc.tigris.org/files/documents/3330/34803/viewvc-1.0.3.tar.gz
user@machine:~$ tar -xvzf viewvc-1.0.3.tar.gz
user@machine:~$ cd viewvc-1.0.3
user@machine:~$ ./viewvc-install

[will be prompted some easy questions] Answer first /opt and then leave it as it is.

Take a look at INSTALL and README. It’s always good to read this stuff, and doesn’t hurt.

user@machine:~$ emacs /opt/viewvc/viewvc.conf
[main changes I made]
user@machine:~$ diff viewvc.conf ../viewvc-1.0.3/viewvc.conf.dist
72c72
< #cvs_roots = cvs: /home/cvsroot
---
> cvs_roots = cvs: /home/cvsroot
80c80
< svn_roots = svn: /var/lib/svn/repository
---
> #svn_roots = svn: /home/svnrepos
105c105
< default_root = svn
---
> default_root = CVS
138c138
< mime_types_file = /etc/mime.types
---
> #mime_types_file = /usr/local/apache/conf/mime.types
142c142
< address = < a href="mailto:svn-admin@XXX.XXX">Administrador del repositorio Subversion< / a>
—
> address = < a href="mailto:cvs-admin@insert.your.domain.here">No admin address has been configured< / a>
248c248
< languages = es-es, en-us
---
> languages = en-us
391c391
< docroot = /viewvc-doc
--- (LOOK APACHE 2 CONFIG TO EXPLAIN THIS CHANGE)
> #docroot = /docroot
435c435
< use_enscript = 1
---
> use_enscript = 0
445c445
< use_highlight = 1
---
> use_highlight = 0
459c459
< use_php = 1
---
> use_php = 0
473c473
< allow_tar = 1
---
> allow_tar = 0

For coloured syntax I installed next packages. But I am not really sure they are needed.

user@machine:~$ apt-get install highlight enscript

Apache 2 configuration

Here I put my apache 2 configuration for viewvc. I’ve two versions, both of them work. Again I recomend take a take a look at INSTALL and README for answers. One is the version for CGI and the other for mod_python. I’m using mod_python because it’s known to be faster.

CGI

< IfModule !mod_python.c>
< IfModule cgi.c>
# para la instalacion local
ScriptAlias /viewvc /opt/viewvc/bin/cgi/viewvc.cgi
# para el paquete debian
# ScriptAlias /viewsvn /usr/lib/cgi-bin/viewcvs.cgi
< /IfModule>
< /IfModule>

mod_python

< IfModule mod_python.c>
Alias /viewvc-doc “/opt/viewvc/templates/docroot”
ScriptAlias /viewvc /opt/viewvc/bin/mod_python/viewvc.py
< Location /viewvc>
AddHandler python-program .py
# This appends “our path” to python path
PythonPath “['/opt/viewvc/bin/mod_python'] + sys.path”
PythonHandler handler
PythonDebug On
< /Location>
< /IfModule>

Look the result at http://www.eldemonionegro.com/viewvc/

Resources and comments

• viewvc official homepage
• Any comments will be welcome.

Al tiempo de pensar los requisitos que debe seguir un proyecto de software libre se publicó este artículo, que razona y aconseja un poco sobre cada uno de los pasos. The Birth of a FOSS application.

En cualquier caso, yo voy a ir detallando cada paso importante. De forma que este documento lo iré actualizando poco a poco.

• ¿Cómo preparar un servidor de subversion en Debian?
• Configuración de viewvc (antiguo viewcvs) para que cualquiera pueda ver el contenido del repositorio subversion
• Para preparar un trac, seguir la guía para instalar trac en Debian en inglés (también está la guía de trac para Debian traducida al español)