Backup rápido entre máquinas con rsync

Aunque no voy a entrar en profundidad en el tema de como montar un servidor rsync, ya que hay muchos manuales y es muy sencillo de montar en un servidor Linux, os voy a dejar mi receta, rápida, para montar un backup de una máquina remota en otra mediante rsync y sin muchos problemas.

Esto lo suelo usar para replicar información importante que siempre necesita tener un backup idéntico. No hace copias incrementales, si no un espejo de lo que hay en un disco a otro. Si el usuario borra una carpeta, en el backup también se borrará. Pero hay scripts para hacer copias incrementales con rsync por internet… no tardarás en encontrarlos.

Partimos que tenemos una máquina con rsyncd configurado y funcionando, pues para hacer un backup rápido, solo hay que hacer:

rsync -Eavz --delete-after --stats --progress --password-file=/etc/rsync.pass /directorio/a/salvar/ rsync://rsync@megaNAS/CompartidoRsync/

Como verás he indicado un directorio donde se almacena el password para el servidor rsync remoto, que no es más que un fichero con el password en texto plano. Pero es importante que tenga los permisos solo para el usuario.

chmod 600 /etc/rsync.pass

Se que lo ideal es montar un follón de certificados para que no te pida password, pero con un fichero nos ahorramos todos los problemas. Ahora metemos esta linea en el fichero de crontab… y ya está.

Please follow and like us:

Error “svn export failed” en WebSVN al hacer un tarball

Pero que complicado es esto… y desesperante. Lograr tener todo perfecto y sin ni una mancha 😛

Logo de WebSVNHoy vamos a luchar contra un “bug” (no se si se puede decir que sea culpa del script) de WebSVN en su rama 2.3.x. Si no conoces este software/script/web, es una pequeña página web que usa PHP, que permite acceder a un servidor Subversion desde una página web muy amigable. Este programa tiene la característica de hacer un zip/tar con el código fuente y bajarlo desde esta web… salvo si pones acentos en algún fichero. Entonces tendremos un bonito error que pondrá algo como:

svn export failed [...]

En ese momento piensas: “Seguro que es una chorrada de configuración de la web”. Mal, compañero, mal. Siguiendo una lógica deductiva busque si era un error de WebSVN, luego de Subversion, luego de Apache, luego de PHP y luego del sistema operativo. Obviamente, y como ocurre en estos casos, era un error en conjunto.

La causa, básicamente, es que Apache siempre arranca con las “locale” asignas a “C”, y obviamente, WebSVN lanza Subversion con dichas “locale” lo que hace que no sepa interpretar los caracteres acentuados y eñes (que están en UTF-8).

¿Como arreglarlo?, así de fácil o de complicado (como quieras verlo):

// Fichero websvn/include/setup.php
//
// Busca la línea 329 mas o menos, donde habrá algo del tipo:
setlocale(LC_ALL, '');
// Cambialo a:
setlocale(LC_ALL, 'es_ES.UTF-8');
// Añade esta línea
putenv('LC_ALL=es_ES.UTF-8');

Si no codificación de caracteres no es la misma, pues pon la que tenga tu equipo (ejecuta un “locale” en la consola).

Hecho.

Referencias:

Please follow and like us:

Instalando las vmware-tools en Ubuntu 10.04

Tener un servidor de máquinas virtuales es una gran idea, y instalar las “vmware-tools” es casi obligatorio, ya que no instalarlas sería un problema en cuanto rendimiento.

Sin duda todo parece muy facil,  ya que desde el interfaz web se pueden “instalar”. Bueno, realmente, sólo monta una iso como un CD, y tu lo instalas desde un tar.gz. Pero claro, no iba a funcionar, y te recomiendo que no pierdas el tiempo. Si quieres instalar estas herramientas ejecuta lo siguiente:

aptitude update
aptitude safe-upgrade
aptitude install open-vm-tools open-vm-dkms

Y dale un poco de tiempo. Y sin romperte la cabeza.

Actualización: Si utilizas una versión más moderna de Ubuntu (espero que sí), te recomiendo que uses este script que suelo usar en mis maquinas, y que te lo instala sin problemas, y con el fichero original de VMWare.

Please follow and like us:

Purgar la cola de impresión en el servidor de impresión de Windows 2003

Una tarea que puede ocurrir cuando centralizas en un servidor Windows 2003 todas las impresoras de un entorno corporativo es recibir una llamada de un usuario del tipo:

La impresora X no imprime, y por más que doy… ná. He reiniciado el ordenador 20 veces, le he rezado 20 avemarias al santo patrón de los BOFH, pero nada. ¡¡¡Arreglalo!!!.

Con resignación nos tocará levantarnos del sitio y tras descartar que el problema sea de la impresora, y ver que a la impresora no le llega nada de lo enviado (ese sería otro problema de no reproducirse este escenario que te cuento, luego busca en otro sitio: Este no es tu error), miramos con resignación a nuestro querido servidor de impresión.

Entramos en “Panel de control > Impresoras y faxes” o bien, mediante la pantalla de “Administre su servidor > Servidor de impresión“, allí miramos la impresora si tiene una impresión indestructible (si damos a cancelar y se queda eternamente “Eliminando…”). Si no queremos reiniciar el servidor, y de paso,no  dejar a los usuarios sin 20 minutos de servidor de impresión donde seguramente haya 3 personas con documentos que no pueden esperar ser imprimidos. La forma más rápida de solucionarlo puede ser esta (unos 2 minutos):

  1. Inicio > Herramientas Administrativas > Servicios“.
  2. Localizar “Cola de impresión” y pararla. No cierres esta ventana.
  3. Entra en “\WINDOWS\system32\spool\PRINTERS“. Puede que la ruta cambien un poco según donde tengas instalado el sistema operativo.
  4. Borra los ficheros *.SHD y *.SPL. Si no hay, comprueba que es allí donde se almacena la cola de impresión en el apartado de “Impresoras y Faxes > Archivo > Propiedades del servidor de impresión > Opciones Avanzadas > Carpeta de cola de impresión”. Si apunta a otra ruta, mira allí. Si tampoco están allí, este manual no te servirá para nada, lo siento.
  5. Vuelve a arrancar el servicio de “Cola de impresión”.
  6. Revisa que ya no hay documentos “enganchados” en la impresora.
  7. “Trabajito bien hecho, cigarrito pal pecho”.
Please follow and like us:

Openlayers, aplicando estilos propios a ArcGIS Server WMS

Una de funcionalidad muy interesante que nos ofrecen los servidores de mapas, con el protocolo “WMS” y mediante la petición “GetMap“, es poder aplicar nuestro propio “estilo” a las capas que nos ofrecen, solo suministrándole un archivo donde se detalla como cambiar el estilo visual de las capas que nos muestra mediante el estándar “Style Language Descriptor” o “SLD” para los amigos. Este estándar no deja de ser un “XML” con una estructura y etiquetas propias. No es muy complejo de entender. Además hay hasta editores para hacerte la vida mucho más sencilla escribiendo SLD, como este, que es totalmente visual.

Para que entendáis, que significa esto, si pedimos un capa a un servidor, de una cierta zona, podría devolvernos esto:

Capa antes de aplicar un estilo

Pero no nos gusta nada su presentación, y tras hacer un poco de magia, obtendríamos algo así:

Capa despues del estilo

Capa después de aplicar un estilo

Normalmente estos estilos están definidos en el servidor de mapas, y el usuario que consume dicho servicio le indica que estilo utilizar. Pero para completar un poco esta funcionalidad, se permitió que el usuario indique que estilo usar, dando en la petición una URL a un fichero de estilos, como por ejemplo:

http://servidor/GetMap?TRANSPARENT=true&LAYERS=RiverBasinDistrict&FORMAT=image%2Fpng&TILED=true&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A4326&BBOX=-1.69189453125,41.21172151054787,1.12060546875,43.29320031385282&WIDTH=256&HEIGHT=256&SLD=http://servidorPublico/misestilos.sld&STYLES=estilo

La parte en negrita, indica donde cambiamos el estilo, indicante el fichero de estilos, y el estilo a usar (que podría estar definido en dicho fichero o no). Si indicamos un estilo que no esta definido ni en el servidor ni en el fichero, obtendremos un bonito error, o obtendremos la capa con el estilo por defecto.

Existen grandes ejemplos para entender este capacidad, como por ejemplo esta web, donde se colorean los polígonos que representan los países según el nombre de dicho país. Bonito, y descriptivo.

Pero hay un problema, como casi con todos estos estándar. Cada uno lo implementa a su modo. Por ejemplo si vemos un fichero de estilo de un servidor de mapas “Geoserver”, este tiene una extensión “sld”, y una sintaxis muy relajada. ¿Pero y si trabajamos con ArcGIS Server WMS?, pues no es igual…

Ahora bien, tras esta larga introducción, no centramos en nuestro caso actual.

  • Openlayers, en mi caso, se uso la versión 2.7, con algunos retoques que no modificaban esta funcionalidad.
  • Servidor ArcGIS Server WMS sirviendo unas capas con un estilo horrible. Para estas pruebas, sólo se sabía que era ArcGIS, y aún no sabemos exactamente que versión exacta es.
  • Hojas de estilo sacadas de un servidor Geoserver en formato SLD. La hoja de estilos tiene que estar almacenada en un servidor web donde el servidor de mapas tenga acceso, es decir que si no está en tu red, tiene que estar en un servidor web conectado a internet.

Si tratas de incluir en OpenLayers el estilo, nos encontramos esto:

wms_1 = new OpenLayers.Layer.WMS( "Capa"
		,url_wms_GIS
		,{
		    transparent:'true',
		    layers: 'capa',
		    styles: 'estilopoligono',
		    sld: 'http://servidorPublico/poligono.sld',
		    format:'image/png',
		    tiled: 'true'
		},
		{
		    'reproject': true,
		    buffer: 0
		}
	);

Y nuestro fichero de estilo, el cual esta alojado en la URL “http://servidorPublico/poligono.sld”:

<?xml version="1.0" encoding="UTF-8"?>
<StyledLayerDescriptor version="1.0.0"
	xsi:schemaLocation="http://www.opengis.net/sld StyledLayerDescriptor.xsd"
	xmlns="http://www.opengis.net/sld" xmlns:ogc="http://www.opengis.net/ogc"
	xmlns:xlink="http://www.w3.org/1999/xlink"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<NamedLayer>
		<Name>capa</Name>
		<UserStyle>
			<Name>estilopoligono</Name>
			<Title>Estilo de un poligono</Title>
			<FeatureTypeStyle>
			<Rule>
				<PolygonSymbolizer>
					<Fill>
						<CssParameter name="fill">#995599</CssParameter>
						<CssParameter name="fill-opacity">0.3</CssParameter>
					</Fill>
					<Stroke>
						<CssParameter name="stroke">#000000</CssParameter>
						<CssParameter name="stroke-opacity">1</CssParameter>
					</Stroke>
				</PolygonSymbolizer>
			</Rule>
			</FeatureTypeStyle>
		</UserStyle>
	</NamedLayer>
</StyledLayerDescriptor>

Como puedes leer, en el fichero “sld” he incluido el nombre de la capa, y el nombre del estilo, y tienen que concordar con los escritos en Openlayers.

Todo parece correcto, pero al usarlo contra el servidor ArcGIS Server… esto no funciona, sencillamente te dice que el tipo de estilo no esta definido. ¡Mi gozo en un pozo!.

Pero no todo esta perdido, tras mucho mirar, y releer, me doy cuenta de lo de siempre, ArcGIS tiene “peculiaridades”, y es muy estricto, aunque gracias a dios, todo se encuentra muy bien documentado en su página de ayuda. Hay que remarcar, que la extensión pasa a ser “.xml”, y que ahora todas las etiquetas tiene el prefijo “sld”, aunque respeta el resto del estándar.

Hacemos unos cambios y ya tenemos la nueva versión:

<?xml version="1.0" encoding="UTF-8"?>
<sld:StyledLayerDescriptor version="1.0.0" xmlns="http://www.opengis.net/ogc" xmlns:sld="http://www.opengis.net/sld" xmlns:ogc="http://www.opengis.net/ogc" xmlns:gml="http://www.opengis.net/gml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd">
	<sld:NamedLayer>
		<sld:Name>capa</sld:Name>
		<sld:UserStyle>
			<sld:Name>estilopoligono</sld:Name>
			<sld:Title>Estilo de un poligono</sld:Title>
			<sld:FeatureTypeStyle>
				<sld:Rule>
					<sld:PolygonSymbolizer>
						<sld:Fill>
							<sld:CssParameter name="fill">#995599</sld:CssParameter>
							<sld:CssParameter name="fill-opacity">0.2</sld:CssParameter>
						</sld:Fill>
						<sld:Stroke>
							<sld:CssParameter name="stroke">#0000FF</sld:CssParameter>
							<sld:CssParameter name="stroke-opacity">1</sld:CssParameter>
							<sld:CssParameter name="stroke-width">1</sld:CssParameter>
						</sld:Stroke>
					</sld:PolygonSymbolizer>
				</sld:Rule>
			</sld:FeatureTypeStyle>
		</sld:UserStyle>
	</sld:NamedLayer>
</sld:StyledLayerDescriptor>

Y tras todo esto, ya podremos disfrutar de poder manejar el estilo con el que un servidor remoto nos sirva las imágenes de su cartografía.

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:

Registrar el nombre de un servidor en el DNS de Windows, mediante DHCP

Un problema clásico, cuando tenemos una nueva máquina linux “out-the-box” (recién instalada), es que cuando nuestra red funciona mediante Active Directory en Windows y con asignación de ips mediante DHCP, no podemos resolver su nombre, es decir, si hacemos ping al nombre de la máquina, esta no responde y necesitamos conocer su ip, lo que en una red con 12 o 13 servidores es un coñazo.

El problema suele residir, en que el cliente DHCP de linux (en mi caso uso Ubuntu) no se registra dentro del DNS correctamente, al recibir la cesión de la ip. Hay muchas preguntas en Internet sobre este tema, peticiones para que se añada esta opción directamente en la configuración por defecto. Y aunque por ahora no es así, no es difícil arreglarlo.

Tenemos que editar del fichero “/etc/dhcp3/dhclient.conf” y añadir las siguientes líneas a este fichero.

send fqdn.fqdn "nombre.dominio";
send fqdn.encoded off;
send fqdn.server-update on;

Como puedes ver, estamos mandando el nombre FQDN, para que el servidor DHCP sea capaz de añadirlo en la base del DNS para poder resolverlo correctamente. Ahora sólo nos queda volver a refrescar nuestra ip mediante el comando:

sudo dhclient3 eth0 -s servidorDHCP

Y ya podremos utilizar su nombre, en vez de la ip. Esperemos que os sirva de ayuda.

Please follow and like us:

Geoserver en entorno de producción (I): Instalación básica

Este post inicia un serie de otros post que vendrán más adelante, en los cuales voy a detallar como voy a diseñar e introducir un servidor de mapas ( en un entorno de producción. Esta guía trata de resumir todo lo que he investigado, a lo largo de unas semanas, para realizar todo lo mejor posible, y con el mayor rendimiento posible también.

En este post, sólo voy a instalar Geoserver y dejarlo funcionando como una aplicación de Tomcat. Nada más. En siguientes post, hablaremos de la arquitectura de red que plantearemos, las librerías que pueden mejorar el rendimiento, y como añadir alguna funcionalidad extra.

Para empezar, voy a explicar porqué elegimos Geoserver, entre tantos y tantos servidores de mapas. Aunque este servidor, esta desarrollado en Java, resulta ser bastante rápido, cuando se configura correctamente, plantando cara a Mapserver, que se encuentra desarrollado en C++ (se pueden ver muchas comparativas sobre estos dos servidores de mapas), y además esta avanzando a pasos agigantados versión tras versión. Es (como no) software libre, con una gran comunidad detrás, que suelen dar soluciones a todos los problemas encontrados. Aparte de ser “relativamente sencillo” su manejo.

En cuanto al sistema operativo, me decanto por un linux, en mi caso un “Ubuntu Server 9.10“, simplemente por costumbre, ya que se podría usar cualquier otra distribución de linux para hacer la implantación.

Bueno, manos a la obra. Os detallo los pasos a seguir, para realizar una instalación básica:

  1. Instalar “Java JDK“, primero comprobaremos que no está ya instalada (en mi caso ya está instalado el Java):
    linux@svrmapas:~$ dpkg --get-selections | grep sun-java
    sun-java6-bin                                   install
    sun-java6-jdk                                   install
    sun-java6-jre                                   install
    

    En caso de no tenerlo instalado, lo hacemos vía “apt“:

    sudo apt-get install sun-java6-jdk
    

    Actualización Ubuntu 10.04: Parece que con los problema que está habiendo con Oracle, y que demuestran que es el mal supremo (apreciación mía), se han movido los paquetes oficiales (que siguen llamándose “sun-java” curiosamente) a un repositorio externo que no viene por defecto. Así que tocará añadirlo en el fichero “/etc/apt/sources.list“, descomentando dos líneas que vienen comentadas por defecto:

    ## Uncomment the following two lines to add software from Canonical's
    ## 'partner' repository.
    ## This software is not part of Ubuntu, but is offered by Canonical and the
    ## respective vendors as a service to Ubuntu users.
    deb http://archive.canonical.com/ubuntu lucid partner
    deb-src http://archive.canonical.com/ubuntu lucid partner
    
    

    Recuerda lanzar un “update” de “apt-get” para reflejar los cambios

    Si todo ha ido bien, encontraras algo parecido a esto al teclear el siguiente comando:

    linux@svrmapas:~$ java -server -version
    java version "1.6.0_0"
    OpenJDK Runtime Environment (IcedTea6 1.6.1) (6b16-1.6.1-3ubuntu1)
    OpenJDK Client VM (build 14.0-b16, mixed mode, sharing)
    

    Si tienes cualquier otra salida a este comando, tienes que revisar tu instalación de Java ya que es muy importante para el rendimiento usar la versión de Sun más moderna posible.

  2. Ahora toca el Tomcat, y es muy recomendable usar el “Tomcat 6“, aunque creo que es el que se instala por defecto desde la “Ubuntu 9.04“.
    sudo apt-get install tomcat6 tomcat6-admin tomcat6-common tomcat6-user tomcat6-docs tomcat6-examples
    
  3. Tenemos Tomcat funcionando, solo nos queda configurar quien tiene acceso al “Gestor de aplicaciones” de Tomcat, mediante la ruta: “http://tuserver:8080/manager/html“. Si entras, te pedirá un usuario y una clave. ¿Pero si no me la han preguntado?. Tranquilo, ve al fichero “/etc/tomcat6/tomcat-users.xml“, editarlo como sigue:
    <tomcat-users>
      <role rolename="tomcat"/>
      <role rolename="role1"/>
      <role rolename="manager"/>
      <user username="tomcat" password="tomcat" roles="tomcat,manager"/>
      <user username="both" password="tomcat" roles="tomcat,role1"/>
      <user username="role1" password="tomcat" roles="role1"/>
    </tomcat-users>
    

    Hemos hecho lo siguiente, definir un nuevo rol, llamado “manager“, el cual es el necesario para manejar las aplicaciones instaladas, y luego al usuario genérico “tomcat” le hemos datos el rol de “manager“. Revisa que no este comentado (por defecto vienen comentados todos los usuarios), ya que si no, no hacemos nada.
    Muy importante: Esto que he hecho no es seguro, solo para comprobar que todo funciona, tendrías que crear un usuario/password seguros si vas a dar acceso a tu servidor a todo el mundo, una vez comprobado que todo funciona, ya que si no sería muy fácil que alguien “malo” adivine lo que has hecho y pueda acceder a este gestor… e imagino que no quieres que ocurra.

    Actualización Ubuntu 10.04: Algunos cambios surgidos en la versión de Tomcat que se instala, hacen más recomendable este fichero de configuración, que le da permisos a un usuario para manejar todo el tomcat sin problemas:

    <?xml version='1.0' encoding='utf-8'?>
    <tomcat-users>
      <role rolename="manager" />
      <role rolename="admin" />
      <user username="mi_usuario_administrador" password="password" roles="admin,manager" />
    </tomcat-users>
    
  4. Ahora reiniciamos el servidor Tomcat:
    sudo /etc/init.d/tomcat6 restart
    
  5. Ya podremos acceder al “manager“, con el usuario con el rol de “manager“, mediante la dirección: “http://tuserver:8080:/manager/html“. Ahora nos vamos a la web oficial de Geoserver y nos bajamos la versión “Web Archive“, como indica la siguiente captura de la web (cuando redacto esto, vamos por la versión 2.0.1):
    Descargar Geoserver
    Ya tenemos, el archivo “war” (te bajaras un .zip, mira dentro), y la intentamos desplegar (es decir, algo parecido a instalar) en nuestro servidor Tomcat, mediante el siguiente interfaz que nos sale por defecto en el  gestor de aplicaciones: Desplegar War
    Una vez hecho, solo nos queda buscar “geoserver” en el listado de aplicaciones, y dar a arrancar… y tras unos instantes: FALLO. Bueno, todo no podía ser tan sencillo, pero no os pongáis nerviosos, está controlado. El error que lanza el interfaz es algo así:

    FALLO – No se pudo arrancar la aplicación en trayectoria de contexto /geoserver

    Actualización Geoserver 2.0.2: Parece que todo esto ya es cosa del pasado, ya que se se despliega sin problemas, y sin dar mas permisos en Tomcat.

  6. El problema anterior, es un problema de permisos, ya que por razones desconocidas, Tomcat viene con los permisos muy recortados y Geoserver necesita prácticamente todos los permisos. Por lo tanto, nos vamos a “/etc/tomcat6/policy.d/04webapps.policy” y al final del fichero (justo antes de cerrar la llave) incluimos esta línea:
    permission java.security.AllPermission;
    

    Volvemos a reiniciar el Tomcat, y probamos de nuevo. No me voy a meter si esto es bueno o malo, si relaja mucho las políticas de seguridad… simplemente hace que funcione.
    Tras esto, al dar a arrancar a la aplicación, nos encontramos con:

    OK – Arrancada aplicación en trayectoria de contexto /geoserver

  7. Accedemos a la aplicación Geoserver, en “http://tuserver:8080/geoserver“. Cruza los dedos, y allí tendrás tu panel de administración de Geoserver.
Los siguientes pasos podrás leerlos en la siguiente entrada: Parte 2.

Referencias usadas:

Please follow and like us:

Como recuperar un Raid0 tras un fallo de disco en Ubuntu

Hoy me he enfrentado a este problema. Uno de nuestros servidores de respaldo (al menos no era un principal) ha muerto. Tras mirar que ocurría, sencillamente que el raid no existía, nos hemos dado cuenta de que un disco duro había pasado a mejor vida. Obviamente, al ser un Raid0 se pierde toda la información (por lo que hay que tener un respaldo, ya sea en otro equipo, o mediante otro raid), y en nuestro caso, este servidor era el respaldo de otro, por lo que simplemente hay que recuperarlo y volver a sincronizar con el principal.

Antes de nada, recordaros un gran blog que habla mucho sobre estos temas y muchos más, como es el blog de Iván López, que merece ser leído ya que ha hecho cosas muchos más complejas que esto, y del cual saco mucha información que vas a leer más adelante.

¿Como vimos el fallo?. La verdad que fue sencillo ya que tuvimos un apagón y el servidor no se recuperó bien, mediante el comando podemos ver el desastre:

more /proc/mdadm

Todos los discos que forman el raid se encuentran con una (S) a su lado (son discos spare) y falta uno. En nuestro caso, teniamos 7 discos, y solo salian 6.

sudo mount

Y nos encontramos que el raid no esta montado… bueno, toca buscar el disco duro roto. Un buen método es mirar el dmesg y ver cual da error, en nuestro caso no quedaba claro (la bios de la máquina marcaba el disco como conectado, pero luego linux no era capaz de mostrarlo), se fue desconectando uno a uno cada disco hasta que le encontramos. Se substituyo por uno de igual capacidad, ya que no es recomendable mezclar capacidades en Raid0.

Bien, pues substituimos el disco duro que esta averiado por el nuevo, pero este no está preparado para formar parte de un raid, por lo que lo conectamos y arrancamos la máquina (obviamente no montará el raid) y abrimos Gparted (en su defecto lo instalas). Le creas una nueva tabla de particiones, lo formateas a capacidad completa con el tipo de ficheros “sin formato”. Aplicamos y luego nos vamos al menú de “Partición > marcas” (no recuerdo exactamente como se dice en castellano, en ingles es “flags”, ya que mi servidor esta en inglés) y marcamos sólo “raid” de todas las opciones que nos aparecen. Aceptamos y el disco duro ya está preparado para ser parte de un raid.

Ahora tocaba eliminar todo rastro del antiguo raid, primero en los discos anteriores:

# Se tiene que parar o dará un error de que está en uso.
# Si se tienen dudas mirar en /proc/mdadm
sudo mdadm --stop /dev/md0
# Si incluyes el disco duro nuevo, este dará un error
#  no importará sigue adelante
sudo mdadm --zero-superbloc /dev/sd[a-g]1

Ya tenemos los discos impolutos y listos para volver a montar, pero antes hay que eliminar cualquier configuración de la existencia de raid en “/etc/mdadm/mdadm.conf” eliminando cualquier linea del tipo:

ARRAY /dev/md0 level=raid0 num-devices=7 UUID=1803e03e:db1868b2:d2508c3c:95c11b58

Aunque esto último no es obligatorio, ya que se va a reescribir unos pasos mas adelante, nos vendrá muy bien por si necesitamos un reinicio en la máquina, y así el sistema no tratará de montar de nuevo el raid con el fallo de disco.

Tras esto, ya podemos volver a crear nuestro raid:

sudo mdadm --create --auto=yes --verbose /dev/md0 --level=0 --raid-disks=7 /dev/sd[a-g]1

Ojo, que el parámetro auto del comando mdadm es muy interesante, ya que crea, si no existiera, el dispositivo md0, dentro del directorio “/dev“. Si has hecho un reinicio seguramente no tengas dicho dispositivo ya que se elimina si no esta en uso.

Bien, comprobamos que todo funciona, formateando la nueva partición:

sudo mkfs.ext3 -v /dev/md0

Con un simple:

sudo mount -a

remontamos el sistema de ficheros, y podemos acceder al raid. Perfecto.

Ahora queda el paso final, y es volver a crear el fichero /etc/mdadm/mdadm.conf:

cd /etc/mdadm
sudo cp mdadm.conf mdadm.conf.`date +%y%m%d`
sudo sh -c 'echo "DEVICE partitions" > ./mdadm.conf'
sudo sh -c 'mdadm --detail --scan >> ./mdadm.conf'

Testeamos que todo este bien:

more ./mdadm.conf
DEVICE partitions
ARRAY /dev/md0 level=raid0 num-devices=7 UUID=bed08171:06afc57d:9c8da9aa:858c4c7d

Y ahora solo queda sincronizar el contenido, en mi caso con un rsync que va a tardar al menos unas 6 horas en sincronizar mediante una gigalan directa entre servidores, pero puedes hacerlo como sea, como por ejemplo discos duros externos, y ya tu raid vuelve a funcionar tras el susto del fallo del disco.

Actualización: Aveces, si usamos en el fichero “/etc/mdadm/mdadm.conf” la linea “DEVICES partitions“, al reiniciar no funcionan correctamente los raid, y cuando se realiza un “mdadm –examine /dev/sdxx” nos encontramos que tienen un diferente UUID que no cuadra ni con el fichero “mdadm.conf“.

Para evitar esto, la única solución que he logrado, gracias a esta entrada de la web de Ubuntu-es, encontrar es eliminar la entrada de los “DEVICES” y poner en el fichero “mdadm.conf“:

# Obviamente pon los devices que use tu raid
ARRAY /dev/md0 level=raid0 num-devices=3 metadata=00.90 UUID=e1fbf1e6:da616113:e368bf24:bd0fce41 devices=/dev/sda2,/dev/sdb1,/dev/sdc1

Al añadir al final los “devices” los monta correctamente, y sin hacer cosas raras. Según leo, no es muy recomendable (no se porqué) pero hace que al menos en mis maquinas no falle.

Please follow and like us:

Plataforma eBox, todo en uno en servidores

Una de las tareas más tediosas de un administrador de sistemas, es siempre tener un buen proxy configurado y apunto para tu empresa. Y digo tediosa, porque resulta bastante “dura” si lo haces desde cero, es decir, un linux con un proxy (normalmente SQUID), con un firewall mediante iproute y iptables, y de paso algun filtro para webs y un buen antivirus para parar las guarrerias que te puedas encontrar en la red y tus “lusers” quieran meter dentro de tu amada red.

Si nos ponemos un poco serios, podriamos montar un servidor de correo, y claro, un buen sistema de monitorización. Y si ya tienes que dar acceso desde fuera pues una buena VPN sería algo necesario.

Bien. Todo esto se puede montar más o menos “a mano”, leyendo muchos manuales, acostumbrandote a tu shell, y a un buen editor de texto (nano rulez!), pero muchas veces te apetecería que todo fuera más sencillo.

En esto, que nuestro querido proxy con Debian, este viviendo malos momentos (si, es una edad, y aunque es un gran servidor, su corazon de Pentium 3 Xeon puede fallarnos en cualquier momento, o cualquier otra parte de su anatomía). Para tal empresa, indagando por la red, nos hemos encontrado con una solución que nos va a permitir migrar todo rapidamente a un nuevo servidor, y darnos algo mas de “sencillez” al asunto.

Se trata de eBox, un desarrollo español, el cual no es más que unos paquetes para Ubuntu (versión 8.04 LTS), que nos permite incluir toda la funcionalidad, con un buen interfaz web, y una comunidad por detrás que nos ayuda y mejora el producto. Tras instalarlo en una maquina de prueba, la verdad que tiene muy buena pinta, con muchas cosas que nos sobran (aunque esta dividido en paquetes para cada funcionalidad), creo que va a ser el gran cambio en el corazón de nuestra red. Nos falta meter mucha mano al sistema, ya que hay que adaptarlo a la locura que tenemos montada en mi empresa, pero al menos parece que el inicio es prometedor. Pero lo mas interesante es el roadmap que tienen planteado. Sobre todo el tema del failover entre servidores, que puede ser muy interesante en grandes compañias (y que trataré de ver como funciona).

La verdad que el interfaz es bastante bueno, aunque no permite toda la funcionalidad que una maquina linux puede ofrecer, por lo que en algún caso tienes que tirar de consola (nada grave). Incluye servidor proxy, de correo, firewall, vpn, monitorización, eGroupWare (para centralizar una agenda y un servidor de contactos… lo que es muy interesante), servidor de ficheros, antivirus,…

Muy buena idea si tienes que montar un proxy en tu oficina o en tu casa. Echarle un vistazo.

Please follow and like us: