Autor: davidrod

Espacio que ocupa una base de datos en MySQL

davidrod Deja un comentario

Para saber el espacio que ocupa una base de datos podemos usar esta consulta

[code]
SELECT table_schema «DATABASE», SUM( data_length + index_length )
FROM information_schema.tables
WHERE table_schema != «information_schema»
GROUP BY table_schema
[/code]

O para verlo un poco más bonito
[code]
SELECT table_schema «DATABASE», CONVERT( SUM( data_length + index_length ) /1048576, DECIMAL( 10, 2 ) ) «SIZE (MB)»
FROM information_schema.tables
WHERE table_schema != «information_schema»
GROUP BY table_schema
[/code]

Como siempre espero que os sirva

Cambiar tamaño de las imágenes en una tarea

davidrod Deja un comentario

Desde opencms podemos crear una tarea con la clase org.opencms.scheduler.jobs.CmsCreateImageSizeJob podemos cambiar el tamaño de las imágenes que han subido los usuarios.
La tarea la va a reescalar respetando las proporciones de la imagen, por lo que es muy bueno para evitar imagenes muy grandes subidas por los usuarios.

Antes debemos configurar en WEB-IF/config/opencms-vfs.xml

<loader class="org.opencms.loader.CmsImageLoader">
<param name="image.scaling.enabled">true</param>
<param name="image.scaling.downscale">w:800,h:600,q:97,c:transparent</param>
></loader>

 

El parámetro image.scaling.downscale tiene:

  • w: El ancho de la imagen
  • h: la altura de la imagen
  • q:la callidad de la imagen en porcentaje
  • t: grado de transparencia de la imagen
  • c: color de fondo en hexadecial como c0c0c0

Otros parámetros que podemos configurar son

  • image.folder
  • image.scaling.maxblursize
  • image.scaling.maxsize

La tarea la creamos como el resto:
tareaopencms-cmscreateimagesizejob

Limpiar un disco de una máquina virtual en Virtualbox

davidrod 1 comentario

Si usáis una máquina virtual dentro de VirtualBox, seguramente hayáis borrado alguna vez ficheros pero vais que el disco sigue manteniendo su tamaño.

La solución es sencilla:

  1. Entrar en la máquina virtual linux
  2. Limpiar de los ficheros que no queremos
  3. Ejecutar «dd if=/dev/zero of=zerofillfile bs=1M» que llenará de ceros todo el espacio libre en el disco
  4. Nos aparecerá un mensaje como «dd: writing ‘zerofillfile’: No space left on device»
  5. Ejecutamos «rm zerofillfile»
  6. Apagamos la máquina virtual con «sudo halt» por ejemplo
  7. Vamos a la carpeta de nuestro ordenador donde se encuentra el fichero del disco. Si tenemos alguna duda podemos verlo en la configuración de la máquina, en el almacenamiento.
  8. VBoxManage modifyhd –compact «RUTA AL FICHERO DEL DISCO».
  9. Si se trata de un fichero vmdl tenemos que hacer algún paso intermedio:
    1. VBoxManage  clonehd «RUTA AL FICHERO DEL DISCO» «cloned.vdi» –format vdi
    2. VBoxManage modifyhd –compact «cloned.vdi»
    3. VBoxManage  clonehd «cloned.vdi» «RUTA AL FICHERO DEL DISCO» –format vmdk

Como siempre, espero que os sirva.

Cachear un 302 con Squid

davidrod Deja un comentario

Aunque sea un poco saltarse el estándar por la torera, os vamos a plantear una solución para que el Squid guarde en su caché los 302. En el caso de OpenCms con sitios exportados, con un squid+Apache+Tomcat, la redirección 302 del sitio por ejemplo de www.uva.es a www.uva.es/export/sites/uva/index.html supone un a carga extra al tomcat ya que llega al Squid (que no o cachea por defecto), llega al apache y finalmente llega al Tomcat. Con un número muy grande de accesos esto supone ua carga extra al Tomcat que podemos evitar.

Lo primero, documentarnos. En la página http://wiki.squid-cache.org/SquidFaq/InnerWorkings, en la sección «How come some objects do not get cached?» podemos leer dos cosas interesantes. que por defecto no cachea los 30x y que para cachear el 302 «A 302 Moved Temporarily response is cachable ONLY if the response also includes an Expires header.», es decir, tenemos que tener una respuesta del servidor del 302 con el dato «Expires» en la cabecera, y aunque no lo dice, debe ser una fecha futura, ya que si ponemos una fecha pasada no lo va a cachear tampoco.

Pues vamos a ponernos a trastear ya. ¿Donde? Tenemos tres opciones, tocar el código de OpenCms, tocar el Tomcat o tocar el apache. En nuestro caso la más sencilla es el apache con su documentación, pero para el Tomcat también en muy sencilla y viene en la documentación buscando «Expires» , y la que no hemos mirado es el código de OpenCms.

En el caso de apache, podemos añadir un htaccess o directamente en la definición del virtualhost añadir estas líneas para que todos los contenidos digan que expiran en 5 minutos.
[code]
ExpiresActive On
ExpiresDefault «access plus 5 minutes»
[/code]

A partir de ese momento los 302 empezarán a ser cacheados por el Squid

[code]

1434098144.302      0 188.85.71.120 TCP_MEM_HIT/302 415 GET http://www.uva.es/ – NONE/- text/plain
1434098144.541      0 157.88.20.208 TCP_MEM_HIT/302 415 GET http://www.uva.es/ – NONE/- text/plain
1434098160.693      0 157.88.240.224 TCP_MEM_HIT/302 415 GET http://www.uva.es/ – NONE/- text/plain
1434098163.364      0 157.88.150.22 TCP_MEM_HIT/302 415 GET http://www.uva.es/ – NONE/- text/plain

[/code]

y desde los navegadores veremos también que el Squid nos devuelve el X-Cache: HIT como podéis ver en la imagen

Squid cacheando 302

 

A continuación podemos afinar más el dato Expires diferenciando por tipo por ejemplo, pero tened en cuenta que ya está el Squid de intermediario, y no afecta mucho al cliente:

[code]

ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 year"
[/code]

y podemos meter condiciones para que sólo lo haga los 302, pero no lo vemos necesario.

Como siempre, esperamos que os ayude!!

Depurar Tomcat con IntelliJ

davidrod Deja un comentario

Vamos a describir los pasos para depurar un Tomcat con IntelliJ, por ejemplo para depurar nuestro OpenCms.

En primer lugar debemos arrancar el Tomcat en modo depuración. Una de las soluciones es modificar el script de arranque, startup.sh y añadir el parámetro jpda. Para ello en ese fichero donde pone
[code]
exec «$PRGDIR»/»$EXECUTABLE» start
[/code]
Debemos poner
[code]
exec «$PRGDIR»/»$EXECUTABLE» jpda start
[/code]

A continuación vamos a indicar al Tomcat el puerto y el modo de depuración. Un a de las opciones es añadir las variables siguientes al .bash_profile de nuestro usuario
[code]
JPDA_ADDRESS=9000
JPDA_TRANSPORT=dt_socket
export JPDA_ADDRESS
export JPDA_TRANSPORT
[/code]

Y tras rearrancar el Tomcat, desde IntelliJ, vamos «Run -> Edit configurations…» y pulsamos al «+», Tomcat Server-> Remote. Nos aparecerá una pantalla como la siguiente:
Tomcat Remoto IntelliJ

Podemos quitar en «Before Launch» el make ya que vamos a depurar directamente el código sin compilarlo, y en «Startup/Connection» debemos seleccionar el puerto que indicamos anteriormente, en este caso el 9000.
Tomcat Remoto IntelliJ

¡¡y ya podemos depurar el tomcat!!. A poner puntos de interrupción como cosacos… ^_^

Libreria Mcrypt de apache

davidrod Deja un comentario

Al instalar esta librería en Mac con un port install php53-mysql o en Ubuntu con un apt-get install php5-mcrypt, y tras reiniciar el apache a veces no nos funciona, y lo vemos porque no sale en un phpinfo o simplemente porque nos da error al cargar la librería.

El problema es que en lugar de dejar la librería mcrypt.so en el sitio por defecto donde php (por ejemplo /opt/local/lib/php/extensions/no-debug-non-zts-20090626/) va a buscarlo deja las librerías en otro directorio, /opt/local/lib/php53/extensions/no-debug-non-zts-20090626/

La solución pasa por modificar el php.ini para añadir un directorio de extensiones. Por ejemplo en Mac sería

[code]

extension_dir=»/opt/local/lib/php53/extensions/no-debug-non-zts-20090626/»

[/code]

Otra solución es crear enlaces simbólicos según las librerías instaladas en la carpeta por defecto. Para ello hacemos un ls de la carpeta y vamos haciendo los enlaces simbólicos.

[code]

ls /opt/local/lib/php53/extensions/no-debug-non-zts-20090626/
ln -s /opt/local/lib/php53/extensions/no-debug-non-zts-20090626/mcrypt.so /opt/local/lib/php/extensions/no-debug-non-zts-20090626/mcrypt.so

[/code]

Y si no nos queremos complicar nada, pues copiamos de una carpeta a otra .

[code]
cp /opt/local/lib/php53/extensions/no-debug-non-zts-20090626/* /opt/local/lib/php/extensions/no-debug-non-zts-20090626/
[/code]

Para comprobar si funciona desde un terminal hacemos

[code]

php -m | grep mcrypt

[/code]

Y ya sólo nos queda reiniciar el apache. Si nos siguiese dando problemas, deberíamos especificar las librerías en el fichero php.ini y en las extensiones añadir

[code]
mcrypt.so
[/code]

Como siempre, espero que os sirva

Actuar sobre una lista de ficheros con espacios

davidrod Deja un comentario

Si queremos hacer algo con una lista de ficheros y nos encontramos espacios, esta es la solución

[code]

find . -type f | while IFS= read -r file; do echo «${file}»; done

[/code]

Lo importante son las comillas.

Si queremos por ejemplo moverlos a otro sitio, deberemos usar también las comillas dobles

[code]

find . -type f | while IFS= read -r file; do echo «${file%.doc}»; mv «${file}» /tmp/»${file}»; done

[/code]

 

Opencms: replicación de índices de Solr

davidrod Deja un comentario

Nosotros tenemos una configuración de un maestro donde la gente edita y dos esclavos para servir las webs de OpenCms. El problema que nos encontramos es que en el disco compartido donde tienen los índices de Solr varias instancias de OpenCms (1 del maestro y 2 de los esclavos) intentaban manipular el mismo índice, y esto daba problemas de bloqueo para hacer los updates y commits. Además si un maestro hace las modificaciones, los esclavos no se enteran de las modificaciones. También había un problema con el cacheado de los esclavos, que no se enteran de los cambios en los contenidos del maestro y no actualizan las caches, por que cachean aunque la tengas desactivado y a tamaño cero.

La solución ha sido complicada pero efectiva.Ehmos replicado el índice Solr Online del maestro en los esclavos, y definiendo un servlet para que los esclavos se enteren de las actualizaciones en el maestro. Todo está basado en la configuración de las realizaciones de Apache Solr (http://wiki.apache.org/solr/SolrReplication) y la clase de OpenCms OpenCmsSolrHandler.

Paso a detallar la configuración del maestro:

– Instalamos un módulo con unas pequeñas modificaciones de CmsSolrIndex.java y una nueva clase OpenCmsHandleSolrReplicationHandler.java creada por nosotros (si alguien tiene interés que contacte con nosotros)

– Configuramos la replicación en WEB-INF/solr/conf/solrconfig.xml dentro de OpenCms con la información de la wiki:

[code]

<requestHandler name=»/replication» class=»solr.ReplicationHandler»>

<lst name=»master»>

<str name=»replicationAfter»>commit</str>

<str name=»replicationAfter»>startup</str>

</lst>

[/code]

– configuramos WEB-INF/web.xml un servlet con nuestra clase OpenCmsSolrReplicationServlet .

 

La configuración de los esclavos es más sencilla.

– Configuracmos el índice en  WEB-INF/config/opencms-search.xml

[code]

<directory>index_esclavoID</directory>

[/code]

– Configuramos la replicación en WEB-INF/solr/conf/solrconfig.xml

[code]

<requestHandler name=»/replication» class=»sold.ReplicationHandler»>

<lst name=»slave»>

<str name=»masterURL»>http://IP:PUERTO/replication</str>

<str name=»pollInterval»>00:00:20</str>

</lst>

</requestHandler>

[/code]

Con esto hemos logrado que los índices se actualicen sin bloqueos ni problemas.