English

warning: Creating default object from empty value in /home/gwolf/drupal6/modules/taxonomy/taxonomy.pages.inc on line 33.

Drupal in Debian: System Integration for Drupal

Submitted by gwolf on Fri, 09/04/2015 - 12:06
Wolf G.  2015.  Drupal in Debian: System Integration for Drupal. Drupal Watchdog. 5:42-43.

As far as how to install and maintain Drupal, it would seem there is no need to dig any further. Installing Drupal in any hosting provider is just a matter of decompressing a tarball, and Drush large-scale automation gives the seasoned sysadmin a wealth of administrative aides. However, when considering integration with the system as a whole, there is ample room for improvement.
Drupal cannot exist outside of a given environment. Say, the PHP version used, the way it is integrated into its host operating system, the modules for connecting to the database — And the database engine itself. Ideally, they will all make up a coherent entity, with a single, unified administrative logic. Looking at each component individually would quickly lead to madness, specially for the sysadmin, who has to keep the whole stack secure and updated.

Debian
Debian is one of the earliest Free Software distributions built around Linux1. By the time this article is printed, Debian 8 (codenamed Jessie) should have been released, with over 35,000 binary packages (that is, independent programs), and lives according to the distribution's motto, the universal operating system: It runs from the smallest embedded devices to the largest workstations, across many different hardware architectures.
System-wide integration
One of Debian's strongest merits that has made it not only exist but be a lively, energetic community with a sound technological platform and projection into the future is its policy: Despite the amount of available packages, they are all standardized: They are all configured in the same location, follow the same layout logic, and are guaranteed not to clash with one another.
But where this policy shines most is when it is applied to keeping things optimally administered: Debian provides
not just easing the installation of the system, but security support throughout the stable release cycle. As it was already stated, our Drupal installs involve quite a bit beyond just Drupal itself. So, on a just-installed system, it's just a matter of stating:
# apt-get install drupal7
And all of the necessary software (that is, an HTTP server, the PHP programming language and execution environment, a relational database engine, and the needed glue between them) will be installed. And, in order to apply all of the pending security and reliability fixes all across the system:
# apt-get update && apt-get upgrade
is all that's needed to get every component in the system up to date.
The Drupal installation is multisite-aware. This means that all of the sites Drupal will respond to are to be configured from the same location: If your host will serve both example.com and anotherexample.org, you only need to create both the /etc/drupal/7/sites/example.com and /etc/drupal/7/sites/anotherexample.org directories and put there the configuration files. All of the codebase will be shared, installed only once in the /usr/share/drupal7/ directory.
This has an interesting advantage security-wise when compared with what I have seen at most shared hosting providers: As the Drupal code belongs all to root, any attacker that manages to subvert Drupal's (or any of the installed modules') security, they will not have enough privileges to modify your site's code and will thus have a harder time leaving a backdoor or modifying your site's behavior for their interests. And even if they got a local privilege escalation exploit, finding their misdeed will be easier as Debian ships cryptographic signatures for all of its files — By simply running:
$ debsums drupal7
any file that was modified will be reported.
Handling
modules
The Drupal ecosystem is very rich on third-party code: Almost 30,000 modules and over 2,000 themes. Packaging them all for Debian is plainly unfeasible — But we have a tool, dh-make-drupal, that takes care not only to package modules and themes pointed to it, but to process dependency handling as well. This way, even having a complex, multi-site and multi-server deployment, it's easy to deliver code with all of the characteristics mentioned in the previous section.
Version stability
Just as, within Drupal, all of the related PHP and Javascript libraries are frozen prior to a release and not changed since that point to avoid breaking internal stability throughout the life cycle of a stable release, packages in Debian are frozen and do not get updated when new versions come out — But in order to keep security tracking to the level required by our users, all important fixes get backportedto the corresponding release.
As an example, Debian 7 (frozen gradually since June 2012 until its release in May 2013) shipped with Drupal 7.14. But that does not mean that it went on for its three years of life unpatched: While feature releases were not incorporated, as you can see in our public Git repository,2 all bugfix releases were.
What about Drupal 8?
Now... With all the hype set in the future, it might seem striking that throughout this article I only talked about Drupal 7. This is because Debian seeks to ship only
production-ready software — And by the time this article is being written, Drupal 8 is still in Beta. Not too long ago, we saw still internal reorganizations of its directory structure.
Once Drupal 8 is released, of course, we will take care to package it. And although Drupal 8 will not be a part of Debian 8, it will be offered through the Backports archive, following all of Debian's security and stability requirements.
Wrapping
up
Of course, I understand the workflow and tools mentioned here are not for every person and situation. Drupal developing is clearly served better by the “traditional” way of installing Drupal. However, for administering a large-scale Drupal installation, operating-system integration through Debian might be just what you need!

( categories: )

Integrating Perl in a wider distribution: The Debian pkg-perl group

Submitted by gwolf on Mon, 03/03/2008 - 17:32
Written in...: 
2007

Perl modules are very well organized in CPAN: They can usually be easily found and, thanks to tools such as the CPAN shell, they are easy to install and update even by novice users. However, when people start using Perl systems (as opposed to using Perl for writing such systems), asking them to take care of the dependencies or having them worry about different distribution architectures is a pain that should be spared from them.
In my talk, I will describe how Debian (and other Free Software distributions) addresses this problem by packaging a large subset of the CPAN archive, what is the task and scope of Debian pkg-perl team, some of the tools we use - and, most importantly, what is the best way for us to interact with you, the upstream authors' community - regarding our bug tracking systems, regarding module building and dependencies information, etc.
I presented this talk at YAPC::Europe 2007, Vienna, August 2007.

Resumen: 

Los módulos de Perl están muy bien organizados en el CPAN: Son fáciles de encontrar, y, gracias a herramientas como el shell de CPAN, son fáciles de instalar y actualizar hasta por usuarios novatos. Sin embargo, cuando la gente no involucrada comienza a utilizar sistemas basados en Perl (en contraposición con utilizar Perl para escribir dichos sistemas), pedirles que se preocupen de cubrir las dependencias o que tengan en mente diferentes arquitecturas de distribución de software es una molestia por la que debemos evitar que pasen.
En mi plática, describo cómo Debian (y otras distribuciones de Software Libre) lidian con este problema, empaquetando un amplio subconjunto del archivo CPAN, cuál es la tarea y misión del equipo pkg-perl de Debian, algunas de las herramientas que utilizamos - y más importante que todo lo demás, cuál es la mejor manera en que podemos interactuar con ustedes, la comunidad de autores - respecto a nuestros sistemas de seguimiento de fallos, construcción de módulos, información de dependencias, etc.
Presenté esta plática en el YAPC::Europe 2007, Viena, agosto de 2007.

ProtoWrap: Using wrappers to protect specific network services

Submitted by gwolf on Sun, 02/10/2008 - 14:20
Written in...: 
2001

I wrote my final paper for graduation on implementing a generic connection wrapper that can be extended to understand and protect specific protocols. I presented this project at YAPC::NA 2001, and published a short article on Usenix's ;login: magazine (published in the June 2002 number).

Resumen: 

Escribí mi proyecto final de graduación implementando un wrapper genérico de conexiones que puede ser extendido para comprender y proteger protocolos específicos. Presenté mi proyecto en el YAPC::NA 2001, y publiqué un corto artículo en la revista ;login: de Usenix, en el número de Junio del 2002.

Security in Perl scripts / Seguridad en scripts de Perl

Submitted by gwolf on Sun, 02/10/2008 - 00:16
Written in...: 
2002

I presented this tutorial at Congreso de Seguridad en Cómputo 2000, and later rewrote it (and moved it to a free, portable format) for Días de Software Libre at Guadalajara, May 2002. In this tutorial, I review some important key points not to fall in security errors while programming with Perl. I later adapted it together with a coworker, Alex Juárez, and we presented it in English at YAPC::Europe 2002. Here you will find this text both in Spanish and in English.

Resumen: 

Un tutorial que presenté para el Congreso de Seguridad en Cómputo en noviembre del 2000, y tras reescribirlo en un formato libre y portable, lo presenté de nuevo en los Días de Software Libre en Guadalajara, mayo del 2002. Lo adapté y traduje junto con mi compañero de trabajo Alex Juárez, y lo presentamos en el YAPC::Europe::2002. Reviso aquí una serie de puntos importantes para no caer en importantes errores de seguridad al programar con Perl. Está tanto en inglés como en español.

What is Free Software?/¿Qué es el Software Libre?

Submitted by gwolf on Sun, 02/03/2008 - 15:52
Written in...: 
2003

I have given this talk on a number of places. It answers a couple of very important questions, that for many people seem to be obvious: What is Free Software? What lies behind our movement? What implications does it have?
Of course, I try to give it a different emphasis, ellaborating on Free Knowledge, on software being an expression of science.

Resumen: 

Plática que he impartido en varios lugares ya que atiende a una duda que mucha gente puede dar por obvia: ¿Qué es el software libre? ¿Qué hay detrás de nuestro movimiento? ¿Qué implicaciones tiene?
Intento, claro está, responder estas dudas dando un énfasis diferente del más común; elaboro sobre del Conocimiento Libre, y en el software como una expresión de la ciencia.

EOT - Expire Old Threads

Submitted by gwolf on Sun, 02/03/2008 - 15:39
Written in...: 
2003

Copyright (c) 2003, 2005 Gunnar Wolf - gwolf@gwolf.org

RATIONALE

I started using mutt as my mail reader a couple of months ago. One of the features I most liked about mutt is that the messages are by default sorted by thread - this really helps following a long conversation in a very active mailing list!

In order to have the threading as complete as possible, I started archiving all my old messages - of course, as mutt users do, I now save each mailing list to a different folder. Life was great.

Resumen: 

Copyright (c) 2003,2005 Gunnar Wolf - gwolf@gwolf.org

RAZONES

Comencé a usar mutt como mi lector de correo hace un par de meses. Una de las características que más me gustaron de mutt es que los mensajes normalmente aparecen ordenados por hilo - esto ayuda realmente a seguir una conversación larga en una lista muy activa!

Para preservar el hilado de los mensajes, decidí archivar todos mis mensajes viejos - claro, tal como acostumbran hacer los usuarios de mutt. Cada lista va para un folder diferente, y la vida es bella.

Sin embargo, la vida no era perfecta. Después de un par de semanas, algunas de mis listas tenían tanto tráfico -con más de 2000 mensajes archivados- que a mutt le tomaba demasiado tiempo ya abrirlos. Y si bien parte de la culpa puedo echársela a que uso buzones en formato mbox, el cambiar a maildir no haría más que posponer este mismo problema por un par de semanas. Y no quería cortar artificialmente el buzón cada cierto tiempo, pues perdería los beneficios de mis queridos hilos.

Me encontré con el maravilloso y tremendamente completo módulo de Perl Mail::Box, y me dí cuenta que mover hilos completos era muy simple, así que escribí este programita que expirara hilos en vez de mensajes individuales.

USO

El uso es muy simple. Antes que nada, como siempre:
eot -h
te dará una lista de las opciones de EOT, todas ellas opcionales (aunque usualmente querrás especificar al menos -f y -F).

Las opciones válidas son:

  1. eot -f <from_mailbox> -t <from_type> -F <to_mailbox> -T <to_type> -p <period>
  2. All arguments are optional.
  3. opt description default
  4. ======================================================================
  5. -f Which source mailbox to use mailbox
  6. -t What format is this mailbox in (mbox, maildir, mh) mbox
  7. -F Which destination mailbox to use mailbox.arch
  8. -T What format is this mailbox in (mbox, maildir, mh) mbox
  9. -p Period of time to declare a thread as old, in days 7
  10. -v Whether to report work statistics to STDOUT 0

-f and -F se refieren a un buzón -un archvio si es tipo mbox o un directorio si es tipo maildir o MH- en el directorio local, o un path completo o relativo al buzón en cuestión.

-t y -T indican el tipo de buzón a abrir - mbox, maildir or mh.

-p indicates how old (in days) should the last message in a thread be
for the whole thread to be considered inactive.

Si no especificas -v, EOT correrá en silencio. Si especificas -v un
corto resumen de actividad aparecerá después de correr.

LICENCIA

EOT is está cubierto por la GNU GPL versión 2 o superior, a tu discreción.
El texto completo de la GNU GPL puede ser encontrado aquí.

REQUISITOS

EOT fue escrito en Perl, y por tanto requiere Perl (versión 5 o
superior). Además de esto, EOT requiere de los siguientes módulos de
Perl:
Mail::Box (probado con 2.038)
Date::Parse - parte de TimeDate (probado con 1.1400)

Puedes encontrarlos en el CPAN. Si usas un sistema Debian, están respectivamente en los paquetes libmail-box-perl y libtimedate-perl.

AUTOR

EOT fue creado por Gunnar Wolf (gwolf@gwolf.org) en mayo del 2003. Puedes usarlo libremente para el propósito que sea, siempre que te
atengas a la licencia GNU GPL.

BAJARLO

Ok, veo que te interesó ;-)

Puedes bajar la versión 1.1 de EOT aquí.

IPManage

Submitted by gwolf on Sun, 02/03/2008 - 15:24
Written in...: 
2003

A system I wrote while working for FES Iztacala. It helps a network administrator on his tough job relating MAC and IP addresses, generating configurations for the DHCP server and for ARP.
Several years later, already working at IIIEc UNAM, I practically re-wrote it from scratch, cleaner, with an object-oriented layer, using the Template Toolkit for the presentation, and as an Apache module (with mod_perl). Both versions are useful and usable - here you have both. Both are, however, in a "snapshot" state, lacking smaller bits of functionality and documentation.
IPManage (2003, CGI-oriented edition)
IPManage (2007, OOP, mod_perl-driven edition)

Resumen: 

Un sistema que hice cuando trabajé para la FES Iztacala. Ayuda a los administradores de redes en su ardua labor relacionando direcciones IP y MAC, generando configuraciones para el servidor de DHCP y ARP.
Varios años más tarde, ya trabajando en el IIEc UNAM, prácticamente lo re-escribí completo, más limpio, con una capa orientada a objetos, utilizando Template Toolkit para la presentación, y como módulo de Apache (con mod_perl). Ambas versiones son funcionales y usables - Aquí están ambas. Ambas están, sin embargo, en un estado de "snapshot", con pequeñas omisiones en lo que concierne a funcionalidad y documentación.
IPManage (versión de 2003, orientada a CGI)
IPManage (versión de 2007, OOP, basada en mod_perl)

TEPATCHE - OpenBSD automatic system patcher / Parchador Automático de sistema OpenBSD

Submitted by gwolf on Sun, 02/03/2008 - 12:57
Written in...: 
2003

RATIONALE

OpenBSD is a stable, robust and secure operating system. Systems administrators running OpenBSD tend to be also more security conscious than administrators running other operating systems. Nevertheless, patching an OpenBSD system can be a tedious process for many people. If a person manages multiple OpenBSD servers, patching each of them can be a long and repetitive task, ideal for automatization.

Resumen: 

RAZONES

OpenBSD es un sistema operativo estable, robusto y seguro. Los administradores de sistemas que corren OpenBSD tienden a ser mas conscientes de la seguridad que los administradores corriendo otros sistemas operativos. En ocasiones, parchar un sistema OpenBSD puede volverse un proceso tedioso para muchas personas. Si una persona se encarga de muchos servidores OpenBSD, el parchar cada uno de ellos puede ser una tarea larga y repetitiva, ideal para automatizarla.
Tepatche revisará periódicamente el sitio FTP que se le indique, y si hay un nuevo parche que pueda ser aplicado, lo descarga, aplica, compila e instala. Tepatche mantiene una pequeña base de datos de estado para saber en que estado se encuentra cada uno de los parches del sistema.

REQUISITOS

  • Una instalación completa de OpenBSD (incluyendo el código fuente en /usr/src y los fuentes del kernel en /usr/src/sys). Tepatche fue probado con OpenBSD versión 3.1, pero mientras se diseñaba, los parches para el 2.9 y 3.0 también fueron estudiados y, como el formato es el mismo, deben de funcionar. Es importante mencionar que la versión 2.9 y versiones mas viejas ya NO SON MANTENIDAS, no hay nuevos parches que sean liberados para ellos. Es importante que se haga una actualización en caso de que estes corriendo una versión vieja.
  • Tepatche usa el módulo de Perl Net::FTP. Puedes instalarlo desde los ports (p5-libnet) ó desde CPAN. Tepatche fue diseñado y probado con p5-libnet-1.0901, la versión de los puertos 3.1.

NOTAS

  • Tepatche esta liberado bajo la licencia BSD - Leer el archivo COPYING
  • Este es código EXPERIMENTAL. A mi me funciona. Sin embargo, es código hecho para ser corrido como root y para modificar binarios vitales del sistema, y un error de programación puede llevar a consecuencias desastrosas.
  • Tepatche asume que los parches publicados en el ftphost especificado son confiables. Si el ftphost (normalmente ftp.openbsd.org o uno de sus espejos) fueran comprometidos, cualquier cosa pudiera pasar. Si Tepatche instala un parche comprometido, puees revertirlo con la opción de parche -R (ver man patch(1)). Hay que notar que Tepatche no correrá cualquier comando que encuentre en un parche, solo los que reconozca... pero hay mucho espacio ahí.
  • Si el aplicar un parche requiere una compilación del kernel, el administrador del sistema DEBE HACERLO MANUALMENTE. Tepatche parchará los fuentes, pero compilar el kernel involucra muchos pasos que requieren que se opere manualmente.
  • Tepatche SOLAMENTE parchará el sistema base - Si usas ports extra, estos NO serán parchados. Por favor véase las notas referentes a los ports y a la auditoría de seguridad en: http://www.openbsd.org/ports.html

USO

Tepatche consiste en un archivo de programa (/usr/local/sbin/tepatche), un archivo de configuración (/etc/tepatche.conf) y un directorio de datos (/var/db/tepatche). El archivo de configuración contiene los siguientes campos:

  • ftphost: Servidor FTP a conectarse (ej: ftp.openbsd.org)
  • ftpdir: La base del directorio FTP para los parches (ej: /pub/OpenBSD/patches/3.1)
  • ftppasv: Donde el modo pasivo FTP es requerido (1) o no (0)
  • ftplogin: usuario y password para ingresar (separado por una coma, ej: anonymous, gwolf@gwolf.cx)
  • archs: Lista separada por comas de arquitecturas a descargar (ej: i386, common) Por favor, recuerda incluir common!
  • patchdir: Donde los parches serán almacenados en nuestra computadora (ej: /var/db/tepatche)
  • statusfile: Localización del archivo de estado (ej: /var/db/tepatche/statusfile)

Con este archivo en su lugar, Tepatche corre simplemente sin argumentos, solo /usr/local/sbin/tepatche. Sugiero que lo corras desde tu crontab (ver man crontab(5)). Sugiero correrlo una vez al día, cuando mucho una vez por cada hora - por favor no inundes ftp.openbsd.org con peticiones cada minuto ;-)

ARCHIVO DE ESTADO

Tepatche mantiene la información que necesita acerca del estado del sistema en el 'statusfile' (por default, en /var/db/tepatche/statusfile). Este es un archivo de texto plano con el siguiente formato:
<descriptor>::<status>
Donde 'descriptor' es una cadena alfanumérica, y 'status' es un número de estado válido. Los números válidos son:

  • 1: nuevo - El parche acaba de ser bajado.
  • 2: aplicado - El parche ya fue aplicado al árbol de fuentes
  • 3: construído - Los binarios relevantes ya fueron generados en el árbol fuente
  • 4: instalado - Los binarios fueron ya instalados en su lugar. El parche ya fue completamente instalado.
  • 5: kernel - El parche requiere recompilar el kernel. Cuando tepatche llega a este estado, el parche fue aplicado, pero aún no ha sido construído..
  • 10: error - Ocurrió un error en algún punto del proceso de parche

El descriptor usualmente llevará el formato <arch>/<num>_<description>.patch - Indica la arquitectura para la cual fue creado, el número consecutivo de parche, una muy corta descripción acerca de su función, y el sufijo '.patch'. Esta es la nomenclatura estándar que sigue el equipo de Open:BSD. Un nombre ejemplo podría ser:
common/001_sshafs.patch
Esto indica que el parche será aplicado a todas las arquitecturas (common), que es el primer parche producido para esta versión del sistema (001), y que corrige problemas relacionados con 'sshafs'.
Si quieres modificar este archivo (claro está, BAJO TU PROPIO RIESGO), puedes seguir estas convenciones para indicar a Tepatche el nuevo estado del parche. Por ejemplo, en la versión 3.1 de OpenBSD apareció un bug muy peligroso en OpenSSH. El equipo de OpenBSD sugirió actualizar de inmediato a OpenSSH 3.4. Posteriormente, para la gente que no actualizó, publicaron un parche (common/006_sshpreauth.patch). Mucha gente ya instaló el árbol de 3.4, con lo que modificaron manualmente el directorio /usr/src/usr.bin/ssh lo cual hace necesario editar /var/db/tepatche/statusfile y reemplazar
common/006_sshpreauth.patch::10
por
common/006_sshpreauth.patch::4

POR HACER

Al menos:

  • Hacer la salida mas amigable (a medio-hacer)
  • Manejo mas confiable de errores (a medio-hacer)
  • (tal vez) incluir un mecanismo de compilación del kernel
  • Probar, probar, probar

DESCARGAS

Puedes obtener Tepatche (actualmente version 0.85) Justo aqui.
Si te interesa leer el artículo publicado en la edición de diciembre del 2003 de SysAdmin, aquí lo tienes.

¿POR QUE TEPATCHE?

Tepatche es una bebida ligeramente alcohólica en México, en donde yo vivo y donde el programa fué concebido. Tepache es el resultado de
fermentar piña en agua. Tomado de http://www.fao.org/docrep/x0560e/x0560e09.htm :
Tepache es una bebida ligera, refrescante preparada y consumida en todo México. En el pasado, el tepache era preparado con maíz, pero en la actualidad varias frutas como la piña, manzana y naranja son usados. La pulpa y el jugo de la fruta son puestos a fermentar por uno o dos días en agua con algo de azucar morena. La mezcla es puesta en barriles de madera sin tapa llamados "tepacheras", que se cubren con trapos queseros. Después de uno o dos días, el tepache es una dulce y refrescante bebida. Si se deja fermentar por mas tiempo, se convierte en una bebida alcohólica y después en vinagre. Los microorganismos asociados con el producto incluyen al Bacilo Sutbtilis, Torulopsis insconspicna, Saccharomyces cerevisiae y Candida queretana (Aidoo, 1986).
Si eres curioso, puedes encontrar recetas de como preparar tepache (en español) en http://www.chi.itesm.mx/chihuahua/arte_cultura/cocina/bebidas/tepache.html o http://mexico.udg.mx/cocina/bebidas/tepache.html

AGRADECIMIENTOS

Primero y sobre todo, quiero agradecer al equipo de OpenBSD por la increíble cantidad de trabajo que hay puesto en este proyecto.
En menor escala, Tepatche no hubiera sido posible sin la ayuda de OpenBSD México. En este proyecto específico, recibí una gran ayuda de Alex Juárez, César Yáñez y Karl Heinz Holtschmit.
Por supuesto, quiero agradecer a mi lugar de trabajo, UNAM FES Iztacala, por permitirme en trabajar en seguridad y software libre por casi 3 años - Y espero sean muchos mas.

Syndicate content