Entradas con la etiqueta “Linux”

Tar: excluir ficheros cuando haces un tar

2 de septiembre, 2011 - por | | Linux, Tips

En bastantes ocasiones me he encontrado con la necesidad de empaquetar código pero excluyendo ciertos ficheros/directorios. Cuando se trata de una exclusión pequeña, con unos pocos ficheros, hago lo siguiente.


$ tar -zcf backup.tar.gz --exclude='fichero1' /home/imedina/code

Cuando se trata de un número mayor, es más cómodo crear un fichero con un listado de todos aquellos ficheros que quieres excluir.


# exclude.txt
fichero1
fichero2
*.jpg

Luego, haces el tar de la siguiente forma.


$ tar -zcf backup.tar.gz -X exclude.txt /home/imedina/code

Es importante recordar que lo que hemos hecho con ficheros, lo puedes hacer igualmente con directorios (puesto que no dejan de ser ficheros).

Actualizar WordPress por SSH

10 de agosto, 2011 - por | | Sistemas, Tips

Tenemos que ir más allá de nuestros límites corporales para conseguir muchas cosas.

WordPress incluye desde hace tiempo la posibilidad de actualizar directamente desde el admin tanto el core, como los plugins y los temas. Es decir, los 3 componentes principales. Para nosotros, que manejamos múltiples WordPress, es la forma más cómoda de mantenerlos actualizados.

La lástima es que la interfaz del admin sólo menciona la posibilidad de hacerlo por FTP, cuando en realidad también existe la alternativa de hacerlo por SSH. Lo único que hace falta es que tengas instalada y funcionando en tu servidor la extensión SSH2 para PHP; una vez la tienes corriendo, verás cómo WordPress te enseña en la misma pantalla de actualización la posibilidad de hacerlo por SSH.

Si te mueves en Linux, en la mayoría de las distribuciones recientes instalar la extensión SSH2 para PHP es muy fácil: no te exige compilar nada, como hace unos años. Por ejemplo, para Debian/Ubuntu este post de Kevin van Zonneveld te lo resuelve todo (en inglés).

Ahora bien, si te mueves en CentOS, y te has animado a probar PHP 5.3 sobre esa plataforma, la cosa desgraciadamente se complica un poco. Si estás interesado en ésto, te lo explicamos en este otro post.

Instalar MySQLdb-Python en CentOS para utilizar sobre Django

6 de agosto, 2011 - por | | Sistemas, Tips

Si desarrollas sobre Django y lo haces tirando de una base de datos sobre MySQL, conectar Python a ésta en un entorno CentOS puede ser más difícil de lo que uno imagina. El paquete que CentOS instala por defecto para el driver de MySQL (“MySQL-python”) no cumple con los requisitos de Django, por antiguo. Así que si intentas hacer la instalación habitual:


yum install MySQL-python

te encontrarás con que cuando vas a levantar tu instancia de Django, ésta dice que no puede conectar a MySQL.

La solución más efectiva es tirar de “easy_install”:


easy_install mysql-python

Como lo que vas a ejecutar es una compilación de las fuentes del driver, tienes que tener instalados “gcc” y “python-devel”. De lo contrario, verás que aparecen errores de compilación. Para instalar éstos:


yum install gcc


yum install python-devel

Artistas del mail

12 de diciembre, 2009 - por | | Curiosidades, Kernel

Si has tenido la curiosidad de trastear alguna vez con el kernel de linux, habrás visto que hay todo un directorio dedicado a documentación, tanto general como particular, ésta última organizada a su vez en directorios que se corresponden con las partes del sistema.

Bueno, el caso es que dentro de la documentación general hay varias joyitas literarias, entre las que suelen destacar las firmadas por Linus Torvalds, el alma mater del proyecto. Una de esas joyitas es el fichero “email-clients.txt”, que describe algunos de los requisitos que debe tener el cliente de email con el que trabaje el desarrollador. ¿Por qué? Pues porque los patches para el kernel de linux se envían a través de emails, y a poder ser, como texto dentro del cuerpo del mensaje. Ésto no es siempre así; el “mantainer” del código puede que acepte adjuntos, pero incluso en ese caso, hay toda una serie de reglas que deberías respetar cuando compongas el adjunto.

Es un nivel de detalle, y para algo que ya nos es tan familiar, que estas cosas son las que me conquistan siempre dentro del espíritu de linux: no hay ninguna barrera humana -cualquiera puede hacerte llegar el patch-, pero se establecen ciertas convenciones -que éstas sí se siguen rigurosamente- para que el trabajo resulte productivo y esa no-barrera pueda llegar a ser una realidad. Por ahí le vas viendo el sentido a toda la arquitectura liviana del entorno: “todo se trata como un fichero”, “pequeñas utilidades que se interconectan”, “cuanto más complejo, más probabilidad de errores”, etc.

Para que veais lo seria que se pone la cosa con la composición de emails, transcribo algunas de las convenciones:

Don’t let your email client do automatic word wrapping for you. This can also corrupt your patch.

Email clients should generate and maintain References: or In-Reply-To:
headers so that mail threading is not broken.

It’s a good idea to send a patch to yourself, save the received message,
and successfully apply it with ‘patch’ before sending patches to Linux
mailing lists.

Lotus Notes (GUI) Run away from it.

Si te parece interesante, échale a un vistazo a otros ficheros tan instructivos como éste en el repositorio del proyecto.

Lecciones de bazaares

13 de noviembre, 2009 - por | | Open Source

En el libro de Eric Raymond, The Cathedral & the Bazaar, hay una parte que me gusta especialmente: aquélla en la que el autor reconoce cómo de chocante les resultó, incluso a los mismos que se encontraban ya en los círculos del desarrollo abierto entre los 80 y los 90, la forma en que el por entonces emergente linux se organizaba. Es donde mejor se aprecian las diferencias entre los 2 mundos que dan título al libro: la catedral que ellos conocían como forma de trabajar, relacionarse y construir, frente al bazaar linuxero lleno de novedades más sociales que técnicas.

Algunas de las que más me gustan:

  • no hay barreras de entrada, la contribución puede llegar de cualquiera en cualquier momento
  • los usuarios se transforman en co-desarrolladores
  • no tiene sentido no beneficiarse de una base cuanto más grande mejor de beta-testers y co-desarrolladores que a la postre se acaban convirtiendo en otras partes del proyecto
  • las fronteras tradicionales entre los profesionales/especialistas y los “otros” se diluyen

Las sensaciones que debieron tener todos aquellos grupos de ingenieros altamente especializados, que habían conseguido hacerse con un espacio propio donde ellos ponían las reglas y marcaban las distancias respecto de todo lo “externo”, seguro que fueron muy mezcladas. Otra vez, las batas se diluían, como habían hecho ellos a su vez con la generación anterior, para dar paso a una nueva forma de hacer las cosas que encima se demostraba productiva.

La evolución otra vez: les llegaba el turno esta vez a los barbudos que un día jubilaron a los encorbatados. Es algo que aún hoy no se ha acabado de asimilar, y todas las modas de palabras sobre redes sociales, web 2.0, etc. dicen mucho al respecto.

Entrevista a Linus Torvalds – Parte I (quinta entrega)

11 de marzo, 2009 - por | | Kernel, Linux

Seguimos con la entrevista a Linus Torvalds. Si no has leído la cuarta entrega, ¿a qué esperas?.

Jim Zemlin: Una de las cosas de las que hablaste fue el incremento en la complejidad en la forma en que la interfaz interactúa con el núcleo y cómo los controladores del dispositivo son parte de ésta.

Yo me he preguntado muchas veces, algo que probablemente no te sorprenderá, ¿por qué no el núcleo tiene un controlador de dispositivo ABI estable?

Linus Torvalds: Bueno, la falta de una ABI tiene dos vertientes: una es que realmente, realmente, realmente no quiero una. Cada vez que la gente me pregunta por una ABI estable, creo que la razón principal para querer una ABI estable es que quieren tener su controladores binarios y que no quieren dar a conocer la fuente – no quieren fusionar su fuente con el Kernel o el núcleo estándar.

Esto, a su vez, significa que todas las personas que realmente trabajan en el Kernel no pueden, al mismo tiempo, trabajar con esa pieza de hardware y con los proveedores, ya que si hubiera cualquier error no podría arreglarlos.

Por lo tanto, todos los proveedores comerciales, incluso los que utilizan los controladores binarios, se están trasladando o alejando de los controladores binarios, ya que son completamente insostenibles.

Así que esta es una de las razones. Algunas personas creen que se trata de algo político. Y, probablemente, exista un aspecto político en esta decisión. Sin embargo, hay un aspecto mucho más pragmático y es que no se puede mantener.

Jim Zemlin: Esto suena como otro de esas cuestiones culturales por la que la gente parece apoyar los controladores binarios si hay beneficio sin entender, quizá, el beneficio de contribuir al soporte.

Linus Torvalds: Bueno, no se trata tanto del beneficio de la contribución al soporte como a la distribución del mismo. Quiero decir, puede que no termine teniendo el soporte de la mayoría de los dispositivos, pero acaba siendo el tipo de apoyo que necesito cuando tengo un gran problema.

Y cuando tienes ese tipo de sistema de apoyo distribuído – donde todo el mundo termina estando involucrado en algún momento -, no puedes darte el lujo de tener la situación en la que sólo unos pocos, de hecho, tienen acceso al código que puede estar causando el problema. Necesitas tener el código por ahí, no debido a cuestiones sociales, sino, simplemente, porque no sabes quién va a ser el que tiene que arreglarlo.

Así que hay una verdadera razón por la que necesitamos poder acceder al código fuente, lo que significa que para todos los desarrolladores del kernel, un interfaz binario es, básicamente, una mala cosa. No hay duda alguna.

Pero hay otra razón que es la que hace, realmente, que se desencadenen las cosas, de manera irremediable, en el interior del Kernel y que ha dado lugar al hecho de que, incluso aunque quisiéramos disponer de un interfaz binario, no podríamos. Y es que nos implicaría cambiar el cómo hacemos las cosas internamente.

Y esto es algo que ves en otros proyectos en los que, sí, tienen interfaces binarias por una u otra razón – muy a menudo debido a razones comerciales -. Esto significa que no pueden fijar un diseño fundamental. Ellos no sólo listan los interfaces binarios sino que también listan el diseño exacto tal y como se lo encontraron.

Además hay una segunda razón de peso por la que no se va a desarrollar una ABI estable; de hecho, significa que no garantizamos siquiera una API estable. Así, incluso a nivel de código fuente nosotros decimos: “Okay, este es el API, y si tú tienes drivers externos que la utilizan, te ayudaremos a corregirlos cuando tengamos que cambiar el API, pero no te garantizamos que el mismo API funcionará con todas las versiones”.