Monitorizar tu servidor con “vmstat”

Tras oír el magnifico podcast (junto con la entrada en su blog que resume todo lo hablado) de DaboBlog junto con Ricardo Galli sobre sus experiencias como SysAdmins, el cual recomiendo encarecidamente oír, ya que cuentan de manera muy amena, y con ejemplos, su día a día administrado un sistema.

Tras oírlo tuve la curiosidad por uno de las utilidades de las que hablaron y que no utilizaba (sencillamente nunca me he visto en la necesidad).

Esta herramienta es vmstat, que nos permite monitorizar lo que pasa dentro de nuestro servidor a nivel de hardware… memoria, discos, procesos, y demás partes oscuras de nuestro sistema.

Tras leer un poco he visto que esta herramienta es totalmente imprescindible cuando su servidor baja de rendimiento y quieres saber el porqué. Si alguna vez te has enfrentado a este problema sabrás lo complicado que es en ocasiones, pero estas herramientas nos permiten hacernos una idea global con un vistazo.

Para hacernos una idea, las cosas que tenemos que tener en mente es lo siguiente:

  • La columna “swap” nos indica la actividad de la paginación, en la subcolumna “so” nos indica la paginación en el sentido memoria->disco. Si ves que hay números elevados, sin duda te has quedado sin memoria, y tiene que mover cosas a disco ya que no entran en memoria.
  • La columna “procs” nos indica el estado de los procesos, en la subcolumna “r” encontramos los procesos que están esperando por el uso del procesador.
  • La columna “memory” nos indica el estado de la memoria, en la subcolumna “free” nos indica la memoria libre. No creo que tenga que decirte que significa cuando llegamos a 0.
  • La columna “cpu” nos indica en que estamos gastando (o perdiendo) el tiempo de CPU, en la subcolumna “wa” os indica el porcentaje de espera por E/S de la CPU. Es especialmente útil cuando queremos ver en que pierde tiempo nuestra CPU (os recomiendo este documento)

Quizás sólo con esto no logres descubrir el 100% de los problemas que se pueden dar en tu servidor, pero sin duda son una buena guía para empezar una investigación.

Referencias que he usado para escribir este artículo:

Please follow and like us:

Como utilizar una controladora LSI Logic SAS 1064e con Ubuntu/Debian

¿No habían pasado los tiempos de los Winmodem?, yo pensaba que si, que todo eso estaba solucionado, hasta que me he enfrentado al reciclaje de un servidor, quitando Windows y instalando una distro de Linux y me encuentro con los RAID-Software. Os cuento lo sucedido:

Imagen: www.kerneltrap.org

Imagen: www.kerneltrap.org

Uno tan feliz, mete el CD de Ubuntu, y se encuentra que: ¡¡¡¡No detecta ningún disco!!!!!. Este ordenador monta una placa Intel s5000spl, con una controladora “LSI Logic SAS 1064e“, que es algo parecido a los clásicos Winmodems, donde tiene una mezcla entre firmware y software que nos vuelve locos si no usamos un sistema operativo soportado.
A esta controladora, inicialmente le montamos un RAID 10 con 4 discos (el RAID 10 no nos quedo más remedio, ya que otra gracia de la placa es que si quieres RAID 5 tienes que poner 100 euros en la mesa, y en el bolsillo de Intel, para que te den una especie de jumper que habilita usar RAID 5 en la placa) y confiamos que funcione… Obviamente no pasó así.
Joder, a buscar los malditos drivers, y te encuentras algo muy molesto: Sólo soporta RedHat o Suse. ¿Lo qué?… La liamos.

Bueno, resignado, busco el código fuente del driver (que te lo dan eso si) y veo que se puede compilar el módulo para el Kernel, pero que tiene un problema: el código fuente del driver no funciona directamente en el Kernel de Ubuntu/Debian. Aparte, si usas un driver precompilado, NO puedes actualizar el Kernel, ya que tendrías que volver a adaptar otra vez el driver… trabajo de chinos.

Total, me rasgo las vestiduras. A la mierda, RAID por software… pero, ¿como leches hago para que se vean los discos?. Tras investigar, encontré un montón de información y vi que la controladora si estaba soportada, pero que a mucha gente no le funcionaba. ¿Pero por qué no funciona?.
Bueno, tras otro rastreo por los foros de ayuda de Ubuntu y el Bug Tracker de la distro , leo que al parecer la parte hardware si esta soportada, pero la parte que montan software no, ya que es propietaria.

Bueno, pues a la mierda con la parte software y todo arreglado. Simplemente hay que ir a la bios y en el apartado de “Mass Storage“, deshabilitar la “SW Raid“. Entonces, al instalar te apareceran los discos SIN el Raid que tenga configurado la controladora. Y ya tranquilamente puedes montar tu software-raid sobre linux, y ahora si podremos montar un RAID 5 como dios manda.

Otra batalla ganada.

Please follow and like us:

Unir Subversion con MantisBt, sin complicaciones.

Cuando trabajamos de manera “seria” en proyectos de desarrollo software, hay una parte muy importante que es utilizar una buena herramienta de control de versiones, y un buen gestor de incidencias o bugs.

Personalmente, llevamos bastante trabajando con Subversion en mi empresa sin grandes quejas, lo cual nos permite mantener los desarrollas saneados y controlados… aparte de saber quien metió la pata en un programa, ya que sabemos quien modifica cada línea del programa.

Hace unos meses, nos dimos cuenta que necesitábamos un control de las incidencias que encontrabamos, y incluimos en nuestros sistemas MantisBt que sustituyó a las clásicas hojas escritas con todos los problemas encontrados :P. Todo un clásico para todo desarrollo informático.

Ahora bien, nuestro sistema de trabajo era muy simple, desarrollar, probar y luego subir a Subversion, y revisar más tarde Mantis para cerrar las incidencias resueltas.

Pero no paramos en este protocolo para el control de nuestros desarrollos y quisimos integrar ambos sistemas, con el siguiente objetivo: cuando subamos una revisión a Subversión, automáticamente se cerraran las incidencias asociadas, que indicaremos en el comentario de la revisión.
Tras investigar un poco por la red, encontramos una forma muy limpia, sin tener que programar, gracias a que ya habían desarrollado un plugin para integrar los dos servicios de manera bastante sencilla.

  1. Al menos tener la versión 1.2.x de Mantis (en nuestro caso la 1.2.3), y Subversion, cualquier versión por encima de 1.3.x, (en nuestro caso la 1.6.6). Tener acceso a un usuario con acceso a los repositorios y ser administrador en Mantis.
  2. Ir a la web del creador del plugin (por si tienes curiosidad, aquí tienes el Mantis del plugin), y bajarte los plugins que indica de este repositorio git. Son solo dos: “meta” y “source-integration“. Desde allí mismo nos permite bajar un snapshot en tar.gz.
  3. Descomprimimos y vemos que el plugin “source-integration” tiene una carpeta “Source” y luego otras carpetas para cada unos de los servidores de control de versiones soportados (Git y SVN). En el caso del SVN, podemos usar directamente el protocolo SVN o a través de WebSVN (en mi caso, use directamente el protocolo SVN), copiando sólo la carpeta “Source” y “SourceSVN“.
  4. Lista de Plugins

    Lista de Plugins en Mantis 1.2.3

    Una vez tengamos copiados las carpetas (ojo es importante que sean las carpetas que contienen los ficheros php) en el directorio “plugins” del directorio donde se encuentra Mantis, ir al interfaz de “Administración > Administrar Plugins“, e instalarlos, respetando las dependencias que muestran.

  5. Ahora seguimos las indicaciones que se indican en esta web, que son mucho más detalladas que las de su creador. Sólo hay una discrepancia: Todo se configura a través del plugin “Source Control Integration“, solo rellenando el campo “SVN: Path to binary“, en mi caso con “/usr/bin” en una Ubuntu 10.04 server.
  6. Ahora si queremos adaptarlo al castellano, cambiamos “Bug Fixed Regex Pass 1”, por algo parecido a:
    /(?:corregido?d?s?|arreglado?s?)+\s+(?:#(?:\d+)[,\.\s]*)+/i
    

    Así cada vez que escribamos esto (“arreglados #001 #008”) en un comentario de un commit de Subversión, cerraremos los bugs asociado en el mensaje.

  7. Se puede cambiar muchas más opciones, pero lo dejo a vuestra investigación. Nosotros no indagamos mucho más. Hay muchas más información en: aquí.
  8. Obtener la ruta de un repositoro

    Ahora aparecerá una nueva sección en los apartados principales de Mantis, llamado “Repositories”. Al entrar, podremos añadir un repositorio que controlar, en nuestro caso, hemos seleccionado el protocolo “SVN”, por lo que tiene que tener usar ruta el repositorio que empiece por “svn://”, y que tendréis que conocer si tenéis el repositorio en nuestro equipo (en Windows sólo hay que seleccionar la carpeta que tiene el repositorio en nuestro ordenador, y en propiedades, en la pestaña de “TortoiseSVN”, esta la ruta con el protocolo SVN). Recuerda que tienes que dar un usuario existe en Subversion, no en el sistema.

  9. Tras esto, pulsamos en “Import Latest Data“, y si no hay ningun error, tendremos un mensaje que nos indica hasta que revisión ha logrado importar. Si tienes muchas revisiones, puede dar un timeout, por lo que tendrás que volver a darle o aumentar el tiempo de timeout de servidor.

Ya está… Bueno, realmente no. Con esto esta conectado, pero cuando subamos un revisión a Subversion, veremos con desesperación que no se refleja en Mantis. ¿Porqué?. Bueno, en teoría, tendríamos que importar los datos cada vez desde el interfaz de Mantis. Esto, claramente, no es lo que buscamos, ya que queremos una experiencia “automática”. Para remediarlo, podemos automatizar la adquisición de los datos de los repositorios mediante una tarea programada. En nuestro caso:

  1. Editar el fichero “/etc/crontab“:
    # Integracion subversion y mantis
    */5 *   * * *   svn     curl "http://localhost/mantis/plugin.php?page=Source/import&id=all" >> /tmp/updateMantisFromSVN 2>&1
    

    Yo, al principio y por depuración, incluyo la redirección a un fichero, tu puedes cambiarlo a “/dev/null” por ejemplo.
    También, se puede cambiar la frecuencia, en este caso está puesto cada 5 minutos, que quizás sea un poco exagerado, y se podría subir.

  2. Nos tiene que devolver algo parecido a esto:
    <pre>Requesting svn log for Repo 1 starting with revision 28...
    Processing svn log...
    No revisions parsed.
    </pre><pre>Requesting svn log for Repo 2 starting with revision 9...
    Processing svn log...
    No revisions parsed.
    

    Y ya tenemos todo el tinglado montado.

Please follow and like us:

Geoserver y las extensiones “ImageIO-ext” no se llevan bien con Tomcat (>= 6.0.24)

Parece que tenemos un problema, Houston. Y uno gordo.

Muchas de las personas que utilizamos Geoserver como servidor de mapas, nos hemos decidido por la combinación Geoserver+Tomcat, ya que parece una forma “ordenada” y “optimizada” de implantar un servidor de mapas.

Pero todo tiene problemas.

Si hemos instalado las extensiones “ImageIO-ext” para obtener la posibilidad de usar muchos más formatos de fuentes de cartografía en nuestro servidor, y por casualidad hemos actualizado a una versión de Tomcat por encima de la 6.0.24 (inclusive) nos encontramos que al intentar usar un formato de los que nos da soporte las extensiones “ImageIO-ext”, encontramos este fantástico error:

Caused by: java.lang.IllegalArgumentException: Incorrect input type!
       at javax.imageio.ImageReader.setInput(ImageReader.java:290)
       at it.geosolutions.imageio.gdalframework.GDALImageReader.setInput(GDALImageReader.java:838)

¿Yuhu?. Bueno, al menos, es un error reconocido por la gente de Geoserver y ahora mismo esta trabajando en ello, aunque no creo que tengan una solución próxima, ya que el problema esta en la extensión, no en el servidor Geoserver. La extensión tiene un problema de “leak” de memoria en ciertas condiciones, y las nuevas versiones de Tomcat tiene un nuevo mecanismo que detecta esto fallos que pueden peligrar el buen funcionamiento del servidor y hacen que no permita el registro de la extensión en el sistema (et voilà, ya no tenemos acceso a la extensión).

Aunque haya algún “workaround” a la vista, como deshabilitar dicho mecanismo de protección anti-fugas de memoria en el servidor Tomcat. Aunque esperemos que no quede mucho para que lo solucionen de una manera mas “fina”.

Referencias:

Please follow and like us:

Doctor, ¿cuanta vida le queda a mi disco?

Es una de las preguntas fundamentales,  y que se le presenta a cualquiera que tiene un servidor en producción durante mucho tiempo, y no sabes si sus discos ya están terminando su vida útil. Aunque tengas medidas para contrarrestar un fallo de disco, si los cambias a tiempo te puedes salvar de muchos sustos.

¿Cuanto tiempo le quedan los discos?. Pues se puede saber mediante una GRAN utilidad que se dispone en casi todas las plataformas, en mi caso, hablaré de Linux. Son las “SMART Monitoring Tools“.

Lo primero instalar, como no:

nas001@nas001:~$ sudo aptitude install smartmontools

Probamos que todo esta bien instalado, preguntándole por la información de un disco:

nas001@nas001:~$ sudo smartctl -i /dev/sdb
smartctl version 5.37 [x86_64-unknown-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Barracuda 7200.9 family
Device Model:     ST3500641AS
Serial Number:    3PM0ELSV
Firmware Version: 3.AAE
User Capacity:    500,107,862,016 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Wed May 12 11:29:08 2010 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Como habéis comprobado, en ningún momento he tenido que desmontar el disco, ya que esto se puede usar mientras tu servidor sigue funcionando normalmente, y en teoría no afecta para nada al rendimiento del disco. Ahora realicemos un test rápido:

nas001@nas001:~$ sudo smartctl -H /dev/sdb
smartctl version 5.37 [x86_64-unknown-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Mira la linea final: “PASSED“, nos indica que parece que el disco esta bien. Pero no nos da mucha mas información.

Para que nos muestre la información SMART que hay en el disco, solo hay que hacer lo siguiente:

nas001@nas001:~$ sudo smartctl -A /dev/sdb
smartctl version 5.37 [x86_64-unknown-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   107   083   006    Pre-fail  Always       -       174790252
  3 Spin_Up_Time            0x0003   097   097   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       81
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   084   060   030    Pre-fail  Always       -       299958621
  9 Power_On_Hours          0x0032   070   070   000    Old_age   Always       -       26403
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       93
187 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0
189 Unknown_Attribute       0x003a   100   100   000    Old_age   Always       -       0
190 Temperature_Celsius     0x0022   054   047   045    Old_age   Always       -       791543854
194 Temperature_Celsius     0x0022   046   053   000    Old_age   Always       -       46 (Lifetime Min/Max 0/19)
195 Hardware_ECC_Recovered  0x001a   053   048   000    Old_age   Always       -       56032012
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   001   000    Old_age   Always       -       4010
200 Multi_Zone_Error_Rate   0x0000   100   253   000    Old_age   Offline      -       0
202 TA_Increase_Count       0x0032   100   253   000    Old_age   Always       -       0

Aun así, si queremos hacer un test mucho mas profundo, tendremos que lanzarlo con el siguiente comando:

nas001@nas001:~$ sudo smartctl -t long /dev/sdh

¿Pero donde estan los resultados?, pues como lees al lanzarlo, te dice el tiempo que va a tardar (en mi caso ponía unos 225 minutos), y los resultados quedaran almacenados y consultables con el siguiente comando:

nas001@nas001:~$ sudo smartctl -a /dev/sda
smartctl version 5.37 [x86_64-unknown-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

# Mucha información que entenderemos... xD

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Self-test routine in progress 10%      5311         -

Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Este comando nos muestra mucha información, pero al final vienen las lineas donde nos muestra como va nuestro test, en este caso sigue en progreso, al 10%.

Otra utilidad muy interesante es conocer los errores pasados de nuestro disco, con el comando:

nas001@nas001:~$ sudo smartctl -l error /dev/sda

Pero pensaréis: vaya coñazo, ¿esto no se puede hacer automático?. Pues claro, nos ha instalado un demonio que podremos activar para que nos envie correos con los fallos que vaya encontrando y lance los test automáticamente. Vamos a “/etc/default/smartmontools” y descomentamos la línea:

start_smartd=yes

Ahora en “/etc/smartd.conf”, comentamos la línea activa y ponemos:

# Tantos como discos queremos monitorizar
# SATA (en caso de ser IDE quitar el parámetro "-d sat")
/dev/sda -d sat -S on -o on -a -I 194 -m informatica@miempresa.com
/dev/sdb -d sat -S on -o on -a -I 194 -m informatica@miempresa.com

Alehop. Ya tenemos un sistema de monitorización de discos.

Referencias:

Please follow and like us:

Como deshabilitar Clamav, si te de problemas, en Postfix

Cuando un servidor Postfix empieza a dar problemas, todos nos echamos a temblar, ya que es un servicio que tiene que funcionar como sea. En nuestro caso, y tras mirar los logs (/var/log/mail.info) nos dimos cuenta que nuestro ClamAV no funcionaba, por alguna extraña razón (… quizás 3 años sin actualizarlo xD), así que tuvimos que tomar una decisión rápida, que fue deshabilitarlo, hasta que podamos corregir todos los problemas.

Para deshabilitarlo, la forma más rápida en quitar Amavis-new del medio, ya que es el que se encarga de pasar por los filtros los correos y era quien devolvía el error al no encontrar el antivirus funcionando. Para esto sólo hay que comentar las siguientes líneas:

  • En “/etc/postfix/main.cf”:
    content_filter = amavis:[127.0.0.1]:10024
    receive_override_options = no_address_mappings
    
  • En “/etc/postfix/main.cf”:
    content_filter = amavis:[127.0.0.1]:10024
    receive_override_options = no_address_mappings
    
  • En “/etc/postfix/master.cf”:
    #amavis unix - - - - 2 smtp
    # -o smtp_data_done_timeout=1200
    # -o smtp_send_xforward_command=yes
    #127.0.0.1:10025 inet n - - - - smtpd
    # -o content_filter=
    # -o local_recipient_maps=
    # -o relay_recipient_maps=
    # -o smtpd_restriction_classes=
    # -o smtpd_client_restrictions=
    # -o smtpd_helo_restrictions=
    # -o smtpd_sender_restrictions=
    # -o smtpd_recipient_restrictions=permit_mynetworks,rej ect
    # -o mynetworks=127.0.0.0/8
    # -o strict_rfc821_envelopes=yes
    # -o receive_override_options=no_unknown_recipient_chec ks,no_header_body_checks
    # -o smtpd_bind_address=127.0.0.1
    
  • Terminado esto, reiniciamos el Postfix.
  • Y ahora hacemos que todo vuelva a “reencolarse” para que no se quede pendiente en la cola de mensajes de Postfix
    postsuper -r ALL
    

Y rezamos porque todo vaya bien 🙂

Please follow and like us:

Migrar una empresa a Software Libre, ¿es posible?

Antes de nada, una aclaración: Este artículo, no es una guía con verdades fundamentales, solamente son unas breves notas sobre todo lo aprendido a lo largo de mi experiencia tratando de ir migrando al software libre los servicios que ofrecemos internamente y luego externamente en mi actual empresa (a lo largo de unos cinco años). Existen puntos que son cosas muy obvias para algunos, pero que para otros puede costar entender, por eso lo incluyo.

Si tuviera que dar una respuesta rápida, sería: tal vez. Depende de las decisiones que tomes. Y en este post voy a ir tratando de darte consejos que he aprendido a lo largo de los años, y espero que te ayuden a lograr tal empresa, que es muy titánica, te lo aseguro.

Logo linuxImaginemos un escenario demasiado recurrente. Un nuevo informático, entra en una empresa que no tiene nada que ver con la informática (pero muy dependiente de la tecnología), donde los usuarios suelen ser personas alejadas del mundo informático salvo por sus tareas diarias, y solo quieren que todo funcione.
En esta empresa se encuentra con el clásico panorama: Una red completa de Microsoft, donde todo tiene instalado un Windows XP, mal administrada, y encima abandonada a su suerte en cuanto al crecimiento de necesidades. Sin darse cuenta, este nuevo informático, se marca como objetivo mejorar dicha infraestructura pero intentando no hacer nunca mucho ruido, ofrecer nuevas funcionalidades a los usuarios y siempre sin gastar un duro, en licencias y posiblemente en hardware. Pero, ¿como se puede hacer esto?.

Si tuviera que destacar algo que he aprendido a fuego a lo largo de los años es que no se puede imponer, si no que hay que convencer al usuario, y si no es posible… se puede ocultar al usuario. Parece una frase muy extraña y malvada, digna de cualquier BOFH, pero me explicaré mas adelante para ver que es mucho más inofensiva de lo que parece. Ahora os voy a exponer mi resumen mental de todo lo que he vivido:

  • Windows/Mac no es un enemigo. No lo trates como tal. No tiene que ser erradicado de tu red, simplemente hay opciones mucho mejores y mucho más “baratas” a largo plazo. Ese es el mensaje que tienes que trasmitir, ya que si no, la gente pensará que haces las cosas porqué eres un miembro de alguna secta “informática”.
  • Nunca vendas el software libre como algo “gratuito”. Aunque parezca algo increíble, hay gente que se resiste a admitir que algo gratis puede tener la calidad de algo que se paga. Es asombroso la cantidad de gente que aun mantiene esa idea en sus cabezas. De hecho, no es cierto que el software libre sea gratis, ya que tendrás que aprender a montar correctamente las cosas, y eso cuesta dinero (es decir, tu tiempo).
  • La resistencia al cambio siempre es tu peor enemigo. Durante mis años de estudiante, un concepto que me parecía ridículo al estudiar “Ingeniería del Software” era la resistencia al cambio, ¿cómo alguien se puede negar a mejorar?… Eso pensaba, hasta que me encontré la resistencia al cambio frente a mis narices. Si algo funciona, nadie quiere cambiarlo. Si no funciona bien, pero con ciertos pasos medio funciona, la gente seguirá usando esos pasos. La palabra “cambio” no gusta, tendremos que evitarla.
  • Eres informático, no eres de fiar. Por norma general, tus motivos no son lo suficientemente válidos por si mismos. Una frase típica es: “Es que a los informáticos os gusta hacer las cosas difíciles y cambiar todo“. No trates de imponer tus razones, aunque sean correctas.
  • No trates de cambiar algo implantado. De hecho esta frase usa la palabra maldita “cambio”. Si tu empresa tiene un IIS con una web desde hace 3 años, y funciona, simplemente es bueno dejarlo. Esto tiene relación con el primer punto, ya que tienes que mantener todo y hacerlo convivir con tus nuevos sistemas o servicios.
  • Mezclar filosofías es una solución perfectamente válida. No es un sacrilegio usar Apache sobre Windows, o Filezilla como servidor de FTP sobre un viejo XP. Es parte de la transición.
  • Permite excepciones. No siempre todo se puede migrar, o no con la sencillez que todos quisiéramos. Por ejemplo la integración de Windows Mobile con Outlook o de iPhone con Mac. Quizás sea mejor dejarlo como está.
  • Tú eres tu mejor cliente. Todo puede comenzar instalando un pequeño servidor, para tus necesidades propias de un departamento informático, luego ir explorando soluciones, según las necesidades que se te presenten. No trates de buscar necesidades donde no las hay frente a tus usuarios finales, si no necesitan tal cosa/servicio (es decir, no te lo han pedido, ya que puede que simplemente no sepan que existe la posibilidad) no trates de crear la necesidad, no suele funcionar.
  • Aprovecha las oportunidades. Cuando se requiera algo nuevo (una nueva necesidad), es un buen momento de ofrecer la solución libre como alternativa a lo que todo el mundo esta pensando (Windows). Normalmente, si tratas el tema económico (más barato ya que no tiene licencias, menores requerimientos de máquina, …) suelen ser argumentos de peso.
  • Conoce las posibilidades que ofrece el software libre. Esto es muy importante. Cuando se te pida un servidor web, si no te piden uno en concreto, busca el que mejor se adapte a tus necesidades. No sólo existe Apache, ni Debian, ni MySQL. Lee y aprende las miles de posibilidades que podemos usar. Por ejemplo soluciones como eBox, OpenFiler, Mantis, Cacti, Subversion, GeoServer, Samba, Likewise, etc… son cosas que se pueden usar en casi cualquier empresa.
  • Implanta, en paralelo. Si vas a quitar un sistema antiguo, nunca desenchufes el anterior. Simplemente hazlo en paralelo mientras todo el mundo usa el anterior sistema.
  • Si puedes dejar al usuario final en la oscuridad, mejor. Ser totalmente transparente es una gran medida, trata de evitar por todos los medios que un usuario tenga que hacer algo para realizar un cambio. Si puede usar un proxy transparente, mucho mejor que tener que configurar en cada usuario un proxy.
  • Si necesitamos un cambio, busca un “grupo de valientes” que difunda la buena nueva. Por ejemplo, un ejemplo real en mi empresa, fue la transición de Outlook express a Thunderbird. No voy a contar las innumerables mejoras que tiene Thunderbird sobre Outlook (sobre todo al recuperarse de errores), pero un usuario final no entendería estos motivos. El método fue ir instalando el cliente de correo a un grupo de valientes convencidos, estos a su vez fueron portavoces del cambio, y poco a poco la gente fue más receptiva al cambio ya que “fulanito” dice que funciona muy bien (no un informático).

Como reflexión final, decir que, personalmente, soy un defensor de Software Libre, porque me ha demostrado que puedo confiar en él. Uno de mis primeros proyectos con software libre fue un proxy/balanceador de carga que lleva 5 años funcionando sin tocarse para casi nada, y en cambio, no creo que ninguna máquina Windows lleva 5 años instalada. Luego vino el cambio de Oracle a bases de datos como MySQL y PostgreSQL. Más tarde un servidor de ficheros montando con Samba… y sinceramente, en ningún momento me he arrepentido de ningún cambio hacia el software libre.

http://subversion.tigris.org/
Please follow and like us:

Geoserver en entorno de producción (III): Configurando PostgreSQL y PostGIS [Mejorado]

No, no habéis vuelto al pasado. Rectificar es de sabios, y más aún cuando mejoras lo dicho. Y este post es exactamente esto, una corrección y una mejora a mi explicación de como instalar una base de datos libre espacial.

Tras empezar a meter datos en mi máquina con PostgreSQL y PostGIS, siguiendo el primer manual que os dejé, me he dado cuenta que esto no funcionaba muy bien, ya que inicialmente no se instalaba PostGIS hasta que no lanzaras un archivo SQL, y luego, fallaba al devolver algunos objetos vectoriales. Recordemos que todo estaba montado con los paquetes estándar de Ubuntu 9.10.

Bueno, tras leer, me di cuenta que la gente recomienda la versión 8.4 de PostgreSQL y la 1.4+ para PostGIS. Pero hay un problema muy gordo, ya que no hay paquete PostGIS para esta versión de PostgreSQL en los repositorio oficiales de Ubuntu. Maldita sea, toca recompilar.

Me mentalizo, tengo que coger el código fuente, y ponerme a compilar, pero por desgracia, la versión actual, 1.5, de PostGIS, tiene unas dependencias que no puedo cumplir (Ubuntu no tiene aún las librerias libgeos-3.1.1, si no las 3.1.0, para mi versión de Ubuntu) con librerías estables liberadas, por lo que usaré la versión 1.4.2, pero en cuanto salga esta versión de las librerías ya podré usar la 1.5 siguiendo este mismo manual.

  1. Empecemos, instalando la versión 8.4 de PostgreSQL:
    sudo aptitude install postgresql-8.4
    
  2. Volvemos a configurar el servidor PostgreSQL, siguiendo el antiguo manual, para darnos acceso remoto.
  3. Ahora nos instalamos unas cuantas librerías que necesitaremos más adelante:
    sudo apt-get install proj-bin libproj-dev gdal-bin postgresql-server-dev-8.4 libgdal-dev libgeos-dev build-essential
    # Esto puede tardar un poco... tómate un café...
    

    Ahora ya tenemos todas las herramientas necesarias.

  4. Como recomendación personal, os recomiendo instalar, opcionalmente el paquete “checkinstall” ya que nos permite crear un archivo .deb, desinstalable mediante “aptitude”, a partir de un ejecutable con su código fuente. Para obtenerlo ponemos:
    sudo apt-get install checkinstall
    
  5. Pasamos a bajar el código fuente de PostGIS de su web oficial. Os recuerdo que yo uso la versión 1.4.2, ya que no tengo ciertas librerías aun disponibles en la versión 9.10 (al menos en su versión estable), pero que si tienes una versión más antigua o la LTS, están portadas en esta web en su versión estable. Recordemos que vamos a instalar un servidor en producción y que la estabilidad es fundamental.
    sudo wget http://postgis.refractions.net/download/postgis-1.4.2.tar.gz
    sudo tar xvzf postgis-1.4.2.tar.gz
    cd postgis-1.4.2
    sudo ./configure
    sudo make
    sudo checkinstall -D
    # Le ponemos un nombre al paquete
    # que es como aparecerá en el listado
    # de "aptitude search"
    # y confirmamos
    
    # Solo en el caso que no hayas instalado 
    # el programa "checkinstall"
    sudo make install
    

    Rezamos porque no haya ningún problema de dependencias ni librerías, aunque en Ubuntu 9.10 no tuve ninguna.

  6. Pero tenemos un problema, ya que si usamos PgAdmin, nos damos cuenta que no hay ningún template (plantilla) creado para postgis. Si usas Windows, esta se crea al instalar PostGIS pero en linux se complica un poco. Sin esta plantilla, cada vez que se crea una nueva base de datos, tenemos que lanzarle varios SQL para incluir toda funcionalidad espacial, y dar permisos a ciertas columnas. Pero si tenemos la plantilla, solo tenemos que elegirla en el momento de la creación para tener todo esto.
    Vamos a crear la plantilla:

    sudo su postgres # Cambiamos al usuario de mantenimiento de PostgreSQL
    createdb -E UTF8 template_postgis # Creamos la base de datos
    createlang -d template_postgis plpgsql
    #
    psql -d postgres -c "UPDATE pg_database SET datistemplate='true' WHERE datname='template_postgis';" # La hago visible para su uso
    # Es importante remarcar que el fichero lwpostgis.sql ha cambiado de nombre a postgis.sql
    psql -d template_postgis -f /usr/share/postgresql/8.4/contrib/postgis.sql # Creo todas las funciones/tablas para habilitar todo
    psql -d template_postgis -f /usr/share/postgresql/8.4/contrib/spatial_ref_sys.sql
    #
    psql -d template_postgis -c "GRANT ALL ON geometry_columns TO PUBLIC;" # Acceso a todo el mundo
    psql -d template_postgis -c "GRANT ALL ON spatial_ref_sys TO PUBLIC;"
    # La dejamos fija ante cambios
    VACUUM FREEZE;
    

    Si todo ha ido bien, ahora al crear una base de datos nueva, veremos esto:

    Al crear una nueva base de datos, tendremos acceso a la nueva plantilla

    Al crear una nueva base de datos, tendremos acceso a la nueva plantilla

  7. Incluimos el “adminpack” como te expliqué en el antiguo manual.
  8. Para testar que todo ha ido bien, desde PgAdmin, abrimos una consulta SQL y escribimos esto:
    select postgis_lib_version();
    

    Y veremos algo así:

    Versión de PostGIS mediante SQL

    Versión de PostGIS mediante SQL

Como siempre, de donde he leido toda la información que os condenso en este post:

Please follow and like us:

Geoserver en entorno de producción (IV): Habilitando GDAL y su soporte para formatos

Esto se está haciendo eterno, pero desde luego esta costando mucho lograr todo lo que me he propuesto. En este caso, me voy a centrar en ampliar los tipos de datos que va a aceptar nuestro servidor de mapas. Y esto me ha dado dos días de guerra. Os recuerdo mi configuración: Ubuntu 9.10 Server, Geoserver 2.0.1 y Tomcat 6. También os recuerdo que si queréis empezar con una instalación limpia, hay 3 manuales anteriores que encontraréis más abajo.

En este caso, vamos a instalar las librerías necesarias para que nuestro Geoserver sea capaz de leer formatos soporta la librería GDAL, entre los que están ECW, MrSID, EHdr, DTED, rasters de ERDAS,  etc…

Importante: Por desgracia, en esta ampliación tendremos un problema con las licencias para utilizar ECW en nuestro servidor, ya que para usarlo hay que usar unas librerías de ERDAS bastante restrictivas, y tendremos que tener un licencia (obviamente de pago, es decir, comprada) para usarlo sin romper la licencia de sus librerías, que no permiten su uso libre en servidores de mapas de terceros. En este tutorial se explica como activar el soporte para ECW, pero contamos con que se tienen las licencias compradas de antemano.

Manos a la obra, empecemos por el principio:

  1. En versiones antiguas de Geoserver hay que instalar un plugin dentro del directorio “WEB_INF/lib” de Geoserver, el cual puedes encontrar aún, en la página de descargas de Geoserver, en el apartado “Extensions>GDAL“. En la versión 2.0.1, ya viene de serie, por lo que no hace falta hacer nada.

Bajar las librerías nativas de GDAL del proyecto “ImageIO-ext” en esta dirección, no tengo que decirte que busques la versión más moderna y para tu sistema operativo, bájate las “native-libraries“. Estas librerías son totalmente independientes de las que tengas instaladas en tu equipo. Es decir, si hay tenias GDAL instalado vía apt/aptitude o porque tu te las instalaras a mano, no interfieren con estas.

Actualización 10-08-21: De nuevo, las cosas han cambiado, ya que como todos sabemos, Java ahora pertenece al eje del mal, es decir Oracle. Y como no, ha tenido que cambiar todo de sitio. Las nuevas direcciones para encontrar las cosas son:

Todas estas librerías son para el GDAL 1.7.3, el cual es el que esta disponible en los repositorios de Ubuntu, en caso de no tenerlo, no se si funcionará, aunque imagino que tendrás que instalarlo a mano para desgracia de nuestros nervios.
cd /usr/lib/
sudo wget https://imageio-ext.dev.java.net/files/documents/7505/144611/imageio-ext-1.0.5-linux32-mrsid-ecw-lib.tar.gz
sudo tar -zxvf ./imageio-ext-1.0.5-linux32-mrsid-ecw-lib.tar.gz
./
./libNCSCnet.so
./libNCSEcwC.so.0.0.0
./libNCSCnet.so.0
./gdalinfo
./libNCSUtil.so.0.0.0
./libNCSCnet.so.0.0.0
./libgdal.so.1
./libNCSEcw.so.0.0.0
./libNCSUtil.so.0
./libgdal.so
./libNCSEcwC.so.0
./libosrjni.so
./libNCSUtil.so
./libNCSEcw.so.0
./libNCSEcw.so
./libNCSEcwC.so
./libgdalconstjni.so
./libgdaljni.so
./libogrjni.so
./libgdal.so.1.11.4

Como habrás notado, he bajado la versión con soporte ECW (solo para probar que funciona), y lo he instalado en la carpeta “/usr/lib”. Si miras los manuales de referencia, todos te dicen que estas librerías puedes instalarlas donde te de la gana y luego fijar una variable de entorno “LD_LIBRARY_PATH” a la ruta para que todo funcione. En mi caso, esto no funcionaba, y la única manera de lograr que funcionara, era instalando estas librerías aquí.

Esto es importante, ya que no tengo muy claro donde se tiene que instalar las librerías nativas del GDAL (en serio, es un follón). Ahora mismo si no las descomprimo tambien en; “/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/amd64” (es decir, en el directorio de mi versión por defecto de Java, y con la arquitectura, en 64 bits en mi caso, pero podría ser en i386 también), no me funciona. Simplemente trata de descomprimir en el directorio JAVA primero, y luego intenta en el directorio de librerías.

  1. Bajar los datos para la GDAL. Este fichero contiene definiciones de proyección y datos que se necesitan para usar esta librería, esta puedes instalarla donde quieras para luego fijar la variable de entorno “GDAL_DATA” para que GDAL sepa encontrarlas.
    cd /usr/share/gdal-data/
    sudo wget https://imageio-ext.dev.java.net/files/documents/7505/137749/gdal_data-1.4.5.zip
    sudo unzip -o ./gdal_data-1.4.5.zip
    

    Ahora editamos el fichero “/etc/profiles” y añadimos la siguiente línea:

    export GDAL_DATA=/usr/share/gdal-data
    

    Y ya hemos instalado todo.

    Actualización 2-11-10: Según he aprendido a lo largo de mis andaduras con linux, el mejor sitio para poner las exportaciones de variables de entorno es en el fichero “/etc/environment“.

  2. Tendremos que reiniciar Tomcat, por seguridad de que refresque y ver reflejados los cambios. En alguna ocasión solo con recargar el Geoserver desde el “manager” de Tomcat me ha valido, pero no lo puedo asegurar.
  3. Ahora entramos en el interfaz Web de Geoserver, que usualmente está instalado en: http://tuservidor:8080/geoserver, y en el apartado “Almacenes de datos” pulsamos “Agregar nuevo almacén”, y tendremos que ver una lista parecida a esta:

    Formatos soportados tras instalar la extensión de GDAL

    Formatos soportados tras instalar la extensión de GDAL

  4. Importante: Parece que están surgiendo problemas con estas librerías y Tomcat, y puedes leer como “arreglarlo” en el siguiente post. Para saber si te ocurre, sólo tienes que tratar de crear un almacén con cualquiera de los nuevos tipos que han aparecido y te saldrá un error. No es muy complicado de arreglar pero asusta 🙂

Como siempre, aquí tienes todas las referencias, de donde he sacado sabiduría:

Please follow and like us:

Geoserver en entorno de producción (III): Configurando PostgreSQL y PostGIS

Después de las dos partes iniciales (I y II) sobre como estoy instalando un servidor Geoserver, dentro de mi organización con miras a que funcione en producción, hoy nos centramos en una de las optimizaciones más mas importantes, y que es la utilización de una base de datos espacial.

Antes de nada, una nota: Existen configuraciones mucho más seguras que la que yo os describo, con usuarios con permisos muy limitados, usuarios de sistema, etc… pero este documento sólo trata de mostrar una configuración rápida de la que partir, y posteriormente ir afinando. No quiero críticas a ese respecto 😛

Este tipo de base de datos, espaciales, nos permite almacenar dentro de su contenido puntos, líneas y polígonos, así como funciones que nos permitan realizar consultas espaciales, es decir, almacenar cartografía dentro de la base y poder hacerle consultas preguntando por coordenadas, pero sólo nos permitirá almacenar datos vectoriales. Con esto, obtendremos todas las mejoras que tiene una base de datos en cuanto a velocidad, pero también ciertas complicaciones “extra”, como son su configuración correcta en nuestra arquitectura. Además hay otro problema: las bases de datos más utilizadas no traen de “serie” esta funcionalidad y se tendrá que que instalar como un añadido o plugins.

Dentro del software libre, cabe destacar la unión de la base de datos PostgreSQL y PostGIS (el cual es su extensión para obtener las funciones espaciales). Pues manos a la obra:

  1. Instalamos PostgreSQL+PostGIS, pero usando cierto “truco” para no tener problemas de versiones. En mi caso, estoy usando Ubuntu 9.10, el cual tiene un paquete para ambas partes, pero por desgracia, PostGIS solo se instala en PostgreSQL 8.3, mientras que el paquete PostgreSQL es el 8.4. Entonces, instalamos PostGIS, y le permitimos que instale correctamente todas las dependencias (es recomendable usar aptitude en vez de apt)
    linux@svrmapas:~$ sudo aptitude search postgis
    p   libpostgis-java                                                                  - geographic objects support for PostgreSQL -- JDBC support
    c   postgis                                                                          - geographic objects support for PostgreSQL -- common files
    p   postgresql-8.3-postgis                                                           - geographic objects support for PostgreSQL 8.3
    linux@svrmapas:~$ sudo aptitude install postgresql-8.3-postgis
    Leyendo lista de paquetes... Hecho
    Creando árbol de dependencias
    Leyendo la información de estado... Hecho
    Leyendo la información de estado extendido
    Inicializando el estado de los paquetes... Hecho
    Se instalarán los siguiente paquetes NUEVOS:
      libgeos-3.1.0{a} libgeos-c1{a} libproj0{a} postgis{a} postgresql-8.3{a} postgresql-8.3-postgis postgresql-client-8.3{a} postgresql-client-common{a} postgresql-common{a}
      proj-data{a}
    0 paquetes actualizados, 10 nuevos instalados, 0 para eliminar y 0 sin actualizar.
    Necesito descargar 11,2MB/11,4MB de archivos. Después de desempaquetar se usarán 31,2MB.
    ¿Quiere continuar? [Y/n/?]
    

    Como puedes ver, fuerza a instalar la PostgreSQL 8.3, tal y como queremos.

  2. Configurar el acceso remoto al motor de la base de datos, y no nos queda mas que cacharrear en los ficheros de configuración para darnos acceso a nuestro equipo para usarlo remotamente. Este acceso remoto, puede aprovecharse con programas como “pgAdmin” que nos permite manejar la base de datos desde tu ordenador, aunque su uso escapa del tema principal de este tutorial.
    En el fichero “/etc/postgresql/8.3/main/postgresql.conf” (ojo, mira que tengo puesta mi versión de la base, en tu caso saldrá el de la tuya) edita lo siguiente:

    # Te encontrarás esto
    #listen_addresses = 'localhost'
    # Pondrás esto:
    # Acceso por todas las ips configurados
    listen_addresses = '*'
    # O por una en particular... usa una de las dos
    listen_addresses = '192.160.0.1'
    

    Tambien cambiamos la siguiente línea:

    # Esto
    #password_encryption = on
    # por esto
    password_encryption = on
    

    Ahora en el fichero “/etc/postgresql/8.2/main/pg_hba.conf” hacemos un par de cambios,  para poder acceder vía usuario/password remotamente. Sólo añadiendo esto al final:

    # IPv4 conexiones dentro de su misma red
    host    all         all         192.168.1.0/24      md5
    

    Es muy interesante estudiar un poco este tema, ya que se pueden configurar varios métodos de acceso dependiendo de la ip que se conecte al servidor, como por ejemplo, una ip que no tenga usuario ni password, o solo usuario, etc… Este tema lo puede leer en mayor profundidad en este link.

    Ya está, y tras esto, recargamos el servicio:

    sudo /etc/init.d/postgresql-8.3 reload
    

    Si todo va bien, podrás acceder desde tu ordenador tranquilamente sin tener que estar delante del ordenador.

  3. En este punto, tendrías que decirme:

    ¡¡¡Esto no funciona!!!, ya que pgAdmin me pide usuario y password
    .

    Bueno, es un pequeño detalle :). Por defecto el usuario es “postgres”, el cual también ha sido creado como usuario local de la máquina linux (una buena idea, un usuario sólo para las tareas administrativas), pero ahora vamos a fijar su password dentro de la base de datos:

    # Ejecutamos el shell de psql como el usuario "postgres"
    sudo -u postgres psql postgres
    # Dentro del shell de psql
    \password postgres
    # Tecleamos el nuevo password
    

    Con esto, acabamos de fijar el usuario y password que vamos a usar remotamente.

  4. Instalación del “Admin Pack”. Esto no es más que funciones para administrar la base remotamente, y que se pueden instalar de dos manera. Antes de nada instalar lo siguiente:
    sudo aptitude install postgresql-contrib-8.3
    

    De manera local, se tiene que hacer con un usuario que no requiera de password, en este caso primero cambio al usuario “postgres” que nos permitirá realizarlo sin password en la configuración por defecto de la base de datos:

    sudo su postgres
    postgres@svrmapas:/home$ psql -U postgres -d postgres < /usr/share/postgresql/8.3/contrib/adminpack.sql
    

    De manera remota, es muy sencillo, te bajas las librerías que necesitas desde el código fuente de PostgreSQL, en tu ordenador claro, y las lanzas desde pgAdmin. Y todo funcionará tal y como lo hace en local.

En siguientes “entregas” comentaremos como enlaza todo esto con Geoserver, y como almacenar tus capas vectoriales dentro de esta base de datos… pero todo más adelante y con paciencia 🙂

Y como siempre, os dejo la lista de referencias que he consultado para realizar este pequeño “tutorial”.

Please follow and like us: