Confieso que lo había olvidado, como dice el maestro Sinner:  LINUX es LINUX es LINUX es LINUX. Tanto tiempo escuchándolo en el trabajo, en la calle, en la red, incluso en Blogdrake alguna vez: “mandriva es para el escritorio”,”en un server instala Debian/CentOS/Fedora“,”mandriva es para  niñas”…  y un largo etc de muletillas.
No me lo trago, mandriva me ha dado estupendos resultados como servidor últimamente en el trabajo.

El primer caso: un piloto para el montaje de un PDC con OpenLdap + Samba, antes de montarlo a “mano” me pidieron evaluar el ahora llamado 389-ds y Mandriva Directory Server.  Evidentemente son versiones en continuo desarrollo, “embriones” para los productos de pago incluidos en Red Hat o en Mandriva Enterprise y no voy a negar que dan problemas. MDS vence por goleada, un producto serio, bien enfocado ( en mi opinión claro) usando herramientas ya conocidas y con una filosofía que va de la mano de la forma tradicional de montar un PDC con OpenLDAP+ SAMBA. 389-ds es todo lo contrario, van un poco “a su aire” por ser los herederos de antiguo NDS,  abandonan smbldaptools por unas nuevas “fdstools”, la integración con samba y postfix casi es “demoníaca” , todo esto con la versión estable para fedora 11 , si nos vamos a la versión testing simplemente no funciona.

El segundo caso (ZAPE): Los pc’s de escritorio son cada vez  más baratos, más potentes y con más almacenamiento que muchos servidores “relativamente modernos” .  Una tarde me llaman del “otro trabajo”: – Oye Bersuit, que me sobra un equipo, me he equivocado con el pedido ¿ Que podemos hacer con él ?. Unas horas después estaba instalando Mandriva 2009 a un clónico con “nosecuantos” núcleos, varios gigas de RAM y 500 Gb de disco duro.  El servidor de almacenamiento/backup (ZIPI) con tropecientos gigas, raid 5 “chupi guay” va hasta el cuello y los discos valen una pasta. Con 100€ para comprar otro disco de respaldo ya tenemos un servidor de backup secundario.

Mandriva 2009 + samba + winbind autenticándose contra el AD corporativo, almacena el repositorio de software, que liberó bastante espacio en el servidor primario,  almacena las copias antiguas de los servidores , las imágenes del pc de algún usuario, la segunda copia de los documentos “importantes” y las unidades para que los lusers guarden sus documentos que no quieren perder cuando llega “la cizalla” . Todas las noches poquito a poquito hace un rsync al segundo disco ( una controladora raid se salia del presupuesto), pero aún hay más …

OpenFire como servidor de IM interno autenticado también contra el AD, los usuarios al principio eran reticentes: ¡Bersuit yo quiero mi msn!, ahora ya no pueden vivir sin él.

Ayer mismo me lleve la última sorpresa, que motiva esta entrada, instalando nagios para monitorizar los servicios dentro de la red interna:

urpmi nagios nagios-www

Y ya, listo para hacer login en la consola web de nagios, ¡si hasta me había generado automáticamente un usuario y password ! listos que son estos chicos de mandriva si señor.

Como conclusión: Linux es Linux es Linux es Linux, instala mandriva en tus servidores. Sí, es cierto, no hay que perder el norte, hay distribuciones “enterprise” que hacen las cosas muy bien, hay sitios donde entra una distribución de Linux suavemente y no es necesario “partirse” la cara para meter tu distro preferida, pero no dejen a mandriva a un lado por ser una “distro de escritorio”.

1- El primer paso después del archiconocido urpmi quota , será habilitarlas, , definiendo las opcciones en /etc/fstab. Editamos el archivo y añadimos :

# Entrada para el nuevo disco:
/dev/sdb1  /mnt/quotas   ext3    relatime,usrquota,grpquota    1  2

2-Crear los ficheros quouta.user y quota.group en la raiz del filesystem /mnt/quota:

[root@mdv1 ~]# touch quota.user quota.group
[root@mdv1 ~]# chmod 600 quota.user  quota.group

Estos dos ficheros contendran las bases de datos de las cuotas de usuario y grupo. Los ficheros de cuota son binarios, cada filesystem con cuotas utilizará sus propias bbdd.

3- Ejecutamos quotacheck para inicializar las bbdd
[root@mdv1 quotas]# quotacheck -avug
quotacheck: Your kernel probably supports journaled quota but you are not using it. Consider switching to journaled quota to avoid running quotacheck after an unclean shutdown. (1)

4. Ejecutamos quotaon para habilitar las cuotas:
[root@mdv1 quotas]# quotaon -av
/dev/sdb1 [/mnt/quotas]: group quotas turned on
/dev/sdb1 [/mnt/quotas]: user quotas turned on
[root@mdv1 quotas]#

5-Verificar que las quotas se arrancan en el inicio del sistema dando un vistazo a /etc/rc.sysinit

Ya estamos listos para trabajar con quotas, nos quedan unas cuantas dudas como (1) activar las journaled quotas, ( que tienen buena pinta) , repquota ( para genera informes) y el uso de edquota para asignar cuotas a usuarios y grupos, también el tema de la actualización de las bbdd de quotas con quotacheck. Asi que no se vayan todavía aún hay más…

Empezamos la segunda parte donde lo dejamos, daremos un vistazo al fichero insane.ldif para hacernos una idea de lo que contiene  nuestro directorio-árbol.  Vamos con la raíz:

# insanecrew.info
dn: dc=insanecrew,dc=info
dc: insanecrew
objectClass: domain
objectClass: domainRelatedObject
associatedDomain: insanecrew.info

Inmediatamente después los dos primeros contenedores donde colocaremos a los usuarios y a los grupos.

# People, insanecrew.info
dn: ou=People,dc=insanecrew,dc=info
ou: People
objectClass: organizationalUnit

# Group, insanecrew.info
dn: ou=Group,dc=insanecrew,dc=info
ou: Group
objectClass: organizationalUnit
description: Container for user accounts

Ahora llega la primera sorpresa, mandriva crea dos unidades organizativas como contenedores de los usuarios y los grupos de los sistemas y servicios que usaran nuestro directorio como fuente para autenticarse.

# System Accounts, insanecrew.info
dn: ou=System Accounts,dc=insanecrew,dc=info
ou: System Accounts
objectClass: organizationalUnit
description: Container for System and Services privileged accounts

# System Groups, insanecrew.info
dn: ou=System Groups,dc=insanecrew,dc=info
ou: System Groups
objectClass: organizationalUnit
description: Container for System and Services privileged groups

Seguimos con otra vuelta de tuerca

# Hosts, insanecrew.info
dn: ou=Hosts,dc=insanecrew,dc=info
ou: Hosts
objectClass: organizationalUnit
description: Container for Samba machine accounts

# Idmap, insanecrew.info
dn: ou=Idmap,dc=insanecrew,dc=info
ou: Idmap
objectClass: organizationalUnit
description: Container for Samba Winbind ID mappings

# Address Book, insanecrew.info
dn: ou=Address Book,dc=insanecrew,dc=info
ou: Address Book
objectClass: organizationalUnit
description: Container for global address book entries

Tenemos una unidad organizativa que contendrá a los host de nuestra red. Seguimos complicando la cosa. otro contenedor para el mapeo de  uids y gid s para integrar samba y winbind con nuestro directorio,  ( en próximos capítulos suplantaremos a cualquier AD).
La última Unidad Organizativa de esta tanda es un contenedor llamado libreta de direcciones ¿Nos dará soporte mandriva para enchufar nuestros clientes de correo al directorio? Pues eso parece.

# sudoers, insanecrew.info
dn: ou=sudoers,dc=insanecrew,dc=info
ou: sudoers
objectClass: organizationalUnit
description: Container for sudo related entries

# dhcp, insanecrew.info
dn: ou=dhcp,dc=insanecrew,dc=info
ou: dhcp
objectClass: organizationalUnit
description: Container for DHCP related entries

# dns, insanecrew.info
dn: ou=dns,dc=insanecrew,dc=info
ou: dns
objectClass: organizationalUnit
description: Container for DNS related entries

Las últimas versiones del paquete sudo permiten enchufarlo contra un directorio  para tener un control más exhaustivo de quién, como y cuando usa sudo en nuestros sistemas. Los servicios de infraestructura basados en GNU/Linux también  se integran con nuestro directorio, DHCP y  DNS. Sí, otra vez como el AD.

# Password Policies, insanecrew.info
dn: ou=Password Policies,dc=insanecrew,dc=info
ou: Password Policies
objectClass: organizationalUnit
description: Container for OpenLDAP password policies

# default, Password Policies, insanecrew.info
dn: cn=default,ou=Password Policies,dc=insanecrew,dc=info
cn: default
objectClass: pwdPolicy
objectClass: namedObject
pwdAttribute: userPassword

# KDEConfig, insanecrew.info
dn: ou=KDEConfig,dc=insanecrew,dc=info
ou: KDEConfig
objectClass: organizationalUnit
description: Container for KDE configuration profiles

# default, KDEConfig, insanecrew.info
dn: ou=default,ou=KDEConfig,dc=insanecrew,dc=info
ou: default
objectClass: organizationalUnit
description: Default KDE configuration for all users

Casi estamos acabando, ¡no sufran!  Los dos primeros contenedores contendrán la política de Password de nuestra empresa. Las dos últimas  Unidades Organizativas son para la configuración del escritorio kde de los puestos de nuestra red. ¡ Quién tuviera KDE en los escritos de usuario!

De un tirón los DN (Distinguished Name) de los usuarios para administrar los servicios en nuestra corporación.

# Account Admin, System Accounts, insanecrew.info
dn: uid=Account Admin,ou=System Accounts,dc=insanecrew,dc=info
uid: Account Admin
objectClass: account
objectClass: simpleSecurityObject
description: Account used to administer all users, groups, machines and genera
l accounts

# nssldap, System Accounts, insanecrew.info
dn: uid=nssldap,ou=System Accounts,dc=insanecrew,dc=info
uid: nssldap
objectClass: account
objectClass: simpleSecurityObject
description: Unprivileged account which can be used by nss_ldap for when anony
mous searches are disabled

# MTA Admin, System Accounts, insanecrew.info
dn: uid=MTA Admin,ou=System Accounts,dc=insanecrew,dc=info
uid: MTA Admin
objectClass: account
objectClass: simpleSecurityObject
description: Account used to administer email related attributes

# XXXX Admin, System Accounts, insanecrew.info
dn: uid=XXXX Admin,ou=System Accounts,dc=insanecrew,dc=info
uid: XXXX Admin
objectClass: account
objectClass: simpleSecurityObject
description: Account used to administer XXXX attributes

Sustituya XXXX por lectores y escritores en DHCP yDNS, SUDO, Libreta de direcciones, kde config..  (Si coloco el ldif entero esto se convertirá en eterno). A continuación tenemos los grupos ( groupOfNames) donde incluir a todos los administradores de los servicios antes nombrados, siguiendo la siguiente estructura

# XXXX Admins, System Groups, insanecrew.info
dn: cn=XXXX Admins,ou=System Groups,dc=insanecrew,dc=info
cn: XXXX Admins
objectClass: groupOfNames
description: Members can administer ou=XXXX entries and attributes
owner: uid=XXXX Admin,ou=System Accounts,dc=insanecrew,dc=info
member: uid=XXXX Admin,ou=System Accounts,dc=insanecrew,dc=info

¡Ya era hora! Menudo lío, nos queda claro, que esto no es un directorio de “chichinabo” como dicen en mi pueblo. mandriva nos coloca a competir directemante en funcionalidad con el  “otro” directorio.
Así que para el siguiente capitulo necesitaremos algo de ayuda:

• La documentación oficial de proyecto en el wiki de mandriva
• La instalación de la consola de administración de mandriva, para manejar todo esto.
• Documentación sobre la integración de DNS , sudo y DHCP con OpenLdap

¿Mande? ¿qué..? Un poco de calma que enseguida me explico…  Este paquete contiene la forma de ver el directorio de nuestra organización (DIT) por  nuestra distro preferida además del corazón de MDS del que ya hablamos aquí.

[root@mdv1 ~]#urpmq  -i openldap-mandriva-dit

Como podemos leer en la descripción del paquete, mandriva nos da “by the face” un ldif básico para cargar en nuestro servidor openldap, además de la estructura del árbol también nos provee de reglas básicas de control de acceso y un pequeño script para facilitarnos la instalación.

[root@mdv1 ~]# urpmi openldap-mandriva-dit
Para satisfacer las dependencias, se instalarán los paquetes siguientes:
Paquete Versión Revision Arq.
(soporte «main_backports»)
openldap-clients 2.4.15 1mdv2009.0 i586
openldap-servers 2.4.15 1mdv2009.0 i586
(soporte «contrib»)
openldap-mandriva-dit 0.17 3mdv2009.0 i586
se utilizarán 3.6MB de espacio de disco adicional.
se descargarán 1.1MB de paquetes.
¿Efectuar la instalación de los 3 paquetes? (S/n)

El tema de las dependencias estaba claro, si es un paquete para ayudarnos a configurar nuestro directorio ldap, tendremos que instalarlo.

El directorio donde se encuentra toda la magia de la cuestión es: /usr/share/openldap:

[root@mdv1 ~]# ls  /usr/share/openldap/
gencert.sh*  mandriva-dit/  schema/  scripts/
[root@mdv1 ~]#

Antes del lanzarnos, como mínimo deberemos de tener claro el nombre de dominio de nuestra organización, en nuestro caso insanecrew.info,  ¡al lío!

[root@mdv1 ~]# /usr/share/openldap/scripts/mandriva-dit-setup.sh
Please enter your DNS domain name [example.com]:
insanecrew.info

Administrator account
The administrator account for this directory is
uid=LDAP Admin,ou=System Accounts,dc=insanecrew,dc=info

Please choose a password for this account:
New password:
Re-enter new password:

Summary
=======
Domain:        insanecrew.info
LDAP suffix:   dc=insanecrew,dc=info
Administrator: uid=LDAP Admin,ou=System Accounts,dc=insanecrew,dc=info

Confirm? (Y/n)

Antes de confirmar, conviene repasar que llevamos hasta ahora

• Hemos definido la raiz de nuestro directorio o RootDN : insanecrew.info
• Definimos la contraseña del administrador del directorio, y a la vez ya sabemos el DN del administrador del Directorio:
  “uid=LDAP Admin,ou=System Accounts,dc=insanecrew,dc=info”

Perfecto, son los primeros pasos a seguir cuando queremos configurar un servidor OpenLdap, decidir el RootDN de nuestro directorio y definir la cuenta/contraseña del administrador del directorio, continuamos  confirmando los datos

config file testing succeeded
_#################### 100.00% eta   none elapsed            none fast!
Stopping ldap service
_#################### 100.00% eta   none elapsed            none fast!
Closing DB…
Finished, starting ldap service
Iniciando slapd (ldap + ldaps):                                 [  OK  ]

Your previous database directory has been backed up as /var/lib/ldap.1241980408
All files that were backed up got the suffix “1241980408″.
[root@mdv1 openldap]#

¡Corcholis!, ¡ya está! comprueba la integridad de los ficheros de configuración, realiza amablemente una copia de seguridad de nuestro antiguo directorio y arranca, así de facil.

Para comprobar que nuestro servidor está funcionando podemos hacer una consulta de este tipo:

[root@mdv1 openldap]# ldapsearch -x -b ” -s base ‘(objectclass=*)’ namingContexts
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts
#

#
dn:
namingContexts: dc=insanecrew,dc=info

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
[root@mdv1 openldap]#

El siguiente comando nos tiene que devolver en formato ldif todo el contenido del directorio:

[root@mdv1 openldap]# ldapsearch -x -b ‘dc=insanecrew,dc=info’ ‘(objectclass=*)’

Volvemos a ejecutar el comando pero esta vez redireccionando la salida a un fichero.

[root@mdv1 openldap]# ldapsearch -x -b ‘dc=insanecrew,dc=info’ ‘(objectclass=*)’ > insane.ldif

En el fichero insane.ldif tenemos el contenido del directorio que será el objeto de nuestro próximo post.

Últimamente llegan visitas, preguntando por la instalación de VMware Server  en mandriva, por un post que publiqué hace meses, intentando instalar  VMware Server en el portátil a pocos días de la liberación de MDV 2009. Ese post está desactualizado y no está completo,  en la actualización del servidor casero con MDV 2008 a MDV 2009 desde cero, seguí el tutorial de falko en howtoforge que me funcionó perfectamente.

La licencia de ese tutorial no está muy clara, por lo que vamos a hacer una traducción-inspiración-libre habiendo citado las fuentes.

• Primero  es necesario saber el kernel que estamos usando para instalar las dependencias
  [root@corsario ~]# uname -r
2.6.29-desktop586-0.rc6.1.1mnb
• Instalación de las dependencias: desde la linea de comandos o desde el centro de control de Mandriva
[root@corsario ~]# urpmi kernel-source kernel-desktop586-devel xinetd perl-devel gcc gcc-c++
Es MUY importante que los paquetes kernel-source y kernel-desktop586-devel coincidan con el kernel que tenemos instalado.
• Nos bajamos el producto desde la Web de VMware , sí, tendremos que registrarnos pero no es para tanto, descargamos VMware Server 2 para Linux ( OJO descarga el tar no el rpm)
• Como root descomprimimos el paquete y ejecutamos el instalador
  tar xvfz VMware-server-*.tar.gz
  cd vmware-server-distrib
  ./vmware-install.pl
• El instalador hace algunas preguntas, ( ninguna demasiado incomoda), para saber más es el momento de acercarnos a blogdrake y al manual de Sinner que las explica “ferpectamente”
• Una vez terminado podemos acceder vía http http://tuip:8222 o https  http://tuip:8333 a nuestro flamante vmware server y empezar a jugetear con él.

Lo primero es lo primero:

# urpmi apache php-mysql phpbb mysql apache-mod_php imagemagick

Ooohh, moskis!! si estos de mandriva lo hacen todo ya por mí.

Respondemos alguna pregunta como el tipo de worker de apache, le ponemos un password al root de mysql , creamos la bbdd.
Modificamos /etc/httpd/conf/webapps.d/phpbb.conf para que nos deje instalar desde otra máquina … et voila!

http://xx.xx.xx.xx/phpbb/ estará listo para empezar a jugar.
“Mañana prometo algo más elaborado …  “

• Cada vez que voy a responder un post en Blogdrake siempre se me adelanta vfmmeo, onnipresencia creo se llama eso.
• No he tenido tiempo de probar MDS pero tengo que evaluar para el curro FDS ¡porca miseria!
• El último kernel de MIB como corre el jodío  ¡ Felicidades a los italianos!

A veces es necesario disponer de varias copias idénticas de nuestro servidor LDAP:

• Cuando el tráfico sea muy alto, para dividir las consultas
• Dotar de alta disponibilidad al directorio
• En el caso de que los clientes estén dispersos geográficamente.

¡La replicación es la solución!

Replicación es el proceso de configuración de un directorio para que mantenga múltiples copias de sus datos en otros árboles sincronizadas en el tiempo. En LDAP, la replicación es un modelo jerárquico, un servidor se considera el maestro, o proveedor, este servidor es el encargado de mantener la última versión de la información del directorio. Bajo el servidor maestro se encuentra uno o más servidores en la sombra (esclavos, replicas o consumidores), un esclavo mantiene una réplica del árbol del servidor maestro y los clientes pueden realizar las consultas sobre uno de los esclavos.. (Los esclavos son de sólo lectura).

Necesitamos tener directorios de respaldo, está claro, en la versión 2.3 de Openldap (La que vamos a usar) todavía no tenemos sincronización multi-master, pero no todo van a ser malas noticias, abandonamos slurpd y vamos a usar syncrelp la nueva forma de sincronizar directorios Openldap.

Lo primero que vamos a hacer es configurar un servidor como maestro. Este servidor escucha peticiones de sincronización de los esclavos y les envía las actualizaciones solicitadas. No es objeto de este manual la configuración SLAPD, asi que supondremos que tiene su directorio perfectamente configurado y ahora vamos a convertirlo en maestro. La funcionalidad de maestro está implementada en el “overlay” syncprov (proveedor de sincronización). Lo primero es cargar el modulo y configurarlo.

En el caso de que nuestro OpenLdap esté configurado por módulos deberiamos de cargarlo.
moduleload syncprov
Por defecto en Red Hat ya viene cargado ese módulo, OpenLdap está compilado de forma monolítica. (Omitimos esa instrucción)
Configuramos nuevos índices que necesitamos en la nueva bbdd preparada para synrepl.

index entryCSN,entryUUID eq

El siguiente paso es cargar y configurar el overlay syncprov. Sólo existen dos directivas de configuración para este overlay, por lo que nuestra configuración quedaría de la siguiente manera:

overlay syncprov
syncprov-checkpoint 50 10
syncprov-sessionlog 100

La primera línea carga el overlay syncprov. La siguiente línea especifica con que frecuencia Syncrepl escribe información en la bbdd y la creación de log.
La mayor parte del trabajo se realiza en el esclavo, bajo la directiva syncrepl

syncrepl rid=001
provider=ldap://directory.example.com
type=refreshOnly
interval=00:00:05:00
searchbase=”dc=example,dc=com”
binddn=”uid=syncrepl,ou=system,dc=example,dc=com”
credentials=secret

En el ejemplo tenemos la minima configuración necesaria para hacer que syncrepl funcione. La directiva tiene 7 parámetros del tip atributos=valor; rid, provider, type, interval, searchbase, binddn, y credentials
El primer parámetro es rid (Replica Identifier), este número de tres dígitos identifica de manera unica a cada uno de los esclavos que atacan un mismo proveedor ( master). La instacia master de SLAPD utiliza el RID del “consumidor” (esclavo) para realizar un seguimiento de lo sservidores que están en contacto con él. Normalmente es mejor empezar con un número bajo de RID y aumentarlo con cada nuevo servidor esclavo. rid=001 será el primer esclavo, si añadiéramos un segundo esclavo sería rid=002

El parámetro provider contiene la url LDAP para el maestro. Cualquier protocolo ldap://host o ldaps://host se puede usar. El host puede ser un nombre de host o una dirección IP el puerto es opccional se puede agregar al final separado por dos puntos, por ejemplo en el caso de usar ldaps e un puerto extraños LDAPS: / / 10.0.1.34:6868. Tenga en cuenta que no se pueden usar url’s de ldap complejas con base’s filtros etc…

El parámetro type determina cual de los modos de replicación utilizará el servidor consumidor (esclavo) para conectar con el proveedor ( maestro). Los únicos valores válidos son refreshOnly (Modo Polling) y refreshAndPersist ( Modo )Push

En nuestro ejemplo hemos utilizado la opción refreshOnly, si utilizamos refreshAndPersist el parámetro intervalo será ignorado. No hay diferencias significativas entre una configuración y otra, si usamos refreshOnly los cambios se replicaran al servidor esclavo en los intervalos de refresco, si usamos refreshAndPersist se transmitiran los cambios inmediatamente después de hacerse en el maestro al esclavo
El parámetro intervalo indica el tiempo que tardará el servidor esclavo antes de verificar si hay cambios en el maestro para actualizarse, En el caso refreshOnly el esclavo conectará al servidor verificará si hay actualizaciones y se desconecta, esperará el tiempo fijado en intervalo para comprobar de nuevo
La sintaxis del parámetro intervalo es: dd:hh:mm:ss, en nuestro caso se refresca cada 5 minutos.
Uno de los problemas del modo refreshOnly es que cuando toque consultar al master para sincronizar no este disponible, por ejemplo por un fallo en el servidor o demasiada carga en lar red. ¿Qué hará el esclavo? Podemos añadir una línea de este tipo: retry=”120 10″, con esta línea el esclavo reintentará la conexión cada 120 segundos 10 veces mientras no este el master disponible

La directiva searchbase es una de las directivas para construir desde donde vamos a sincronizar, en este ejemplo el searchbase coincide con el RootDN, por lo que vamos a sincronizar todo el arbol. El resto de atributos para “complicar” la busqueda son scope, filter, attrs, attrsonly, sizelimit, and timelimit.
Por defecto el atributo scope es igual a sub (la busqueda es en profundidad), el valor del filtro es filter=(objectclass=*) y el attrs=”*,+”, ser recuperan todos los objetos y todos los atributos. Los parametros sizelimit y timelimit tienen como valor por defecto “ilimitado”.
Los últimos parámetros (seis y siete) de la directiva synrepl son binddn y credentials el usuario y el password con el que nos vamos a conectar al SLAPD master. Es obvio que uid=syncrepl tiene que estar creado en el maestro. Los permisos de lectura/escritura sobre el árbol del usuario synrepl deben estar en las ACL’s del master.

Me entero por Blogdrake que en Mandriva vuelven a moverse,  sale Vicent el encargado del equipo de seguridad, que pasa a manos de Oden que vuelve. ¿Pero que será de los paquetes que mantenía Oden?. Vicent era otro de los empleados “freelance” en mandriva.

Parece lógico que en tiempos de crisis recorten a los “freelance”, pero al igual que AdamW, Vicent era uno de los “MDVistas” más reputados en la red.

Es hora de arrimar el hombro, nuestra distro preferida pasa por problemas, nos pide apoyo, como podemos leer en noticiasdrake. Los hispanos nos  prepararamos, los “spaghetti” mueven ficha, tiempos convulsos que recuerdan al pasado.
¿Que voy a hacer yo? Después de leer a Pacho aquí y de despertar de la resaca :
Comenzar a recopilar información para “empaparme” sobre la construcción de rpms en mandriva.

• Como_construir_RPM
• Como_Cooker
• Testzilla
• Quién es quién en mandriva
• FAQ Desarrollo
• Cómo Participar

Empezar a empaquetar algo, supongo que lo más sencillo sería colaborar con MIB ( Mandriva Italia Backports)

Elaborar documentación al respecto para fomentar desde blogdrake la colaboración directa con mandriva aportando “capital humano”.
En el horizonte colaborar activamente en el desarrollo de mandriva, manteniendo algún paquete de contrib

Como esto suena a buenos propósitos para el año nuevo: dejar de fumar, mejorar el ingles (que luego no se cumplen) le pondremos fecha, el primer semestre de 2009 tiene que acabar con algún paquete para mandriva hecho por bersuit

Se agradecen ideas, aportaciones, consejos, sugerencias. No conozco desarrolladores/empaquetadores hispanos, la referencia más cercana es Pacho Ramos,  sinner? dalfa?, vfmmeo? y demás blogdrakeros  no se si alguno  a trabajado en estos temas, espero que se pasen por aquí para aportar algo de su experiencia.