sistemas - Userlinux.net

Una de las infinitas opciones que nos ofrece SSH es hacer Forward Dinámico en modo de Socket para proxy de navegador (por ejemplo). Si queremos configurar "atajos" de las máquinas en el ~/.ssh/config podemos decirle también que conecte activando el DynamicForward de la siguiente forma:

$ cat ~/.ssh/config
Host atajo
        User root
        Port 122
        HostName mi-host-remoto.com
        DynamicForward 8080

Simple como el mecanismo de un botijo pero me ha costado encontrarlo en los frondosos bosques de documentación que habitan este gran servicio. Así que aquí queda el tip, una vez escrito este archivo llegará con un simple ssh atajo para establecer la conexión. Para nota sería ya combinarlo con IdentityFile, pero eso ya es más sencillo de encontrar ;).

Cuando las herramientas funcionan como tienen que funcionar a veces se ven situaciones de lo más graciosas. Si quieres cambiar el propietario de todos los ficheros (ocultos y normales) que están bajo una estructura de directorios, ¿harías lo siguiente?:

$ cd directorio/
$ chown -R usuario:grupo *
$ chown -R usuario:grupo .*

A ver quien es capaz de ver el pequeño error que se comete. Venga que no es tan complicado... quien no esté dispuesto a pensar demasiado puede leer el spoiler: El patrón [.*] coincide con el archivo especial [..] de forma que se hace el cambio de usuario también en el nivel superior.

So much funny for a monday.

Ha sido toda una odisea y al final no lo he conseguido. Llevaba tiempo queriendo cambiar de sistema operativo en el Macbook (2.1 para más detalles) porque MacOSX cada día se ralentizaba más. Así que, HD externo en mano, me puse a hacer backup y cuenta nueva.

La primera elección fue Ubuntu por su sencillez y totalidad soporte de hardware, sin embargo esa "totalidad" no fue tanto por culpa del dichoso touchpad. Si bien no tenía limitada ninguna funcionalidad, simplemente iba a saltos, sin suavidad. Parecía como si le costase moverse por la pantalla. No era usable ni mucho menos, y tampoco me había planteado la posibilidad de prescindir del touchpad en favor de un ratón usb... ¡estamos hablando de un portátil!.

¡Menuda combinación!. A decir verdad empecé jugando un poco con el maldito slowloris y al final acabé montando este batiburrillo de servidores, primero para paliar el efecto del dichoso gusano y segundo para preparar el servidor para la inminente nueva versión del blog - que me gustaría estrenar con el décimo aniversario de este humilde rinconcito -.

En un esquema inicial analógico de esos que tantos nos gustan podemos ver la pirula (pido perdón de antemano por la calidad de la foto):

Llevo desde el fin de semana con la mosca detrás de la oreja. Uno de los servidores que administro ha visto incrementada de forma inexperada su carga media de CPU sin motivo aparente. Donde el load average normal de 1 minuto variaba entre 0.40 y 0.80 de repente suponía cargas tan elevadas como 60 o 100 unidades.

En esos momentos puntuales que llegaban a dejar la máquina zombie el proceso que abarcaba un consumo de entre el 60% y el 90% de CPU era apache2. Intrigante que ni error.log ni slow-queries.log de MySQL (lo que normalmente suele ser cuello de botella) dieran ninguna pista.

Si trabajas con Mercurial y has actualizado a la rama 1.7.x es posible que, en tus comunicaciones https con Bitbucket aparezca un mensaje como el siguiente:

$ hg pull -u
warning: bitbucket.org certificate with fingerprint fi:ng:er:pr:in:tt not verified (check hostfingerprints or web.cacerts config setting)
warning: bitbucket.org certificate with fingerprint fi:ng:er:pr:in:tt not verified (check hostfingerprints or web.cacerts config setting)
pulling from https://r0sk:***@bitbucket.org/r0sk/proyecto
warning: bitbucket.org certificate with fingerprint fi:ng:er:pr:in:tt not verified (check hostfingerprints or web.cacerts config setting)
warning: bitbucket.org certificate with fingerprint fi:ng:er:pr:in:tt not verified (check hostfingerprints or web.cacerts config setting)
searching for changes
adding changesets
adding manifests
adding file changes
$

Este warning no implica el mal funcionamiento o la inseguridad puntual de dicha acción, simplemente informa de que siempre ha sido inseguro. Tenemos dos opciones, o dejar de usar https o indicar en configuración los certificados SSL a utilizar para que no vuelva a aparecer el warning. Esto último se consigue editando el fichero .hg/hgrc del proyecto en cuestión, agregando lo siguiente (en Debian/Ubuntu):

[web]
cacerts = /etc/ssl/certs/ca-certificates.crt

Una vez agregadas estas dos lineas en el fichero probamos de nuevo a ejecutar cualquier operación sobre https y vemos que ya no se muestran los avisos. (Fuente).