enero 11th, 2012 
Uncategorized 
jorge 
no comments
Buscamos un programador con conocimientos avanzados de Java para trabajar con nosotros en nuestra oficina del centro de Madrid. Necesitamos una persona con profundos conocimientos y experiencia en Java en el lado servidor: Spring, Hibernate, Jboss, MySQL.
Valoramos conocimientos de python y que sea alguien con interés en la plataforma Java en toda su extensión, tanto en relación a frameworks y herramientas como en lo que respecta a otros lenguajes como groovy o scala.
Su responsabilidad no será el código frontend, pero le será de ayuda tener conocimientos en javascript, html y css.
Si crees que encajas, envía tu CV a soyesapersona arroba 11870.com.
diciembre 15th, 2011 curro jorge no comments
Buscamos un programador front end para que se incorpore a nuestra oficina en el centro de Madrid.
Trabajará integrado en el equipo de tecnología pero en estrecha colaboración con el equipo de experiencia de usuario, por lo que es necesario un fuerte interés por las disciplinas que cubren la experiencia de usuario.
Es necesario un conocimiento extenso y profundo de HTML, CSS y javascript, en particular jquery y prototype.
Es deseable conocimiento y experiencia en aplicaciones web en entorno java.
Valoraremos trabajos y/o experimentos realizados visibles.
Si crees que encajas envíanos tu CV a soyesapersona arroba 11870 punto com.
noviembre 11th, 2011 java, sistemas Juan Vicente Herrera no comments
Es altamente conveniente tener unas mínimas medidas de seguridad para dificultar el acceso a la jmx-console y la web-console de Jboss, especialmente si tienes una versión antigua de Jboss(por debajo de la 6 y especialmente la rama 4.x), ya que se pueden realizar numerosas operaciones y obtener datos desde las mismas.
Además hace unos días que circula un gusano que aprovecha una vulnerabilidad(CVE-2010-0738) de hace un año aproximadamente y se aprovecha de la costumbre de proteger mediante security constraints las peticiones POST y GET pero no el resto de peticiones http. Para más detalles ver este comunicado.
El primer paso es activar la autenticación mediante usuario y password.
1. Editar el fichero $JBOSS_HOME/PROFILE/deploy/jmx-console.war/WEB-INF /web.xml
Y descomentar el siguiente bloque:
<security-constraint>
<web-resource-collection>
<web-resource-name>HtmlAdaptor</web-resource-name>
<description>An example security config that only allows users with the
role JBossAdmin to access the HTML JMX console web application
</description>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>JBossAdmin</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>jmx-console</realm-name>
</login-config>
<security-role>
<role-name>JBossAdmin</role-name>
</security-role>
El valor indicado en el parámetro <real-name> del apartado <login-config> debe coincidir con el indicado em el fichero $JBOSS_HOME/server/PROFILE/conf/login-config.xml el cual define la autenticación y autorización a realizar .El usuario y password se indica en un fichero de texto plano (especial cuidado con los permisos de acceso) $JBOSS_HOME/server/PROFILE/conf/props/jmx-console-users.properties. El usuario que especifiquemos debe tener rol JBossAdmin tal y como especificamos en el fichero web.xml .
2. Editar el fichero $JBOSS_HOME/PROFILE/deploy/jmx-console.war/WEB-INF/jboss-web.xml, para fijar el nombre del dominio de seguridad que usaremos más adelante:
<security-domain>java:/jaas/web-console</security-domain>
3. Editar el fichero $JBOSS_HOME/server/default/conf/login-config.xml:
y asegurarnos de que tenemos este bloque de código
<application-policy name = "jmx-console">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required">
<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
</login-module>
</authentication>
</application-policy>
<!-- A template configuration for the web-console web application. This
defaults to the UsersRolesLoginModule the same as other and should be
changed to a stronger authentication mechanism as required.
-->
<application-policy name = "web-console">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required">
<module-option name="usersProperties">web-console-users.properties</module-option>
<module-option name="rolesProperties">web-console-roles.properties</module-option>
</login-module>
</authentication>
</application-policy>
En las versiones anteriores o iguales a JBoss AS 5.x, el fichero web.xml incluye una security-constraint que bloquea las peticiones GET y POST :
<http-method>GET</http-method>
<http-method>POST</http-method>
Eliminar estas opciones para que la restricción de seguridad afecte a todos los tipos de peticiones http
La aplicación puede ser deplegada mediante touch jmx-console.war en caliente, sin reiniciar el servidor.
El proceso para securizar la web-console es parecido:
- Editamos $JBOSS_HOME/PROFILE/deploy/management/console-mgr.sar/web-console.war/WEB-INF/web.xml y $JBOSS_HOME/server/PROFILE/deploy/management/console-mgr.sar/web-console.war/WEB-INF/jboss-web.xml de la misma manera que con la jmx-console
- Editamos $JBOSS_HOME/PROFILE/deploy/management/console-mgr.sar/web-console.war/WEB-INF/classes/web-console-users.properties de la misma manera que con la jmx-console
Debemos comprobar que ambas aplicaciones se han redesplegado bien y que se pide la autenticación.
Tags: constraint, jboss, jmx, web-console
noviembre 10th, 2011 sistemas Juan Vicente Herrera no comments
En primer lugar comentar que la instalación sobre la que vamos a tratar consiste en dos nodos con sharding, uno de ellos hace además de config y router.
En las pruebas realizadas con los comandos mongodump y mongorestore, la restauración de datos no ha sido satisfactoria y estable, puesto que en algunos casos se pierde la configuración del sharding y en otras no se restauran los datos correctamente, aun usando la opción –oplog que permite escribir los datos recién escritos mientras se hace el backup. A partir de cierto volumen de datos (2.000.000 de registros) se queda colgado el restore.
La versión utilizada es la 2.0. El sistema de ficheros empleado en las particiones donde se alojan los datos del Mongo es ext4 con LVM.
La manera de realizar el backup de manera más fiable (aunque con la importante pega de no ser un backup incremental) es realizando un snapshot del volumen lógico(previo bloqueo de las escrituras en la base de datos), para posteriormente realizar un backup de ese snapshot en el directorio remoto que deseemos. De esta manera solo se bloquean las escrituras en la base de datos durante el tiempo que tarde en hacerse el snapshot.
Partimos de la siguiente infraestructura:
En cada máquina tenemos la siguiente configuración de particiones:
- 1 lvm con el sistema /
- 1 lvm con los datos de Mongo /var/lib/mongodb
- Espacio para crear un snapshot de la partición anteriormente mencionada(si /var/lib/mongodb ocupa 40 gb, necesitamos otros 40 gb libres por lo menos para crear el snapshot).
Os dejo un pequeño resumen de como redimensionar un volumen LVM, así como crearlos por si fuera necesario(especialmente necesario si esta montado todo el sistema Linux en un solo volumen lógico).
Una vez cumplimos estos requisitos previos nos conectamos a la consola del Mongodb:
#mongo -port 30000
y bloqueamos las operaciones de escritura sobre la base de datos:
mongo1$ use admin
mongo1$ db.runCommand({fsync:1,lock:1})
A continuación realizamos una copia exacta del volumen lógico donde guardamos los datos del mongo:
mongo1$ lvcreate -L40G -s -n mongosnapshot /dev/mapper/lvmcondatosmnongo
desbloqueamos las escrituras en en la base de datos(todas las operaciones pendientes seran ejecutadas):
mongo1$ db.$cmd.sys.unlock.findOne()
Y ahora ya podemos hacer el backup sobre esta imagen recien creada. Para ello montamos la imagen en un directorio de nuestra elección:
#mkdir -p /mnt/backup/mongonapshot
#mount /dev/mapper/mongosnapshot /mnt/backup/mongosnapshot
Ahora tenemos que elegir si queremos una copia exacta a nivel de bloques físicos o una copia a nivel de ficheros. Recomiendo la opción de ficheros para restaurar con más rapidez y optimizar el espacio en disco. Con la copia a nivel de disco, copiamos también el espacio no usado.
Fichero: #tar -pczf /backups/mongo.tar.gz /mnt/backup/mongosnapshot
Disco: #dd if=/mnt/backup/mongosnapshot of=/backups/mongo.dd
¡Ya tenemos backup!
Ahora sólo queda restaurar los datos, para lo que tendríamos que para los servicios en cada nodo y descomprimir la copia:
# /etc/init.d/mongodb stop
#tar zxvf backups/mongo.tar.gz /var/lib/
o restaurar la imagen de disco:
#dd if=/backups/mongo.dd of=/var/lib/mongodb
Referencias:
http://www.howtoforge.com/linux_lvm_snapshots_p1
http://www.mongodb.org/display/DOCS/Backups
Tags: backup. mongodb, lvm
octubre 25th, 2011 sistemas Juan Vicente Herrera no comments
En ocasiones tenemos un sistema de ficheros LVM donde se aloja todo el sistema operativo y luego surge la necesidad de crear otros volúmenes lógicos sin añadir otro disco duro para aumentar el espacio, es decir tenemos que reducir el volumen lógico actual para dar cabida a los nuevos.
Por ejemplo podemos necesitar un nuevo volumen lógico para tener un sistema de ficheros distinto al del sistema operativo para aumentar el rendimiento de un servicio, realizar un backup mediante una imagen exacta del volumen etc …
Esta operación en un volumen lógico que no aloje los directorios del sistema operativo básicos es más fácil al poder desmontarse, pero en el sistema raíz es más complicada.
Para ello necesitaremos un disco que contenga un sistema operativo Linux que arranque en modo “Live”.
Nosotros usaremos para este ejemplo Ubuntu 11.04.
Tras arrancar mediante el cd y seleccionar la opción “Probar Ubuntu”, abrimos una terminal e instalamos las utilidades LVM:
#apt-get install lvm2
Tras ello montaremos los volúmenes lógicos de nuestro sistema de ficheros mediante la siguiente instrucción:
#lvm vgchange -a y
Miramos cuanto espacio ocupa actualmente el sistema para no reducir más de la cuenta la partición:
#df -h
S.ficheros Tamaño Usado disp Uso% Montado en
/dev/mapper/root 60G 30G 50% 50% /
Antes de redimensionar el volumen lógico chequeamos el correcto estado del volumen:
#e2fsck -f /dev/VolGroup00/LogVol00
Despues de la comprobación, resize2fs puede ser usado para reducir el tamaño del sistema de ficheros del volumen . Este paso es imprescindible para asegurar la integridad de los datos.
#resize2fs -f /dev/mapper/root 35G
Tras esto reducimos el volumen lógico con la misma cantidad de espacio que haya quedado el sistema de ficheros:
#lvm lvreduce -L35G /dev/mapper/root
Tras ello miramos el espacio libre que queda para crear volumenes lógicos:
y el actual estado de los mismos:
#lvdisplay
Creamos el nuevo volumen lógico
#lvcreate -L 25G -n backup VG Name(mostrado previamente con vgdisplay)
Y listo, arrancamos el sistema de manera normal.
Referencias
http://equivocation.org/node/103
http://www.tcpdump.com/kb/os/linux/lvm-resizing-guide/shrink.html
Tags: linux, lvm