Pero esta configuración genera problemas con el reenvio de ventanas X11 a través de SSH. Por ejemplo, con sistemas HP-UX y Solaris (luego veremos qué pasa con Linux), cuando accedes por SSH con un usuario reenviando las ventanas X11 y luego haces un su, perdemos el túnel de X11:

$ ssh -X usuarioprueba@solx86
Password:
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
$
$ echo $DISPLAY
localhost:10.0
$
$ /usr/openwin/bin/xclock
$
$ su -
Password:
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
#
# echo $DISPLAY
#
# /usr/openwin/bin/xclock
Error: Can't open display:

Si ponemos a mano la variable $DISPLAY, el error pasará de ser que no puede acceder al display a que no tiene autorización para usar el display:

# DISPLAY=localhost:10.0
# export DISPLAY
#
#  /usr/openwin/bin/xclock
X11 connection rejected because of wrong authentication.
X connection to localhost:10.0 broken (explicit kill or server shutdown).

Una solución, aprovechando que root puede acceder a los ficheros de todos los usuarios, es modificar la variable $XAUTHORITY para usar el fichero .Xauthority del usuario con el que entramos y no el de root:

# XAUTHORITY=/export/home/usuarioprueba/.Xauthority
# export XAUTHORITY
#
# /usr/openwin/bin/xclock

Al entrar a un sistema por SSH con la opción de reenvío de X11 activada, el servidor SSH añade una MIT-MAGIC-COOKIE-1 al fichero $HOME/.Xauthority para que sólo ese usuario (y no otros que estén conectados a la máquina e intenten usar el mismo $DISPLAY) pueda usar su túnel SSH para reenviar ventanas X11. Si el usuario root usa la misma magic cookie, pues podrá entrar sin problemas.

Otra opción para no reemplazar por completo el .Xauthority de root pasa por listar las magic cookies disponibles en el .Xauthority del usuario:

$ /usr/openwin/bin/xauth list
clientessh:0  MIT-MAGIC-COOKIE-1  e712f99f148d5bf00e5df9f345635434
sistemavncserver:1  MIT-MAGIC-COOKIE-1  d30c3ab6ca017837260ff6221fd80da7
solx86/unix:10  MIT-MAGIC-COOKIE-1  1d9076a2068a5e79d1259bea382cec2d

extraemos en formato binario sólo la entrada que nos interesa:

$  /usr/openwin/bin/xauth extract .Xauthority_solx86 solx86/unix:10

y ya como root, unimos la entrada a las existentes y ya podremos acceder al servidor X:

$ su -
Password:
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
# DISPLAY=localhost:10.0
# export DISPLAY
#
# /usr/openwin/bin/xauth merge /export/home/prueba/.Xauthority_solx86
#
# /usr/openwin/bin/xauth list
solx86/unix:10  MIT-MAGIC-COOKIE-1  1d9076a2068a5e79d1259bea382cec2d
#
# /usr/openwin/bin/xclock

Y otra opción más sería, tras listar las entradas existentes, simplemente añadir la magic cookie a mano en el .Xauthority de root:

# /usr/openwin/bin/xauth add solx86/unix:10  MIT-MAGIC-COOKIE-1  1d9076a2068a5e79d1259bea382cec2d
#
# /usr/openwin/bin/xclock

Decíamos que en Linux no tenemos este problema. Al pasarnos a root, la variable $DISPLAY se conserva y no necesitamos añadir la magic cookie para que el reenvío de ventanas X11, simplemente, siga funcionando:

# ssh -X usuariopruebap@rh5x64
usuariopruebap@rh5x64's password:
$
$ xclock
$
$ echo $DISPLAY
localhost:10.0
$
$ su -
Password:
[root@rh5x64 ~]# echo $DISPLAY
localhost:10.0

Esta magia de los sistemas Linux la proporciona el módulo PAM pam_xauth:

The pam_xauth PAM module is designed to forward xauth keys (sometimes referred to as “cookies”) between users.

Without pam_xauth, when xauth is enabled and a user uses the su(1) command to assume another user’s privileges, that user is no longer able to access the original user’s X display because the new user does not have the key needed to access the display. pam_xauth solves the problem by forwarding the key from the user running su (the source user) to the user whose identity the source user is assuming (the target user) when the session is created, and destroying the key when the session is torn down.

Así, en el fichero /etc/pam.d/su, típicamente encontraremos una línea como ésta:

session         optional        pam_xauth.so

El módulo guarda las magic cookies necesarias en diferentes ficheros $HOME/.xauth??????:

# xauth -f .xauthrBGj8r list
rh5x64/unix:10  MIT-MAGIC-COOKIE-1  aaceeca9bf499b5c85aba64a3ae42bd0

que, aunque normalmente se eliminan solos al salir, en ocasiones se quedan ahí abandonados. Por ello, en Google podemos encontrar bastantes casos de gente preguntando qué son dichos ficheros .xauthXXXXX y por qué tienen muchos.

Y para finalizar, una mención al Remote X Apps mini-HOWTO, en el que podremos repasar los conceptos básicos sobre cómo ejecutar aplicaciones X11 de un sistema en el servidor X de otro sistema UNIX/Linux.

:wq

Lo hice y lo entendí © Vicente Navarro 2011 con una licencia CC BY-SA | 8 comentarios
Etiquetas: GNU/Linux, HP-UX, OpenSSH, Solaris, SSH, UNIX, X Window System

Entradas relacionadas

• VPN con OpenSSH (3)
• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (3)
• Memoria swap en un fichero. ¿Cuánta memoria swap necesitamos? (3)
• Evitando problemas con la “host key” en sesiones no interactivas de OpenSSH (3)
• Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH (3)
• Autentificación trasparente por clave pública/privada con OpenSSH (3)

Feed enhanced by Better Feed from Ozh

OpenSSH permite esto desde su versión 4.3, y es tan sencillo que en la página man de ssh se describe en apenas 5 párrafos (sección SSH-BASED VIRTUAL PRIVATE NETWORKS). La parte no tan sencilla es la de gestionar las rutas.

Además, como digo, esta configuración es adecuada para una red improvisada y no como solución definitiva porque, como indica la propia página de manual, la sobrecarga por el protocolo SSH es muy alta:

     Since an SSH-based setup entails a fair amount of overhead, it may be
     more suited to temporary setups, such as for wireless VPNs.  More
     permanent VPNs are better provided by tools such as ipsecctl(8) and
     isakmpd(8).

Vamos a trabajar con el escenario mostrado en el siguiente esquema:

Tenemos dos oficinas de una misma empresa conectadas internamente y a Internet con el típico router/switch ADSL que tiene una única IP pública y que hace NAT para compartirla. Ahora queremos interconectarlas, de forma que todos los nodos de una oficina accedan a los de la otra y viceversa. En la primera de ellas se usa la subred 192.168.10.0/24 para la red local, y en la segunda, la subred 172.16.20.0/24. En la configuración del NAT del router ADSL de la segunda oficina abrimos el puerto 22 de SSH y lo redirigimos hacia el nodo servidorssh172 (172.16.20.2), que está ejecutando el sshd de OpenSSH. La IP pública de la segunda oficina debería ser fija o tal vez se podría usar un servicio de DNS dinámico. El nodo clientessh192 (192.168.10.2) de la primera red establecerá una conexión OpenSSH con el nodo servidorssh172 (172.16.20.2) de la segunda red usando la IP pública de la segunda oficina.

(...)

Leer el resto de VPN con OpenSSH (1,114 palabras)

Lo hice y lo entendí © Vicente Navarro 2010 con una licencia CC BY-SA | 9 comentarios
Etiquetas: GNU/Linux, OpenSSH, Redes, UNIX, Windows

Entradas relacionadas

• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (5)
• Port Knocking (4)
• Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget) (4)
• Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH (4)
• Accediendo a una red mediante NAT en Linux (4)
• Usando ntfsclone y dd para clonado por red con netcat (3)

Feed enhanced by Better Feed from Ozh

Lo más típico sería tratar de extender el sistema de ficheros, especialmente si estamos usando LVM, ya que sólo necesitaríamos algo de sitio libre en el VG. En Linux, si estamos usando particiones de toda la vida, también podríamos extender el sistema de ficheros con aplicaciones como GParted.

Otra opción bastante típica es la de montar un nuevo sistema de ficheros allí donde necesitemos espacio. Por ejemplo, si necesitamos más sitio en /opt/applicacionX porque ahí vamos a instalar una aplicación que necesita mucho espacio, podemos montar ahí un nuevo sistema de ficheros con todo el espacio necesario.

Si no tenemos espacio disponible en los discos, pero sí en otros sistemas de ficheros, siempre podemos hacer la típica chapucilla de crear un enlace simbólico del sistema de ficheros sin sitio a algún directorio del sistema de ficheros con suficiente espacio libre.

Hace unos días me encontré con una situación similar, pero en Windows. Me quedé sin espacio en C: y lo necesitaba para que cierta aplicación pudiera funcionar bien. Explorando las opciones que tenía, resulta que todas estas cosas que típicamente hacemos en sistemas UNIX también las podemos hacer en Windows.

(...)

Leer el resto de Unidades montadas y enlaces simbólicos en Windows (683 palabras)

Lo hice y lo entendí © Vicente Navarro 2010 con una licencia CC BY-SA | 8 comentarios
Etiquetas: UNIX, Windows

Entradas relacionadas

• VPN con OpenSSH (2)
• Samba/CIFS: Enlaces simbólicos y Unix CIFS Extensions (2)
• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (2)
• Wake on LAN (1)
• VFD, la disquetera virtual para Windows (1)
• Usando ntfsclone y dd para clonado por red con netcat (1)

Feed enhanced by Better Feed from Ozh

$ ssh usuario.dominio@sistema
The authenticity of host 'sistema (10.22.31.45)' can't be established.
RSA key fingerprint is 7d:2f:1e:69:21:e9:06:f3:d9:fd:36:0a:9e:6c:47:10.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'sistema.dominio,10.22.31.45' (RSA) to the list of known hosts.
[usuario@sistema ~]$

Actualización 5/7/2010: Como en el ejemplo anterior, en todos los ejemplos que siguen veremos que el comando ssh no nos pregunta la contraseña porque hemos configurado Autentificación trasparente por clave pública/privada con OpenSSH.

Dicha clave se almacena en el fichero $HOME/.ssh/know_hosts:

$ tail -1 known_hosts
sistema.dominio,10.22.31.45 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAng/LUBaJa0qATdMMkmB3ufytR/BauKbCyz+Dvg0NMPUE2EF6zy5o3zSVMRlrgUmKakA3DoUez5oOaaSlR4d5ZZjOfsBmnn5dp7M0QtY681HYny1QQFUpRxNbARP3X8+2jlnWjOEBOmk+N8pRJCURUwkjSMs81ThAiZoIv8sVYYbNzKDpL8RaDTqEN0Xn+1dHJdeLrt+Hsl6GzX8f+SoWwkNVmt8Nc8T7vzrG93Xku6XXdOh5SKeTDXv+0shJUziPQApEwR0gcc+7L0hBEAw4GU1ctGnC22aVDkyqTKlbORq2YoufDErq+wv8lwgZKYd5AbOuvuwX7w9c8P+P+jKw==

Actualización 5/7/2010: Que aparezca el nombre de los hosts en claro en el fichero known_hosts es un problema de seguridad, ya que permite a un atacante que haya conseguido acceder a nuestro sistema conocer fácilmente otras máquinas que pueden ser objeto de ataque. Para evitar el problema, desde OpenSSH 4.0, es posible ofuscar el nombre de la máquina en el known_hosts con un hash. Sólo es necesario usar la opción “HashKnownHosts yes” en /etc/ssh_config o en $HOME/.ssh/config y ejecutar “ssh-keygen -H” para ofuscar el nombre de los hosts en nuestro known_hosts actual: Hashing the OpenSSH known_hosts File. Algunas distribuciones de Linux ya están implementando esto por defecto.

Si la máquina remota es víctima de algún tipo de ataque, si se ha reinstalado, si se ha sustituido por otra máquina con la misma IP o si, por cualquier motivo, la máquina remota no manda la clave de host que corresponde con la que tenemos almacenada, la próxima vez que intentemos conectarnos a ella, obtendremos un error como el siguiente:

$ ssh usuario@sistema.dominio
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
77:8b:3f:5c:95:18:30:2b:83:fe:21:73:d2:16:85:64.
Please contact your system administrator.
Add correct host key in /home/usuario/.ssh/known_hosts to get rid of this message.
Offending key in /home/usuario/.ssh/known_hosts:2
RSA host key for sistema.dominio has changed and you have requested strict checking.
Host key verification failed.

Y no podremos volver a conectarnos a menos que eliminemos la entrada vieja del known_hosts y volvamos a intentarlo. En dicho caso, volverá a pedirnos que aceptemos la nueva clave remota del host remoto, como al principio.

Si tenemos algún proceso no interactivo que se base en SSH, el que nos pregunte si aceptamos la clave del host remoto es un problema importante. En dichos casos, podemos evitar que nos lo pregunte y hacer que el ssh local la acepte siempre automáticamente poniendo el siguiente parámetro en el /etc/ssh_config (para todos los usuarios) o en el $HOME/.ssh/config (sólo para el usuario actual):

StrictHostKeyChecking no

Tras ponerlo comprobaremos que, efectivamente, la clave del host remoto se añade automáticamente al known_hosts la primera vez que accedemos a un nodo sin preguntar:

$ ssh usuario@sistema.dominio
Warning: Permanently added 'sistema.dominio,10.22.31.45' (RSA) to the list of known hosts.
[usuario@sistema ~]$

Pero esto puede no ser suficiente. Hay veces en las que la clave del host remoto siempre o muy a menudo cambia. Por ejemplo, puede ocurrir cuando hacemos un “ssh localhost” tras crear algún tipo de túnel que cada vez acabe en una máquina diferente (Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH) o cuando trabajamos con multitud de máquinas físicas o virtuales (con éstas pasa especialmente a menudo) en las que reutilizamos frecuentemente la IP de unas máquinas en otras, etc.

Que la clave del host cambie frecuentemente es una simple molestia en sesiones interactivas (que nos obliga a buscar y a eliminar la entrada correspondiente del known_hosts), pero un auténtico problema cuando queremos usar ssh de forma no interactiva. En dichos casos, podemos solucionarlo usando el “StrictHostKeyChecking no” como antes, pero además, añadiendo ahora “UserKnownHostsFile /dev/null” en el $HOME/.ssh/config (no parece conveniente usarlo en el /etc/ssh_config y que aplique a todos los usuarios) para indicarle al comando ssh que en lugar de usar $HOME/.ssh/known_hosts para almacenar las claves de hosts, queremos usar /dev/null:

StrictHostKeyChecking no
UserKnownHostsFile /dev/null

Así conseguimos que, como las claves en realidad no se guardan, siempre que nos conectemos a una máquina se acepte automáticamente su clave de host, haya cambiado o no haya cambiado:

$ ssh usuario@sistema.dominio
Warning: Permanently added 'sistema.dominio,10.22.31.45' (RSA) to the list of known hosts.
[usuario@sistema ~]$ exit

$ ssh usuario@sistema.dominio
Warning: Permanently added 'sistema.dominio,10.22.31.45' (RSA) to the list of known hosts.
[usuario@sistema ~]$

Sobra decir que estas opciones suponen la eliminación de una medida de seguridad base del sistema SSH, con lo que se está más expuesto a posibles ataques.

:wq

Lo hice y lo entendí © Vicente Navarro 2010 con una licencia CC BY-SA | 9 comentarios
Etiquetas: Cygwin, GNU/Linux, OpenSSH, UNIX

Entradas relacionadas

• VPN con OpenSSH (3)
• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (3)
• Mantener el reenvío de ventanas X de SSH tras hacer un su (3)
• Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH (3)
• Backups con rsync (3)
• Usando ntfsclone y dd para clonado por red con netcat (2)

Feed enhanced by Better Feed from Ozh

Para conseguir tal cosa, apenas es necesario descomentar unas líneas de la configuración por defecto de Samba en Debian y Ubuntu (/etc/samba/smb.conf) y releer la configuración (sudo /etc/init.d/samba reload):

# Un-comment the following (and tweak the other settings below to suit)
# to enable the default home directory shares.  This will share each
# user's home directory as \\server\username
[homes]
   comment = Home Directories
   browseable = no

Normalmente un usuario tiene en su $HOME todos los ficheros que pueda necesitar, pero en los PC a menudo tenemos otros sistemas de ficheros (unidades externas, particiones grandes que se comparten entre sistemas operativos, etc.) en los que los usuarios guardan otros ficheros. Por ejemplo, yo tengo unas particiones adicionales que suelo montar en /mnt/e y en /mnt/i con los permisos adecuados para que los usuarios puedan escribir en ellas. En el $HOME de los usuarios tengo unos enlaces simbólicos a estos sistemas de ficheros:

vicente@servidorcifs ~ $ pwd
/home/vicente

vicente@servidorcifs ~ $ ll e i
lrwxrwxrwx 1 vicente vicente 7 2008-04-30 20:51 e -> /mnt/e/
lrwxrwxrwx 1 vicente vicente 7 2008-07-17 15:11 i -> /mnt/i/

Pues bien, ¿qué diríais que pasa cuando monto //servidorcifs/vicente/ desde otro sistema e intento acceder a //servidorcifs/vicente/e/ o a //servidorcifs/vicente/i/?

Pues que si intento acceder desde Windows, los enlaces e, i aparecerán como un directorio más al que puedo acceder y en donde encuentro los ficheros de /mnt/e/, /mnt/i/ que hay en la máquina. Este es el comportamiento deseado en este caso.

Sin embargo, si intento acceder desde otro Linux (con una versión reciente de Samba), tras montar el sistema de ficheros remoto:

vicente@clientecifs ~ $ sudo mount -t cifs -o username=vicente //servidorcifs/vicente /mnt/smb/

lo que ocurrirá es que en la máquina donde hemos montado el sistema de ficheros CIFS, los enlaces simbólicos e, i se verán como lo que son, enlaces simbólicos, y apuntarán a los directorios /mnt/e/, /mnt/i/ del cliente de CIFS, no del servidor de CIFS, con lo cual no tendremos acceso a los ficheros del usuario:

vicente@clientecifs ~ $ ll /mnt/smb/e /mnt/smb/i
lrwxrwxrwx 1 vicente vicente 7 2008-04-30 20:51 /mnt/smb/e -> /mnt/e/
lrwxrwxrwx 1 vicente vicente 7 2008-07-17 15:11 /mnt/smb/i -> /mnt/i/

vicente@clientecifs ~ $ cd /mnt/smb/e
-bash: cd: /mnt/smb/e: No such file or directory

(...)

Leer el resto de Samba/CIFS: Enlaces simbólicos y Unix CIFS Extensions (1,033 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 7 comentarios
Etiquetas: GNU/Linux, Kernel, Samba, UNIX, Windows

Entradas relacionadas

• VPN con OpenSSH (3)
• SMB connection failed: Insufficient server memory to perform the requested function. (3)
• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (3)
• Memoria swap en un fichero. ¿Cuánta memoria swap necesitamos? (3)
• Hibernación en Linux con TuxOnIce. Notas sobre los initrd y sobre cpio. (3)
• Fork Bombs, ulimit y limits.conf (3)

Feed enhanced by Better Feed from Ozh

Sin embargo, en aquella entrada nos dejamos en el tintero el reenvío dinámico de puertos y varios lectores lo echaron de menos, de modo que esta entrada tratará de complementar a aquélla (muchas gracias a todos por la sugerencia).

Cuando hablamos de hacer dynamic port forwarding con SSH, de lo que estamos hablando exactamente es de convertir el SSH en un servidor SOCKS. ¿Y qué es un servidor SOCKS?

¿Sabes para qué sirve un proxy web? Probablemente sí, muchas empresas usan uno. Se trata de un sistema directamente conectado a Internet que permite que los clientes de una intranet sin acceso a Internet puedan navegar por la web si configuran sus navegadores para que hagan sus peticiones a través del proxy (aunque también hay proxies transparentes). Un proxy web, además de permitir la salida a Internet, también cacheará las páginas, imágenes, etc. ya descargadas por algún cliente para no tener que descargarlas para otro cliente. Además, permite filtrar los contenidos y monitorizar la actividad de los usuarios. Sin embargo, su función básica es la de reenviar tráfico HTTP y HTTPS.

Un servidor SOCKS le daría un servicio similar a la intranet de una empresa que el que proporciona un servidor proxy pero no está limitado a HTTP/HTTPS, sino que permite reenviar cualquier trafico TCP/IP (con SOCKS 5 también UDP).

Por ejemplo, imaginemos que queremos usar nuestro correo usando POP3 o ICMP y SMTP con Thunderbird desde una intranet sin acceso directo a Internet. Si sólo tenemos un proxy web disponible, la único sencillo que nos quedaría sería usar algún webmail (aunque si es un webmail también podríamos usar la extensión Webmail de Thunderbird). También podríamos aprovecharnos del proxy montándonos un túnel por HTTP. Pero lo más sencillo sería que la red tuviera un servidor SOCKS disponible que nos permitiera usar POP3, ICMP y SMTP a través de él sin ningún inconveniente.

(...)

Leer el resto de Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (974 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 6 comentarios
Etiquetas: GNU/Linux, OpenSSH, Redes, SOCKS, Thunderbird, UNIX, wget, Windows

Entradas relacionadas

• VPN con OpenSSH (5)
• Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget) (5)
• Port Knocking (4)
• Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH (4)
• Accediendo a una red mediante NAT en Linux (4)
• Usando ntfsclone y dd para clonado por red con netcat (3)

Feed enhanced by Better Feed from Ozh

Como este tema está muy tratado por toda la red:

• Wikipedia: SSH Tunneling
• O’Reilly: Using SSH Tunneling
• ssh.com: Tunneling Explained
• ssh.com: Port Forwarding
• SecurityFocus: SSH Port Forwarding
• Red Hat Magazine: SSH Port Forwarding

en esta entrada no entraremos en los detalles del reenvío de puertos, sino que pretende ser una chuleta, una referencia rápida (cheat sheet) de cómo reenviar puertos TCP con OpenSSH en los 8 diferentes escenarios que se pueden dar. Otros clientes de SSH como PuTTY también permiten el reenvío de puertos, pero la configuración se hará con un interfaz gráfico. Nosotros nos centraremos en OpenSSH.

En los siguientes ejemplos y situaciones supondremos que tenemos una red externa y una red interna y entre ambas redes, la única conexión posible es una conexión SSH entre el nodo de la red external externo1 y el nodo de la red interna interno1. El nodo externo2 está en la red externa y tiene conectividad total con externo1. El nodo interno2 está en la red interna y tiene conectividad total con interno1.

(...)

Leer el resto de Creando túneles TCP/IP (port forwarding) con SSH: Los 8 escenarios posibles usando OpenSSH (1,242 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 19 comentarios
Etiquetas: GNU/Linux, OpenSSH, Redes, UNIX, VNC

Entradas relacionadas

• VPN con OpenSSH (4)
• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (4)
• Port Knocking (3)
• Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget) (3)
• Mantener el reenvío de ventanas X de SSH tras hacer un su (3)
• Evitando problemas con la “host key” en sesiones no interactivas de OpenSSH (3)

Feed enhanced by Better Feed from Ozh

Otros fabricantes desarrollaron otros tipos de terminales, con el mismo concepto, pero incompatibles con otros sistemas, como este HP 700/96, que aún se sigue usando en algunos CPD hoy en día:

Los ordenadores personales, como el PC y los Apple o los Commodore, Spectrum, Amstrad CPC, etc. siguieron otro camino para mostrar la información al usuario, ya que, o bien usaban un sistema de vídeo propietario para mostrar texto y gráficos (p.e. MDA o VGA), o bien se conectaban directamente al televisor.

Los grandes servidores UNIX (basados en AIX, HP-UX, Solaris, etc.) o similares (por ejemplo, basados en OpenVMS, o z/OS) han llegado a nuestros días permitiendo la conexión de un terminal serie para usar la consola, pero cada día es más infrecuente su uso, ya que han sido sustituidos por consolas LAN (accedemos por Telnet o por SSH a una dirección IP diferente a la propia del sistema) o por consolas Web (una página web donde nos aparece la consola), que, por supuesto, nos permiten interactuar con la máquina incluso durante el arranque y la parada.

Hoy en día los terminales serie están bastante en desuso. Sin embargo, los emuladores de terminal están en pleno apogeo, bien sean para conectarnos por Telnet, por SSH, o, por supuesto, por el puerto serie/módem (ya lo vimos en Configurar Linux para permitir el acceso remoto por módem a la consola y por RAS/PPP). Por cierto, ¿qué tipo de terminal emulan la mayoría de emuladores de terminal como mínimo? Pues, por supuesto, el famoso VT100. Pero como otros fabricantes hicieron otros terminales con sus propios protocolos, secuencias de escape y capacidades, hay múltiples tipos de emuladores de terminal. Las emulaciones de terminal ansi y vt100 (y tal vez xterm) son las más usadas.

(...)

Leer el resto de Emuladores de terminal. GNU screen: El multiplexador de sesiones de terminal. (1,373 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 21 comentarios
Etiquetas: GNU screen, GNU/Linux, PuTTY, termcap, terminal, terminfo

Entradas relacionadas

• Terminales para Cygwin. Notas sobre Terminfo y Termcap. (4)
• Probando la netconsole de Linux (2)
• El paso a UTF-8 con Ubuntu Hardy Heron: rsync entre sistemas con distinto juego de caracteres (2)
• Configurar Linux para permitir el acceso remoto por módem a la consola y por RAS/PPP (2)
• Autentificación trasparente por clave pública/privada con OpenSSH (2)
• Ya tenemos un plugin de Flash nativo para Linux de 64 bits (1)

Feed enhanced by Better Feed from Ozh

Si lo pensamos detenidamente, tener una partición de swap, es tener una cantidad de espacio ahí abandonada y que en rarísimas ocasiones veremos usar. Y si el kernel llega a usarla, hemos de prepararnos, en la mayoría de los casos, a experimentar un sistema extraordinariamente pesado, con lo que si es una situación habitual, más nos vale comprar una ampliación de la memoria. De nuevo, recalcar que me refiero a sistemas domésticos. En un servidor, la memoria swap nos puede ayudar a absorber un pico puntual de trabajo que sólo se da en ocasiones aisladas y que no podemos dejar de atender.

Para nuestro sistema doméstico, resulta mucho más conveniente un fichero de swap, igual que hacen todos los Windows basados en NT con el pagefile.sys. Las ventajas son muchas:

• Lo podemos poner en la partición/sistema de ficheros que queramos
• Podemos borrarlo para liberar espacio si éste nos hace falta
• Podemos crear uno nuevo en cualquier momento
• No supone tener un espacio en disco bloqueado inservible para otros propósitos
• Posiblemente su rendimiento sea algo peor que el de una partición dedicada de swap, pero si la memoria swap llega a tener que usarse intensivamente, el rendimiento será ya nefasto, ¿qué más da que sea un poco peor?

Y, además, lo último, lo de que el rendimiento es peor parece que ni siquiera es cierto. En la LKML leemos que usando kernels 2.6 el rendimiento de un fichero de swap no es peor que el de una partición de swap (Jesper Juhl: a swap file is just as fast as a swap partition):

With a 2.4.x kernel swap files were slower than swap partitions, but with the 2.6 kernel a swap file is just as fast as a swap partition.

(...)

Leer el resto de Memoria swap en un fichero. ¿Cuánta memoria swap necesitamos? (2,097 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 15 comentarios
Etiquetas: dd, GNU/Linux, HP-UX, Kernel, memoria RAM, rendimiento, swap, sysstat, UNIX

Entradas relacionadas

• sysstat, la colección de herramientas de monitorización de rendimiento (5)
• Solucionando el error “attempt to access beyond end of device” con reglas de udev, hal y/o un parche del kernel (3)
• Samba/CIFS: Enlaces simbólicos y Unix CIFS Extensions (3)
• Obtener estadísticas de dd mientras se está ejecutando (3)
• Mantener el reenvío de ventanas X de SSH tras hacer un su (3)
• Hibernación en Linux con TuxOnIce. Notas sobre los initrd y sobre cpio. (3)

Feed enhanced by Better Feed from Ozh

La última vez que he sido consciente de mi enorme desconocimiento ha sido esta semana, cuando fruto de un comportamiento que me parecía ilógico me enredé con manuales y documentación de diferentes shells. ¿Habrá mucha gente capaz de dominar casi todos los aspectos de la shell?

Vayamos al grano… El problema que tuve fue que un script muy sencillo que en ksh funcionaba sin problemas, en bash no hacía lo que esperaba. El problema estaba en una línea como esta:

comando | read a b c

(...)

Leer el resto de Redirigir la salida de un comando a un read con una tubería (pipe) (1,288 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 4 comentarios
Etiquetas: GNU/Linux, shell, UNIX

Entradas relacionadas

• Sobre la señal SIGHUP: nohup, disown, trap (3)
• Expresiones Regulares en la shell. Ejemplos de uso con grep, awk y sed. (3)
• VPN con OpenSSH (2)
• Servir con Apache imágenes con marca de agua (watermark) (2)
• Samba/CIFS: Enlaces simbólicos y Unix CIFS Extensions (2)
• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (2)

Feed enhanced by Better Feed from Ozh

rsync es una herramienta para sincronizar los ficheros y directorios que tenemos almacenados en un sitio en otro diferente minimizando la transferencia de datos (Wikipedia: rsync). En realidad, rsync son dos cosas: un algoritmo de delta compression para sincronizar dos ficheros similares y una utilidad que usa dicho algoritmo junto con otras técnicas para hacer mirroring de ficheros y directorios en otro sitio transfiriendo la mínima cantidad de datos posible.

(...)

Leer el resto de Backups con rsync (3,566 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 87 comentarios
Etiquetas: backup, Cygwin, GNU/Linux, OpenSSH, rsync, Windows

Entradas relacionadas

• Hosting casero HOWTO (4)
• El paso a UTF-8 con Ubuntu Hardy Heron: rsync entre sistemas con distinto juego de caracteres (4)
• ¿Piensas en si un día te roban el portátil? (4)
• VPN con OpenSSH (3)
• Usando ntfsclone y dd para clonado por red con netcat (3)
• Servicios en Cygwin (syslogd, sshd, telnetd, ftpd, nfsd, etc.) (3)

Feed enhanced by Better Feed from Ozh

Cómo hacer esto en concreto varía entre implementaciones de cliente y servidor de SSH, pero si estamos usando OpenSSH, que es lo estándar tanto en Linux y *BSD, como en Cygwin, sólo hay que seguir unos sencillos pasos que vamos a ver a continuación.

(...)

Leer el resto de Autentificación trasparente por clave pública/privada con OpenSSH (534 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 13 comentarios
Etiquetas: Debian, GNU/Linux, OpenSSH, PuTTY, SSH

Entradas relacionadas

• Port Knocking (3)
• Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget) (3)
• Mantener el reenvío de ventanas X de SSH tras hacer un su (3)
• Hosting casero HOWTO (3)
• El paso a UTF-8 con Ubuntu Hardy Heron: rsync entre sistemas con distinto juego de caracteres (3)
• VPN con OpenSSH (2)

Feed enhanced by Better Feed from Ozh

El puerto de red asignado al syslog es el 514/UDP:

# grep syslog /etc/services
syslog          514/udp

Sin embargo, el proceso syslogd de Debian no se conecta a ese puerto porque no escucha mensajes de la red por defecto. Si queremos que lo haga, tenemos que editar el fichero /etc/default/syslogd, que en la configuración estándar no contiene ninguna opción:

# For remote UDP logging use SYSLOGD="-r"
#
SYSLOGD=""

Si queremos que escuche de la red, hemos de especificar la opción -r:

# For remote UDP logging use SYSLOGD="-r"
#
SYSLOGD="-r"

que sirve precisamente para esto:

       -r     This option will enable the facility to receive message from the
              network using an internet domain socket with the syslog  service
              (see  services(5)).   The default is to not receive any messages
              from the network.

y reiniciar el proceso con “/etc/init.d/sysklogd restart“. Tras esto, podremos comprobar que el demonio funciona con la opción deseada

# ps -ef | grep syslog
root      4547     1  0 17:35 ?        00:00:00 /sbin/syslogd -r

y que el proceso está escuchando en el puerto 514/UDP:

# netstat -a | grep syslog
udp        0      0 *:syslog                *:*

Puesto que los mensajes del Zyxel van a llegar por la facility local2, podemos querer establecer un fichero de log específico para él en el /etc/syslog.conf (para que se relea después de modificarlo, haremos un “/etc/init.d/sysklogd reload“):

local2.* /var/log/zyxel.log

Si quisiéramos que fuera un sistema Linux (por ejemplo, una Debian) el que mandara ciertos mensajes a un syslog remoto, podríamos hacerlo simplemente poniendo en el syslog.conf una línea como:

local3.* @sistemaremoto.dominio

Tras releer la configuración, con una sencilla prueba con el comando logger:

logger -p local3.info "Mensaje de prueba"

veremos que, efectivamente, el mensaje aparece en el sistema remoto en varios logs configurados para recibir mensajes de la prioridad formada por la pareja facility/level que hemos especificado:

# grep "Mensaje de prueba" /var/log/*
/var/log/messages:Dec  8 18:18:15 ordenador logger: Mensaje de prueba
/var/log/syslog:Dec  8 18:18:15 ordenador logger: Mensaje de prueba

Recordemos que las facilities son:

• auth, security ¹
• authpriv
• cron
• daemon
• ftp
• kern
• lpr
• mail
• mark (sólo para uso interno)
• news
• sys-log
• user
• uucp
• local0 → local7

y los levels:

• debug
• info
• notice
• warning, warn ¹
• error, err ¹
• crit
• alert
• emerg, panic ¹

1. En los casos en que aparecen dos etiquetas juntas, la segunda es equivalente a la primera y está obsoleta.

Si tomamos una traza de red vemos que el protocolo (BSD syslog Protocol) es extraordinariamente sencillo (RFC 3164):

Podemos ver que la prioridad es un byte que contiene la facility (5bits) y el level (3bits).

Con un simple netcat también podemos mandar mensajes a un syslogd remoto que esté escuchando la red, aunque no pongamos la cabecera con la prioridad y la fecha del evento:

# echo "Nuevo mensaje de prueba con el netcat" | netcat -q 0 -u 192.168.1.20 514

y en el /var/log/syslog remoto encontramos el mensaje:

Dec  8 18:39:15 ordenador Nuevo mensaje de prueba con el netcat

:wq

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 9 comentarios
Etiquetas: Debian, GNU/Linux, syslog, UNIX, Zyxel 660HW

Entradas relacionadas

• Sobre la señal SIGHUP: nohup, disown, trap (3)
• Probando la netconsole de Linux (3)
• Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget) (3)
• Hosting casero HOWTO (3)
• Hibernación en Linux con TuxOnIce. Notas sobre los initrd y sobre cpio. (3)
• Expresiones Regulares en la shell. Ejemplos de uso con grep, awk y sed. (3)

Feed enhanced by Better Feed from Ozh

Los PCs no están bien preparados para tener como única posibilidad de entrada/salida un terminal serie. Al menos no durante el arranque y para configurar la BIOS. Una vez que el sistema operativo o el GRUB toma el control ya sí que podemos usar el puerto serie para gestionar el ordenador. Pero es precisamente en circunstancias muy dramáticas cuando nos puede interesar especialmente controlar el arranque remotamente. Por eso hay fabricantes de servidores x86 cuyos sistemas permiten redirigir la salida de la BIOS a un puerto serie, como por ejemplo la HP BIOS Serial Console. Para ampliar información sobre servidores con esta posibilidad, podemos leer sobre IPMI y sobre Out-of-band management o Lights-out management. En la web en japonés sobre la tarjeta Lights-Out 100 de HP podemos ver capturas de una BIOS por el puerto serie.

En cualquier caso, en PCs normales no tenemos esta posibilidad. El primer momento en el que podemos comenzar a redirigir la salida estándar es en el GRUB. El segundo momento es al arrancar el kernel de Linux. El tercero es cuando el sistema operativo ya está totalmente arriba.

Veamos cómo acceder a la consola por el puerto serie una vez que el sistema está arriba y luego veremos qué dificultades presentan los otros casos.

(...)

Leer el resto de Configurar Linux para permitir el acceso remoto por módem a la consola y por RAS/PPP (2,559 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 18 comentarios
Etiquetas: consola, Debian, GNU/Linux, GRUB, iptables, minicom, modem, NAT, PPP, RAS, terminal, UNIX

Entradas relacionadas

• Probando la netconsole de Linux (5)
• Hibernación en Linux con TuxOnIce. Notas sobre los initrd y sobre cpio. (4)
• vga=ask y los modos VESA disponibles en el sistema (3)
• Sobre la señal SIGHUP: nohup, disown, trap (3)
• Instalar Ubuntu 8.04 Hardy Heron sobre un fakeRAID (3)
• Hosting casero HOWTO (3)

Feed enhanced by Better Feed from Ozh

vnavarro@DARKSTAR ~
$echo $TERM
cygwin

Cada tipo de terminal supone una forma diferente de hacer scrolling, de mover las líneas por la pantalla, los retornos de carro y de línea, de borrar el carácter anterior, de limpiar la pantalla, de conocer el número de líneas y columnas, de cómo usar colores y si se pueden usar, etc. Para la mayoría de aplicaciones de línea de comandos típicas de UNIX (por ejemplo, ls, awk, sed, grep, cat, mv, cp), todas estas especificaciones son indiferentes: Ellas toman la información que necesitan de sus argumentos de la línea de comandos o de la entrada estándar y sacan los resultados a través de la salida estándar y del código de error. Pueden incluso funcionar sin un terminal. Sin embargo, hay muchas otras aplicaciones que tienen que conocer muy bien cómo mover y posicionar texto por el terminal, como por ejemplo el vim, el mc, o el top.

Para que las aplicaciones que lo necesiten puedan interactuar con los múltiples tipos diferentes de terminales, las aplicaciones pueden usar, bien la librería Termcap, bien la librería ncurses junto con la base de datos de terminales Terminfo.

El Terminfo almacena la información de todos los tipos de terminal en /usr/share/terminfo. Dentro de ese directorio, por ejemplo el fichero c/cygwin almacena la información sobre el tipo de terminal que por defecto usa el Cygwin en el CMD de Windows, y el fichero v/vt100 almacena el tipo de terminal más común y más emulado.

El Termcap también tiene su (mucho más pequeña) base de datos de terminales centralizada en un fichero único, el /etc/termcap. Podemos usar herramientas como el infocmp -C o el captoinfo (herramientas incluidas en el ncurses) para pasar la configuración para un tipo de terminal de un formato al otro.

(...)

Leer el resto de Terminales para Cygwin. Notas sobre Terminfo y Termcap. (1,034 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 2 comentarios
Etiquetas: Cygwin, PuTTY, termcap, terminal, terminfo, X Window System

Entradas relacionadas

• Emuladores de terminal. GNU screen: El multiplexador de sesiones de terminal. (4)
• El paso a UTF-8 con Ubuntu Hardy Heron: rsync entre sistemas con distinto juego de caracteres (2)
• vga=ask y los modos VESA disponibles en el sistema (1)
• Trabajando con Cygwin (1)
• Servicios en Cygwin (syslogd, sshd, telnetd, ftpd, nfsd, etc.) (1)
• Probando la netconsole de Linux (1)

Feed enhanced by Better Feed from Ozh

Para poder usar servicios de red, es muy importante tener en cuenta que la configuración por defecto del Firewall de Windows no nos permitirá su uso, de modo que en todo momento tenemos que tener en cuenta la necesidad de configurar correctamente este Firewall o cualquier otro Firewall Personal que podamos tener instalado.

También es muy importante, si queremos crear servicios de Windows, haber hecho la instalación para todos los usuarios, no sólo para el actual:

Además, los usuarios de Windows 2003 tendrán que tener alguna precaución adicional, ya que como dice el manual de Cygwin en la importante sección NT security and usage of ntsec:

On NT and Windows 2000 the SYSTEM user has these privileges and can run services such as sshd. However, on Windows 2003 SYSTEM lacks the Create a token object right, so it is necessary to create a special user with all the necessary rights, as well as Logon as a service, to run such services. For security reasons this user should be denied the rights to logon interactively or over the network.

En esta entrada vamos a tratar los siguientes servicios:

• inetd
• xinetd
• syslogd
• sshd
• nfsd, mountd, portmap
• cygserver
• Eliminar todos los servicios
• Y si algo no funciona…

(...)

Leer el resto de Servicios en Cygwin (syslogd, sshd, telnetd, ftpd, nfsd, etc.) (2,656 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | Un comentario
Etiquetas: Cygwin, OpenSSH, SSH, Windows

Entradas relacionadas

• Backups con rsync (3)
• VPN con OpenSSH (2)
• Usando ntfsclone y dd para clonado por red con netcat (2)
• Trabajando con Cygwin (2)
• Reenvío dinámico de puertos / montar un servidor SOCKS con SSH (2)
• Port Knocking (2)

Feed enhanced by Better Feed from Ozh

Sin embargo, el Cygwin tiene algunas peculiaridades debidas a su naturaleza Windowsera que conviene que conozcamos para poder sacar el máximo rendimiento de este excelente proyecto. Vamos a verlas:

• Formas de escribir los paths en Cygwin
• El sistema de paquetes
• La longitud de los argumentos en la línea de comandos
• Los ficheros de dispositivo /dev
• La extensión .exe
• El directorio /proc
• Las utilidades
• Enlaces simbólicos
• ¿LF o CR/LF?
• Referencias imprescindibles

(...)

Leer el resto de Trabajando con Cygwin (2,148 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 74 comentarios
Etiquetas: Cygwin, Windows

Entradas relacionadas

• Servicios en Cygwin (syslogd, sshd, telnetd, ftpd, nfsd, etc.) (2)
• Pequeños trucos para Windows (2)
• Instalar un Cygwin portable en una memoria USB (2)
• El paso a UTF-8 con Ubuntu Hardy Heron: rsync entre sistemas con distinto juego de caracteres (2)
• Ejemplos de scripting en Windows: Añadir la fecha y la hora al nombre de un fichero (2)
• Cambiar la fuente del CMD de Windows (2)

Feed enhanced by Better Feed from Ozh

• Una librería dll (cygwin1.dll) que proporciona una capa de emulación de POSIX a las aplicaciones que hagan uso de ella.
• Una muy importante colección de herramientas migradas de Linux fácilmente usando la librería anterior.

Con Cygwin tenemos en un entorno unificado la mayoría de las aplicaciones de consola de Linux y, además, como lleva también una implementación del X.org (Cygwin/X), también muchas aplicaciones gráficas. Hay incluso GNOME sobre Cygwin (CyGNOME) y KDE sobre cygwin.

Para dar una idea de lo que lleva cygwin, podemos citar algunos de los programas que lleva la distribución estándar: gcc, bash, sed, awk, bzip2, wget, apache, ssh, sshd, perl, vim, emacs, latex, pine, netcat, rsync, rpm, dpkg, mc, cpio, curl, gv, fvwm, twm, xfig, xterm… Cygwin Package List.

(...)

Leer el resto de Instalar un Cygwin portable en una memoria USB (2,162 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 10 comentarios
Etiquetas: aplicaciones portables, Cygwin, memorias USB, Windows

Entradas relacionadas

• Trabajando con Cygwin (2)
• Sobre el BartPE. Arrancar Windows/BartPE desde una memoria USB. (2)
• Servicios en Cygwin (syslogd, sshd, telnetd, ftpd, nfsd, etc.) (2)
• Pequeños trucos para Windows (2)
• Instalar Windows XP desde una memoria USB que arranque BartPE (2)
• El paso a UTF-8 con Ubuntu Hardy Heron: rsync entre sistemas con distinto juego de caracteres (2)

Feed enhanced by Better Feed from Ozh

The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell
resends the SIGHUP to all jobs, running or stopped. Stopped jobs are sent SIGCONT to
ensure that they receive the SIGHUP. To prevent the shell from sending the signal to a
particular job, it should be removed from the jobs table with the disown builtin (see
SHELL BUILTIN COMMANDS below) or marked to not receive SIGHUP using disown -h.

Ante la señal SIGHUP normalmente todos los procesos reaccionan simplemente saliendo, lo cual es un problema si queremos que nuestro programa siga ejecutándose en el sistema una vez que hayamos dejado la shell. Para evitar que esto ocurra, tradicionalmente se ha usado el comando nohup. Adicionalmente, el bash, desde la versión 2.0, también tiene el comando interno disown como podemos leer en el párrafo anterior.

(...)

Leer el resto de Sobre la señal SIGHUP: nohup, disown, trap (1,183 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 15 comentarios
Etiquetas: bash, C, Debian, disown, GNU/Linux, nohup, patch, shell, SIGHUP, trap, UNIX

Entradas relacionadas

• Hibernación en Linux con TuxOnIce. Notas sobre los initrd y sobre cpio. (4)
• Expresiones Regulares en la shell. Ejemplos de uso con grep, awk y sed. (4)
• Solucionando el error “attempt to access beyond end of device” con reglas de udev, hal y/o un parche del kernel (3)
• Sobre las VIA EPIA (VI): Gráficos y vídeo acelerado por HW en Linux con la EX10000EG (3)
• Redirigir la salida de un comando a un read con una tubería (pipe) (3)
• Mostrar un árbol de los paquetes instalados que dependen de otro en Debian (3)

Feed enhanced by Better Feed from Ozh

QUERY_STRING='parametro1=valor1&parametro2=valor2&parametro3=valor3'

Estaba yo ya comenzando a darle vueltas a una Expresión Regular para interpretar dicha salida cuando he decidido buscar en Google para ver si alguien tenía una solución más completa que la que yo ya tenía a medias. He llegado al artículo CGI Scripting Tips for Bash or SH que propone lo siguiente para extraer del QUERY_STRING la variable que nos interese:

PARAMETROX=`echo "$QUERY_STRING" | grep -oE "(^|[?&])parametrox=[^&]+" | sed "s/%20/ /g" | cut -f 2 -d "="`

Y es que con bash y sus compañeros sed, awk, cat, grep, etc. aún se puede hacer casi de todo, incluso un weblog o un servidor web. Como las Expresiones Regulares son tan excepcionalmente útiles como complicadas a la hora de usarlas, me he decidido a comentar algunos ejemplos, comenzando por el que me ha llevado a este artículo.

(...)

Leer el resto de Expresiones Regulares en la shell. Ejemplos de uso con grep, awk y sed. (1,917 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 9 comentarios
Etiquetas: aMule, awk, Debian, ed2k, expresiones regulares, GNU/Linux, grep, sed, shell, UNIX

Entradas relacionadas

• Sobre la señal SIGHUP: nohup, disown, trap (4)
• Redirigir la salida de un comando a un read con una tubería (pipe) (3)
• Hosting casero HOWTO (3)
• Hibernación en Linux con TuxOnIce. Notas sobre los initrd y sobre cpio. (3)
• El Sticky Bit y el SGID en directorios (3)
• Configurar Linux para permitir el acceso remoto por módem a la consola y por RAS/PPP (3)

Feed enhanced by Better Feed from Ozh

sst rwx rwx rwx
421 421 421 421
S   U   G   O

S=SUID, SGID y Sticky Bit
U=Usuario
G=Grupo
O=Otros

Esto forma parte de los conocimientos básicos y mínimos de cualquier usuario de UNIX y podemos leer sobre ello en Permisos de ficheros del manual Seguridad en UNIX y Redes. También es muy conocida la existencia de los bits SUID y SGID, formados por los dos bits más significativos del octal más significativo. Aplicados sobre un fichero ejecutable, permiten que el programa se ejecute como si lo hiciera el usuario propietario (SUID) o el grupo propietario(SGID) del fichero.

Pero el propósito de esta entrada es resaltar la curiosidad, bastante menos conocida, de aplicar el bit menos significativo de la cifra octal más significativa (el que en el esquema anterior he marcado con una t), el Sticky Bit, a un directorio (aplicado a un fichero no se usa para nada en la gran mayoría de los UNIX modernos). En el man del chmod leemos:

(...)

Leer el resto de El Sticky Bit y el SGID en directorios (377 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 11 comentarios
Etiquetas: Debian, filesystems, GNU/Linux, Sticky Bit, UNIX

Entradas relacionadas

• Sobre la señal SIGHUP: nohup, disown, trap (3)
• Instalar Ubuntu 8.04 Hardy Heron sobre un fakeRAID (3)
• Hibernación en Linux con TuxOnIce. Notas sobre los initrd y sobre cpio. (3)
• Expresiones Regulares en la shell. Ejemplos de uso con grep, awk y sed. (3)
• El paso a UTF-8 con Ubuntu Hardy Heron: rsync entre sistemas con distinto juego de caracteres (3)
• Creación de reglas udev para personalizar el nombre de los ficheros de dispositivo de las memorias USB (3)

Feed enhanced by Better Feed from Ozh