Son numerosas las aplicaciones webs que podemos encontrar en la red que utilizan Java: aplicaciones bancarias, chats, web conferencing,… Para poder ejecutarlas, nuestro navegador,firefox en este caso, debe tener habilitado el soporte para Java.

En sistemas Windows, el soporte del navegador, suele instalarse y configurarse junto con el paquete de Java, pero en sistemas Linux (CentOS, Fedora, Debian, Ubuntu…) el proceso no es automático.

Esta guía describe cómo habilitar el soporte de Java para Firefox en Fedora, pero es aplicable a cualquier otra distro Linux como Centos, Debian, Ubuntu, …

Para poder habilitar Java en Firefox, debemos tener previamente instalado Java en nuestro sistema. Si no lo tienes instalado, puedes utilizar nuestra guía de instalación de Java 7 en Centos y Fedora.

En nuestro caso, disponemos de la última versión de Java JDK 7 instalada en nuestro sistema.

[root@ardn-ix etc]# java -versionjava version "1.7.0_02"
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
Java HotSpot(TM) Server VM (build 22.0-b10, mixed mode)

Para habilitar el soporte en firefox, solo necesitamos crear un enlace simbólico desde la librería de Java correspondiente, hasta el directorio de plugins de firefox.

Podría efectuarse directamente con el comando ln pero es preferible utilizar alternatives para gestionar los enlaces simbólicos, de esta forma, podríamos utilizar versiones diferentes del plugin de Java y cargar una u otra según necesidades (por ejemplo una estable, y otra de testeo).

Ejecutamos el siguiente comando para habilitar el soporte de Java para firefox en Fedora:

alternatives --install /usr/lib/mozilla/plugins/libjavaplugin.so libjavaplugin.so /opt/jdk1.7.0_02/jre/lib/i386/libnpjp2.so  1

Activamos ahora el plugin con el comando alternatives –config libjavaplugin.so

alternatives --config libjavaplugin.so 
There is 1 program that provides 'libjavaplugin.so'.
 
  Selection    Command
-----------------------------------------------
*+ 1           /opt/jdk1.7.0_02/jre/lib/i386/libnpjp2.so
 
Enter to keep the current selection[+], or type selection number:  1

Introducimos 1, y pulsamos enter.

Con esto ya tendríamos activado el plugin Oracle Java 7 para firefox en Fedora o Centos.

Otros artículos relacionados que pueden interesarte:

1. HOWTO: Instalación de Java 7 en Centos y Fedora

AraDaen, sysadmin notes

Cuando se ejecuta desde una shell un comando o un script, se crea un subproceso (proceso hijo) de la shell que ejecuta el comando o el script (proceso padre).
Si el script que ejecuta el proceso hijo crea o modifica alguna variable de entorno, esos cambios o variables desaparecen cuando finaliza el comando o script.

Si deseamos que dichos cambios permanezcan, podemos utilizar el comando de Bash source. Este comando hace que el proceso o comando se ejecute sin crear ningún proceso hijo, de forma que los cambios efectuados en las variables de entorno y demás, se mantengan al finalizar el archivo.

Veamos el uso del comando source de Bash con un ejemplo.
Tenemos creado el script ejemplo_source.sh, que contiene el siguiente código

1
2
3
4
5

#!/bin/bash
 
VAR_EJEMPLO_SOURCE='www.aradaen.com';
 
echo '$VAR_EJEMPLO_SOURCE='$VAR_EJEMPLO_SOURCE;

Este script asigna a la variable VAR_EJEMPLO_SOURCE el valor ‘www.aradaen.com’ y muestra su valor en pantalla.
En este ejemplo vamos a mostrar el valor de la variable VAR_EJEMPLO_SOURCE antes y después de la ejecución del script de forma estándar:

1
2
3
4
5
6
7

[usr@srv]: echo $VAR_EJEMPLO_SOURCE
 
[usr@srv]: ejemplo_source.sh
$VAR_EJEMPLO_SOURCE=www.aradaen.com
[usr@srv]: echo $VAR_EJEMPLO_SOURCE
 
[usr@srv]:

Como vemos en el ejemplo anterior, la variable VAR_EJEMPLO_SOURCE, no existe previamente de forma que no tiene ningún valor asignado.

1
2
3

[usr@srv]: echo $VAR_EJEMPLO_SOURCE
 
...

Al ejecutar de forma estándar el script ejemplo_source.sh, se le asigna el valor a la variable, y muestra su valor.

2
3
4
5

...
[usr@srv]: ejemplo_source.sh
$VAR_EJEMPLO_SOURCE=www.aradaen.com
...

Pero al finalizar el programa, los cambios que realiza desaparecen con el: VAR_EJEMPLO_SOURCE al finalizar la ejecución del script, sigue sin tener valor asignado

3
4
5
6

...
[usr@srv]: echo $VAR_EJEMPLO_SOURCE
 
[usr@srv]:

Vamos a efectuar ahora el mismo proceso, pero utilizando el comando source para ejecutar el script ejemplo_source.sh:

1
2
3
4
5
6
7

[usr@srv]: echo $VAR_EJEMPLO_SOURCE
 
[usr@srv]: source ejemplo_source.sh$VAR_EJEMPLO_SOURCE=www.aradaen.com
[usr@srv]: echo $VAR_EJEMPLO_SOURCE
www.aradaen.com
[usr@srv]:

Inicialmente la variable $VAR_EJEMPLO_SOURCE no tiene valor.

1
2
3

[usr@srv]: echo $VAR_EJEMPLO_SOURCE
 
...

Al ejecutar el script utilizando el comando source, se asigna el valor a la variable y se muestra en pantalla

2
3
4
5

...
[usr@srv]: source ejemplo_source.sh$VAR_EJEMPLO_SOURCE=www.aradaen.com
...

Pero a diferencia del ejemplo anterior, ahora, al finalizar la ejecución del script, la variable mantiene $VAR_EJEMPLO_SOURCE mantiene el valor asignado en el script:

4
5
6
7

...
[usr@srv]: echo $VAR_EJEMPLO_SOURCE
www.aradaen.com
[usr@srv]:

Como vemos, al ejecutar el script utilizando el comando source es ejecutado directamente por el mismo proceso y no con un subproceso, por lo que los cambios en variables se mantienen.

No hay artículos relacionados en este momento

AraDaen, sysadmin notes

La instalación por defecto de Fedora y CentOS trae la versión libre de Java, openJDK. OpenJDK resulta suficiente normalmente, pero en algunas ocasiones da problemas con algunos applets y aplicaciones, y si deseas desarrollar aplicaciones Java, es preferible utilizar Java de Oracle (antiguamente de Sun).

Oracle Java se presenta, básicamente en dos paquetes, JRE y JDK: el primero está orientado a la ejecución de aplicaciones Java; el segundo, además incluye compiladores y librerías necesarias para desarrollar aplicaciones Java.

Para comenzar la instalación de Java en CentOS o Fedora, accedemos a la plataforma web de Oracle Java y descargamos la versión deseada, en nuestro caso Java JDK 7.

Podemos descargar la versión elegida de Java en formato rpm o comprimida en tar.gz.
Descargamos la versión comprimida de Java que ofrece mayor control sobre la instalación, además el proceso de instalación es, de esta forma, prácticamente igual para cualquier sistema operativo Linux.

Una vez descargada, con privilegios administrativos, descomprimimos y movemos su contenido a /opt/:

cd /tmp
wget http://download.oracle.com/otn-pub/java/jdk/7u2-b13/jdk-7u2-linux-i586.tar.gz
tar xvzf jdk-7u2-linux-i586.tar.gz
mv jdk1.7.0_02/ /opt/

Creamos el archivo ahora que contendrá las variables de entorno (/etc/profile.d/java.sh) con nuestro editor de textos favorito:

vim /etc/profile.d/java.sh

Y agregamos las siguientes líneas:

export JAVA_HOME=/opt/jdk1.7.0_02
export PATH=$JAVA_HOME/bin:$PATH

Guardamos los cambios, y cargamos las variables en el entorno actual:

source /etc/profile.d/java.sh

Como indicábamos al principio, las instalaciones por defecto de Centos y Fedora, suelen traer OpenJDK. Tenemos dos opciones, o eliminar la instalación existente de OpenJDK, o mantenerla e instalar Java de Oracle utilizando alternatives para configurar la nueva instalación de Java como predeterminada. Esto es lo que vamos a hacer nosotros.

Comprobamos si hay instalada alguna versión de Java o OpenJDK anterior:

alternatives --config javaThere is 1 program that provides 'java'.
 
  Selection    Command
-----------------------------------------------
*+ 1           /usr/lib/jvm/jre-1.6.0-openjdk/bin/java
 
Enter to keep the current selection[+], or type selection number:

En este caso está instalado openJDK como indicábamos.
Instalamos y configuramos con alternatives la nueva instalación de Oracle Java 7:

Si tuvieramos más de una instalación previa de openJDK u Oracle Java (por ejemplo la versión 6), debemos sustituir el 2 por el número de instalaciónes previas más uno.

alternatives --install /usr/bin/java java /opt/jdk1.7.0_02/bin/java 2

Ahora configuramos Oracle Java JDK como predeterminada con el comando:

alternatives --config java

Que ahora nos mostrará:

There are 2 programs which provide 'java'.
 
  Selection    Command
-----------------------------------------------
*+ 1           /usr/lib/jvm/jre-1.6.0-openjdk/bin/java
   2           /opt/jdk1.7.0_02/bin/java
 
Enter to keep the current selection[+], or type selection number: 2

Introducimos el número correspondiente a la nueva instalación de Java 7 (en este caso 2) y pulsamos enter.

Finalmente, para comprobar que ya está funcionando la nueva instalación de Java en CentOS ejecutamos el siguiente comando:

java -version
java version "1.7.0_02"
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
Java HotSpot(TM) Client VM (build 22.0-b10, mixed mode)

Hasta aquí la pequeña guía de instalación de Java 7 de Oracle en CentOS o Fedora.
Si tienes alguna consulta, no dudes en dejar un comentario.

Otros artículos relacionados que pueden interesarte:

1. Habilitar Oracle Java en Firefox
2. HOWTO: Instalación de PostgreSQL en Fedora 16
3. CentOS 6 network: sin red después de instalar

AraDaen, sysadmin notes

Si efectuas una instalación de CentOS 6 minimal o sever es probable que al iniciar por primera vez el sistema te encuentres que la red no funciona: los dispositivos de red están desactivados.

La solución es sencilla, y la encontramos en las FAQ de CentOS6: activar durante el arranque del sistema nuestros dispositivos de red.

Para ello debemos editar los archivos de configuración en Centos 6 de nuestros dispositivos de red.

vim /etc/sysconfig/network-scripts/ifcfg-eth0

Su contenido inicial es:

1
2
3
4

DEVICE="eth0"
HWADDR="08:00:27:21:FA:A7"
NM_CONTROLLED="yes"
ONBOOT="no"

Para activar la tarjeta de red de nuestro sistema CentOS 6 debemos modificar el valor de la variable ONBOOT, y, además, indicar que obtenga una IP vía DHCP, o bien, especificar nuestra configuración IP.
En nuestro caso optamos por DHCP, y el archivo debe quedar así:

1
2
3
4
5

DEVICE="eth0"
HWADDR="08:00:27:21:FA:A7"
NM_CONTROLLED="yes"
ONBOOT="yes"BOOTPROTO="dhcp"

Tras guardar los cambios, reiniciamos el servicio de red de CentOS 6 para finalizar:

service network restart

Para comprobar que realmente ha funcionado ejecutamos el comando

ifconfig -a

que nos mostrará el estado de nuestros dispositivos de red:

eth0      Link encap:Ethernet  HWaddr 08:00:27:21:FA:A7  
          inet addr:192.168.0.121  Bcast:192.168.0.255  Mask:255.255.255.0          inet6 addr: fe80::a00:27ff:fe21:faa7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:355 errors:0 dropped:0 overruns:0 frame:0
          TX packets:171 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:42671 (41.6 KiB)  TX bytes:36343 (35.4 KiB)
 
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Como vemos, ya está funcionando el dispositivo eth0 y ha obtenido una IP del servidor DHCP local. Además, los dispotivos de red serán activados cada vez que se inicie Centos 6.

Otros artículos relacionados que pueden interesarte:

1. Instalar fail2ban en servidores Centos y Debian
2. HOWTO: Instalación de Java 7 en Centos y Fedora

AraDaen, sysadmin notes

Empezamos nuestro blog hablando sobre  cómo protegernos de ataques de fuerza bruta con fail2ban y publicamos un manual de instalación de fail2ban para servidores Centos y Debian.

Días después comentamos como La Casa Blanca se opone a SOPA (proyecto de ley antipiratería similar a la Ley Sinde) y continuamos con un guía breve de instalación de PHP 5.3 en Centos 5.

Tratamos también la instalación de VTiger CRM 5.3 en Centos con SELinux, y cómo instalar los módulos de traducción de castellano.

Como no todo es trabajar, explicamos como instalar el cliente de Spotify para linux en Fedora 16,  y nos hicimos eco de la polémica de  Twitter y la censura.

Finalmente cerramos el mes con una pequeña guía de instalación de PostgreSQL en Fedora 16.

En general, estamos contentos con el número de artículos publicados, y esperamos que hayan sido de vuestra agrado. Si pensáis que son demasiado extensos, (o breves), demasiado superficiales (o detallados), o simplemente tenéis alguna duda o comentario, no dudéis en hacernoslo saber dejándono algún comentario, o por cualquier otro medio de contacto.

Saludos.

No hay artículos relacionados en este momento

AraDaen, sysadmin notes

Esta es una pequeña guía de instalación del servidor de base de datos PostgreSQL en Fedora 16. No pretende ser una guía exhaustiva, pero sí proporcionar una forma sencilla y fácil de instalar PostgreSQL de forma segura en Fedora 16.

Esta pequeña guía de instalación y configuración de PostgreSQL en Fedora 16 va a constar de 3 partes:

1. Instalación básica de PostgreSQL en Fedora 16
2. Mejoras de seguridad
3. Configuracion de acceso remoto

Instalación básica de PostgreSQL en Fedora 16

El proceso de instalación y configuración de PostgreSQL en Fedora 16 es muy similar al de Fedora 15 y anteriores, pero presenta ciertas diferencias en el arranque e inicialización del servicio: a pesar de que en Fedora 15 ya estaba presente systemd como sustituto de SysVinit y Upstart, ha sido en Fedora 16 cuando se han sustituido los scripts de SystemV para postgreSQL por el uso de systemd, como veremos posteriormente.

Para comenzar la instalación de PostgreSQL ejecutamos los siguientes comandos como un usuario con privilegios administrativo para instalar los paquetes necesarios del servidor, cliente, librerías y documentación:

yum install postgresql-server postgresql postgresql-libs postgresql-contrib postgresql-docs

Este comando nos ha instalado PostgreSQL 9.1.2, que es la última versión publicada en los repositorios oficiales de fedora.

Ahora, creamos el cluster y arrancamos el servicio ejecutando los siguientes comandos:

postgresql-setup initdb
systemctl start postgresql.service
systemctl status postgresql.service

El comando postgresql-setup initdb lleva a cabo la creación del cluster donde se almacenarán los archivos de configuración y bases de datos de la instancia de PostgreSQL que acabamos de iniciar. Por defecto se ubica en en /var/lib/pgsql/data.

El segundo comando (systemctl start postgresql.service) arranca la instancia del servidor de bases de datos PostgreSQL.

Estos dos comandos son los que han sustituido a los scripts de SystemV en Fedora 15 y anteriores. Su correspondencia en esos sistemas sería service postgresqld initdb y service postgresqld start.

El último comando (systemctl status postgresql.service) sirve para comprobar que PostgreSQL se ha instalado y se está ejecutando correctamente en el servidor. Su salida será de este tipo:

postgresql.service - PostgreSQL database server
	  Loaded: loaded (/lib/systemd/system/postgresql.service; disabled)
	  Active: active (running) since Mon, 30 Jan 2012 20:00:11 +0100; 17s ago
	 Process: 15620 ExecStart=/usr/bin/pg_ctl start -D ${PGDATA} -s -o -p ${PGPORT} -w -t 300 (code=exited, status=0/SUCCESS)
	 Process: 15614 ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
	Main PID: 15624 (postgres)
	  CGroup: name=systemd:/system/postgresql.service
		  ├ 15624 /usr/bin/postgres -D /var/lib/pgsql/data -p 5432
		  ├ 15625 postgres: logger process   
		  ├ 15627 postgres: writer process   
		  ├ 15628 postgres: wal writer process   
		  ├ 15629 postgres: autovacuum launcher process   
		  └ 15630 postgres: stats collector process

En este momento ya está ejecutándose PosgreSQL como servidor de bases de datos en Fedora 16 escuchando en el puerto 5432. La instancia del servidor PostgreSQL es ejecutada por el usuario postgres que se crea con la instalación de la paquetería. La instalación por defecto también crea como usuario de PostgreSQL el usuario postgres con privilegios de administrador del servidor de bases de datos.

Para conectarnos a PostgreSQL utilizamos los siguientes comandos:

su - postgres
psql

psql lanza el cliente de postgreSQL que nos permite gestionar, consultar, etc… el servidor PostgreSQL que acabamos de instalar. Por ejemplo, si deseamos obtener un listado de las bases de datos que tenemos en el servidor utilizamos el comando \l:

postgres=# CREATE USER jose WITH PASSWORD 'claveJose';
CREATE ROLE
postgres=# CREATE USER ana WITH PASSWORD 'claveAna';
CREATE ROLE
postgres=# CREATE DATABASE miBaseDeDatos;
CREATE DATABASE
postgres=# CREATE DATABASE basedatos1;
CREATE DATABASE
postgres=# GRANT ALL ON DATABASE basedatos1 TO ana;
GRANT
postgres=# \l
                                       List of databases
     Name      |  Owner   | Encoding |   Collate   |    Ctype    |      Access privileges      
---------------+----------+----------+-------------+-------------+-----------------------------
 basedatos1    | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =Tc/postgres               +
               |          |          |             |             | postgres=CTc/postgres      +
               |          |          |             |             | ana=CTc/postgres
 mibasededatos | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =Tc/postgres               +
               |          |          |             |             | postgres=CTc/postgres      +
               |          |          |             |             | miusuarioadmin=CTc/postgres
 postgres      | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
 template0     | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres                +
               |          |          |             |             | postgres=CTc/postgres
 template1     | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres                +
               |          |          |             |             | postgres=CTc/postgres
(5 rows)
 
postgres=# SELECT * FROM pg_shadow;
    usename     | usesysid | usecreatedb | usesuper | usecatupd | userepl |               passwd                | valuntil | useconfig 
----------------+----------+-------------+----------+-----------+---------+-------------------------------------+----------+-----------
 postgres       |       10 | t           | t        | t         | t       | md5586e8ed69b76aeb92c0e9e68d59edede |          | 
 jose           |    16387 | f           | f        | f         | f       | md52dfa8209753ae8f742dbcd6fd449136f |          | 
 ana            |    16388 | f           | f        | f         | f       | md55c5d5cd6877585633503c1bb36c2d866 |          | 
(3 rows)
postgres=#

Hasta aquí ya tenemos instalado y funcionando PostgreSQL en Fedora 16, escuchando en el puerto 5432. Por defecto permite solo conexiónes locales a través del usuario del sistema postgres.

Aumentando la seguridad en PostgreSQL

Al instalar los paquetes de postgreSQL se crea también en el sistema la cuenta postgres que se utilizará para ejecutar el servidor. Esta cuenta se crea sin contraseña por defecto. Asignamos una contraseña a postgres:

su -
passwd postgres

Sucede lo mismo con el usuario postgres de PostgreSQL: es el usuario administrador, pero se crea sin contraseña. Procedemos a asignarle una desde el cliente psql:

postgres=# ALTER USER postgres WITH PASSWORD 'miContraseña';
ALTER ROLE
postgres=# SELECT * FROM pg_shadow;
 usename  | usesysid | usecreatedb | usesuper | usecatupd | userepl |               passwd                | valuntil | usecon
fig 
----------+----------+-------------+----------+-----------+---------+-------------------------------------+----------+-------
----
 postgres |       10 | t           | t        | t         | t       | md5586e8ed69b76aeb92c0e9e68d59edede |          | 
(1 row)

Acceso remoto en PostgreSQL

Como hemos indicado la configuración por defecto hace que PostgreSQL solo sea accesible localmente, y utilizando el puerto 5432.

postgres=# show port;
 port 
------
 5432
(1 row)
 
postgres=# show listen_addresses;
 listen_addresses 
------------------
 localhost
(1 row)
 
postgres=#

Para permitir el acceso remoto al servidor de PostgreSQL debemos modificar el parámetro listen_addresses del archivo /var/lib/pgsql/data/postgres.conf. Este parámetro sirve para especificar desde qué interfaz de red escuchará el servidor postgreSQL. :

Por defecto está configurado para escuchar conexiones locales:

listen_addresses = 'localhost'

Pero puede configurarse para que escuche en todos los interfaces de red sel servidor

listen_addresses = '*'

O incluso delimitar su uso a determinos interfaces de red del servidor:

listen_addresses = '192.168.0.10 200.168.0.15'

En nuestro caso vamos a configurar PostgreSQL para que escuche en todas las interfaces de redes.
Editamos el archivo:

vim /var/lib/pgsql/data/postgresql.conf

Y modificamos el valor del parámetro:

listen_addresses = '*'

A continuación, modificamos el archivo que define a qué bases de datos se pueden conectar los usuarios y desde dónde. Esta información se detalla en en el archivo /var/lib/pgsql/data/pg_hba.conf. Es una capa extra de seguridad complementaria a la gestión de privilegios de usuarios dentro del PostgreSQL (GRANT…).

El contenido del archivo es el siguiente:

1
2
3
4

# TYPE  DATABASE        USER            ADDRESS                 METHOD
local   all             all                                     peer
host    all             all             127.0.0.1/32            ident
host    all             all             ::1/128                 ident

Sin entrar en detalle, las tres reglas que aparecen definen exclusivamente el acceso local, tanto socket como TCP/IP, a nuestro servidor PostgreSQL en Fedora 16.

La configuración de reglas es bastante sencilla, y permite desde limitar el acceso a una base de datos a un determinado usuario, desde una IP determinada, hasta permitir un acceso global desde cualquier IP:

• Acceso para todos los usuarios a todas las bases de datos desde cualquier dirección de red:

  host    all             all             0.0.0.0/0               md5

• Acceso desde una determinada IP a todas las bases de datos y con cualquier usuario:

  host    all             all             192.168.0.4/32          md5

• Acceso desde cualquier nodo de la red 192.168.0.0 a la base de datos basedatos1 con el usuario juan, y solo desde 192.168.0.10 con usuarioAdmin:

  host    basedatos1      juan            192.168.0.0/24          md5
  host    basedatos1      usuarioAdmin    192.168.0.10/32         md5

• Acceso con cualquier usuario a la base de datos otraBD desde la red 192.168.0.0/24 excepto con el usuario pedro:

  host    otraBD          all           192.168.0.0/24          md5
  host    otraBD          pedro         192.168.0.0/24          reject

En nuestro caso, vamos a permitir el acceso desde nuestra red LAN (192.168.0.0/24) a cualquier usuario, con dos excepciones:

1. no se va a permitir conexiones con el usuario postgres por ser el usuario con privilegios administrativos en la instalación de PostgreSQL
2. no se va a permitir ningún tipo de conexión desde la máquina con IP 192.168.0.44

Editamos el archivo /var/lib/pgsql/data/pg_hba.conf y agregamos las reglas, de forma que quede así:

1
2
3
4
5
6
7

# TYPE  DATABASE        USER            ADDRESS                 METHOD
local   all             all                                     peer
host    all             all             127.0.0.1/32            ident
host    all             all             ::1/128                 ident
host    all             all             192.168.0.0/24          md5host    all             postgres        192.168.0.0/24          rejecthost    all             all             192.168.0.44/32         reject

Después de guardar los cambios, solo nos queda reinciar PostgreSQL y añadir la regla en el firewall que permita el acceso al puerto 5432 que es donde escucha por defecto PostgreSQL:

systemctl stop posgresql.service
systemctl start postgresql.service
iptables -A INPUT -p tcp --dport 5432 -j ACCEPT

Con esto ya estará funcionando nuestro servidor PostgreSQL en Fedora 16 con acceso remoto habilitado.

Como siempre, si tienes alguna consulta no dudes en preguntar.

Otros artículos relacionados que pueden interesarte:

1. Fail2ban: protege tu servidor de ataques por fuerza bruta
2. HOWTO: Instalación de Java 7 en Centos y Fedora
3. Instalar fail2ban en servidores Centos y Debian
4. CentOS 6 network: sin red después de instalar

AraDaen, sysadmin notes

Hace varios días anunciaba Twitter en su blog oficial que si bien ellos entendían la libertad de expresión como unos de los derechos humanos fundamentales, y apostaban por el libre intercambio de información y opiniones,  en su expansión por nuevos países se veían obligados a cumplir con la legislación vigente de cada uno de ellos. Y, debido a esto, se veían en la obligación legal de restringir en determinados países (exclusivamente) el contenido de tweets y usuarios, sobre los que se presentaran reclamaciones basadas en la legislación de cada país.

Como consecuencia de esto, son numerosas las voces que se han alzado mostrando su oposición a lo que según ellos es una práctica de censura por parte de Twitter.  Hasta tal punto que bajo el hashtag #TwitterBlackout se ha propuesto para hoy, a modo de protesta, que aquellos usuarios de Twitter que estén en contra de esta medida que han tomado desde la red social, dejen de utilizarla durante el día de hoy.

Por otra parte, personas de cierta relevancia en el mundo digital han mostrado, si no su apoyo a la nueva medida de Twitter, sí su sorpresa ante la reacción de los usuarios y el movimiento #TwitterBlackout. Es el caso de Enrique Dans, Ricardo Galli, y otros. Su defensa gira en torno a que es lógico esperar que Twitter se someta a la legislación de los países en los que ofrece sus servicios, y recuerdan que la actual política de Twitter al respecto es borrar de forma global los tweets que son denunciados, de forma que en realidad se está limitando la censura de los tweets al ámbito de determinados países.

Personalmente creo que la nueva política anunciada por Twitter va a servir para disminuir la censura en la medida en que el sesgo será aplicado por países y no de forma global. Es más, los casos censurados serán publicados en Chilling Effects. Entiendo, además, que es imprescindible que Twitter se someta a la legislación vigente, como exigiríamos a cualquier otra compañia que opera en España. Es por eso que no comparto el movimiento #TwitterBlackOut: el destino de la protesta no debería estar enfocado en Twitter, por cumplir las leyes de un determinado país, si no en los legisladores de esos países.

No hay artículos relacionados en este momento

AraDaen, sysadmin notes

Si eres usuario de Spotify y utilizas Linux, habrás descubierto que Spotify recomienda para Linux utilizar el cliente de Spotify de Windows bajo Wine.
Lo cierto es que ofrecen también una versión de Spotify experimental nativa para Linux Debian y Fedora, aunque la versión de Fedora está desatendida y el último paquete que ofrece pertecene a Fedora 13. Además, es imprescindible tener una cuenta Premium para poder utilizar la versión de Spotify para Linux.

En general, considero que Spotify tiene muy desatendidos a los usuarios de Linux. Más todavía si pensamos que los usuarios, somos en la mayoría de casos que conozco usuarios Premium (de pago). En mi caso, de no ser porque también lo tengo en el móvil, no creo que pagara por un servicio que muestra tanto desinterés por sus usuarios de pago.

En cualquier caso, voy a explicar como instalar Spotify en Fedora 16, utilizando para ello la versión más reciente del cliente de Spotify para Debian. Para ello lo que vamos a hacer es convertir el paquete de Debian en un rpm instalable en Fedora 16, instalarlo y solventar los requisitos de librerias.

El primer paso para instalar Spotify de forma nativa en Fedora 16 es descargar e instalar alien, un conversor de formato de paquetería entre distintas distros Linux y Debian. Ejecutamos los siguientes comandos con privilegios administrativos:

yum -y install perl-ExtUtils-MakeMaker gcc qt-webkit rpm-build git
cd /tmp
git clone git://git.kitenet.net/alien
cd alien
perl Makefile.PL
make
make install

A continuación descargamos el paquete del cliente de Spotify para Debian desde los repositorios de Spotify para Linux. Está disponible la versión de 32 y 64 bits. En nuestro caso descargamos la versión de 32 bits, y ejecutamos la conversión del paquete con alien:

wget http://repository.spotify.com/pool/non-free/s/spotify/spotify-client-qt_0.6.2.291.gcccc1f5.116-1_i386.deb
/usr/bin/alien --to-rpm http://repository.spotify.com/pool/non-free/s/spotify/spotify-client-qt_0.6.2.291.gcccc1f5.116-1_i386.deb

La ejecución del comando anterior, crea el paquete rpm de instalación de Spotify. Este paquete requiere las librerias libssl.so.0.9.8 y libcrypto.so.0.9.8. Estas librerías no están disponibles en Fedora 16, así que instalamos el paquete sin comprobar las librerías, y posteriormente creamos un enlace simbólico a las librerias similares que dispone Fedora 16 libssl.so.X.X.X y libcryptopp.so.X.X.X (*ver nota):

rpm -Uvh --nodeps spotify-client-qt-0.6.2.291.gcccc1f5.116-2.i386.rpm 
ln -s /usr/lib/libssl.so.1.0.0g /usr/lib/libssl.so.0.9.8
ln -s /usr/lib/libcryptopp.so.6.0.0 /usr/lib/libcrypto.so.0.9.8

Hecho esto ya tenemos disponible la versión nativa de Spotify para Fedora 16, y puede lanzar la aplicación desde el menú de aplicaciones de Gnome, Audio y Video.

Editado el día 27-01-2012:

Al crear los enlaces simbólicos anteriores, si instalamos alguna actualización de openssl, y podría variar la versión de las librerias, por lo que el enlace simbólico estaría roto, y no funcionaría Spotify.
Para evitar esto, en lugar de realizar los enlaces simbólicos anteriores, debemos crear los siguientes:

ln -s /usr/lib/libssl.so /usr/lib/libssl.so.0.9.8
ln -s /usr/lib/libcrypto.so /usr/lib/libcrypto.so.0.9.8

Los archivos libssl.so y libcrypto.so son enlaces simbólicos del sistema que apuntan a la ultima versión de las librerías libssl.so.X.X.X y libcrypto.so.X.X.X. Estos enlaces se actualizan cuando si hay cambios en las librerias al instalar una actualización. De esta forma, con los comandos anteriores, siempre mantendremos nuestro enlace simbólico funcionando, independientemente de las actualizaciones.

No hay artículos relacionados en este momento

AraDaen, sysadmin notes

Cómo indicábamos en el tutorial de instalación de VTiger 5.3 en Centos, el instalador web de vtiger te da la opción de añadir diversos módulos opcionales, entre ellos los de idiomas (language packs). Esta sería la opción ideal, si no fuera porque el paquete de español (spanish language pack) que instala se corresponde con al versión 5.2 de VTiger, y no la 5.3 que es la última versión estable de vtiger.

Vamos a buscar el language pack de español para VTiger, y después utilizaremos el Gestor de Módulos que trae Vtiger para importarlo a nuestra instalación.

Después de buscar en la web de vtiger, hemos encontrado en la wiki un apunte que hace referencia al mantenimiento de los language packs dónde se indica que todo lo relacionado con la versión en castellano de vtiger 5 podemos encontrarlo en un subproyecto oficial de la forja de vtiger. Lo más gracioso, es que después de dar un vistazo y no encontrar la traducción de la versión 5.3, leemos que para la versión de vtiger 5.2 se ha creado otro proyecto: VTiger Language Pack Es 5.2.
¡Eureka! Después de dar un vistazo, por fín encontramos en este proyecto el language pack de español para la versión 5.3. Aunque es una versión Release Candidate, y nos indica que la últiva versión se puede obtener a través del repositorio de subversión.

Descargamos el archivo de la versión 5.3 desde la web anterior o bien desde consola con el comando:

 # wget http://forge.vtiger.com/frs/download.php/1122/vtSpanish_es_es_5.3.0RC.zip

Ahora, para poder instalar los módulos de traducciónes de vtiger desde el Gestor de Módulos que incluye, es necesario que modifiquemos los permisos de las carpetas de la instalación de vtiger que incluyen los archivos de idiomas:

# chmod g+w cron/language/ include/language/ include/install/language/ include/Webservices/language/ include/js/ jscalendar/ jscalendar/lang/ modules/PriceBooks/language/ modules/PickList/language/ modules/PurchaseOrder/language/ modules/Project/language/ modules/Calendar/language/ modules/Emails/language/ modules/Emails/language/ modules/MailManager/language/ modules/FieldFormulas/language/ modules/Webmails/language/ modules/Dashboard/language/ modules/RecycleBin/language/ modules/RecycleBin/language/ modules/Faq/language/ modules/Rss/language/ modules/Yahoo/language/ modules/uploads/language/ modules/Users/language/ modules/Settings/language/ modules/Invoice/language/ modules/Services/language/ modules/Leads/language/ modules/Assets/language/ modules/Portal/language/ modules/Import/language/ modules/Accounts/language/ modules/Mobile/language/ modules/Quotes/language/ modules/ConfigEditor/language/ modules/Potentials/language/ modules/Campaigns/language/ modules/Tooltip/language/ modules/WSAPP/language/ modules/ModComments/language/ modules/Vendors/language/ modules/Documents/language/ modules/Products/language/ modules/Home/language/ modules/Administration/language/ modules/Migration/language/ modules/Webforms/language/ modules/Utilities/language/ modules/VtigerBackup/language/ modules/ProjectMilestone/language/ modules/Help/language/ modules/Reports/language/ modules/SalesOrder/language/ modules/PBXManager/language/ modules/Contacts/language/ modules/ProjectTask/language/ modules/SMSNotifier/language/ modules/HelpDesk/language/ modules/com_vtiger_workflow/language/ modules/System/language/ modules/ServiceContracts/language/ modules/CustomerPortal/language/ modules/CustomView/language/

Una vez hecho esto, accedemos al CRM como administradores, y accedemos al Gestor de Módulos desde el menú SETTINGS >> Module Manager.

Instalación VTiger spanish language pack - Paso 1: gestor de módulos

En el gestor, seleccionamos la pestaña Custom Modules, y cargamos el archivo del language pack que hemos descargado, e importamos.

Paso 2 Instalación VTiger spanish language pack: importación del módulo

Paso 3 Instalación VTiger spanish language pack: confirmar importación

La importación del módulo de idioma de CRM VTiger genera un registro que podemos visualizar, comprobando qué archivos se han importando, y si se ha producido algún fallo.

Paso 4 Instalación VTiger spanish language pack: resultado de la importación

Una vez finalizada la importanción, solo queda acceder a My Preferences y seleccionar en Language el nuevo paquete de idiomas instalado.
Guardamos los cambios, y al recargar la página aparecerá ya VTiger traducido al castellano.

Paso 5: selección de idioma en preferencias

Paso 6: activación del nuevo idioma

Como habéis visto, el proceso realmente es bastante sencillo, siendo la localización del paquete de idioma lo que más tiempo nos ha llevado. El proceso para instalar otro idioma es similar.

Recuerda que si tienes cualquier duda, puedes utilizar el sistema de comentarios o cualquiera de los otros medios disponibles.

Otros artículos relacionados que pueden interesarte:

1. Instalación de VTiger CRM 5.3 en Centos con SELinux

AraDaen, sysadmin notes

Vtiger es un CRM que resulta bastante últil a empresas y profesionales para gestionar y llevar un seguimiento de las relaciones con sus clientes.

La instalación de vtiger no es demasiado complicada, y consta de varios pasos:

• Configuración del Apache y PHP
• Configuración de MySQL
• Configuración de SELinux
• Instalación de VTiger

Este artículo describe el proceso de instalación de Vtiger 5.3.0, corriendo en un servidor Centos 5.7 que ya tiene instalado Apache 2.2 con Virtual Hosts, MySQL 5.0, y PHP 5.3.

Configuración de Apache y PHP para VTiger

No es necesario utilizar virtual hosts para instalar vtiger, pero es recomendable si vas a acceder desde otros equipos y, además, tienes otras webapp instaladas en el servidor. Lo mismo pasa con PHP, solo requiere la versión 5.2 pero en este caso, tenemos instalado PHP 5.3.
Para comenzar con la configuración del sistema, editamos el archivo de configuracion de los virtual hosts de Apache (en mi caso /etc/httpd/conf.d/vhosts.conf) y añadimos los datos del virtualhost para vtiger:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

 # VIRTUALHOST vtiger.localhost
<VirtualHost *:80>
# Name and admin
ServerAdmin admin@localhost
ServerName vtiger.localhost
# Indexes + Directory Root.
DirectoryIndex index.html index.php
DocumentRoot /var/www/html/vtiger/
# Logfiles 
ErrorLog /var/log/httpd/vtiger.srv-error.log
CustomLog /var/log/httpd/vtiger.srv-access.log combined
# Vtiger PHP Requeriments
php_admin_value allow_call_time_pass_reference 1
php_admin_value error_reporting 2
php_admin_value safe_mode 0
php_admin_value display_errors 1
php_admin_value file_uploads 1
php_admin_value max_execution_time 600
php_admin_value memory_limit 64M
php_admin_value log_errors 0
php_admin_value output_buffering 4096
php_admin_value register_globals 0
php_admin_value short_open_tag 1
</VirtualHost>

Como hemos indicado, accederemos al virtualhost por el nombre vtiger.localhost y como raiz del mismo la carpeta /var/www/html/vtiger. La última parte de la configuración es para habilitar PHP tal y como requiere la instalación y ejecución de VTiger.

Creamos el directorio raiz, y reiniciamos el servidor web:

mkdir /var/www/html/vtiger
service httpd restart

Configuración de MySQL para VTiger

A continuación, creamos en MySQL la base de datos, y el usuario de acceso a la misma que utilizará Vtiger. Para ello, necesitaremos tener privilegios en MySQL:

mysql -u root -p
Enter password:
mysql> CREATE DATABASE vtigerDB DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;
Query OK, 1 row affected (0.10 sec)
 
mysql> CREATE USER 'vtDB_user'@'localhost' IDENTIFIED BY 'claveAcceso';
Query OK, 0 rows affected (0.11 sec)
 
mysql> GRANT ALL ON vtigerDB.* TO vtDB_user@localhost;
 
Query OK, 0 rows affected (0.00 sec)
 
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
 
mysql>quit;

Hemos creado la base de datos vtigerDB, el usuario vtdb_user con contraseña claveAcceso y le hemos dado privilegios totales sobre todas las tablas de la base de datos creada.

Configuración de SELinux para VTiger

Descargamos vtiger, desde su web o utilizando el comando wget, descomprimimos en la el DocumentRoot del virtualhost que hemos creado para vtiger:

cd /tmp
wget http://sourceforge.net/projects/vtigercrm/files/vtiger%20CRM%205.3.0/Core%20Product/vtigercrm-5.3.0.tar.gz/download
tar xvzf vtigercrm-5.3.0.tar.gz
mv vtigercrm/* /var/www/html/vtiger/

Asignamos recursivamente a root y apache como propietario y grupo respectivamente para todos los archivos descargados. Y damos permisos de escritura para el grupo a los archivos necesarios:

chmod -R root:apache *
chmod g+w config.inc.php tabdata.php install.php parent_tabdata.php cache cache/images/ storage/ install/ user_privileges/ Smarty/cache/ Smarty/templates_c/ modules/Emails/templates/ modules/ cron/modules/ test/vtlib/ backup/ Smarty/templates/modules/ test/wordtemplatedownload/ test/product/ test/user/ test/contact/ test/logo/ logs/ modules/Webmails/tmp/ cache/import/ test/vtlib/HTML/

Se asigna como grupo apache, porque es el usuario y grupo con el que se ejecuta el servidor web. Puedes comprobarlo en el archivo de configuración de apache (/etc/httpd/conf/httpd.conf).

En este punto, ya solo nos queda configurar SELinux para tener listo nuestro sistema para poder realizar la configuración de VTiger.
SELinux es un sistema de políticas de seguridad que se aplican según determinados contextos. Para que el servidor web pueda acceder a las páginas de vtiger y conectar a MySQL tenemos que ejecutar los siguientes comandos:

chcon -R -t httpd_sys_content_t /var/www/html/vtiger/*
setsebool -P httpd_can_network_connect_db 1

Instalando VTiger

Una vez realizadas las configuraciones previas, ya solo queda seguir los pasos del instalador web que incluye VTiger accediendo vía web a la url http://vtiger.localhost y realizar la instalación:

Paso 1 Instalación VTiger: Pagina de Bienvenida

Paso 2 Instalación vtiger: Licencia

Después de leernos la información sobra la licencia de VTiger, continuamos con las instalación.

Paso 3 Instalación VTiger : Comprobación de requisitos

Si hemos realizados correctamente los pasos previos para configurar Apache, MySQL, PHP y SELinux, el instalador realizará una comprobación de los requisitos del sistema, y nos permitirá proseguir con la instalación.

Paso 4 Instalación VTiger: Configuracion base de datos y acceso

En esta página deberemos indicar los datos de nuestra base de datos (url, nombre, usuario), y la url de acceso a la instalación (nuestro virtualhost).
También introduciremos la contraseña para el usuario admin de vtiger.

Paso 5 Instalación VTiger: confirmación configuración

Con los datos introducidos, el instalador intentará realizar una conexión a la base de datos, y si todo es correcto, solo nos queda confirmar en esta página los datos introducidos para dar comienzo la instalación de vtiger

Paso 6 Instalación VTiger: selección de módulos opcionales

Una vez finalizada la instalación de vtiger, el instalador nos da la posibilidad de realizar la instalación de modulos opcionales.
En este caso, hemos instalados todos menos los de idiomas: la traducción de castellano incluida no está actualizada, siendo recomendable instalar posteriormente este paquete si lo deseas.

Paso 7 Instalación VTiger: resumen instalación

Para dar por finalizada la instalación solo queda el borrado de la carpeta de instalación y el renombrado del archivo htaccess.txt. Desde una consola ejecutamos los siguientes comandos:

[root@srv ~]# rm -rf /var/www/html/vtiger/install*
[root@srv ~]# mv -r /var/www/html/vtiger/htaccess.txt /var/www/vtiger/.htaccess

Una vez realizado esto, ya hemos finalizado la instalación de VTiger, y podemos acceder vía web a la aplicación:

Paso 8 Instalación VTiger: accediendo a VTiger

Paso 9 Instalación VTiger: VTiger funcionando

Como habéis visto, el proceso de instalación no es demasiado complicado. No obstante, si tienes cualquier pregunta o consulta, no dudes en utilizar el sistema de comentarios, o cualquiera de las otras formas de contacto. Estaremos encantados en poder ayudarte.

Enlace: www.vtiger.com

Otros artículos relacionados que pueden interesarte:

1. Módulos de idioma en CRM VTiger 5.3: spanish language pack

AraDaen, sysadmin notes