lunes, 14 de octubre de 2013

Linux - Conexion Remota en MySQL

En este manual les voy a explicar como habilitar la conexión remota para nuestro usuario root en MySQL.
Esto es aplicable para nuestros servidores locales o servidores dedicados. Normalmente los servicios de Hosting lo tienen deshabilitado y no se puede utilizar. Tan solo nos permiten gestionar mediante PhpmyAdmin.

Linux - Conexion Remota en MySQL

En mi caso tengo un servidor montado con Debian y necesito gestionar la base de datos remotamente mediante SQLyog, MySQL Browser Query y otros.

Lo primero que debemos hacer es editar el archivo: /etc/mysql/my.cnf. Debemos hacerlo desde la consola y como root, ya que es un archivo protegido. Abrimos el terminal y logueamos como root.
Ahora escribimos:
nano /etc/mysql/my.cnf
Con esto abrimos ese archivo con el editor. Buscamos la línea: 
bind-address = 127.0.0.1

Y la cambiamos por:
bind-address = 0.0.0.0
Y reiniciamos el servicio MySQL:
/etc/init.d/mysql restart

Con este paso ya hemos habilitado el acceso remoto al servidor. Ahora debemos dar permiso a el usuario para que pueda acceder.

Iniciamos la utilidad mysql en un Terminal del servidor donde esta instalado MySQL Server con el siguiente comando: 
mysql -u root -p

Escribimos la contraseña que nos pide del MySQL y procedemos a configurar a los usuarios para acceso remoto:
GRANT ALL PRIVILEGES ON *.* TO root@'%'; FLUSH PRIVILEGES; 

Ya tenemos el acceso y podemos conectarnos sin problemas. 


A partir de aquí explico como como conseguir una conexión más segura y describo con detalle el comando anterior.

Cabe puntualizar que no es la forma más segura de conceder el acceso. Supongamos que estamos trabajando desde una LAN y tenemos la IP 192.168.1.50 pues vamos a dar acceso solamente a esta IP con el siguiente comando:
GRANT ALL PRIVILEGES ON *.* TO root@192.168.1.50 FLUSH PRIVILEGES;
Listo, ahora solo se puede acceder desde la IP mencionada (y del mismo servidor, claro).

Vamos a rizar un poco más el rizo. Supongamos que el usuario root desde la IP 192.168.1.50 solo necesita conectarse a la base de datos llamada "clientes", pues bien, la línea es la siguiente:
GRANT ALL PRIVILEGES ON clientes.* TO root@192.168.1.50 FLUSH PRIVILEGES;

Ya lo tenemos listo. Un apunte más. La opción FLUSH PRIVILEGES, es para aplicar los cambios realizados al instante sin tener que reiniciar el servicio ni el servidor.

miércoles, 25 de septiembre de 2013

Inicio automatico xen server 6

Yesterday I finally had some hours left to spare at home to attend to my Homelab. as I’m prepping the environment for my next exam (A19 Citrix XenDesktop 5 Administration) I did wanted to upgrade the XenServers to the latest version. So I spent yesterday evening cleaning up the servers with the old VMs from previous studies and left the two XenApp 6.5 servers and my domain server in place.

Upgrading the XenServer Homelab
The upgrade itself was done easily with the single disk image. This time I was smart enough to learn from my previous mistake, so I brought down any running VMs (even disabled the auto start options to be sure) and started with my Pool Master upgrade,without triggering any Maintenance Mode. The upgrade went smoothly for both servers, so I was quickly up and running again and checking all VM settings.

VM auto start feature
I was a little puzzled on how I could set up my License Server VPX appliance to auto start on booting my XenServer, but I figured it was now set with the vApp features and settings. However the GUI did not offer a select box to enable the auto start feature at the Start Options in the General Properties of the VM. I did not configure HA as it is not necessary right now for my Homelab environment. I just made the assumption that creating and configuring the vApp would enable the auto start feature all the same. And turned off the Homelab servers to test it when I would boot my servers the next day.
Unfortunately for me, it wasn’t that easy this time. As Bill Carovano explains in this post on the Citrix Forums, so design decisions changed the auto start feature availability. As it interfered with the HA, DR and Pool upgrade functionality it was opted out for the XenServer 6 release.

Alternative configuration
For me it still is a very useful feature to ensure my Citrix License Server is automatically started when my XenServer is booted, so luckily for me Bill also gave the right commands to enable the feature with the CLI and have the perfect setup back for my Homelab
You first have to enable the auto power on feature at pool level, before being able to configure it for each VM individually.
* Find the uuid of the Pool:
[root@ ~]# xe pool-list
uuid ( RO) : [uuid-pool]
name-label ( RW): [pool-name]
name-description ( RW): [pool-desc]
master ( RO): [uuid-xs]
default-SR ( RW): [uuid-sr]
 
Which returns the following values:
  • uuid-pool: A unique identifier for the Pool.
  • pool-name: The name given to the Pool.
  • pool-desc: The description set for the Pool.
  • uuid-xs: The unique identifier of the XenServer that currently is the Pool Master.
  • uuid-sr: The unique identifier for the default Storage Repository configured for the Pool.

* Enable the auto power on feature at pool level:
[root@ ~]# xe pool-param-set uuid=[uuid-pool] other-config:auto_poweron=true
 
Which uses the following additional syntax:
  • uuid-pool: A unique identifier for the Pool.

* Find the uuid of the VM:
The quicky way to find the uuid of your VM is to run the vm-list command. This does however give you an overview of all VMs, so if you have alot of VMs defined, try to narrow it done with the name-label parameter (which is case sensitive). With the uuid known for the VM, you can easily enable the auto start feature.
[root@ ~]# xe vm-list
uuid ( RO) : [uuid-vm]
name-label ( RW): [vm-name]
power-state ( RO): [vm-power]
 
Which returns the following values:
  • uuid-vm: A unique identifier for the Virtual Machine.
  • vm-name: The name given to the Virtual Machine.
  • vm-power: Shows the power state the VM is currently in (running, halted).

* Enable the auto power on feature for the specified VM:
[root@ ~]# xe vm-param-set uuid=[uuid-vm] other-config:auto_poweron=true
 
Which uses the following additional syntax:
  • uuid-vm: A unique identifier for the Virtual Machine.
Fuente:

Almacenamiento en Citrix XenServer: cómo funciona y qué puede fallar

El almacenamiento es un aspecto clave en un entorno Citrix Systems Inc. XenServer. Los archivos de imagen de disco de la máquina virtual (VMDK) residen ahí, y si algo falla entonces no es posible arrancar las máquinas virtuales. Por lo tanto, si su centro de datos está ejecutando XenServer y tiene algún poder sobre la administración, debe entender cómo se organiza el almacenamiento.
En un entorno XenServer, los dispositivos de almacenamiento físico están disponibles en un repositorio sobre el que se crea una base de datos que permite a los hosts de XenServer poder conectar con el almacenamiento. Si hay problemas a la hora de reconocer ese almacenamiento, suele deberse a errores de identificación del almacenamiento físico con la identificación de la base de datos de XenServer. Pero antes de explicar cómo poder resolver este problema, hablemos de la relación entre XenServer y el almacenamiento.
En XenServer el almacenamiento se organiza a través de repositorios de almacenamiento, que contienen imágenes de disco virtual, dispositivos de bloque físico y dispositivos de bloque virtual. Y la máquina virtual puede usar el almacenamiento de distintas maneras: como un archivo de disco virtual (creado en el formato de disco duro virtual, o VHD), un gestor de volúmenes lógicos (LVM) o una conexión directa a la SAN a través de Citrix StorageLink.
Si profundizamos en el almacenamiento de XenServer, un repositorio de almacenamiento es una abstracción del dispositivo de disco físico, que pueden ser un dispositivo local o un dispositivo en SAN. En el repositorio de almacenamiento de XenServer, las imágenes de disco virtual se crean como una abstracción del almacenamiento de objetos que pueden ser presentados a una máquina virtual. Para hacerlo, el repositorio de almacenamiento conecta los dispositivos basados en bloques que están ubicados en una máquina local, en SAN o donde sea, usando el objeto de conector de dispositivos de bloque físico de XenServer. Conforme a la imagen de disco virtual, el almacenamiento puede presentarse a la VM. Este almacenamiento se ofrece como objeto de conector de dispositivo de bloque virtual, que la VM ve como su disco virtual.
Como ya hemos indicado antes, hay tres formas para que una VM acceda al almacenamiento. El sistema clásico es mediante archivos VHD. Estos son archivos almacenados en el repositorio de almacenamiento siguiendo el formato estándar definido por Microsoft en 2005. Desde el lanzamiento de XenServer 5.5 en 2009, Citrix también ofrece acceso a través de LVHD o discos duros virtuales basados en LVM. El beneficio de este enfoque es que la capa subyacente de LVM permite aplicar algunas soluciones avanzadas de gestión de almacenamiento como el clonado rápido o las instantáneas. Una tercera opción sería asignar una VM directamente a una LUN en el sistema de almacenamiento. Este sistema solo funciona si su sistema de almacenamiento tiene un complemento que lo soporte.
Un problema frecuente que puede ocurrir en el almacenamiento son los errores en la identificación del almacenamiento. Si esto ocurre se pierde el acceso a todo el almacenamiento. En la plataforma XenServer los dispositivos de disco pueden ser dirigidos de distintas formas por diferentes componentes del sistema. En XenCenter, se refiere al almacenamiento con un identificador de SCSI que corresponde con el UUID que usted puede ver en la consola de XenServer. Si su almacenamiento no es accesible desde XenCenter, compruebe que los UUID usados en XenCenter coinciden con los UUID visibles en la consola XenServer en el directorio /dev/disk/by-uuid.
Si el almacenamiento está basado en LVM, puede encontrar el identificador del almacenamiento del dispositivo de disco a través del comando pvs de la consola de XenServer. Las VM individuales están conectadas a volúmenes lógicos individuales. Para tener una visión general de estos, puede usarse el comando lvs, que muestra de nuevo un identificador que corresponde con el identificador usado en XenCenter.
Si hay un error de configuración en la forma en que se maneja el almacenamiento, entonces usar el comando xe en el host puede ser útil. Este comando le permite ejecutar una consulta directa al host y ver qué dispositivos de almacenamiento «puede ver». El comando necesario es xe sr-list. Este comando muestra los UUID actualmente en uso junto a los demás parámetros que nos permiten identificar el tipo de almacenamiento.
Si usamos xe sr-list, podemos consultar el repositorio de almacenamiento para obtener más información, usando parámetros adicionales. Por ejemplo podemos usar xe sr-list params=name-label,uuid,VDIs,PBDs para ver los diferentes UUID asignados al dispositivo de almacenamiento. El objetivo es encontrar los UUID de los dispositivos reales tal y como se ven en el repositorio de almacenamiento y compararlos con los UUID tal y como se ven en XenCenter. Si hay un error, debe volver a importar los dispositivos de almacenamiento al entorno de administración de XenCenter para reconstruir la base de datos.
Veamos un ejemplo real sobre cómo puede ocurrir esta identificación errónea: una organización de TI con la que trabajo perdió la conexión de todos sus dispositivos de almacenamiento después de migrar sus hosts de XenServer a un nuevo centro de datos. Tras analizar la configuración, resultó que los problemas fueron provocado por un error de los identificadores reales en el almacenamiento y los identificadores tal y como se conocían en la base de datos utilizada por XenServer. Después de encontrar los problemas, la solución fue sencilla: usar el comando xe sr-rescan para escanear de nuevo los identificadores de los dispositivos físicos y volver a construir la base de datos.
Sander van Vugt es formador independiente y consultor residente en Holanda.

Fuente: