Domingo, 30 de Marzo de 2008 - 19:14

Backup de BD de forma remota

Con esto de que el blog (aspecto gráfico, programación y BD) me lo he hecho yo al 100% pues la cosa es que fastidiaría mucho perderlo por algún problema con el servidor o con la BD.

Hasta ahora hacía las copias de seguridad diarias, pero dentro del mismo servidor, pero la verdad es que no lo veía como algo de seguridad, sino para acallar la conciencia. Fue el otro día cuando a raíz de leer el blog de Alfredo Pérez, me propuse usar ése método pero con algunas variantes.

Las diferencias entre ese método y el que ahora expongo es una mayor seguridad en que alguna modificación de la BD, no nos afectaría a gran escala, quiero decir, hacer copias por horas de la BD, por lo que si por error eliminamos algún dato, en el anterior backup todavía estará intacto. Hay que decir que son copias totales de la BD, ya que es pequeña, lo ideal seria usar este método con backup incrementales. También se han seguido otros pasos para que resultaran en Mandriva.

Creamos el archivo ejecutable por lotes (sh)



Creamos el archivo con el editor de consola nano, aunque se puede hacer con cualquiera.
# nano bajarBDAl abrirse el editor ponemos la siguiente línea (mysqldump –user=USUARIO –password=PASSWORD –host=IP_REMOTA nombre_BD | gzip > /home/_usuario_/_carpetaBackup_/database`date +%d%m%Y%H%M%`.sql.gz):
mysqldump --user=USUARIO --password=PASSWORD --host=IP_REMOTA nombre_BD | gzip > /home/_usuario_/_carpetaBackup_/database`date +%d%m%Y%H%M%`.sql.gz #Estas 3 líneas van todo seguido en una
echo Backup realizado con éxito en:
date +%c
En la sentencia mysqldump ponemos nuestro usuario, contraseña y IP de la máquina remota de la que queremos importar la BD, luego el nombre de la base de datos, hacemos una compresión con gzip al archivo que se ve posteriormente. La sentencia rara que veis como “database`date +%d%m%Y%H%M%`.sql.gz” es porque al nombre del archivo he añadido la fecha de creación, para que no se sobrescriban y tener un registro por horas sin problema. Hay que tener en cuenta que para esto las comillas deben ser las invertidas.

Las dos últimas líneas las he puesto para saber en que fecha se ha realizado el backup con éxito, porque si éste diera algún error, mostraría el error desde ”mysqldump” y lo siguiente nos seguiría dando la fecha, pero de este error.

A continuación copiamos el archivo a /usr/bin y le damos permisos restringidos:
mv bajarBD /usr/bin/bajarBD
chmod 775 /usr/bin/bajarBD
Una vez acabado esto toca editar cron para ñadir la tarea.

Editando cron



Vamos a usar el editor por defecto de cron, que es vi:
crontab -ePara añadir pulsamos ”a” y para guardar y salir: Esc y luego ”ZZ”. Añadimos la siguiente línea que ahora explicaré
SHELL=/bin/bash
00 * * * * /usr/bin/bajarBD >> /home/_usuario_/_carpetaBackup_/registro.log
Con esto lo que hacemos es que nos produzca una copia cada hora a las 00, y nos imprima un registro de la salida de nuestro archivo por lotes, al que le habíamos puesto un par de echo’’s. Una vez salimos y guardamos, nos generará un backup de la base de datos automáticamente cada hora.

Ahora solo queda hacerlo de todo el /home del hosting, pero eso, para otro día.

Categoria: Trucos | 1 Comentario

Sábado, 29 de Marzo de 2008 - 14:08

FreeNX y NXServer

NX es un programa informático que realiza conexiones remotas X11 muy rápidas, lo que permite a los usuarios acceder a escritorios remotos de Linux o Unix incluso bajo conexiones de 56k. Trabaja por el puerto 5000, cosa que no hay que olvidar a la hora de abrirlo en el firewall de Mandriva.

El tráfico del servidor X se comprime y transmite por SSL usando una conexión SSH que puede ser resumida automáticamente en caso de ser interrumpida. Es por esto que es más veloz que VNC.

Realiza una eficiente compresión del tráfico X, lo que permite ejecutar aplicaciones tanto entre redes externas como entre ordenadores en una LAN. También utiliza mecanismos de cache para almacenar y reusar la información transferida entre cliente y servidor. NX utiliza un método de cache innovador que divide el mensaje X en dos partes, uno de identificación y otro de datos.

El tiempo consumido en realizar roundtrips es prácticamente nulo. Además utiliza un algoritmo de codificación perezoso para las actualizaciones de pantalla.

En la red existe una pequeña confusión acerca de FreeNX. Pues esta aplicación es libre (despues de la apertura del código por parte de NoMachine). Esta empresa posee una aplicación servidor propia y es la que suministra el cliente mas utilizado. La diferencia entre el servidor libre y el de NoMachine, radica en que el primero no tiene los asistentes y facilidades del segundo, y no tiene soporte.

Ambos están disponibles para Debian (y familia), Centos, Fedora (y familia Red Hat), Mandriva, Gentoo, FreeBSD, Solaris (SPARC).

La instalación es bastante fácil en los dos. Por ejemplo en el software de NoMachine. La dirección es: http://64.34.161.181/download/3.1.0/Linux/
# wget nxclient-3.1.0-6.i386.rpm
# wget nxnode-3.1.0-6.i386.rpm
# wget nxserver-3.1.0-5.i386.rpm

Instalamos:
# rpm -i nxclient-3.1.0-6.i386.rpm
# rpm -i nxnode-3.1.0-6.i386.rpm
# rpm -i nxserver-3.1.0-5.i386.rpm

Una vez instalado todo a la perfección toca configurar el cliente. Por defecto usa la clave publica/privada de NoMachine. Esto atenta seriamente a la seguridad, lo ideal es importar las claves publicas que genera para los clientes; así sólo tenemos que copiarlas mediante sftp o scp y cargarlas:
Para generar la clave:
# /usr/NX/bin/nxserver --keygen

Importamos la clave de la máquina remota a la nuestra:
# sftp usuario@host
# get /usr/NX/share/keys/default.id_dsa.key /home/usuario/

Una vez hecho esto solo queda configurar el tipo de la sesión, y conectarnos:

FreeNX1

Nombre de sesión y máquina a la que nos conectaremos

FreeNX2

Configuramos la sesión e importamos la clave con: Key -> Import (Buscamos el directorio donde la habíamos copiado mediante SFTP)

FreeNX3

FreeNX conectandose

FreeNX3

Una vez que estamos conectados a un escritorio remoto virtual

Categoria: Acceso remoto | Dejar un comentario

Viernes, 28 de Marzo de 2008 - 11:25

Archivo .basrch

Ayer estaba estudiando en la sala de la UMH, cuando intentando instalar la Wifi con sus permisos y certificados, se me jodió el archivo .bashrc del root. (Imagino que sería por estar ejecutando un script para Debian en Mandriva, y retocándolo en tiempo real…XD).

El caso es que por internet solo encontraba como arreglar el PATH, pero lo que está claro es que la línea con todas las direcciones tiene que estar en algún sitio, y uno de esos sitios es el archivo bashrc. Existen dos sitios dónde está este archivo. El primero es en /etc/bashrc, y como es shell script, se ejecuta siempre que que un usuario entra a bash. El otro archivo es el relativo a cada usuario, sea “mengano”, “francesc” o en el caso que nos ocupa, “root”. Cada archivo de cada usuario se encuentra dentro de /home/_usuario_/.bashrc (para hacerlo invisible). En nuestro caso estaba en /root/.bashrc.

Digo todo esto porque la diferencia de las direcciones del archivo por defecto y el de “root”, estaba en una dirección: /usr/sbin. Me dí cuenta al ir a actualizar paquetería, pues no encontraba urpmi. (error: “bash: urpmi: command not found”) cuando si que lo tengo instalado, así que me puse manos a la obra. La causa era que al borrarse la línea del bashrc del root, cargaba el archivo por defecto, el cual no tiene esta línea en el PATH. El arreglo fue sencillo definiendo un nuevo PATH dentro del archivo, agregando la línea, y exportándolo todo.

# .bashrc

PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin

ENV=$HOME/.bashrc
USERNAME=”root”
export USERNAME ENV PATH

# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi

Categoria: Trucos | Dejar un comentario

Jueves, 27 de Marzo de 2008 - 01:20

VNC

VNC (Virtual Network Computing, realvnc.com) es un software cliente-servidor que permite compartir una sesión gráfica mediante el protocolo RFB (Remote framebuffer). El escritorio compartido puede ser la pantalla actual o un nuevo escritorio:

  • Compartir un nuevo escritorio sirve para que varios usuarios puedan trabajar en el servidor desde sus propias máquinas simultáneamente, en un entorno gráfico.
  • Compartir la pantalla actual es muy útil, por ejemplo, para mostrar a un técnico un problema remotamente o para que un profesor comparta su pantalla con los alumnos.

Trabaja por el puerto 5900, cosa que no hay que olvidar a la hora de abrirlo en el firewall de Mandriva. Por defecto VNC ya viene instalado en el sistema, en caso de que no fuera así simplemente usaríamos el gestor de paquetería que más nos guste ara hacer la instalación:#urpmi vncAntes que nada convendría repasar teóricamente para que sirven algunos archivos que vamos a usar mas tarde:

  • Xvnc: servidor X VNC, es más conveniente que la llamada a este programa se haga a través del script “vncserver”.
  • vncviewer: cliente de VNC con el que se visualizan los escritorios para poder modificarlos.
  • vncpasswd: programa para cambiar la clave de acceso a los escritorios.
  • vncconnect: para conectarnos a un servidor VNC.
  • vncserver: script en Perl que arranca el servidor X VNC. En la primera llamada por usuario y máquina ejecuta “vncpasswd”, para establecer la clave de acceso a dichos escritorios.

Acceder a un escritorio remoto virtual

Antes de acceder tenemos que configurar el archivo xstartup. Por defecto VNC carga solo el entorno X-Window, por lo que si lo que queremos es que nos muestre nuestro ordenador tal como está, con la sesión en el entorno de escritorio que queramos, sea KDE o Gnome, tendremos que descomentar las primeras dos líneas:unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc
La utilización de VNC es bastante sencilla. Para abrir una nueva sesión sólo tenemos que poner:# vncserver :1

VNC 1

Esto nos creará una sesión del escritorio en el display:1, por lo que si queremos acceder a nuestro sistema, lo deberemos hacer hacia aquí. En caso de que quisiéramos modificar los parametros por defecto:# vncserver :1 −name xesco −depth 16 −geometry 640x480Para matar el proceso, y con ello el display:
# vncserver -kill :1Para entrar al escritorio en remoto tenemos que hacerlo desde vncviewer:# vncviewer :1

VNC 2
Acceder a la pantalla en uso

Hasta ahora hemos accedido de forma remota a un display creado por nosotros, pero no es la sesión que está manejando el usuario, la cual se encuentra en display:0. Para conectarnos al dislplay:0, cosa realmente útil si lo que queremos es asistir remotamente, tendríamos que crear la contraseña de la sesión a la que queremos acceder y copiarla en el directorio /home//.vnc/passwd:# vncpasswd ~/.vnc/passwdUna vez hecho esto, sólo queda habilitar el servidor VNC en el display 0. Es necesario mantenerlo en ejecución, de ahí el ”&”.:# x0rfbserver &

VNC 3

Al principio aparecerá una pantalla de configuración. Solo aparecerá una vez, por lo que las demás veces cogerá la configuración que lo hayamos dado.

Ahora por fin podemos conectarnos desde la máquina que queramos a nuestro ordenador remoto, de la misma forma que antes:# vncviewer :0

VNC 4

Esto es lo que pasa cuando ejecutamos VNC sobre el display en uso (:0) siendo el ordenador de acceso el mismo que al que queremos acceder

Conexión inversa con VNC

Puede haber casos en los que el equipo remoto no pueda o no sepa abrir el puerto necesario para la conexión. Existe una forma de hacer una conexión invertida, es decir, que el usuario remoto nos lance su escritorio al nuestro y no que nosotros lo pidamos.

Antes que nada el ordenador con el que queremos acceder, debe estar en modo esucha:# vncviewer -listen &Ahora es cuando vamos a hacer que el ordenador al que queremos acceder, nos mande la petición. Para esto emplearemos un paquete llamado x11vnc (# urpmi x11vnc). La sentencia queda de la siguiente forma:# x11vnc -connect ip:puertoLa IP será la de nuestra máquina (la que controlará a la otra) y el puerto sólo será necesario si la conexión se realiza a través de Internet, de ser así además la IP debe ser la pública. Si es una conexión en una red local, se trata de la IP privada.

Categoria: Acceso remoto | 1 Comentario

Martes, 25 de Marzo de 2008 - 21:47

SSH

Basado en el post hermano de Entre tuxes y pepinos.

Instalación y configuración

SSH son las siglas de Secure SHell. Lo que te ofrece es una consola en un ordenador remoto con los privilegios que tenga la cuenta con la que conectes. Se trata de un protocolo de acceso remoto que permite copiar datos de forma segura, pasar datos de cualquier aplicación mediante tunneling con SSH. Y todo esto con encriptación de datos. Trabaja por el puerto 22, cosa que no hay que olvidar a la hora de abrirlo en el firewall de Mandriva.

Los archivos de configuración que se ocupan de SHH, son:
- sshd_config (Para los servidores)
- ssh_config (Para los clientes)

Nosotros sólo necesitamos retocar el primero.

Puede ser que venga ya instalado y solo tengáis que ir al Centro de Control de Mandriva para abrir los puertos, pero por si no lo estuviera, como root ejecutamos:
# urpmi opensshEsto automáticamente nos instalará las dependencias openssh-clients y openssh-server. Una vez instalado pasamos a la configuración del sistema. En el archivo sshd_config, que se encuentra en /etc/ssh/, encontraremos un apartado con lineas comentadas y otras descomentadas tal que así:

Archivo de configuración de SSH

La parte descomentada es la que se ejecutará de forma predeterminada. Ahora nosotros vamos a configurar el archivo para tener unas mínimas condiciones de seguridad en cuanto a proteger el acceso por usuario. El acceso por clave pública/privada lo veremos más adelante.

Cambiaremos el puerto para evitar los robots que atacan directamente al de SSH. Esto no quita que el caco pueda intentar averiguar “el portal” si sabe cómo hacerlo, pero al menos, le ponemos impedimentos. También hay scripts que atacan directamente el puerto 22, por lo que el cambio de puerto es algo obligatorio. Para esto pondremos la variables siguientes en el archivo anterior:
#Cambiamos el puerto
Port 9918

#Especificamos que use el protocolo versión 2
Protocol 2
Respecto a las opciones de autentificación, encontramos dos. La primera es el número de segundos que tendrá el usuario remoto para hacer login en tu máquina. Como no deberíamos tardar mucho en hacer login si sabemos la cuenta y la password, vale la pena poner un valor pequeño. De esta forma evitamos ciertos scripts que se aprovechan de ese tiempo.
LoginGraceTime 15Otra opción fundamental que tenemos que desactivar es permitir el acceso en modo “root”. Si queremos usar comandos de administrador, o instalar algun paquete o cualquier cosa para la que necesitemos ese tipo de permisos, lo podemos hacer mas tarde estando ya dentro del sistema remoto, con el comando “su”.
PermitRootLogin noTambién podéis señalar con el dedo las cuentas que tienen permitido el uso SSH (AllowUsers). Esto es muy útil para restringir el uso de SSH en el acceso a nuestra cuanta a quien nosotros queramos. Además de restringir el acceso de esta forma, también se puede hacer mediante la IP desde donde nos vamos a conectar.
AllowUsers mandriva amigo
AllowUsers nuestra_cuenta cuenta_amigo@IP_amigo
Quien intente conectar debe acordarse de su login y password, por lo que es tontería darle un número grande de intentos. En principio con dos son más que suficientes. Si al segundo intento no lo ha conseguido se cortará la conexión SSH. Siempre se puede volver a conectar y reintentarlo, pero así nos quitamos de encima ciertos scripts que intentan encontrar el login por fuerza bruta a base de ensayo y error.
MaxAuthTries 2Otra opción interesante es marcar un máximo de conexiones simultáneas. En nustro caso al ser 5 personas en el grupo de SO, vamos a configurarlo para poder entrar todos al mismo tiempo.
MaxStartups 5Ahora solo queda reiniciar el servicio ssh para que los cambio se apliquen:
# service sshd restartSSH tiene infinitas opciones de configuración y de ejecución, si queréis ampliar más es conveniente mirar el manual (# man ssh).

Acceso por clave pública/privada

La generación de una pareja de claves pública-privada se realiza ejecutando en el cliente ssh-keygen. Nos dará la opcion de crear una palabra de paso aunque en caso de pulsar intro nos creará una en blanco, la cual no nos será requerida cuando accedamos.
# ssh-keygen -t rsa

Generación de claves RSA

Las claves se almacenan por defecto en ~/.ssh/, quedando el directorio así:

Generación de claves RSA - Caputra 2

Los ficheros id_rsa e id_rsa.pub contienen respectivamente las claves privada y pública. El fichero known_hosts contiene la lista de las claves públicas de las máquinas reconocidas.

Ahora se debe copiar la clave pública al fichero ~/.ssh/authorized_keys de cada usuario que vamos a usar, dentro del servidor al que queremos acceder. Para ello se utiliza el comando ssh-copy-id:
# ssh-copy-id -i ~/.ssh/id_rsa.pub user@machine1
# ssh-copy-id -i ~/.ssh/id_rsa.pub user@machine2
ssh-copy-id es un script que se conecta a la máquina y copia el archivo (indicado por la opción -i) en ~/.ssh/authorized_keys, y ajusta los permisos a los valores adecuados.

Ahora la conexión debería funcionar sin necesidad de introducir la clave. Si no es así es posible que sea un problema de permisos en los ficheros. Los permisos correctos deben ser similares a estos:
# chmod go-w $HOME $HOME/.ssh
# chmod 600 $HOME/.ssh/authorized_keys
Para poder acceder al servidor desde cualquier cliente, debemos copiar los ficheros id_rsa e id_rsa.pub dentro de ~/.ssh/ de la cuenta de usuario de cada cliente desde el que queramos realizar la conexión hacia el servidor. Además de esto, en el archivo sshd_config debemos habilitar las opciones de acceso mediante clave publica/privada:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

SCP

CP viene junto a SSH, y se trata de una herramienta para transmitir archivos y directorios entre ordenadores de forma remota. La sintaxis es muy simple teniendo las mismas opciones que SSH, las cuales hereda.

El modo de empleo sería el siguiente en caso de que queramos copiar archivos de nuestro ordenador al remoto:
# scp archivo usuario@servidor.com:rutaY para copiar a la inversa, desde el computador remoto al tuyo, simplemente tienes que invertir el orden de los elementos:
# scp usuario@servidor.com:ruta/archivo ruta_localPara mandar carpetas completas se puede emplear el siguiente comando
# scp -r carpetaSO/ usuario@host:/carpeta_padreLa forma inversa sería exactamente igual a la de los archivos, solo que cambiaríamos el susodicho por una carpeta:
# scp -r usuario@host:/carpeta_padre/carpetaSOSi queremos copiar el contenido de la carpeta pero no la misma, la sintaxis es:
# scp carpetaSO/* usuario@host:/carpeta_padre/carpetaSOHay que decir que por defecto la ruta a la que copia es en /home/usuario, así que en caso de querer copiar archivos allí podemos omitir la ruta, pero no los dos puntos:
# scp fichero.txt usuario@host:

SFTP

El protocolo de transferencia de archivos SFTP es un protocolo de red que proporciona la transferencia de archivos y la funcionalidad de manipulación de datos fiables sobre cualquier secuencia ya que los datos circulan cifrados por la red. Se utiliza normalmente con SSH a fin de asegurar la transferencia de archivos.
# sftp usuario@hostImplementa muchas de las opciones que tenemos por defecto en consola. Para copiar datos tenemos el método put, y para importar tenemos get:
# get [-P] /ruta/remota/del/archivo /ruta/local/del/archivo# put [-P] /ruta/local/del/archivo /ruta/remota/del/archivo-P Cuando esta opción está presente, copiará todos los permisos y accesos del archivo.

Categoria: Acceso remoto | Dejar un comentario

keep looking »