Mis choremas

Crear usuarios es una tarea fácilmente realizable mediante la interfaz gráfica del sistema, sin embargo, puede resultar útil para un administrador conocer el modo de hacer lo mismo mediante la línea de comandos, ya sea para agregar muchos usuarios de una sola vez o para un proceso de automatización.

El programa a utilizar se llama dscl y he aquí algunos ejemplos de su uso (es necesario ejecutarlos como root):

Para crear un usuario nuevo en el sistema local:

dscl / -create /Users/nuevoUsuario

Asignación de un shell adecuado:

dscl / -create /Users/nuevoUsuario UserShell /bin/bash

Agregar el nombre completo del usuario:

dscl / -create /Users/nuevoUsuario RealName "Nuevo Usuario"

Asignarle un número de id:

dscl / -create /Users/nuevoUsuario UniqueID 99999

Asignarle un id de grupo:

dscl / -create /Users/nuevoUsuario PrimaryGroupID 1000000

Asignarle un directorio base (home folder):

dscl / -create /Users/nuevoUsuario NFSHomeDirectory /Users/nuevoUsuario

Finalmente asignarle una contraseña:

dscl / -passwd /Users/nuevoUsuario PASSWORD
o bien:
passwd nuevoUsuario

Si acaso se desea que el nuevo usuario pueda administrar el equipo:

dscl / -append /Groups/admin GroupMembership nuevoUsuario

Hay ocasiones que el comando tal como aparece no se ejecuta, dando lugar a un mensaje de error; en esos casos se deberá cambiar la sintaxis:

dscl / …

por:

dscl . …

Proximamente: Modificación de la sintaxis del comando para agregar usuarios a un directorio maestro residente en otra computadora.

Desde hace varias versiones del sistema operativo es posible establecer conexiones de red con servidores Windows directamente desde el Finder, desafortunadamente siempre existen variables que pueden provocar todo tipo de inconvenientes durante la comunicación.

A veces son detalles en la configuración del algún servidor, a veces se trata de algún ajuste en la computadora que se quiere conectar, pero el resultado invariablemente es la frutración del usuario.

Resulta que en la versión 10.5 del sistema operativo (y tal vez desde antes) una de tantas variables que hace ruido al establecer una conexión con un servidor Windows está del lado de la Mac. Algunos servidores no entienden ciertos mensajes que la computadora maneja mientras se conecta con ellos, por lo que la comunicación resulta extremadamente lenta, tanto, que copiar unos pocos MegaBytes puede tardar horas.

Aunque es posible configurar los servidores para que ignoren esos mensajes generalmente es imposible, ya que no están al alcance de uno o simplemente las políticas del lugar impiden realizar cambios (más aun si todos los demás no tienen dificultades para conectarse). ¿Qué queda entonces?, decirle a la Mac que deje de usar esos mensajes.

El comando ‘mágico’ para que la comunicación entre un cliente Mac y un servidor Windows se agilice es:

sudo sysctl -w net.inet.tcp.delayed_ack=0

Una vez entrado el comando en la Terminal la comunicación con el servidor Windows cambia totalmente, a partir de ese momento copiar algunos GigaBytes entre computadoras tomará unos pocos minutos.

Desafortunadamente el ajuste anterior se perderá cuando se reinicie el equipo.

Cuando se desarrollan sitios web es práctica normal guardar todo el desarrollo en una carpeta, la cual puede ser accedida de distintas maneras usando el servidor web incluido en el sistema (Apache).

La ubicación por omisión puede ser un poco problemática para trabajar, ya que solo un usuario con privilegios de administrador puede hacer modificaciones ahí (aunque ese tipo de usuario es el primero que se crea cuando se instala el sistema); un punto a favor de esa carpeta es que para accederla a través del servidor web su dirección es corta: http://localhost/proyecto1

Pero a veces el usuario del equipo no necesariamente es administrador del mismo (y aunque lo sea, es una buena medida de seguridad trabajar como un usuario sin privilegios), por lo que hacer modificaciones a la carpeta por omisión del servidor web no es posible; en esos casos es necesario utilizar la carpeta “Sites” (o “Web”) de cada usuario para guardar el proyecto en desarrollo. La dirección para acceder a la carpeta es un poco más larga: http://localhost/~usuario/proyecto1

Existe una tercera opción todavía más corta y adecuada si, por alguna razón el sitio en desarrollo debe estar en un primer nivel, sin directorios intermedios; algo como: http://proyecto1

Para lograr algo así es necesario utilizar una opción del Apache llamada “Virtual Hosts“, lo que le permite al servidor web responder a distintos nombres (y por lo tanto hospedar distintos sitios) en una misma dirección. De esta manera la carpeta con el sitio en desarrollo puede estar en casi cualquier lugar del disco duro, siempre y cuando sea accesible por el usuario bajo el cual corre el servior web, para asegurar que así sea, es adecuado seguir trabajando en la carpeta “Sites” (o “Web”).

En el archivo de configuración del Apache ubicado en /etc/apache2/extras/httpd-vhosts.conf, está lo necesario para activar el hospedaje virtual:

NameVirtualHost *:80
#
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for all requests that do not
# match a ServerName or ServerAlias in any <VirtualHost> block.
#
<VirtualHost *:80>
    ServerAdmin webmaster@dummy-host.example.com
    DocumentRoot "/www/docs/dummy-host.example.com"
    ServerName dummy-host.example.com
    ServerAlias www.dummy-host.example.com
    ErrorLog "/private/var/log/apache2/dummy-host.example.com-error_log"
    CustomLog "/private/var/log/apache2/dummy-host.example.com-access_log common"
</VirtualHost>
<VirtualHost *:80>
    ServerAdmin webmaster@dummy-host2.example.com
    DocumentRoot "/www/docs/dummy-host2.example.com"
    ServerName dummy-host2.example.com
    ErrorLog "/private/var/log/apache2/dummy-host2.example.com-error_log"
    CustomLog "/private/var/log/apache2/dummy-host2.example.com-access_log common"
</VirtualHost>

Como el mismo texto del archivo indica, el primer bloque “VirtualHost” va a ser el comodín que el servidor usará para contestar todas las solicitudes que le lleguen, mientras que los subsecuentes serán las configuraciones que se utilicen según el nombre que se le asigne a cada una. Así por ejemplo con un proyecto almacenado en el directorio “Sites” la configuración quedará más o menos así (se han eliminado opciones por motivo del ejemplo, para más detalles hay que revisar el manual del Apache):

NameVirtualHost *:80
<VirtualHost *:80>
    ServerName localhost
    DocumentRoot "/Library/WebServer/Documents"
</VirtualHost>
<VirtualHost *:80>
    ServerName proyecto1.com
    DocumentRoot "/Users/usuario/Sites/proyecto1"
</VirtualHost>

Desafortunadamente eso no es todo, para que el servidor realmente pueda reponder a nuestras solicitudes para el nuevo nombre, son necesarias dos cosas: reiniciar al Apache y decirle a la computadora donde encontrar la dirección proyecto1.com.

Reiniciar el Apache se puede hacer de dos formas, la primera es apagando el “Web Sharing” en el panel “Sharing” en “System Preferences” y volviendo a activarlo unos instantes después. La segunda opción es mediante la Terminal, utilizando el comando sudo apachectl graceful (es necesario estar como administrador del sistema para poder ejecutar ese comando).

Indicacarle a la computadora dónde puede localizar al servidor proyecto1.com también es sencillo y, al igual que lo anterior, existen dos maneras de hacerlo: la fácil y la que aprueba Apple (también fácil, pero no tanto).

La manera fácil:

Usando nano en la Terminal o un programa como TextEdit, TextWrangler o BBEdit, es necesario modificar el archivo /etc/hosts y hacer que se parezca a algo como esto:

127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost

127.0.0.1 proyecto1.com

El último renglón es el cambio a efectuar, lo demás es el contenido original del archivo, el cual no debe ser modificado. Como es de esperarse es necesaria la clave de administrador para modificar este archivo.

La manera oficial:

Esta manera de agregarle al sistema direcciones ficticias es la que Apple aprueba y permite otras funcionalidades que no se logran únicamente con modificar el archivo /etc/hosts. Para este fin existe una utilierá de nombre dscl. Para ver la lista de direcciones existentes se usa el comando de la siguiente manera:

dscl localhost -list /Local/Default/Hosts

En un sistema sin alteraciones el comando no va a mostrar nada, para agregar la modificación que se desea el comando toma la forma:

sudo dscl localhost -create \
/Local/Default/Hosts/proyecto1.com \
IPAddress 127.0.0.1

Para verificar que la información quedó bien:

dscl localhost -read /Local/Default/Hosts/proyecto1.com
AppleMetaNodeLocation: /Local/Default
IPAddress: 127.0.0.1
RecordName: proyecto1.com
RecordType: dsRecTypeNative:hosts

El paso final:

Sea por la manera fácil o por la oficial, el último paso es limpiar la caché de direcciones del sistema en la Terminal:

dscacheutil -flushcache

Después de todo esto lo último que falta por hacer es apuntar el navegador a la dirección http://proyecto1.com y revisar que el sitio aparezca en la ventana del navegador.

En muchos aspectos el sistema operativo Mac OS X facilita el trabajo y hasta invita a explorar un poco más mientras se utiliza la computadora. Desafortunadamente no existen las cosas perfectas, y ese mismo sistema puede convertirse fácilmente en un obstáculo cuando, aparentemente de la nada, las cosas comienzan a fallar.

Siendo una bestia demasiado complicada, formada por un montón de partes que deben de funcionar en conjunto para que todo se mueva, a veces no es fácil rastrear qué es lo que provoca una falla cuando alguno de esos “pequeños trabajadores” internos no hace su labor adecuadamente.

Esta ocasión me tocó lidiar con un problema de impresión que comenzó justo después de actualizar las computadoras de los laboratorios a la versión 10.5.5 del sistema operativo (actualización que “brinda mejoras generales en el sistema”, imagínense). La actualización se realizó un viernes en la noche, pero no se hizo evidente sino hasta el lunes por la mañana cuando los alumnos comenzaron a enviar trabajos a impresión. Las impresoras simplemente no tomaban el papel tabloide cuando se les solicitaba, así como tampoco imprimían por ambos lados.

Entre apuros de otro tipo y el que no daba con una respuesta adecuada, tardé unos días en hallarla, al igual que una explicación del por qué fallaba todo.

En el sitio de Adobe ya tienen identificado el problema, ya que afecta principalmente a sus aplicaciones Illustrator e InDesign (mismas que mayoritariamente usaron los alumnos estos días), y la solución que ahí se propone básicamente consiste en dejar que el sistema controle la impresión (esos dos programas tienen la capacidad de ser su propio controlador de impresión y manejan la información que se envía a la impresora de manera directa, aparentemente brincándose al sistema).

Pero en los foros de la misma empresa, alguien de nombre “Thomas Kaiser” describe la manera como trabajan los programas de Adobe y su interacción con el sistema de impresión de la Mac. Resulta que con la actualización a la versión 10.5.5 Apple introdujo cambios en el sistema de impresión que interfieren con la manera de trabajar de los programas de Adobe, y tal vez con los de otras empresas, provocando que las impresoras se confundan. El problema consiste en algo como lo siguiente: el programa que envía el trabajo de impresión incluye como parte del archivo información sobre el tamaño del papel, por ejemplo, y el sistema de impresión de la Mac a su vez vuelve a introducir esos datos, a veces inconsistentes, provocando que la impresora no sepa que hacer (¿a quien le va a hacer caso?), como “medida de precaución” la impresora utiliza sus valores de fábrica y con eso realiza la impresión.

En los foros de Apple, MacTips y otros sitios, hacen referencia a una solución publicada en los foros de Adobe, la cual consiste en reemplazar el archivo encargado de procesar los archivos PostScript antes de su envío a la impresora, por una versión anterior.

El archivo en cuestión se llama pstops, localizado en /usr/libexec/cups/filters. Se puede obtener una versión anterior de una computadora con Mac OS X 10.5.4, o del instalador combinado a la misma versión, en el último caso es necesario contar con un programa como Pacifist para extraer el archivo del paquete de instalación.

En mi caso tuve que hacer la extracción del instalador combinado, ya que todas las computadoras habían sido actualizadas a la versión 10.5.5. Una vez extraído e instalado en mi computadora pude copiarlo a todas las demás con la ayuda del Apple Remote Desktop, afortunadamente el archivo pstops es idéntico para la versión Server del sistema, por lo que fue posible copiarlo también al servidor que se encarga de las filas de impresión.

Algunos días, alumnos frustrados y ojos cansados después, ya están las impresoras trabajando correctamente desde todas las computadoras en los laboratorios y desde todos los programas, incluidos los dos de Adobe: Illustrator e InDesign.

En una entrada anterior había comentado que los trabajos de impresión que llegan a una fila en el servidor, por omisión no quedan retenidos, por el contrario pasan directamente a la impresora.

En un entorno de laboratorios eso no es deseable, ya que esto propicia mucho desperdicio de papel, por lo que es mejor que los trabajos queden retenidos en el servidor hasta que quien los envió solicite que sean liberados.

El comando que mencioné en esa ocasión resulta que no es del todo funcional en la version 10.3.9 del Mac OS X Server, ya que por alguna razón no se queda fija, simplemente funciona en algún momento pero al poco rato se quita y todo regresa como estaba.

Una posible solución fue colocar ese comando es un script ejecutado por cron cada hora, el resultado fue el mismo. Se cambió a un intervalo de un minuto y de todas maneras resultó igual.

Finalmente di con la respuesta, y la verdad me pregunto porqué no la encontré antes, está documentada en el propio sitio de Apple:

Mac OS X Server 10.3: Setting default print job status to hold

No es un procedimiento difícil aunque siento que es un poco rebuscado, pero también queda la duda de porqué fue eliminada esa opción de la interfaz gráfica de administración; sólo Apple sabe.

Desde que las computadoras pudieron conectarse entre si para compartir información también nació la necesidad de que los registros sobre los usuarios pudieran conocerse entre equipos, de esta manera quien estuviera registrado podría utilizar cualquier equipo en la instalación.

Conforme las redes crecen y se diversifica el uso de las estaciones de cómputo, el permiso de uso necesita restringirse de algún modo, al mismo tiempo se vuelve necesario juntar los datos de los usuarios en algún lugar donde sea más sencillo administrar su información. Para realizar estas tareas surgieron sistemas de administración de directorios, los cuales han sido varios y de distintos proveedores, casi siempre incompatibles entre si, a pesar de ello varios lograron establecerse y eventualmente también apareció un estándar que ahora es la base de la mayoría.

Algunos de estos sistemas tienen nombres somo “Active Directory” de Microsoft o “eDirectory” de Novell, el estándar que ha moldeado a todos ellos se llama “LDAP” (Lightweight Directory Access Protocol). Por otro lado NeXT, antes de que fuera adquirida por Apple, desarrolló su propio sistema llamado “NetInfo”, el cual cubre las mismas necesidades.

En general todos los sistemas mantienen una base de datos central donde se administra la información de los usuarios, así como toda una serie de permisos para utilizar o no ciertos recursos disponibles en red, dicha información se puede mantener en uno o varios servidores e incluso, puede estar escalonada de tal forma que algunos datos sean exclusivos de algunas zonas mientras que otros pueden ser globales para la organización.

Con el establecimiento de LDAP como estándar para los servicios de directorios, Apple comenzó a trabajar en su propia versión basada en él, la denominó “Open Directory” y poco a poco ha estado remplazando a NetInfo como el repositorio central de la información de los usuarios.

Hasta la versión del Mac OS X 10.4 NetInfo se ha utilizado para almacenar los datos de los usuarios que son locales a la computadora, mientras que para los servicios de red la versión de servidor utiliza ya Open Directory. Con la nueva versión del sistema, la 10.5, Apple le ha dado cierre al ciclo de vida de NetInfo, todo ahora esta almacenado utilizando el otro servicio, por lo que la administración en redes de los equipos Macintosh se modificará.

Todas las utilerías de la linea de comandos que se utilizaban para controlar NetInfo ya no son válidas en el nuevo sistema y han sido remplazadas por otro tipo de comandos. Algunos de estos comandos son descritos en un artículo de la revista Macworld que habla sobre este mismo tema.

Tener un servidor de impresión en una instalación con varias computadoras ayuda a controlar lo que se envía y a aprovechar las impresoras entre todos los equipos. En el caso de los laboratorios es necesario contener los trabajos de impresión hasta que el usuario que lo envió solicite que se le de paso, de este modo se minimiza el desperdicio y sólo se permite la impresión de aquellos trabajos que hayan sido pagados.

En el sistema Mac OS X Server 10.2 existe una opción para las filas de impresión en la que todos los trabajos que se reciben quedan automáticamente en pausa, de esta manera sólo la persona encargada del servicio puede liberar aquellos que se vayan solicitando.

Cuando salió el Mac OS X Server 10.3 el programa para administrar el servidor fue mejorado en su facilidad de uso y la interfaz se consolidó en una sola ventana (eso si, con muchas secciones). Lo que se ganó en esos aspectos se perdió en algunas opciones de configuración, entre ellas, la de poner los trabajos de impresión en pausa en cuanto llegan.

El no contar con esa opción, sumado a la prisa para terminar la instalación de los laboratorios antes de iniciar el semestre, impidió que se migrara a la nueva versión, por lo que la 10.2 continúa trabajando razonablemente bien a pesar de que ya han pasado 6 años desde que se instaló por primera vez.

El día le está llegando al servidor para ser reemplazado por una máquina un poco más nueva, sin embargo, las opciones que se están considerando para reemplazarlo no van a funcionar con la misma versión de sistema con el que contamos ahorita, va a ser necesario actualizar también esa parte.

Resulta que la versión del Mac OS X Server 10.4 utiliza la misma interfaz que su predecesor y aunque ofrece algunas opciones de configuración adicionales, tampoco cuenta con la “pausa automática”. ¿Qué hacer?.

Pues por fin se me ocurrió echarme un recorrido por el sistema sobre el cual funciona el servicio de impresión, que el el CUPS. Este sistema es en realidad toda una colección de programas que controlan la configuración de las impresoras, las filas de impresión y la administración de los trabajos que se envían a éstas. Algunos de los programas clave para conseguir lo que necesito son:

lp o lpr
y lpoptions

Todos estos programas tienen un montón de opciones razonablemente bien explicadas en el manual, pero la opción clave es para el comando lpoptions, lo que resulta en una línea como la que sigue:

lpoptions -d NombreFilaDeImpresion -o job-hold-until=indefinite

Como precaución ejecuté este programa como super-usuario para que el ajuste fuera para todos los usuarios de la computadora. Probablemente eso no sea necesario pero de todas maneras así lo hice (ese pequeño detalle no aparece por ningún lado en el manual).

¿El resultado?, pues una lista creciente de trabajos en la fila de impresión, y no un casi imperceptible parpadeo causado por algún trabajo que pasaba por ahí en su camino a la impresora.

Supongo que también funciona en el Mac OS X Server 10.3, pero al menos en el 10.4 si lo hace… y si acaso lograra obtener el Mac OS X Server 10.5 es probable que también funcione, ya que la base que hace funcionar al servidor de impresión es el CUPS en las tres versiones.

Cuando se conecta una computadora a una red se le expone a un entorno pocas veces amable. En algún momento mientras visitamos algún sitio web podemos exponer nuestro equipo a una página con elementos que provoquen la apertura de hoyos en la seguridad de nuestro navegador. Es posible también que algún juego que parecía inocente y decidimos instalar, resultara ser una puerta para llenar de anuncios la computadora, o peor aun, que se quede descansando sin percatarnos de ello y mientras capture todo lo que escribamos en el teclado (contraseñas y todo), en casos más extremos, pudieran enviar a algún otro sitio esa información o dejar abierta una puerta a nuestra computadora para que alguien más la use.

Aun quienes utilizamos una Mac no estamos libres de todos esos programas malignos (si, es cierto, también hay eso para la Mac, afortunadamente son prácticamente inexistentes), sin embargo no es excusa para no prevenirse un poco.

Recién salida de la caja una Mac es completamente segura, en realidad no comparte nada y supuestamente no hay puertas abiertas al exterior, pero por si acaso hemos activado el “compartir archivos”, “compartir impresora”, “compartir web”, “acceso remoto” o alguna otra cosa parecida ya tenemos una puerta abierta al mundo.

Lo mejor en esos casos es tener contraseñas “difíciles de adivinar”, pero no tanto como para que ni siquiera uno las recuerde. Por ejemplo algo como “aVerSiEntras” (a partir de este momento ni pensar en usar esa) puede ser una contraseña razonablemente buena, pero no completamente segura, usar más letras ayuda, y utilizar números y otros caracteres todavía más: aV{rSi3ntr]as (consejo: ya tampoco usar esta).

Si lo anterior no ha sido suficiente para pensar en mejores contraseñas, revisar el registro de seguridad del sistema puede ser otro incentivo. Dicho archivo se encuentra en /var/log/secure.log y sólo el súper-usuario lo puede leer.

Usando la Terminal o programas como TextWrangler se puede revisar el contenido del mismo. Tal vez en una computadora que no tiene muchos programas, no se le han activado las opciones de compartir y que rara vez ha solicitado que se escriba la contraseña del administrador, no aparecerá gran cosa en ese registro. Por el contrario, otro equipo donde se han instalado montones de programas y actualizaciones, comparte archivos y se cambia de usuario continuamente tendrá cientos de líneas en él.

Para poner un ejemplo extremo, el servidor web que sirve este blog es un objetivo seguro de cuanto zombie y hacker pueda toparse con él. Por supuesto que está activo el servicio web, pero también el servicio ssh y alguno más; se encuentra detrás de un cortafuegos y simplemente está ahí esperando que alguien solicite una conexión. No es un sitio de gran tránsito y principalmente es para uso interno, pero es visible desde el exterior.

Durante los últimos meses este servidor ha visto solicitudes de conexión por parte de 24,709 usuarios distintos, sorprendente si se toma en cuenta que en realidad solo hay poco más de 100 usuarios registrados, y no todos tienen permiso de conectarse. Para dar una idea del volumen de intentos de conexión, aquí va la lista de “los primeros 10″:

105901 root
6722 admin
2936 mysql
2477 test
2354 webmaster
1887 alex
1624 www
1331 nobody
1298 postfix
1135 guest


Por supuesto que el más atacado siempre va a ser root ya que se trata del mismísimo súper-usuario, pero por ejemplo mi propio usuario es uno de los más solicitados, por lo que tengo que mantener una contraseña razonablemente buena (y no, no es ninguna de las mencionadas arriba), además de cambiarla con regularidad.

Si se quiere conocer qué tan atacada ha sido una computadora el siguiente comando puede ayudar a obtener una lista como la anterior (todo en una sola línea):

sudo grep "failed to auth" /var/log/secure.log | sed "s/^.* user \(.*\)\.$/\1/" | sort | uniq -c | sort -nr

El comando usa grep para revisar el registro de seguridad por intentos fallidos, los pasa a sed parar dejar solo el nombre del usuario, con sort los ordena, uniq los cuenta y finalmente los vuelve a ordenar.

En la computadora de la oficina lo único que obtengo es mi propio usuario con un par de intentos, lo que indica que el ambiente de red es inofensivo comparado con el del servidor.

Un detalle a observar del comando anterior es que sólo busca por intentos fallidos, si acaso alguno de esos intentos logró obtener una conexión (consiguió dar con una contraseña válida), eso no se reportará en la lista. Para lidiar con esas situaciones se requiere de otras estrategias, aunque de eso trataré de hablar en otra entrada, ya que esta se ha convertido en la más larga que he escrito.

El Mac OS X ha sido hasta la fecha un sistema operativo bastante estable y apto para el trabajo diario. En especial la versión de servidor, aunque un poco antigua para la fecha, ha resultado bastante bien para el trabajo que se le tiene realizando, que es controlar la filas de impresión en los laboratorios.

Probé con el servidor de impresión de la versión 10.3, pero nunca encontré la opción para que los trabajos quedaran en pausa automáticamente al llegar a la fila de impresión. Como no hubo mucho tiempo para buscar y además, los trabajos a la fila de color nunca salían, se regresó a la versión 10.2 (dicen que más vale malo por conocido…).

En fin, todo ha funcionado bien salvo algunas ocasiones… los trabajos no aparecen en la fila de impresión… el servidor no parece responder… se detiene el servidor de impresión.

En el tercer punto creo que el problema ha sido humano. Tal vez haya ocurrido que inadvertidamente se haya seleccionado la opción de apagar el servicio cuando la intención era seleccionar la opción para mostrar la lista de colas de impresión.

El segundo punto se ha arreglado apagando el servicio y arrancándolo de nuevo. En casos muy desesperados, reiniciando por completo el servidor, afortunadamente eso es muy raro que ocurra.

El primer punto se resuelve más o menos fácil, la cola problemática se borra, se da de alta nuevamente y se comparte otra vez. Aunque es sencillo son varios pasos los que hay que configurar. Pero funciona… o eso creia hasta ayer.

Esa operación de borrar la fila de impresión y crearla de nuevo simplemente no sirvió. El servidor funcionaba, los trabajos llegaban al servidor, pero nunca eran pasados a la fila de la impresora de color. Lo anterior se puede observar con el comando:

tail -f /var/log/cups/error_log

Buscando en Google solo encontré la misma pregunta, pero no respuestas. Lo más cercano que encontré fue la sugerencia de aumentar el nivel de detalle en el registro de errores:

Cambiando el valor de la variable LogLevel a debug en el archivo de configuración /etc/cups/cupsd.conf

Lo anterior solo me ayudó a confirmar que el servidor operaba y que los trabajos llegaban.

Finalmente en la mañana me encontré con un foro donde se discutía algo similar, aunque no está expresamente la solución al problema, si encontré mención a un directorio sobre el que trabaja el servidor de impresión:

/var/spool/PrintService

Dentro de ese directorio existen otros con los nombres de las colas de impresión. En el caso de la fila de la impresora blanco y negro su directorio se encontraba vacío, pero en el directorio de la impresora a color éste contenía archivos desde ayer cuando comenzó el problema.

Pues bien, después de tanto choro la solución aparente para este problema fue: borrar todos los archivos estancados en el directorio de la cola de impresión.

Inmediatamente después de hacer eso el registro /var/log/cups/error_log mostró que un nuevo trabajo que arribó fue pasado a la fila de impresión.

¿Qué exactamente provocó el problema? no lo se, pero es probable que alguno de los archivos estancados que borré haya sido el causante.