Cambios en shorewall 3.0

Una rápida. En shorewall 3.0 han modificado la manera de especificar las reglas del firewall en /etc/shorewall/rules. Donde dije:

AllowSSH    net:$MI_IP    fw

Ahora digo:

SSH/ACCEPT    net:$MI_IP    fw

Han cambiado /usr/share/shorewall/action.* por /usr/share/shorewall/macro.*. Antes utilizando el sistema de actions sólo podías hacer el Allow, mientras que con las macros le puedes pasar el parámetro de la acción a ejecutar (ACCEPT, REJECT, etc), bastante más flexible.

Hosting virtual masivo a medias

En Apache es posible configurar de manera muy fácil el hosting virtual masivo de manera general a nivel de servidor, pero hay un caso con el que me he encontrado que no se especifica y que paso a describir:

Tenemos una sola máquina con una sóla dirección IP y muchos nombres de máquina apuntando a ella. Podemos montar de manera muy fácil un hosting virtual masivo, con las mismas configuraciones para todos los dominios. Este caso es diferente, ya que necesitamos tratar uno de los dominios de manera especial, puesto que ese tiene muchas más visitas que los demás y queríamos dividir el log de apache en dos: uno para el dominio gordo y otro para los otros más pequeñitos.

Conseguir esto en Apache 1.3 me llevó un par de tardes, pero al final lo conseguí con una configuración similar a estas (parece una chorrada, pero cuando me encontré con ello no vi ni un sólo ejemplo por ningún sitio):

NameVirtualHost ip_del_server
ServerName nombre_oficial

<VirtualHost>
   VirtualDocumentRoot /var/www/sitios/%0
   CustomLog /var/log/apache/log_pequeñito combined
</VirtualHost>

<VirtualHost>
   ServerName www.gordo.com
   DocumentRoot /var/www/docroot/
  CustomLog /var/log/apache/log_gordo combined
</VirtualHost>

La idea aquí es aislar dos configuraciones, una para el dominio gordo y la otra, que será común para el resto de dominios. Para que funcione es necesario que la definición del hosting masivo esté la primera, ya que la primera definición la pilla como default y van todas las peticiones a ese host (siempre y cuando no haya definido otro VirtualHost cuyo ServerName coincida con la petición).

Así, si viene una petición a www.gordo.com, ésta seguirá las configuraciones de su host virtual. En cualquier otro caso se utilizará la configuración del hosting masivo.

Eh Broda' print me

El sistema de impresión en Linux siempre ha sido una cosa que me ha fascinado y aterrorizado a partes iguales. Cuando en mis tiempos mozos me miré cómo configurar una impresora con el sistema LPD me entraba un nosequé que queseyó.

Hoy en día con CUPS todo es más fácil. No te tienes que preocupar de los filtros a utilizar, puedes elegir la impresora de un listado... y con la ayuda de linuxprinting todo se hace mucho más sencillo. Y aún más cuando la impresora que tienes que instalar es PostScript, con las que sólo hace falta enchufarle el fichero PPD y listos.

Listos... si el PPD está bien. Hoy en el curro he tenido un pollo con una impresora de esas que pasan de departamento en departamento "porque no va bien". La impresora está muy apañada, es una Brother HL-2700CN láser y a color, y lo único que "no va bien" es que tiene la correa un poco rayada y deja unas rayitas en la parte superior de la página. La cuestión es que ayer la instalé, utilizando el paquete linuxprinting.org-ppds de Debian Etch, que trae zillions de ppds para todo lo habido y por haber. En principio iba todo bien hasta que hoy me han dicho que había un PDF que no imprimía bien.

Después de romperme la cabeza y activar algunas opciones de la impresora he llegado a la conclusión de que había algo en un logo del PDF que hacía que se le enviaran órdenes PJL a la impresora (y evidentemente ésta no las soporta). Una vez modificado el logo (que tenía toneladas de mierda en pseudo-xml embebidas en la imagen por el Photoshop) me salía otro error al intentar imprimir el mismo PDF:


ERROR NAME:

undefined

COMMAND:

-12345X@PJL

OPERAND STACK;


Pues buscando por ahí he visto que es un error relacionado con una orden PostScript que no está soportada por la impresora, pero ¿quién mandaba esa orden? La respuesta es.... ¡el propio ppd! Vamos, que tenía un "driver" para una impresora que contenía instrucciones no soportadas por esa impresora. Cojonudo.

Buceando por el ppd he comentado unas líneas que parecían las ofensivas y todo ha comenzado a ir rodado (una vez reiniciado el servidor CUPS):

*%JCLBegin: "<1b>%-12345X@PJL JOB<0a>"
*%JCLToPSInterpreter: "@PJL ENTER LANGUAGE = POSTSCRIPT <0a>"
*%JCLEnd: "<1b>%-12345X@PJL EOJ <0a><1b>%-12345X"

La verdad es que no sé si esa es la forma correcta de solucionar el error, pero desde que he realizado los cambios todo va a la perfección.

Probando, probando

Bueno, esta es mi primera entrada al blog. No me gustan mucho estas cosas, ya que prefiero perder el tiempo en otras cosas, así que me lo tomaré como un tabló de "apuntes" para cositas que me vayan surgiendo ;)