viernes, 27 de septiembre de 2013

Jobscheduler: Z-JAVA-101 Java Virtual Machine is not started


Montando un Jobscheduler en un servidor Red Hat tuve el problema de que al arrancarlo y tras lanzar el script jobscheduler_environment_variables.sh donde hace los export de las variables de sistema que necesita, me daba el famoso error Z-JAVA-101 Java Virtual Machine is not started. Revisando el propio log del Jobscheduler vi que me indicaba que no tenia permisos para ejecutar libjvm.so. Rascando un poco averigüé que esto se produce por las políticas de seguridad en linux y más concretamente las de Red Hat (Security-Enhanced Linux) que impedían que se cargara esa librería en el contexto donde debería cargarse. El error que aparece en el log es algo similar a este con las rutas que tengáis:

[ERROR Z-JAVA-100  Java Virtual Machine cannot be loaded [xxx/lib/i386/client/libjvm.so: cannot restore segment prot after reloc: Permission denied] [libjvm.so]]

Para cambiar el contexto de seguridad de la librería libjvm.so a textrel_shlib_t lanzaremos lo siguiente:

[pp@core bin]$ chcon -t textrel_shlib_t /home/xx/jdk/jdk1.6.0_27_i586/jre/lib/i386/client/libjvm.so

Otra manera sería desactivar el Security-Enhanced Linux, para esto podéis consultar este artículo.


Activar o Desactivar SELinux

Para desactivar la Security-Enhanced Linux en Red Hat tenemos que realizar los pasos que detallo a continuación.

El archivo de configuración del SELINUX se puede consultar con un vi /etc/sysconfig/selinux pero este realmente no es el archivo en cuestión si no un enlace simbólico al mismo. Lo podemos comprobar lanzando lo siguiente:

[root@core ~]$ ls -ltr /etc/sysconfig/selinux
lrwxrwxrwx 1 root root 17 ene 25  2012 /etc/sysconfig/selinux -> ../selinux/config

El archivo final es /etc/selinux/config y es el que tenemos que modificar. Para esto y accediendo como root lanzamos el comando vi  /etc/selinux/config. Deberemos modificar la linea SELINUX=enforcing y cambiar el enforcing por disabled. Adicionalmente yo suelo comentar SETLOCALDEFS para que no lo evalúe quedando el siguiente archivo de configuración:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - SELinux is fully disabled.
SELINUX=disabled
# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=targeted

# SETLOCALDEFS= Check local definition changes
#SETLOCALDEFS=0

viernes, 20 de septiembre de 2013

Error en prestashop: order_state (Unknown column 'deleted' in 'field list')

Este error es un error que sucede en la versión 1.4.8-2 de prestashop. Cuando intentábamos cambiar de estado un pedido nos lanzaba ese error y el motivo es porque en la tabla PREFIX_order_state no estaba el campo deleted. Para solucionarlo lo único que tenemos que hacer es añadir el campo deleted, sustituyendo PREFIX por el prefijo de nuestra tabla en prestashop, lanzando lo siguiente:

ALTER TABLE `PREFIX_order_state` ADD `deleted` tinyint(1) unsigned NOT NULL DEFAULT '0'

Configurar dns en Linux

Para configurar el dns en linux tenemos que modificar el fichero /etc/resolv.conf y /etc/network/interfaces.
Para añadirlo en el fichero /etc/resolv.conf basta con añadir la linea nameserver IP_SERVIDOR_DNS, quedando el fichero de una manera similar a esta:


root@pre:~# more /etc/resolv.conf
nameserver 10.0.10.25

Por otro lado tendremos que modificar el fichero /etc/network/interfaces y añadirle la propiedad dns-nameservers IP_SERVIDOR_DNS, quedando de una manera similar a esta:

root@pre:~# vi /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
        address 10.0.10.66
        netmask 255.255.255.128
        network 10.0.10.0
        broadcast 10.0.10.255
        gateway 10.0.10.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 10.0.10.25

Redimensionar Volúmenes en Linux


La mayor parte de los servidores que se contratan a empresas como 1and1 o Arsys vienen con un volumen creado y con tamaños predefinidos de 4GB para los puntos de montaje /var/, /home/ y /usr/. Por esto tendremos que redimensionar el tamaño de los volúmenes para darles más espacio. Lo primero, miraremos el fichero /etc/fstab para comprobar la tabla de particiones y puntos de montaje del servidor. En mi caso compruebo que tengo montado el /var, /home y /usr cada uno en un volumen (el nombre del volumen puede cambiar, por defecto sería vg00 pero en mi caso es volu00)

/dev/md1        /               ext3    defaults        1 1
/dev/sda2       none            swap    sw
/dev/sdb2       none            swap    sw
/dev/volu00/usr   /usr            ext4    defaults        0 2
/dev/volu00/var   /var            ext4    defaults,usrquota       0 2
/dev/volu00/home  /home           ext4    defaults,usrquota       0 2
devpts          /dev/pts        devpts  gid=5,mode=620  0 0
none            /proc           proc    defaults        0 0
none            /tmp    tmpfs   defaults        0 0

Realizando un df -h compruebo además que las tengo montadas y funcionando.

[aa@flopa ~]# df -h
Filesystem                             Size  Used Avail Use% Mounted on
/dev/md1                                 4.0G  543M  3.5G  14% /
/dev/mapper/volu00-usr         4G  1.5G  2,5G   69% /usr
/dev/mapper/volu00-var         4G  2.2G  1,8G   57% /var
/dev/mapper/volu00-home     4G   1G     3G     25% /home
none                                        3.9G  4.0K  3.9G   1% /tmp

Con el comando vgdisplay comprobamos el espacio que tenemos libre para para poder ampliar.

[aa@flopa ~]# vgdisplay
  --- Volume group ---
  VG Name               volu00
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  5
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               3
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               925.51 GiB
  PE Size               4.00 MiB
  Total PE              236931
  Alloc PE / Size       105472 / 412.00 GiB
  Free  PE / Size       131459 / 513.51 GiB
  VG UUID              ******************


Por último solo quedaría indicarle el espacio que queremos ampliar y el volumen donde realizarlo. Para esto utilizaremos el comando lvextend


[aa@flopa ~]# lvextend -L +87Gb /dev/mapper/volu00-var

Con esto queda apuntada la redimensión y para hacerla persistente tendremos que utilizar el comando resize2fs si trabajamos con ext4 o xfs_growfs si trabajamos con ext3 quedando de la siguiente manera.

Para ext4:
[aa@flopa ~]# resize2fs /dev/mapper/volu00-var

Para ext3:
[aa@flopa ~]# xfs_growfs /var 

miércoles, 4 de septiembre de 2013

Backup de una tabla en Postgres

Para hacer el backup de una tabla en Postgres basta con irnos al directorio que contiene el archivo pg_dump, normalmente está en /usr/local/pgsql/bin/, y lanzar lo siguiente:

root@db:~# pg_dump -i -h localhost -p 5432 -U usuario -t tabla -F p -b -v -f "/root/llamadas.sql" BaseDeDatos

Esto nos generará un archivo llamadas.sql en el directorio /root/ que contendrá todo el contenido para regenerar esa tabla (create table, add constraint,...etc ).
Para recargarlo solo tenemos que lanzar el siguiente comando:

root@db:~# ./psql -U usuario -d BaseDeDatos -f /root/llamadas.sql

Como nota adicional decir que hay que tener en cuenta que a la hora de recuperar exclusivamente los datos tendremos que editar el fichero y borrar todo lo que no sea el COPY con nuestros datos además de tener en cuenta que si lo que estamos recuperando en una tabla que tiene FOREIGN KEY el tiempo se puede disparar. Por esto siempre es mejor crearnos una tabla secundaria sin FOREIGN KEY para recuperar en ella los datos y posteriormente mediante un insert select volcarlos a la tabla original. Este tipo de sentencias que pueden tardar un tiempo es recomendable lanzarlas en la propia base de datos sin que intervenga la conexión de red a la misma. Para ello nos logamos con el usuario postgres entramos en la base de datos y lanzamos nuestra sentencia:

[root@db log]# su  postgres
[postgres@db01 log]$ psql baseDeDatos

BaseDeDatos=# select................