• Cambiar el puerto en /etc/ssh/sshd_config por el 6969 —por ejemplo :

  Port 11810

• Cambiar el tiempo de espera en segundos para identificarse —en el mismo archivo— por un valor inferior

  LoginGraceTime 30

• No permitir acceder directamente como root; para ello se puede utilizar el su root una vez identificado un usuario normal —también en /etc/ssh/sshd_config

  PermitRootLogin no

Estos son básicos. Luego hay mil y un consejos más que pueden llegar a hacer estallar a los administradores cuando estén llenos de nervios intentando resolver algún problema que tiene inutilizado el servidor. De primeras parecen muy útiles pero no siempre serán deseables:

• Cerrar la sesión de root por inactividad, que si el administrador se despista y se olvida del asunto no pueda luego llegar un pillo en persona y aprovecharse. En /root/.bashrc se añade el tiempo en segundos:

  TMOUT = 300

  aunque si se prefiere que sea para todos los usuarios se puede añadir en /etc/profile:

  readonly TMOUT = 300

• Limitar las direcciones IP desde las que poder conectarse —si el demonio de SSH tiene soporte para TCP Wrappers— añadiendo al archivo /etc/hosts.deny:

  sshd : ALL

  y a /etc/hosts.allow las direcciones IP autorizadas:

  sshd : IP1,IP2,IP3,IPn

• Limitar con iptables el número máximo de conexiones por minuto, útil por ejemplo contra los ataques por fuerza bruta para el puerto configurado para SSH (6969):

  iptables -A INPUT -p tcp --dport 6969 -m limit --limit 3/minute -m state --state NEW -j ACCEPT

• Bloquear el puerto para el primer intento de conexión y aceptar conexiones a continuación en el plazo de un minuto. Práctico para intentar esconder que el puerto está abierto ante escaneos de puertos:

  iptables -A INPUT -p tcp --dport 4587 -m limit --limit 1/minute -m state --state NEW -j DROP

  OJO: esta regla se ha de aplicar antes de la del punto anterior.

Esto ha sido en cuanto a SSH. No obstante hay un montón de reglas más para ipfilter válidas para otros servicios del servidor, ajustes del núcleo, eliminar la consola para usuarios de sistema, etc. Muchas vulnerabilidades que pueden ser detectadas con la herramienta Tiger.

Fuente → Reforzando la instalación de Debian GNU/Linux [esdebian.org].

Según comentan en la sección de bugs se trata de problemas que tiene Flash con la implementación memcpy de glibc. Mientras glibc lo corrige en la distribución que utilicen, o Adobe en sus siguientes versiones —lo cual sí que sería novedoso— hay que usar un parche:

1. Instalar si no lo está el paquete bspatch.
2. Descargar el parche de aquí o de este hilo de los informes de errores de Adobe.
3. Copia de seguridad de la librería por si las moscas: # cp /usr/lib64/flash-plugin/libflashplayer.so /usr/lib64/flash-plugin/libflashplayer.so.old
4. Ubicarse en la consola en donde se halle guardado el parche descargado.
5. Parchear la librería con: # bspatch /usr/lib64/flash-plugin/libflashplayer.so.old /usr/lib64/flash-plugin/libflashplayer.so ./memcpy-10.3.162.29.bsdiff
6. Cerrar y volver a abrir el navegador web y probar si funciona.

Ojo: # indica que han de ejecutarse los comandos desde root o mediante sudo … Como corresponda a cada sistema.

• ServerSignature. Es la más conocida y la responsable de que cuando Apache devuelve un documento generado por él mismo, como mensajes de error, en el pie del mismo informe de su versión, sistema operativo, correo del administrador,.. Para evitarlo se cambia su parámetro a off, quedando: ServerSignature Off.
• ServerTokens. Es la que dice qué información se devuelve, tanto en el pie de página —si lo está— como en las cabeceras de la respuesta del servidor web. Tiene varios niveles de mostrar información. El más restrictivo consiste en sólo informar del nombre del servidor web: Apache. Esto se logra con el parámetro Prod: ServerTokens Prod.

Apache sería pues un poco más disimulado con la información del servidor web que envía al cliente —también a nivel de cabeceras:

En realidad, las cosas como son, estos son mejores siempre y cuando sigan soportando la tarjeta gráfica .Para las antiguas los libres sí que son fieles y nunca las abandonan. Pero con los privativos bien instalados es fácil apreciar cómo el entorno va más liviano. El contenido de los navegadores web parece que pesara menos. Sin embargo las nuevas tecnologías de aceleración aún no están muy pulidas y causan inestabilidades en cuanto al abanico de aplicaciones que las toleran bien. Por ejemplo en el navegador Opera el desplazamiento vertical va de lujo, pero en Chromium o Evince tironea y en Iceweasel directamente faltan partes del navegador si son versiones anteriores a la cuatro, o de lo contrario tironea cuando se encuentra con contenido distinto de texto, como imágenes.

Pero como casi todo tiene arreglo, esto también lo tiene. Volver por el momento a XAA mientras EXA sigue evolucionando y sacrificar algo de velocidad, aunque la vista agradecerá un entorno gráfico fluido. En el caso del driver libre bastaba con editar el archivo de configuración del X.Org, pero para el privativo es necesario utilizar un comando que viene a deshabilitar esa aceleración 2D que todavía da los problemas antes descritos. Como root y fuera de las X, con ellas desactivadas:

aticonfig --set-pcs-str=DDX,ForceXAA,TRUE

y santas pascuas. Por lo visto esto tiene algo que ver con X.Org y por ello, según dicen, otra solución es actualizar la versión de X.Org a la 7.6, pero en mi caso eso todavía está en la rama experimental de Debian y de momento no me convencen el jaleo de dependencias que Aptitude me propone.

Fuente → Scrolling problems Iceweasel (Radeon HD 3850 problem?) @ NGINX.

Pero el problema en realidad, salvo que se recurra a la versión de gThumb para lenny, está en udev y las reglas que libgphoto2 le indica sobre cada cámara. Le faltan un par de propiedades para que estos se enteren de que es una cámara lo que está conectado:

1. ID_GPHOTO2 = 1
2. GPHOTO2_DRIVER = proprietary

Así que hay dos soluciones:

• Añadirle las propiedades necesarias a dichas reglas.
• O extraer la tarjeta de memoria de la cámara e insertarla en el típico lector de tarjetas. Además suelen transferir a mayor velocidad al ordenador que la propia cámara.

Pero no siempre se dispondrá de un lector de tarjetas, o habrá a quien le guste complicarse la vida. Estos son los pasos que yo he seguido:

1. Conectar por USB la cámara de fotos al ordenador.
2. Extraer el identificador del fabricante y del producto, por ejemplo con dmesg.

   $ dmesg
   [...]
   [ 3163.740042] usb 1-2: new high speed USB device using ehci_hcd and address 21
   [ 3163.896554] usb 1-2: New USB device found, idVendor=04a9, idProduct=311c
   [ 3163.896559] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
   [ 3163.896562] usb 1-2: Product: Canon Digital Camera
   [ 3163.896564] usb 1-2: Manufacturer: Canon Inc.
   [ 3163.896707] usb 1-2: configuration #1 chosen from 1 choice
   [ 3186.295973] usb 1-2: USB disconnect, address 21
   [...]

3. Lo importante, en este caso, es idVendor=04a9 e idProduct=311c.
4. Editar el archivo /etc/udev/rules.d/025_libgphoto2.rules y buscar donde ponga 311c, comprobando que pertenezca a la propiedad idProduct y que la idVendor correspondiente valga 0419, y añadir en la misma línea el par de propiedades que le faltan separadas también por comas.
   Originalmente:

   # nano /etc/udev/rules.d/025_libgphoto2.rules
   [...]
   ATTRS{idVendor}=="04a9", ATTRS{idProduct}=="311c", MODE="0664", GROUP="plugdev"
   [...]

   Resultando:

   [...]
   ATTRS{idVendor}=="04a9", ATTRS{idProduct}=="311c", ENV{ID_GPHOTO2}="1", ENV{GPHOTO2_DRIVER}="proprietary", MODE="0664", GROUP="plugdev"
   [...]

5. Guardar los cambios. En el caso de nano es con Ctrl+O.
6. Recargar udev.

   # /etc/init.d/udev reload

7. Volver a conectar la cámara de fotos al ordenador y a esperar tener suerte con gThumb y Shotwell.

Fuente → Debian Bug y Launchpad.

Con los tiempos que corren raro es quien no utiliza ninguna vía de comunicación a través de mensajería instantánea. Con raro no me refiero a marginal, ojo. Más raro es aún quien sólo utiliza la respectiva a un solo programa. Pero para nada raro es que la gente tenga abierta a la vez dos, tres, cuatro, o las que sean aplicaciones para manejar a la vez tanto programa o protocolo de mensajería.

Motivos los hay muchos. Yo por ejemplo siempre había pensado que la gente importante la tengo en cualquiera, además de en otros medios más propios de toda la vida, pero con el tiempo he ido comprobando que eso no es así. Pepito usa Google Talk porque es el único que le funciona desde el trabajo, Fulanito Skype porque lo lleva en el móvil último modelo, Menganita Facebook que es lo único que no le bloquean en el trabajo, Perico de los palotes Messenger y a través de una web que utiliza un proxy para saltarse las restricciones,.. y así un enorme etcétera.

Y para intentar aglutinar a tanto contacto disperso existen para Linux programas como Empathy y Pidgin —deriva del archiconocido Gaim y está para otras plataformas también—, que permiten utilizar Messenger, Facebook, Google Talk, Skype, ICQ, Yahoo!, AIM, Jabber, MySpace,.. y hasta el IRC de siempre. Cada uno con sus limitaciones puesto que por separado cada invento de estos tienen sus mil y una cosas como iconos personalizados, zumbidos, enviar archivos, compartir carpetas, webcam, sonidos, videollamadas ¡y hasta compartir fondos melosos con las churris! Pero para quien se limite al uso sencillo de escribir y leer le sobra con este par de programas. Mi cantidad de iconos junto al reloj del escritorio y de pestañas del navegador ha disminuido considerablemente. Y eso que también disponen de posibilidad de añadirles Twitter.

El autor aludió principalmente a dos razones que le han llevado a abandonar el proyecto. La más grande explicó que es la manera en que Twitter está manejando la implementación del protocolo OAuth, que no hace mucho caso de los desarrolladores y ello complica su inclusión en los clientes de código abierto. La segunda, el verdadero «ya ha sido suficiente» según él, fue cuando señaló que los usuarios bloqueados todavía aparecían en la timeline, y obtuvo por respuesta que el bloqueo debía hacerse en el lado del cliente. Y este par de desavenencias junto con la mala leche que te va generando error tras error que hay que andar corrigiendo cuando programas pues han acabado por hacer que se le quiten las ganas de seguir con el asunto. No obstante pone el código fuente a disposición de quien lo quiera y se ofrece para ayudar en dudas con el diseño o a quien quiera hacer una nueva versión.

Yo lo entiendo. Desarrollar por amor al arte es bonito, le dedicas el tiempo que te da la gana, pero cuando empiezan a surgir demasiados cambios y en donde se supone que dan soporte pasan de ti o te dan largas, cansa. Y lo digo ahora mismo que estoy un poco aburrido ya de la desgana de los desarrolladores de SilverStripe en sus foros.

atención, in file ‘/var/lib/dpkg/available’ near line 48034 package ‘virtualbox-3.0′: error in Version string ’3.0.12-54655_Debian_lenny’: invalid character in revision number

Al parecer se trata de un error con los caracteres utilizados en la versión del paquete Virtualbox-3.0, que encima ya ni tengo instalado. Y hoy echando un vistazo he dado con que a más gente le ocurre [bugs.debian.org], también algún español [linuxparatodos.net], y he dado con la solución [azitech.wordpress.com]. Es decir:

# dpkg --clear-avail

que «elimina la información sobre qué paquetes están disponibles» como dice el manual de dpkg. Aunque también es posible solucionarlo comentando el repositorio correspondiente al paquete que da el error, actualizando, y descomentándolo. O supongo que también vaciando el contenido del archivo /var/lib/dpkg/available.

Es posible probarlo sin necesidad de instalarlo, y por mi parte lo recomendable. Muy sencillo de instalar en Debian y similares, como indican en Glandium [en inglés]. A mi me han funcionado estos pasos en Debian testing:

1. Instalar xulrunner-2.0 y libmozjs4d_2.0. Se descargan estos .deb de los repositorios para Mozilla en Debian.net seguidos de un #dpkg -i <los-paquetes> para instalarlos.
2. Descargar iceweasel_4.0~b4-0_<arquitectura>.deb, pero no instalarlo, extraerlo en donde se quiera tener la aplicación con dpkg-deb -x iceweasel_4.0b1-0_*.deb /ruta/dondesequiera.
3. Crear el enlace simbólico: ln -s /usr/lib/xulrunner-2.0 /ruta/dondesequiera/usr/lib.
4. Y cada vez que se quiera usar abrirlo con: /ruta/dondesequiera/usr/bin/iceweasel.

A ver si se dan prisa y se aplican bien estos de Mozilla, que Chromium —Chrome— me va como una bala.

Así pues parece que manda tocar retirada y volver a las andanzas de antes, utilizar versiones para 32 bits sobre un sistema de 64 bits, y en el wiki de Debian para Flash Player [en inglés] han tratado el problema y cómo volver a combinar Flash y NSPluginWrapper. A ver si pronto vuelve Adobe con el desarrollo de nuevo y juega a favor de que se deje de responsabilidad únicamente a Linux de su mala compatibilidad con algunas páginas web.