Hiparco

Recetas y trucos de GNU/Linux e informática en general

Alojado en http://guimi.net

Reconfigurar WiFi en Windows 8

Windows 8 (los dioses confundan a sus creadores) elimina la interfaz gráfica que permitía gestionar las redes WiFi, de manera que si se configura una erróneamente, no se puede editar ni re-crear.

Ante esta situación debemos acudir a la línea de comandos.

Para ello buscamos la consola -> botón derecho -> lanzar como administrador.

Eliminar un perfil:
netsh wlan delete profile name=”ProfileName”

Mostrar todos los perfiles inalámbricos en el equipo:
netsh wlan show profiles

Mostrar una clave de seguridad:
netsh wlan show profile name=”ProfileName” key=clear

Más información:
http://windows.microsoft.com/es-es/windows-8/manage-wireless-network-profiles

sshfs – Montando recursos mediante SSH y FUSE

Mediante SSH y FUSE podemos montar un recurso de una máquina remota. Se pueden usar las opciones de ssh y de fuse, pero puede resultar un poco confuso.
Aquí un ejemplo con opciones para cambiar el puerto y usar un fichero de clave:

$ sshfs guimi@guimi.net:/home/guimi ~/mnt -p [puerto] -o IdentityFile=[fichero]

Instalación
Como siempre, es muy facil:

# aptitude install sshfs

Además, el usuario debe estar en el grupo “fuse”.

Otros artículos relacionados

Configuración de ssh
Confianza ssh
Túneles SSH
Uso de ssh
Uso de scp

ssh, fuse, sshfs

Uso de VNC: Escritorio remoto. Compartir escritorio.

VNC (Virtual Network Computing/Computer) permite utilizar una sesión gráfica de un equipo desde otro. Hay servidores y clientes disponibles para los principales SO como GNU/Linux, Mac, Windows…
La sesión gráfica puede ser la misma que se utiliza desde la consola del equipo u otra diferente, siempre que lo permita el sistema operativo. Así se puede compartir una sesión, útil para dar soporte remoto, por ejemplo; o bien se puede utilizar una sesión totalmente independiente.

Siendo VNC (incluido su protocolo) software libre, existen múltiples versiones del servidor (vncserver) y del cliente (vncviewer). No es el objeto de este artículo comentar las ventajas e inconvenientes de cada uno. Las diferentes versiones tienen diferentes optimizaciones, algunos permiten claves de “solo lectura”… Pero en lo principal siguen el estándar y no se diferencian.

Con GNU/Linux, en algunas situaciones, en vez de usar VNC puede ser mejor usar ssh con reenvío de las X (ssh -X servidor; ver Túneles SSH).

Servidor

Por un lado tenemos x11vnc que se usa para compartir una sesión gráfica y por tanto se ha de lanzar desde una sesión con entorno gráfico.
Por otro lado tenemos vncserver que genera diferentes instancias de las X. Se usa por tanto para generar nuevos escritorios independientes.

Compartir escritorio (x11vnc)

Se instala con el previsible:

# aptitude install x11vnc

Y su uso más sencillo es:

$ x11vnc -many

Aunque esto es inseguro.

Para mejorar un poco la situación se recomienda crear una clave (por omisión en ~/.vnc/passwd):

$ x11vnc -storepasswd

Y después lanzar el servidor

$ x11vnc -usepw

Si queremos poner la clave en otro fichero podemos usar:

$ x11vnc -storepasswd /path/to/file
$ x11vnc -rfbauth /path/to/passfile

Generar nuevos escritorios (vncserver)

vncserver es provisto por diferentes programas, como tightvncserver y vnc4server. Podemos instalarlos así (solo es necesario uno):

# aptitude install tightvncserver
# aptitude install vnc4server

Para generar un nuevo escritorio simplemente hacemos:

$ vncserver
New 'servidor:1 (usuario)' desktop is servidor:1

Starting applications specified in /home/usuario/.vnc/xstartup
Log file is /home/usuario/.vnc/servidor:1.log

Nota: Si no existe una clave , por ejemplo la primera vez que se utiliza, solicita al menos una nueva clave. Puede generarse una clave añadida que permita únicamente ver el escritorio pero no interactuar.

You will require a password to access your desktops.

Password: 
Warning: password truncated to the length of 8.
Verify:   
Would you like to enter a view-only password (y/n)? n

Para matar un escritorio hacemos:

$ vncserver -kill :1

Si queremos optimizar la conexión, lo que generalmente ocurre si la conexión no se realiza en una red local, podemos hacer:

$ vncserver :1 -geometry 1024×768 -depth 16 -pixelformat rgb565

Cliente (vncviewer)

El uso del cliente es independiente de si el servidor está compartiendo un entorno gráfico (x11vnc) o generando uno independiente (vncserver).
De nuevo existen múltiples versiones del cliente que proveen el programa vncviewer. Por ejemplo:

# aptitude install xtightvncviewer

Para conectar con el servidor hacemos:

$ vncviewer servidor:puerto
Connected to RFB server, using protocol version 3.8
Enabling TightVNC protocol extensions
Performing standard VNC authentication
Password: 

A la hora de indicar el puerto podemos simplemente indicar el número del escritorio. Este número lo indica el servidor y suele ser el 0 para el escritorio disponible en consola (compartido por x11vnc), el 1 el primer escritorio generado por vncserver…
En todo caso el servidor lo indica en su ejecución (en el ejemplo de arriba “servidor:1″).

Esto no siempre funciona bien fuera de una red local por lo que es mejor indicar el puerto. Por omisión el puerto utilizado es el 590x (5900 para el :0, 5901 para el :1…).

Si conectamos a un equipo a través de una red lenta podemos hacer:

$ vncviewer -encodings “copyrect hextile” servidor:5901

VNC a través de túnel SSH

El protocolo VNC es inseguro. Aunque algunas versiones de servidor vnc implementan capas de SSL, el sistema más estándar es utilizar un túnel ssh:

$ ssh servidor -N -f -L 5901:localhost:5901
$ vncviewer -encodings "copyrect hextile" localhost:5901

Como para VNC la conexión es a un puerto local, por defecto no comprime la comunicación (indica “Same machine: preferring raw encoding”), por eso forzamos la compresión con el parámetro -encodings “copyrect hextile” (ver un poco más arriba como optimizar desde el lado del servidor -vncserver-).

Uso de scp

El uso de scp es muy similar al de ssh (Uso de ssh).
El único parámetro “importante” que cambia es el que indica el puerto, que en ssh es -p y en scp es -P. Todavía no entiendo el porqué de este cambio tan molesto.

El uso es muy similar a cp pero indicando el equipo remoto.

Para copiar el fichero local “prueba” en el equipo remoto (servidor) usamos:

$ scp prueba servidor:.

El fichero se copiará en la carpeta inicial del usuario en el servidor (generalmente ‘/home/usuario/’).

Podemos indicar rutas relativas a la carpeta inicial o absolutas.
Para copiar el fichero “documentos/prueba” del servidor al equipo local usamos:

$ scp servidor:documentos/prueba .

Ahora, usando parámetros de ssh/scp:

$ scp -P 10022 -i .ssh/id_dsa *.tgz usuario@servidor:/ruta/fichero

Otros artículos relacionados:
Configuración de ssh
Confianza ssh
Túneles SSH
Uso de ssh
sshfs – Montando recursos mediante SSH y FUSE

ssh, scp

Uso de ssh

En esta entrada resumiré los diferentes usos del cliente ssh que han ido apareciendo en otras entradas.
Para configurar un servidor ssh se puede consultar: Configuración de ssh.

El uso más sencillo del cliente ssh es:

$ ssh servidor

Esto nos abre una sesión remota interactiva con servidor.
Estamos dando por supuesto que el usuario del equipo remoto tiene el mismo nombre que nuestro usuario local y que el servidor ssh está escuchando en el puerto estándar (22).
Para indicar el usuario del servidor hacemos:

$ ssh usuario@servidor

Algunos parámetros útiles:

-p puerto
Indica el puerto del servidor ssh al que conectarse (puerto)
-i fichero
utiliza el fichero de claves fichero para autenticar la conexión, en vez de usuario/password (ver Confianza ssh)
-X
Indica que queremos utilizar nuestro servidor X para las aplicaciones gráficas (ver Túneles SSH)
-L puerto_local:maquina3:puerto_maquina3
Realiza un túnel entre puerto_local y maquina3:puerto_maquina3 (ver Túneles SSH)
-R puerto_remoto:maquina3:puerto_maquina3
Realiza un túnel entre servidor:puerto y maquina3:puerto_maquina3 (ver Túneles SSH)
-N
Sin conexión interactiva (útil en Túneles SSH)
-f
En segundo plano (útil en Túneles SSH). Al acabar puede usarse, por ejemplo $ killall ssh

Por ejemplo con ficheros de claves, puerto no estándar, usuario diferente del local y varios túneles:

$ ssh usuario@servidor -p 10022 -i .ssh/id_dsa -X -L 18070:localhost:8070 -L 5555:localhost:5901

Otros artículos relacionados

Configuración de ssh
Confianza ssh
Túneles SSH
Uso de scp
sshfs – Montando recursos mediante SSH y FUSE

ssh
 

Túneles SSH

Podemos usar SSH para generar túneles seguros. Estos túneles ssh establecen una conexión cifrada entre un puerto de nuestra máquina local y otro puerto accesible desde la máquina remota, generalmente un puerto local de la máquina remota, pero no necesariamente.

Puede ver como configurar un servidor ssh [Configuración de ssh], de confianza ssh, usos básicos de ssh [Uso de ssh] y scp [Uso de scp].

Túnel directo

Si queremos conectar con un servidor MySQL de una maquina remota “servidor” sin usar ssh conectaremos con nuestro cliente de base de datos al puerto 3306 del servidor. El problema es que toda la comunicación es insegura y viaja en claro.
Si “servidor” dispone de ssh podemos generar un túnel ssh para proteger la comunicación. Lo que hacemos es “conectar” un puerto de nuestra máquina local, por ejemplo 13306 con el puerto 3306 de “servidor”. Después conectamos nuestro cliente de base de datos al puerto local 13306 y ssh se encargará de comunicar con “servidor” de manera segura.

Para hacer este primer túnel sencillo hacemos:

$ ssh servidor -L 13306:localhost:3306

Esto indica que el puerto 13306 de la máquina local (cliente) se dirige al puerto que servidor conoce como “localhost:3306″; esto es el puerto local 13306 apunta al puerto 3306 de “servidor”.

También podemos complicar un poco el comando ssh para usar ficheros de claves (http://guimi.net/blogs/hiparco/confianza-ssh/) que es lo recomendado, mediante -i; para indicar el usuario de la máquina “servidor” si no coincide con el usuario de la máquina local; para indicar el puerto ssh del servidor (si no utiliza el puerto por omisión: 22).
Esta vez generaremos un túnel para el puerto 5432 (el puerto habitual de PostgreSQL) desde el puerto local 5555:

$ ssh usuario@servidor -p x -i id_dsa_copiada -L 5555:localhost:5432

El puerto 5555 de la máquina local (cliente) se dirige al puerto que servidor conoce como “localhost:5432″; esto es el puerto local 5555 apunta al puerto 5432 de “servidor”.

Túnel a una tercera máquina

Supongamos que “servidor-ssh” y “servidor-svn” son dos máquinas de una red local. Uno tiene ssh y otro svn. Nos interesa desde internet conectar de forma segura al servidor de svn:

$ ssh servidor-ssh -L 3690:servidor-svn:13690

El puerto 3690 de la máquina local (cliente) se dirige al puerto que servidor-ssh conoce como “servidor-svn:5432″; esto es el puerto local 5555 apunta al puerto 5432 de la máquina que servidor-ssh conoce como “servidor-svn”. Es importante remarcar que el nombre “servidor-svn” lo resuelve “servidor-ssh”, no nuestro cliente local, por tanto puede ser la IP de la red local o un nombre que sea capaz de resolver “servidor-ssh”.

Con esto establecemos una conexión segura hasta “servidor-ssh” que a su vez conecta en claro (por la red local) con “servidor-svn”. De esta forma si utilizamos un cliente SVN para conectar con el puerto local 13690, la información estará viajando protegida por el túnel ssh hasta “servidor-ssh” y después en claro hasta “servidor-svn”.
Esto permite que “servidor-svn” no tenga ninguna conexión directa con el exterior y esté más protegido.

Túnel inverso

Aunque menos utilizado puede interesarnos que un puerto del equipo “servidor-ssh” se redirija a un puerto a través de nuestra máquina local:

$ ssh servidor -R 13690:localhost:3690

De esta manera todas las conexiones al puerto 13690 de “servidor” será redirigidas al puerto “localhost:3690″ de la máquina local.
También se puede hacer por tanto:

$ ssh servidor -R 13690:otra-maquina:3690

El puerto 13690 de la máquina “servidor” se dirige al puerto que nuestra máquina local conoce como “otra-maquina:3690″; esto es el puerto servidor:13690 apunta al puerto que nuestra máquina local conoce como “otra-maquina:3690″. Es importante remarcar que el nombre “otra-maquina” lo resuelve nuestra máquina local.

Túnel no interactivo

Podemos usar la opción -N para que no se abra una conexión interactiva (una consola remota) y podemos usar -f para que el cliente ssh pase a en segundo plano. De esta forma si solo queremos hacer el túnel es más cómodo. Por ejemplo para habilitar un túnel a un servidor de OpenERP:

$ ssh servidor -N -f -L 18070:localhost:8070

Túnel de las X (servidor gráfico)

Aquí trataremos algo totalmente diferente a todo lo anterior. En principio, cuando abrimos una terminal remota mediante ssh “solo” podemos utilizar comandos sin GUI y no aplicaciones gráficas. Podemos pedirle a ssh que para la sesión abierta utilice nuestras X locales (si las tenemos, claro) como servidor gráfico. Así podemos lanzar comandos con GUI, es decir aplicaciones gráficas, que se ejecutarán en el servidor pero las veremos en nuestra máquina local.

$ ssh servidor -X

Varios túneles a la vez

Pueden generarse varios túneles a la vez, por ejemplo:

$ ssh servidor -X -L 18070:localhost:8070 -L 5555:localhost:5901

O con ficheros de claves, puerto no estándar y usuario diferente del local:

$ ssh usuario@servidor -p 10022 -i .ssh/id_dsa -X -L 18070:localhost:8070 -L 5555:localhost:5901

Otros artículos relacionados

Configuración de ssh
Confianza ssh
Uso de ssh
Uso de scp
sshfs – Montando recursos mediante SSH y FUSE

ssh, túnel, túneles ssh

Copia de sistemas, clonado de discos

Para copiar sistemas hay muchas herramientas disponibles: g4l, partimage, ntfsclone… y por supuesto el viejo y confiable tar.
Veamos unas chuletas rápidas que pueden ayudarnos. Lógicamente hay que ajustar los nombres de los discos y las particiones.

Copia del MBR y la tabla de particiones
Para copiar el MBR y la tabla de particiones de un disco usamos dd y sfdisk.
MBR:
# dd if=/dev/sda of=sda.mbr count=1 bs=512
Tabla de particiones
# sfdisk -d /dev/sda > sda.sf

Para recuperarlos.
MBR:
# dd if=sda.mbr of=/dev/sda
Tabla de particiones
# sfdisk /dev/sda < sda.sf

Para clonar discos NTFS (Windows), usamos ntfsclone
Esta herramienta (ntfsclone) no permite volcar una imagen de una partición en otra partición más pequeña, aunque los datos quepan. En cambio volcar una partición pequeña en una más grande sí es posible.
Por ello se recomienda que la partición original sea lo más pequeña posible. Lo más cómodo es instalar en una partición grande y después redimensionarla antes de hacer la imagen.
# ntfsclone -s -o – /dev/sda1 | gzip | split -b 1500m – sda1.ntfsclone.gz.

Para recuperar la partición usamos:
# cat sda1.ntfsclone.gz.aa sda1.ntfsclone.gz.ab | gunzip -c | ntfsclone –restore-image –overwrite /dev/sda1 -

Para copiar datos de un sistema GNU/Linux a otro, mediante ssh+tar
Desde el equipo en el que vamos a volcar los datos (usamos p para preservar los permisos):
$ ssh IP_equipo_origen “tar cpf – /path_a_copiar” | tar xpf -

Si la red en que trabajamos es lenta (por ejemplo a través de internet) podemos comprimir los datos antes de enviarlos, podemos cambiar el directorio en que se copian los datos…:
$ ssh IP_equipo_origen “tar czpf – /path_a_copiar” | tar xzpf – -C /nuevo_path_base

También podríamos volcar los datos a un fichero:
$ ssh IP_equipo_origen “tar czpf – /path_a_copiar” | dd of=copia_datos.tar.gz
O en el sentido contrario:
$ tar czpf – /path_a_copiar | ssh IP_equipo_destino “dd of=copia_datos.tar.gz”

Más opciones con
$ man tar
$ man ssh

Trabajar con imágenes de particiones
$ partimage
Sí, ya está, solo eso.
Se pueden ver más opciones para evitar el asistente, como siempre mediante:
$ man partimage

tar, ssh, partimage, ntfsclone, dd, clonado, copia

Configuración de ssh

Configuración del servidor SSH

Una vez instalado con:
aptitude install openssh-server

Para mayor seguridad cambiamos el puerto, reducimos el tiempo de login y no permitimos conexiones de root
# vi /etc/ssh/sshd_config

Port xxxx
LoginGraceTime 45
PermitRootLogin no

Restricción de usuarios

Solo permitimos acceder por ssh a los usuarios indicados en el fichero /etc/loginusers
# vi /etc/pam.d/sshd

#auth       required     pam_env.so # [1]
auth       required     pam_listfile.so sense=allow onerr=fail item=user file=/etc/loginusers

Creamos el fichero /etc/loginusers con los usuarios autorizados:
# vi /etc/loginusers

guimi

Denegación de uso de usuario/password

Es posible conectarse al servidor ssh desde otra maquina utilizando login y contraseña ($ ssh usuario@maquina -p xxxx) o usando ficheros de clave pública/privada ($ ssh usuario@maquina -p xxxx -i id_dsa_copiada).

Para permitir solo el uso de certificados (recomendado) reconfiguramos sshd desautorizando las autentificaciones por contraseña
# vi /etc/ssh/sshd_config

PasswordAuthentication no

Reiniciamos el servicio
# /etc/init.d/ssh restart

Para más información sobre la generación y uso de ficheros de claves ver Confianza ssh.

Una vez configurado el servidor SSH puede hacer Uso de ssh y Uso de scp. También se puede, por supuesto, generar Túneles ssh.

Otros artículos relacionados

Confianza ssh
Túneles SSH
Uso de ssh
Uso de scp
sshfs – Montando recursos mediante SSH y FUSE

SSH, SSL, túnel SSH, openssh-server

Configurar juego de caracteres (charset) en LAMP (Linux, Apache, MySQL, PHP)

Instalamos los paquetes necesarios:
# aptitude install apache2 mysql-server php5

Modificamos la configuración de apache:
# vi /etc/apache2/conf.d/charset

...
AddDefaultCharset       UTF-8
...

Modificamos la configuración de PHP:
# vi /etc/php5/apache2/php.ini

...
default_charset = "utf8"
...

En la cabecera de las páginas indicar:

...
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
...

Y en los scripts PHP de conexión:

...
$sql_script("SET NAMES 'utf8'");
...

Modificamos la configuración de MySQL:
# vi /etc/mysql/my.cnf

...
language    = /usr/share/mysql/spanish
...

Y reiniciamos los servicios:
# /etc/init.d/apache2 restart
# /etc/init.d/mysql restart

En caso de tener una BB.DD. en otra codificación como iso-8859-1, conviene exportarla a un fichero de texto, convertir el fichero con “iconv bbdd.sql -f iso-8859-15 -t utf-8 -o bbdd_utf8.sql” y volver a importarla.

juego de caracteres, charset, Linux, Apache, MySQL, PHP

Red con IP estática

Cada día hay más automatismos… y ya casi se nos olvida como hacer las cosas por nosotros mismos.
Para configurar una IP estática hacemos lo que indica el manual de Debian:
Primero configuramos la interfaz (en el ejemplo eth0 con la IP 192.168.11.100).
# vi /etc/network/interfaces
allow-hotplug eth0
iface eth0 inet static
address 192.168.11.100
netmask 255.255.255.0
broadcast 192.168.11.255
gateway 192.168.11.1
dns-domain lan
dns-nameservers 192.168.11.1

Después los DNSs, si no está instalado resolvconf, basta con:
# vi /etc/resolv.conf
domain localdomain
search localdomain
nameserver 192.168.1.1

Si está instalado resolvconf (y ante la duda no está de más):
# vi /etc/resolvconf/resolv.conf.d/base
nameserver 192.168.1.1

Tumbamos y levantamos la interfaz…
# ifdown eth0
# ifup eth0

¡Y ya está!

static ip, ip estática, red estática