lo tomàs avança

Ohhh, Moshe Bar és… és… un ídol. Si a la presentació del projecte em pregunten perquè els pthreads no poden migrar respondré l’explicació que dóna aquest gran home. No té pèrdua.

PD: Sergi, sento si et desperto a aquestes hores ^_^’

Moshe wrote this answer about threading and openMosix to the mailing list.

From: Moshe Bar
To: openmosix-general@lists.sourceforge.net
Subject: pthreads and The Matrix
Date: 07 Aug 2002 06:30:56 +0200
HI Larry

Not being able to migrate pthreads is not an openMosix limitation but a
Linux one. Contrary to platforms like Solaris where threads are
light-weight processes with their own address space, threads in Linux do
not have their own memory address space. You can see the threads with ps
because each thread is a “task” for the Linux scheduler. However, that
task cannot live on its own, it needs the address space where it was
born. If we migrate the pthread to another machine, which address space
would it be connected to? I am sure you saw Matrix, and at one point
Neon asks what happends if somebody dies in the Matrix, if he would also
die in the real world. Trinity answered to him that a body (a pthread)
cannot live without a mind (ie memory, ie address space).

A great many things can be learned from Matrix.

But coming back to our subject here, once we have distributed shared
memory, we will be able to connect remote pthreads to their address
space back home. But that is still some time down the road. I guess
Matrix 2 will be out before we have distributed shared memory.

Ahir, fent la documentació del projecte em vaig trobar amb aquesta explicació sobre quins tipus de fallades provoquen els problemes que solucionen els clústers HA (High Availability o d’Alta Disponibilitat).

“Per poder solucionar problemes necessitem les fallades que els provoquen. Existeixen dos tipus de fallades:

– Provocats pels administradors per veure o mesurar els temps de recuperació i temps de caigudes, o sigui per testejar el temps de resposta davant les caigudes.
– No provocats, que són els que demostren que els temps de reparació solen ser molt més grans dels que s’ha estimat en les fallades provocades. Solen ocórrer sempre un patró de comportament bastant lineal. Generalment estan basats en la coneguda llei de Murphy [4], i solen ocórrer en aquells moments en que els temps de reparació (sempre depenent de factors humans) sigui la més alta possible, com per exemple festes nacionals, Nadal…”

Mmm… quines paraules més dolçes… xD

Està extret de la traducció oficial i amplida del HOWTO d’openMosix al castellà, disponible a http://alumnes.eup.udl.es/~b4767512/07.openMosix/oM_como.html

22/05/2004

   Aquest cap de setmana ha estat molt contradictori, ja que he treballat un munt d’hores però he avançat poquíssim. No, pitjor, he retrocedit, ja que m’he cargat la Gentoo del portàtil… I justament aquesta nit que l’havia de deixar compilant la gnome 2.6… jarl.

   Sobre el projecte a veure… Alguns punts d’especial rellevància:
   * De les 3 màquines que tinc, 2 són athlons (les que usava fins ara) i l’altra és un pentium3, arquitectura x86. He compilat el kernel amb openmosix a l’athlon i clar, després el i686 no l’identificava com a un kernel vàlid. Després d’unes quantes reinstalacions més he trobat que colocant els 2 kernels al mateix lloc (on toca) cada ordinador s’agafa el que necessita.
   * He pogut solucionar el problema del disc dur del pentium3 modificant el particionament dels compute nodes tal i com diu al manual de ROCKS.
   * Trobo que la versio 3.2.0 és més estable i dóna menys problemes, ja que casi tot ha funcionat bastant bé a la primera.
   * Al manual de Rocks també he trobat una cosa interessant anomenada cluster-fork, que és una eina per ejecutar aplicacions sobre altres nodes. Això pot ser útil per montar scripts per executar els programes d’openmosix.
   * La versió 2.4.22-3 d’openMosix té un bug amb les comandes per a l’execució amb les eines cpujob, fastdecay… ja que no estan ben compilades i queda una referència a una macro que no existeix. Buscant al google @mosrundir@ (o algo així) hi ha un parell de notícies.
   * La cervesa es gela molt pronte encara que la posi al costat de la finestra.
   * Demà com a mínim he de fer funcionar el puto PXE. Costi el que costi, ja que facilitaria molt les coses.
   * Encara no he aclarit quina instal lació hauria de realitzar amb el frontend pel que fa a la xarxa. Com sóc tonto no havia llegit a la documentació que recomanen que el frontend tingui 2 interfícies de xarxa, una pública cap a Internet i l’altra privada per al clúster. Això ho podria aconseguir conectant una a la toma de xarxa directament i l’altra al switch, amb la qual cosa el portàtil l’hauria de conectar a la toma del darrera. El dilluns li puc demanar una altra tarja al David i preguntar-li que tal ho troba.
   * He estat provant Ganglia i és molt xulo, si senyor. Dóna un munt d’opcions, fins i tot una et crea les etiquetes necessàries per imprimir-les i apegar-les als nodes xDDD
   * Bé, finalment he conseguit instalar openmosix als 2 nodes. El mosmon funciona bé, els pilla perfectament. Però, quan faig un showmap l’athlon no apareix, però en canvi al mosmon si. Els processos no es reparteixen ni a la de 4.
   * Hauria de buscar la manera per configurar el oMFS, ja que per defecte no s’activa.
   * openMosix sembla que funciona, però no acaba d’anar fi. Quan migra, ho migra tot, no sé pq.
   * Comandes útils:
      # mosctl bring   // fa tornar tots els processos locals cap als seus home nodes
      # mosctl expel   // fa tornar tots els processos remots cap als seus home nodes
      # mosctl lstay   // deshabilita la migracio automatica de processos
      # mosctl whois compute-0-x // Retorna l’identificador dintre del cluster mosix d’aquesta maquina

   * Per mirar l’espai lliure al disc dur:
      # df -h

23/05/2004

   Ahir per la nit vaig estar llegint el HOWTO d’openmosix, i llegint llegint vaig veure que és molt millor una configuració manual que la de l’omdiscd, ja que aquesta última no deixa de ser una versió beta. Per tant, aquest matí he arribat i he canviat la configuració d’openMosix:
      # vi /etc/openmosix.map
         1         10.30.255.253      1
         2         10.30.255.253      1
   Teòricament ho podria posar només amb una línia, posant “1   10.30.255.253   2&Prime, però si ho faig així continua sense agafarme el node athlon. Posant-ho en 2 línies separades si que tinc visibilitat, i el showmap em mostra els 2. Ara hauré de veure si funcionen amb els tests o no.

   També vaig estar llegint sobre les opcions de configuracions del kernel d’openmosix. Explicació procedent del HOWTO:

openMosix process migration support: Esta opción permite activar el soporte a la migración de procesos en openMosix. Esto incluye tanto la migración forzada por el administrador como la migración transparente automática de procesos, el algoritmo de equilibrado de carga y el Memory Ushering. Si no activamos esta opción, no tenemos openMosix. Por ello, si estamos leyendo este documento, nos interesa tener esta opción activada.

Support clusters with a complex network topology: Las máquinas que pertenecen al cluster openMosix pueden pertenecer a la misma red IP, estando conectadas por un hub o por un switch. En este caso, en openMosix consideramos que la topología de la red es simple, lo que permite realizar algunas modificaciones en los algoritmos de calculo de la función de coste del algoritmo de equilibrado de carga que hacen muchísimo más eficiente su cálculo. También mejora la eficiencia del algoritmo de colecta automática de información del cluster. Si tenemos todas las máquinas del cluster conectadas a través de hubs o switchs -es decir, que un paquete openMosix nunca necesitará pasar por un router- podemos aumentar sensiblemente el rendimiento de nuestro cluster desactivando esta opción.

Maximum network-topology complexity to support (2-10): Si activamos la opción anterior, aparecerá esta opción. En esta opción se nos pregunta cuantos niveles de complejidad hay entre las dos máquinas más lejanas del cluster, entendiendo por niveles de complejidad el número de routers intermedios más uno. Si ponemos un número más alto de la cuenta, no tendremos todo el rendimiento que podríamos tener en nuestro cluster. Si ponemos un número más bajo de la cuenta, no podrán verse entre sí las máquinas que tengan más routers intermedios que los indicados en este parámetro menos uno.

Stricter security on openMosix ports: Esta opción permite un chequeo adicional sobre los paquetes recibidos en el puerto de openMosix, y unas comprobaciones adicionales del remitente. Aunque esto suponga una pequeña pérdida de rendimiento, permite evitar que mediante el envio de paquetes quebrantados se pueda colgar un nodo del cluster. De hecho, hasta hace poco tiempo se podía colgar un nodo del antiguo proyecto Mosix sólo haciéndole un escaneo de puertos UDP. Salvo que tengamos mucha seguridad en lo que estamos haciendo, debemos activar esta opción de compilación.

Level of process-identity disclosure (0-3): Este parámetro indica la información que va a tener el nodo de ejecución real de la tarea sobre el proceso remoto que está ejecutando. Aquí debemos destacar que esta información siempre estará disponible en el nodo raíz -en el nodo en el que se originó la tarea-; limitamos la información sólo en el nodo en el que se ejecuta la tarea si este es distinto del nodo raíz. Este es un parámetro de compromiso: valores más bajos aseguran mayor privacidad, a cambio de complicar la administración. Valores más altos hacen más cómoda la administración del cluster y su uso, pero en algunos escenarios pueden violar la política de privacidad del departamento o de la empresa.

Un 0 significa que el nodo remoto que ejecuta el proceso migrado no tiene ninguna información relativa al proceso migrado que se ejecuta en dicho nodo. Este modo paranoico hace la administración del cluster realmente complicada, y no hay ninguna razón objetiva para recomendarlo.

Un 1 significa que el nodo remoto que ejecuta el proceso migrado tiene como única información el PID del proceso. Este es un modo paranoico, pero que permite al menos al administrador del cluster saber con un poco de más comodidad qué es lo que está pasando en caso de problemas. Es un nodo útil cuando usamos máquinas no dedicadas que estén en los despachos de los usuarios del cluster, y no queremos protestas entre los usuarios del cluster sobre quién está haciendo más uso del cluster.

Un 2 significa que el nodo remoto que ejecuta el proceso migrado conoce PID , el usuario propietario y el grupo propietario del proceso. Este es un modo útil en clusters dedicados y no dedicados cuando sabemos que no va a haber discusiones entre los usuarios porque alguien use los recursos del cluster más de la cuenta. Es una buena opción si tenemos nodos no dedicados en despachos de usuarios donde cualquier usuario no tiene cuentas en las máquinas de los otros, para asegurar una cantidad razonable de privacidad.

Un 3 significa que en el nodo remoto que ejecuta el proceso migrado se tiene exactamente la misma información de los procesos migrados que de los procesos locales. Esto significa que para la información de los procesos el sistema se comporta realmente como un sistema SSI. Este modo es recomendable en los escenarios donde todos los usuarios tienen cuentas en todas las máquinas del cluster, con lo que mantener la privacidad del espacio de procesos ya es de por si imposible, y bloquear esta información solo complica el uso y la administración del cluster. Este es el escenario más habitual de uso de un cluster, por lo que en caso de dudas es mejor que usemos este nivel de privacidad. De cualquier forma, cualquier proceso puede variar su nivel particular de privacidad grabando desde el propio proceso su nuevo nivel de privacidad en el archivo /proc/self/disclosure.

Create the kernel with a -openmosix extension: Si activamos esta opción, el nombre simbólico del kernel llevará la extensión -openmosix. Esto es importante a la hora de buscar y enlazar los módulos. Debemos activar esta opción si, teniendo la misma versión de kernel base y de kernel para openMosix, queremos que los módulos del kernel openMosix y los módulos del kernel antiguo no sean compartidos. En nuestro caso significa que si activamos esta opción podemos tener un kernel 2.4.20 en el sistema y un kernel openMosix 2.4.20-2 al mismo tiempo, y que cada uno tendrá sus módulos por separado y guardados en directorios distintos. En principio, es una buena idea activar esta opción para evitar problemas de efectos laterales con un kernel ya existente en el sistema.

openMosix File-System: Si activamos esta opción podremos usar el sistema de ficheros oMFS, por lo que debemos activar esta opción sólo si vamos a usar el oMFS.

Poll/Select exceptions on pipes: Esta opción es interesante, aunque separa a openMosix de una semántica SSI pura. En Unix, un proceso que escriba en un pipe en principio no es interrumpido si otro proceso abre el mismo pipe para leer o ya lo tenía abierto y lo cierra. Activando esta opción nos separamos de Posix: un proceso escritor en un pipe puede recibir una excepción cuando otro proceso abra un pipe para leer dicho pipe, y puede recibir también una excepción si el pipe se queda sin lectores.

Activamos el lanzamiento de la excepción de lectura del pipe con la llamada al kernel ioctl(pipefd, TCSBRK, 1), y activamos la señal de que el último lector ha cerrado el pipe con ioctl(pipefd, TCSBRK, 2). Por último, podemos tener una estimación aproximada de la cantidad de información que los procesos lectores han pedido leer de un pipe en particular con la llamada al sistema ioctl(pipefd, TIOCGWINSZ, 0). Esta llamada no da un valor exacto, y puede equivocarse -pensemos que nos da apenas una estimación a la baja-. Por lo tanto, en caso de equivocación de la llamada, suele ser porque el proceso lector lee más de lo estimado. Aunque activemos esta opción, por defecto, el envío de estas excepciones está desactivado para todos los procesos, y cada proceso que quiera usar estas excepciones debe activar su posibilidad con ioctl. En principio no activamos esta opción, salvo que queramos usarla para nuestros propios programas.

Disable OOM Killer (NEW): Las últimas versiones del kernel de Linux incluyen una característica bastante discutida: el OOM Killer. Esta opción nos permite inhabilitar el OOM Killer, y evitar los problemas que este suele causar. En caso de duda, es recomendable habilitar esta opción -es decir, inhabilitar el OOM Killer-.

Por último, no debemos olvidar que todos los nodos del cluster deben tener el mismo tamaño máximo de memoria, o si no las tareas no migrarán. Para ello, entramos en la opción Processor type and features, y en la opción High Memory Support asignamos el mismo valor a todos los nodos del cluster.

   Resumint, la configuració deuria quedar:
      [ * ] openMosix Migration Suppor
      [ ] Support clusters with a complex (potser als laboratoris tocarà activar-ho)
      [ ] Maximum network-topology complexity to support (2-10) (només sortirà si activem l’anterior)
      [ * ] Stricter security on openMosix ports
      [ 3 ] Level of process-identity disclosure (0-3)
      [ ] Create the kernel with a -openmosix extension (me sembla que esta ja no està)
      [ * ] openMosix File-System
      [ ] Poll/Select exceptions on pipes
      [ * ] Disable OOM Killer
      [ ] Load Limit
      Anar a Processor type and features -> High Memory Support el mateix valor per a tot el clúster

   Acabo de llegir un truco molt bo per tenir openMosix corrent amb un master. El que podem fer es dir-li que la seva velocitat és molt inferior a la dels altres, i d’aquesta manera tots els processos migraran cap als nodes deixan el master lliure per gestionar les peticions.

21/05/2004

   Avui a ampliar el clúster. He anat a buscar al David un disc dur i faré servir la màquina del costat. Intentaré probar la primera solució anteriorment comentada, i espero que resulti.
   Abans d’esborrar i reinstalar una nova imatge he copiat els 3 directoris dels kernels al portàtil per mirar els arbres i mirar si veig alguna cosa que em pugui ajudar.
   He estat tot el mati reinstalant, i ara cap dels nodes me pillen lo cd (?¿?¿?) Paranoiaaaaaaaaa
   Al final no se que ha passat, però m’ha tocat instalar la 3.1.0 pq la 3.2.0 no me veia res. I a part conectada al Internet (encara que no tenia visibilitat) per a mi que m’he equivocat de cable… pq sinó no li trobo explicació.
   Procediment per recompilar el kernel:
   # ssh compute-0-0
   # mkdir /root/cd
   # scp frontend-0:/root/cd/* /root/cd
   # rpm -ivh /root/cd/openmosix-kernel-source-2.4.22-openmosix3.i386.rpm
   # cd /usr/src
   # rm linux-2.4
   # ln -s linux-2.4.22-openmosix3 linux-2.4
   # scp frontend-0:/home/instal…/rocks-kernel-…rpm /root/cd
   # rpm -ivh /root/rocks-kernel…rpm –force
      Si no posem force diu que dona un conflicte entre el mkspec d’openmosix i aquest
   # cp /boot/config-2.4.21-4.0.1.EL /usr/src/linux-2.4/.config
      Aqui es on es pot observar que la versio 3.2.0 porta el kernel 2.4.21-9.0.1.EL
   # cd /usrc/src/linux-2.4
   # make menuconfig
      Diem que volem usar el openmosix file-system.
   # make rpm
      A berenar
   # scp /usr/src/rehat/RPMS/i686/kernel-2.4.22-openmosix3.i686.rpm frontend-0:/export/home/install/contrib/enterprise/3/public/i386/RPMS
   
   Ara s’ha d’afegir el paquet openmosix-tools:
   # cd /home/install
   # cp /root/cd/openmosix-tools-0.3.5-1.i386.rpm /home/install/contrib/enterprise/3/public/i386/RPMS
   # rocsk-dist dist
   # cd /home/install/profiles/3.1.0/site-nodes
   # cp skeleton.xml extend-compute.xml
   # vi extend-compute.xml
      Canviem una linia que diu … per
       openmosix-tools    # ssh-agent $SHELL
   # shoot-node compute-0-0

   Sorpresa!! El HDD que m’ha donat david no era de 6 Gb, era de 3 Gb… Caguentoloquesemenea. Pro bueno, aixi tinc l’oportunitat d’explorar mes a fons la seccio “5.4.2 Modifying Compute Node Disk Partitioning”. Es molt facil
   # cd /home/install/profiles/3.1.0/site-nodes
   # cp skeleton.xml replace-auto-partition.xml
   # vi replace-auto-partition.xml
      Dintre hem d’afegir
      

      Tambe acabo de trobar quina punyetera RedHat es aixo!!!! Es una RedHat Linux 7.3…. snif snif… 3 setmanes per trobar aixo… xDDD

      He tingut un problema amb les mascares de xarxa… 255.255.0.0 (uni) no es 255.0.0.0 (rocks)… haure de canviar la configuracio del dhcpd! L’he canviada, pero tinc problemes amb l’ip-forwarding trobo. O potser amb les ip-tables.

      %%% REINSTALACIO AMB DHCP PER AL FRONTEND %%%

      Mentre aprofito per llegir el manual d’openmosix. He trobat una cosa molt interessant:

Planteamientos de tu cluster (pag. 142)
Para configurar tu cluster openMosix en un pool de nodos, o conjunto de estaciones de trabajo, tendremos diferentes opciones, cada una con sus ventajas e inconvenientes:

   * Single Pool: Todos los servidores y estaciones de trabajo son utilizadas como un clúster único: cada máquina forma parte del clúster y puede migrar procesos hacia cada uno de los otros nodos existentes. Esta configuración hace que tu propia máquina forme parte del pool.

   * Server Pool: Los servidores son parte del cluster mientras que las estaciones de trabajo no lo son. Si quisiéramos ejecutar aplicaciones en el cluster necesitaremos entrar en él de forma específica. De este modo las estaciones de trabajo permanecerán libres de procesos remotos que les pudieran llegar.

   * Adaptive Pool: Los servidores son compartidos mientras que las estaciones de trabajo podrán entrar y salir del cluster. Podemos imaginar que las estaciones deban ser usadas durante un cierto intervalo de tiempo diario, y que fuera de este horario puedan ser aprovechadas para las tareas del cluster.

   Acabada la instalació m’ha tornat a donar el problema aquell, que ara que m’he fixat millor i m’he peleat més ja l’he sabut resoldre.
   * Problema 1: No podia entrar a /home/install
      Solució: He editat el /etc/hosts (fent abans una copia de seguretat) i he afegit 2 linies:
         10.30.206.31      frontend-0
         10.30.206.31      frontend-0.local
         Després he fet un /etc/init.d/autofs restart i ja ha funcionat tot. He fet el següent per acabar la instalació:
         # cd /home/install
         # rocks-dist dist
   * Problema 2: No se que dels rpm, pero no trobo el fixer on m’ho diu. Gràcies a això he mirat al /vat/log/messages i he vist que el dhcpd no va bé :/ Té un error a la configuració!.
      Solució:
         # vi /etc/dhcpd.conf
            ddns-update-style none;
            option space PXE;
            option PXE.mtftp-ip code 1 = ip-address;
            subnet 10.30.0.0 netmask 255.255.0.0 {
               default-lease-time 1200;
   max-lease-time 1200;
   option domain-name “local”;
   option nis-domain “rocks”;
   if substring (option vendor-class-identifier, 0, 9) = “PXEClient” {
# Chroot TFTP appropriately”
filename “pxelinux.0″
option vendor-class-identifier “PXEClient”;
option PXE.mtftp-ip 0.0.0.0;
vendor-option-space PXE;
#next-server ;
   } else {
filename “/install/kickstart.cgi”;
   }
            }

      Hem va super lento pq trobo que tinc problemes amb el route.
      # route del -net 10.30.0.0 netmask 255.255.0.0

21/05/2004

   Decididament, la 3.2.0 no funciona. Quan la instalo no m’agafa els nodes ni a la de 4!! Total, a reinstalar la 3.1.0. Però he tingut una idea molt bona. Instalaré, i abans de rebotar per primera vegada entraré amb un cd de la gentoo i modificaré els fitxers necessàris per a que pugui acabar correctament la instalació

19/05/2004

   Avui he reinstalat el frontend des de 0, i després he actualitzat el kernel a soles, o sigui, he canviat el kernel de la 2.4.21-9.0.1.EL a la 2.4.22.
   Conclusions: Això que em passa de que MySQL no funciona no es culpa del parche d’openMosix, ja que ara sense el parche tampoc hem funciona. No sé si es un pas endavant o un pas endarrere, però és un pas.

   Intentaré reinstalar els paquets de MySQL (abans he canviat la configuracio del netconfig):
      # rpm -Uvh –force /export/home/install/ftp.rocksclusters.org/pub/rocks/rocks-3.2.0/rocks-dist/enterprise/3/en/os/i386/RedHat/RPMS/mysql-*
      Error: Failed dependencies
         perl(CGI) is needed by mysql-3.23.58-1
         perl(DBI)
         perl-DBD-MySQL
         perl-DBI
   A buscar al Google. He trobat una cosa molt interessant. Per instalar el que necessito:
         # perl -MCPAN -e ‘install DBI’
         # perl -MCPAN -e ‘install DBD::mysql’
   Per si de cas tambe ho tinc a http://search.cpan.org/CPAN/authors/id/T/TI/TIMB/DBI-1.42.tar.gz
         # perl -MCPAN -e ‘install Bundle::DBD::mysql’
         # perl -MCPAN -e ‘install DBD::mysql’        #per si de cas
   I tambe a http://search.cpan.org/CPAN/authors/id/R/RU/RUDY/DBD-mysql-2.9003.tar.gz

   Aquesta tarde ha entrat en escena sergi. Ha entrat al sistema, fent el seu wall xD I bé, després de molta estona mirant, toquetejant, veient que al servidor no hi havia fotos guarrindongues i fent-li kills a les aplicacions que se li quedaven enganxades hem arribat a la conclusio que la culpa era del kernel. On ha estat decisiu ha estat en trobar el fitxer de configuració del kernel de la ROCKS. Al final el punyeteru fitxer estava a /boot/config-2.4.21-9.0.1.EL. Tot seguit:
   # make oldconfig
   # make dep clean modules modules_install install
   I a esperar. Com a nota dir que al log del kvirc tinc tota la conversa amb sergi.
   Després de reiniciar continua semblant que no ho ha fet del tot be. O sigui que he reiniciat i tornat a instal lar.

   Reinstalant, vaig a posar el kernel openmosix directament. He instalat el paquet rocks-kernel també, i l’he destripat per veure que portava:
   # cd /usr/src
   # rpm -ql rocks-kernel
      /usr/src/linux-2.4/scripts/mkspec
      Nomes conte un fitxer, aquest i em diu que em dona conflicte amb la versio instalada per openmosix
   # mv /usr/src/linux-2.4/scripts/mkspec /usr/src/linux-2.4/scripts/mkspec.old
      Copia de seguretat
   # rpm -Uvh –force /export…./rocks-kernel….rpm
      Que ens el maxaqui
   # cp /boot/config-2.4.21-9.0.1.EL /usr/src/linux-2.4/.config
      Copiem la mateixa configuracio del kernel
   # make menuconfig
      Assenyalem openMosix file system. De moment no marcare el /dev file system
   # make dep clean bzImage modules modules_install install
      Recordar que a la primera arrancada ha acabat d’instalar 2 paquets, el pvfs-kernel i el gm. Quan reinicie amb el nou kernel tambe els tornare a instalar.

20/05/2004

   Un petit avanç per a un dia on ha digut reventar la meitat dels routers de la uni. Em sembla que ja he trobat que vol dir kernel 2.4.21-0.9.EL. Vol dir Red Hat EL, que vol dir Red Hat Enterprise Linux!!! Joer joer

ftp://ftp.redhat.com/pub/redhat/linux/enterprise/
ftp://ftp.redhat.com/pub/redhat/linux/updates/enterprise/

   Buscant a http://ftpsearch.elmundo.es he buscat “kernel-2.4.21&Prime i em surt el paquet del kernel que hi ha instalat. Però buscant el “kernel-2.4.22&Prime no en surt cap per a RHEL…

   També he trobat una ordre que treu informació sobre els paquets:
      # rpm -qi kernel.i686

   A veure… farem un resum una mica general de la situació. 2 coses:
   * Per una part tinc els nodes. Als nodes no hi ha cap problema en instalar openmosix, això ja ho vaig poder comprobar. D’aquí puc treure una solució, que seria instal lar el frontend sense openmosix i tots els nodes amb openmosix. M’hauria de preguntar quins problemes em pot portar això, que suposo que algun portarà, sobretot pel que fa a gestió de processos openmosix. Una de les ventatges seria que mantindria independència entre les aplicacions que usen MPI amb openMosix i les que usen MPI sense openmosix. És la més factible. He de demanar una altra máquina per a provar-ho.

   * L’altra solució seria parchejar a mà el kernel 2.4.21, que, realment, no m’hi veig molt capaç. Tinc un munt de dubtes sobre fitxers, codi i demés coses, però si tingués mooooooooooolt de temps potser em plantejaria provar-ho. A més se segur que un ha pogut, o sigui que casi m’ho podria pendre com algo personal… Però lo que se diu temps temps, no n’hi ha.