Google Cloud Print en ArchLinux vía CUPS

image host

A pesar de que no es algo nuevo, no había tenido la oportunidad de probar Google Cloud Print, y ahora que lo hice, estoy seguro que es algo que estaré usando con extrema frecuencia practicamente todos los días.

Al principío me frustró el hecho de que en ArchLinux tenía que usar necesariamente Google Chrome para imprimir con esta tecnología, y tampoco quería tener que entrar su web para subir los archivos que necesitaba imprimir, así que investigando descubrí la existencia de un driver para CUPS, el cual puede instalarse fácilmente pues ofrece repositorios para las distros principales, ¡incluyendo a ArchLinux!

Dicho ésto, sólo debemos editar nuestro /etc/pacman.conf y agregar:

[niftyrepo]
Server = https://niftyrepo.niftiestsoftware.com/arch
SigLevel = Required TrustAll

Entonces, ejecutamos:

pacman -Syu cupscloudprint

Nos pedirá que aceptemos su llave PGP (2048R/C5541D9D), ¡háganlo!

Luego, ejecutamos su script de configuración (sigan sus instrucciones):

/usr/share/cloudprint-cups/setupcloudprint.py

¡Eso es todo! Más sencillo imposible.

Cabe aclarar, que para que todo lo anterior funcione, debemos previamente tener configurado Google Print Cloud.

Finalmente, si no usas ArchLinux, puedes seguir las intrucciones correspondientes para otras distros.

Solucionar problemas al actualizar a Apache 2.4 en ArchLinux

¡Ha llegado Apache 2.4 a ArchLinux! Es un cambio importante y requiere nuestra intervención manual para hacer que nuestro servidor LAMP vuelva a funcionar sin problemas.

Con la actualización, tenemos nuevos archivos httpd.conf, php.ini y magic, por lo que primero debemos hacer un respaldo de nuestros viejos archivos:

sudo mv /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.old
sudo mv /etc/httpd/conf/magic /etc/httpd/conf/magic.old
sudo mv /etc/php/php.ini /etc/php/php.ini.old

Entonces, renombramos los nuevos archivos:

sudo mv /etc/httpd/conf/httpd.conf.pacnew /etc/httpd/conf/httpd.conf
sudo mv /etc/httpd/conf/magic.pacnew /etc/httpd/conf/magic
sudo mv /etc/php/php.ini.pacnew /etc/php/php.ini

Apache viene con una serie de Módulos de MultiProcesamiento (Multi-Processing Modules o MPMs) que son responsables de conectar con los puertos de red de la máquina, acceptar las peticiones, y generar los procesos hijo que se encargan de servirlas. En el “nuevo” Apache 2.4 se usa el event MPM (previamente se usaba el prefork, que era más lento y consumía más memoria), que proporciona escalabilidad y buen soporte para alto tráfico de sitios web.

Por lo anterior, hay dos posibles soluciones: Volver a habilitar el prefork, o hacer los cambios necesarios para que el event MPM funcione adecuadamente.

Solución 1: Regresar a mod_mpm_prefork

Si no quieres romperte la cabeza con la migración a las novedades de Apache 2.4, lo que necesitas es volver a habilitar mod_mpm_prefork. Para ello, vamos a abrir el archivo /etc/httpd/conf/httpd.conf

sudo vim /etc/httpd/conf/httpd.conf

… y ahí, reemplazaremos la línea

LoadModule mpm_event_module modules/mod_mpm_event.so

con

LoadModule mpm_prefork_module modules/mod_mpm_prefork.so

Además, debemos incluir dos líneas adicionales, muy conocidas por nosotros. La primera debemos colocarla en la lista de carga de módulos (LoadModule list) después de LoadModule dir_module modules/mod_dir.so:

LoadModule php5_module modules/libphp5.so

La segunda, al final de la lista de configuraciones adicionales (Include list):

Include conf/extra/php5_module.conf

Y reiniciamos Apache para reflejar los cambios:

sudo systemctl restart httpd.service

Solución 2: Usar el nuevo mod_mpm_event

Si queremos aprovechar todas las bondades y novedades de Apache 2.4, ésta es la solución que debemos seguir.

Como primer paso, vamos a instalar php-fpm desde los repos oficiales:

sudo pacman -S php-fpm

Adicionalmente, instalaremos mod_proxy_handler desde AUR (esperemos que pronto lo agreguen a los repos oficiales):

yaourt -S mod_proxy_handler

En el archivo /etc/php/php-fpm.conf, descomentar la línea (quitar ; del principio):

listen = 127.0.0.1:9000

y comentar la línea (agregar ; al principio):

listen = /run/php-fpm/php-fpm.sock

En el mismo archivo, también debemos descomentar la línea:

listen.allowed_clients = 127.0.0.1

En el archivo /etc/httpd/conf/httpd.conf, agregar al final:

LoadModule proxy_handler_module modules/mod_proxy_handler.so
<FilesMatch \.php$>
    SetHandler "proxy:fcgi://127.0.0.1:9000/"
</FilesMatch>
<IfModule dir_module>
    DirectoryIndex index.php index.html
</IfModule>

Finalmente, en el archivo /etc/php/php.ini debemos asegurarnos de que la siguiente línea está habilitada (descomentada):

cgi.fix_pathinfo=1

Reiniciar los daemons involucrados:

sudo systemctl restart php-fpm.service
sudo systemctl restart httpd.service

¿Y MySQL / MariaDB? Al usar el nuevo archivo php.ini, debemos volver a decirle a PHP de la existencia del servidor de base de datos. Vamos a abrir el archivo /etc/php/php.ini con tu editor favorito …

sudo vim /etc/php/php.ini

… y descomentar (eliminar el ; al inicio) las siguientes líneas:

extension=mysqli.so
extension=mysql.so
extension=pdo_mysql.so

Finalmente, reiniciemos Apache y MariaDB para aplicar los cambios realizados.

sudo systemctl restart httpd.service
sudo systemctl restart mysqld.service

Fuentes: 1, 2, 3.

Inminente llegada del Kernel 3.13 a ArchLinux, ahora con soporte modular para PS/2

Teclado PS/2 en ArchLinux

Luego de una buena espera, el Kernel Linux 3.13 está a unas horas de llegar al repo [core] de ArchLinux, pero los desarrolladores nos avisan de un detallito que podría ocasionar problemas en algunos equipos: Ahora el soporte para teclados (keyboards) y ratones (mouse) con interfaz PS/2 será modular, o sea, ya no formará parte predeterminada del kernel.

¿Aún usas algún dispositivo de entrada PS/2? ¡Yo sí! ¿Qué debemos hacer? Antes que nada, no hay que dejar que panda el cúnico (como diría el gran Chespirito, ¡que casualmente hoy cumple 85 años!), sólo basta seguir los siguientes pasos:

  1. ¡Aún no actualices al nuevo kernel! Si lo haces, luego del reboot no podrás acceder a tu teclado o mouse PS/2.
  2. Antes que nada, cerciórate que en la línea HOOKS= del archivo /etc/mkinitcpio.conf tienes agregado keyboard. Si no es así, agrégalo, guarda el archivo (necesitas ser root), y ejecuta mkinitcpio -P.
  3. Ejecuta el siguiente comando:
    dmesg -t | grep '^i8042'
  4. Si aparece un mensaje que diga: “i8042: PNP: No PS/2 controller found. Probing ports directly.“, entonces debes agregar atkbd a la línea MODULES= en el archivo mkinitcpio.conf y ejecutar mkinitcpio -P.
  5. Si luego de reiniciar, aún no tienes acceso a tus dispositivos PS/2, debes agregar earlymodules=atkbd modules-load=atkbd a tu línea del kernel en tu bootloader instalado (GRUB, Syslinux, etc).

Eso es todo, no es un procedimiento complicado, pero repito: Si tienes un teclado o mouse PS/2, DEBES verificar el procedimiento mencionado ANTES de actualizar al Kernel Linux 3.13 (el cual debe llegar en unas pocas horas al repo [core] de ArchLinux).

¿Copia lenta de archivos a memorias USB?

Algo que me encanta de ArchLinux es que cada vez que me enfrento a un problema, siempre encuentro información al respecto en la wiki y/o en los foros; desde el primer día en que empecé a utilizar esta maravillosa distro, todos los días he aprendido algo nuevo… y esta ocasión no es la excepción.

El problema: Pobre desempeño al copiar o mover archivos (en particular los “pesados”, pero no es exclusivo) a una memoria USB o pendrive, en especial al usar KDE (de nuevo, el Desktop Environment tampoco es exclusivo).

La solución: En la wiki se menciona un procedimiento, pero editando el archivo /etc/rc.local, el cual sabemos ya no existe con la llegada de systemd, así que tuve que “modernizarlo” basándome en un par de guías. El resultado a continuación.

Paso 0

No usen sudo para crear/editar los archivos de los pasos siguiente, mejor entren al usuario root con el comando su -:

[gespadas@localhost ~]$ su -
Contraseña: ******
[root@localhost ~]#

Ahora si, pueden seguir leyendo.

Paso 1

Vamos a crear el archivo /etc/tmpfiles.d/disable-hugepage.conf (realmente puede llamarse como gusten). Para ello usaré:

vim /etc/tmpfiles.d/disable-hugepage.conf

¿No les gusta vim? ¡Muy mal! Ok ok, pueden usar el editor que deseen ;-)

Ahí, el contenido del archivo será el siguiente:

w /sys/kernel/mm/transparent_hugepage/enabled - - - - madvise
w /sys/kernel/mm/transparent_hugepage/defrag - - - - madvise
w /sys/kernel/mm/transparent_hugepage/khugepaged/defrag - - - - 0

Las primeras dos líneas están escribiendo el valor madvise al archivo indicado (algo como hacer un echo madvise > /sys/.../archivo), y la última línea hace lo mismo, pero escribiendo el valor 0.

No quiero profundizar en lo que significa lo anterior (¡lean las referencias que pongo!), pero brevemente les comento que estamos estableciendo durante el booteo (por eso usamos tmpfiles) los parámetros transparent hugepages y hugepage defragmentation del kernel.

Paso 2

Adicionalmente, editen el archivo /etc/sysctl.conf (ese si existe, su función es la de establecer parámetros del kernel en tiempo de ejecúción):

vim /etc/sysctl.conf

Y al final pongan lo siguiente:

kernel.shmmax=134217728
vm.dirty_background_bytes = 4194304
vm.dirty_bytes = 4194304

¿Por qué esos números? 134,217,728 bytes = 128 MB y 4,194,304 bytes = 4 MB.

¿Y por qué esos parámetros? Ayudan a reducir el efecto freeze en KDE.

¿Les da miedo editar un archivo que se mete directamente con el kernel? ¡Deberían! Es por eso que una solución más elegante, más acorde a la filosofía de systemd, es crear un archivo .conf dentro de la carpeta /etc/sysctl.d/ (similar a lo que hicimos en el paso 1). Por ejemplo, el archivo podría llamarse /etc/sysctl.d/disable-freeze.conf, cuyo contenido serían las tres líneas antes descritas.

Paso Extra

Si el desempeño mejoró, pero no lo suficiente, repitan el paso 1, pero usando el valor never en vez de madvise. ¡Atención! Hay efectos colaterales, y el más molesto es que la hibernación del sistema ya no funcionará.

¿Problemas con package-query al tratar de actualizar pacman en ArchLinux?

Ya estaba anunciado, y hace unas horas pacman 4.1 llegó al repo [core] de ArchLinux. Muchos han tenido conflictos al querer actualizar, y es por que tenermos yaourt instalado, el cual depende de package-query.

$ sudo pacman -Syyu
:: Los siguientes paquetes deben actualizarse primero:
    pacman
:: ¿Desea cancelar la operación actual
:: y actualizar estos paquetes ahora? [S/n]
resolviendo dependencias...
verificando conflictos...
error: error al preparar la transacción (no se pudieron satisfacer las dependencias)
:: package-query: necesita pacman&lt;4.1

¿Qué hacer? Aquí la solución que funcionó conmigo, la cual espero les funcione también.

  1. Elimino yaourt y dependencias (incluyendo package-query):

    sudo pacman -Rs yaourt
  2. Actualizo al nuevo pacman:

    sudo pacman -Syu
  3. Uso el nuevo pacman.conf, ya que la directiva SyncFirst en la sección options ya no es reconocida (Allan McRae, declarado detractor de Manjaro, asegura que este cambio no fue deliberado para afectar a dicha distro):

    sudo mv /etc/pacman.conf /etc/pacman.conf.respaldo
    sudo mv /etc/pacman.conf.pacnew /etc/pacman.conf
  4. Agrego el repo de la comunidad francesa (el cual ya tenía en el viejo pacman.conf):

    sudo echo "[archlinuxfr]" >> /etc/pacman.conf
    sudo echo "Server = http://repo.archlinux.fr/$arch" >> /etc/pacman.conf
  5. Recargo mis repos e instalo yaourt (gracias al repo francés):

    sudo pacman -Syy yaourt
  6. Actualizo todo lo que me hace falta:

    sudo pacman -Su
  7. Ya pueden respirar tranquilos ;-)

¿Les funcionaron los pasos? ¿Hicieron algo diferente? ¡Comenten!

¿Problemas con libgl al tratar de actualizar ArchLinux?

Hoy al encender mi equipo, quise actualizar mi querido ArchLinux

sudo pacman -Syyu

y me encuentro con ésto:

error: error al preparar la transacción (no se pudieron satisfacer las dependencias)
:: cairo: necesita libgl
:: compiz-core: necesita libgl
:: gnome-session: necesita libgl
:: lib32-cairo: necesita lib32-libgl
:: lib32-glu: necesita lib32-libgl
...
:: qt4: necesita libgl
:: xorg-server-xephyr: necesita libgl
:: xorg-xdriinfo: necesita libgl

Como pueden ver, hay problemas de dependencias con libgl (y con lib32-libgl). Luego de investigar un poco, descubrí que el motivo es la última actualización del driver de Nvidia (la versión 313.30).

La solución para el conflicto de libgl:

sudo pacman -Rdd nvidia-utils
sudo pacman -S nvidia-libgl

La solución para el conflicto de lib32-libgl:

sudo pacman -Rdd lib32-nvidia-utils
sudo pacman -S lib32-nvidia-libgl

Ahora si, ya pueden actualizar sin problemas:

sudo pacman -Su

Referencia: Foro de ArchLinux.

Deshabilitar el Historial de Documentos Recientes en ArchLinux

¡Un pequeño tip! Si eres de los que odian el historial de los Documentos Recientes, hay una forma muy sencilla de deshabilitarlo por completo en ArchLinux.

Primero, debemos hacerlo para aplicaciones GNOME:

rm -f ~/.local/share/recently-used.xbel
touch ~/.local/share/recently-used.xbel
chmod 400 ~/.local/share/recently-used.xbel

Ahora, para aplicaciones KDE:

rm -f ~/.kde4/share/apps/RecentDocuments/*
chmod 500 ~/.kde4/share/apps/RecentDocuments

Este truco debería funcionar en cualquier distro, sólo verifiquen que las rutas sean las mismas (por ejemplo, en ArchLinux se usa ~/.kde4/ mientras que en otras distros es ~/.kde/).

ArchLinux reemplaza qt por qt4, ¿qué hacer?

¡Cambios importantes en ArchLinux! El paquete qt ahora es reemplazado por qt4, ¿qué implica este cambio?

  • Los paquetes que dependan del “viejo qt” (ahora qt4) que tengas instalados desde los repositorios oficiales, de manera automática se actualizarán. En otras palabras, aquí no deberías tener ningún problema.

  • Muchos paquetes que dependan del “viejo qt” que tengas instalados desde AUR ocasionarán conflictos, y de entrada no te dejarán actualizar adecuadamente de qt a qt4. ¿Qué hacer?

    1. Desinstalar todos esos paquetes con sudo pacman -R <lista-de-paquetes>
    2. Efectuar la actualización con sudo pacman -Syu
    3. Volver a instalar los paquetes desde AUR, reemplazando qmake (en caso de que se uilice) con qmake4 en PKGBUILD para decirle al compilador que queremos usar Qt 4.x.
  • El nuevo Qt5 (ya en su rama estable) se puede instalar con el paquete qt5-base.

Espero lo anterior sea de ayuda de todos mis colegas archeros.

[Actualización] Ya hay anuncio oficial sobre el tema.

¿Formateaste con Ext4 y la partición tiene 5% de espacio ocupado?

¿Formateaste con Ext4 y la partición tiene 5% de espacio ocupado?

Hoy me topé con algo raro y quisiera compartirlo con ustedes. Tuve la necesidad de eliminar el NTFS de fábrica de un disco duro externo de 1 TB para ponerle un flamante Ext4 (aquí las instrucciones para hacerlo), y cuál va siendo mi sorpresa que al verificar el espacio disponible, noté que tenía ocupado el 5%, ¡eso son casi 50 GB!

Investigando un poco (como siempre, la wiki de ArchLinux es mi primer punto de referencia), me entero que ese 5% se reserva para root de manera predeterminada. Para discos duros modernos de gran capacidad, ese 5% es demasiado, y totalmente innecesario si el disco en cuestión no será usado para archivos de sistema.

Para reducir ese porcentaje, basta usar el comando tune2fs:

sudo tune2fs -m 0.2 /dev/sdc1

La cantidad especificada con -m representa el porcentaje. Por ejemplo, yo usé 0.2 %, lo cual me redujo el espacio reservado de root de casi 50 GB a sólo 2 GB en mi disco duro externo de 1 TB. Si quieres ser más conservador, puedes usar 1.0 (el 1 %).

Cabe mencionar que en el ejemplo puse /dev/sdc1 como la partición de mi disco duro externo, la cual debes reemplazar por la tuya. Para identificar tus particiones, sus puntos de montaje, así como su porcentaje de uso, basta ejecutar el comando df:

df

Tip: Si son observadores, en la captura de pantalla al inicio de este post, usé el comando dfc (disponible en AUR para ArchLinux y en los repos de tu distro favorita), que proporciona una salida más cómoda en comparación del clásido df.

[Actualización] Por cierto, lo mismo aplica para Ext3 (duda que me preguntaron vía Twitter).

ConsoleKit es reemplazado por systemd-logind en ArchLinux

¡Más cambios en ArchLinux! Hoy amanecimos con la tremenda noticia de que ConsoleKit ha sido eliminado de los repositorios oficiales, y que toda su funcionalidad ahora es responsabilidad de systemd-logind.

¡El pánico se apodera de todos los archeros del mundo! ¡Es el apocalipsis que los mayas predijeron! … Jajaja, nada más alejado de la realidad. Sin embargo, el anuncio es demasiado escueto y no proporciona mayores detalles sobre las implicaciones de este cambio, así que me puse a investigar de inmediato y a hacer varias pruebas. Aquí el resultado.

¿Qué rayos es eso de ConsoleKit y systemd-logind?

Por si no lo sabías, ConsoleKit era utilizado para dos cosas principalmente: Permitir a usuarios normales (no root) montar dispositivos removibles (como pendrives o memorias USB), así como permitir suspender, reiniciar y apagar el sistema. Incluso, es muy probable que en tu archivo ~/.xinitrc tengas algo como ésto:

exec ck-launch-session openbox-session

El “ck-launch-session” era lo que permitía que tu usuario pudiera hacer lo que mencioné previamente. Ahora el encargado de hacerlo es systemd-logind, y aunque este detalle no se menciona en el anuncio oficial, si podemos encontrarlo en una reciente modificación en la wiki de Arch, y cito textualmente:

All PolicyKit actions like suspending the system or mounting external drives will work out of the box.

¡Así que no hay nada que temer! Sólo hay un “pequeño” requisito… ¡ya estar usando systemd!

Como observación adicional, con logind las X (el entorno gráfico) se ejecutan en el mismo tty donde se inició sesión, mientras que con ck-launch-session se creaba una nueva sesión.

¿Qué implica que ConsoleKit ya no esté en los repositorios?

En instalaciones existentes, al actualizar el sistema no se eliminará ConsoleKit, o sea, que aún puede seguirse usando, aunque ya no tiene sentido.

En instalaciones nuevas, ya no podrá instalarse ConsoleKit (aunque parece que pronto estará disponible desde AUR, pero repito, no tiene sentido), lo cual implícitamente nos estará obligando a realizar una instalación basada en systemd.

¿Qué cambios debo hacer en mi sistema?

No mucho. Primero, ¡actualiza!

sudo pacman -Syu

Es muy importante actualizar, para que los últimos cambios se apliquen, pues incluyen paquetes a los cuales se les ha eliminado su respectiva dependencia con ConsoleKit.

Ahora, ya puedes eliminar ConsoleKit, no debes tener problemas de dependencias.

sudo pacman -R consolekit

En caso de ser necesario, no olvides eliminar “ck-launch-session” de tu archivo ~/.xinitrc.

Eso es todo, ya puedes reiniciar y verificar que todo funcione bien.

Adicionalmente, les recomiendo usar el siguiente comando para ver información sobre la sesión actual.

loginctl

Para información más detallada, pueden usar lo siguiente.

loginctl show-session $XDG_SESSION_ID

¿Eso es todo?

¡Si! Bye bye ConsoleKit :-)