Archivos de etiquetas: Windows

Errores de red con Windows 10 y Alfresco

Con la actualización de Windows 10 pueden volver algunos errores que en otras versiones y sistemas operativos ya estaban solucionadas.

Estos errores vienen derivados principalmente de las nuevas configuraciones de red implementadas en Windows, a partir de la versión 7 en realidad, y que en su versión 10 han sufrido un gran cambio.

Por ejemplo, una vez instalado Alfresco puede presentarse el siguiente error:

— log —
ERROR [sf.ehcache.Cache] [main] Unable to set localhost. This prevents creation of a GUID. Cause was: Mordor: Mordor
 java.net.UnknownHostException: Mordor: Mordor
at java.net.InetAddress.getLocalHost(Unknown Source)
at net.sf.ehcache.Cache.(Cache.java:155)
[…]
— log —

Si se realiza una investigación sobre este error se encuentran muchas páginas donde la solución es introducir la dirección IP 127.0.0.1 y el nombre del host o «hostname» en el fichero hosts, tanto en Linux, Windows y Mac OSX, pero esta solución ya no funciona en Windows, debido principalmente a dos cuestiones:
1. El uso de DNSSEC 
2. El uso de IPv6 sobre IPv4
Por lo tanto, para solucionarlo, no basta con poner nada en el fichero %SystemRoot%system32Driversetchosts, de hecho, no hace falta.
La solución es más sencilla que esto, hay que usar IPv4. Se puede hacer (tocando el registro de Windows) que la versión 4 tenga prevalencia sobre la versión 6 del TCP/IP, pero también, y creo que esto es mejor, se puede arrancar la máquina virtual de Java para que use la versión de TCP/IP que se necesita. El parámetro es: 
-Djava.net.preferIPv4Stack=true
Con este parámetro se solucionan los posibles errores de detección del host que es necesario para el arranque de Alfresco.
Además, hay que incluirlo también en otros sitios donde se utilicen descargas o llamadas a direcciones de Internet, como el caso de maven, eclipse, etc.
Por ejemplo, mi variable MAVEN_OPTS es la siguiente:
-Xms256m -Xmx1024m -XX:PermSize=320m -Xss1024k -Djava.net.preferIPv4Stack=true
Y que es la misma que tengo en la configuración de eclipse (Servers) para cada servidor de Tomcat y para cada llamada de maven.
Evidentemente hay que usar este parámetro también en el fichero eclipse.ini si se necesitan instalar plugins.

Enviar documentos a Alfresco de forma desantendida

En ocasiones necesitamos enviar a Alfresco documentos que han sido escaneados o generados por otras aplicaciones de forma automatizada.

La forma más común de «inyectar» documentos a Alfresco es mediante el uso del protocolo CIFS, de forma que podemos usar una unidad de red o recurso compartido (según el sistema operativo utilizado) para guardar el documento directamente en el entorno de Alfresco.

En ocasiones, bien porque el producto está limitado a usar unidades de red, o bien, porque necesitamos que los ficheros generados se envíen de alguna forma u orden y a una hora o espacio de tiempo determinado, hay que usar sistemas de copia o de movimiento de ficheros de forma desatendida.

En este caso, se ha utilizado un sistema utilizando el producto DigiDocFlow (http://www.digidocflow.com/) que en lugar de guardar el documento escaneado y el correspondiente fichero XML con los valores de los metadatos en el recurso de red del servidor donde está instalado Alfresco, se ha utilizado un directorio local de la máquina donde está instalado el producto (en Windows XP) y mediante un proceso batch se copian cada minuto a una unidad compartida de red que hace referencia a una carpeta de Alfresco llamada FROMSCAN.

Los pasos han sido:

1. Crear una carpeta en Company Home de Alfresco llamada FROMSCAN. Esta llevará las reglas necesarias para mover los documentos que entran.

2. Crear una carpeta local en Windows XP donde está instalado DigiDocFlow llamada también FROMSCAN.

3. Escribir el siguiente fichero batch:

@ECHO OFF
SET CARPETAWIN=C:FROMSCAN
SET CARPETAALF=Y:FROMSCAN
COPY /Y «%CARPETAWIN%*.pdf» «%CARPETAALF%»
COPY /Y «%CARPETAWIN%*.xml» «%CARPETAALF%»
IF ERRORLEVEL 1 GOTO SALIR
DEL /F /Q «%CARPETAWIN%*.*»
:SALIR

4. Crear la tarea (ejecutar en intérprete de comandos en Windows XP llamado CMD.EXE) para que se realice (ejecute) el batch cada hora:

SCHTASKS /CREATE /TN FROMSCAN /TR «CMD /C «C:FROMSCAN.BAT»» /SC HOURLY

Hay que tener en cuenta «escapar» las comillas con para que no se produzcan errores, no en este caso, pero si, si en el directorio o nombre de fichero batch se contienen caracteres en blanco.

De esta forma podemos tener incluso un directorio local donde van a parar ficheros que provienen de un ERP, un CRM o un sistema de escaneo como Kofax o DigiDocFlow sin tener que usar ningún tipo de conector y personalizando tanto el tiempo de envío de los ficheros como el orden.

Alfresco, WebDAV y WebSphere

WebDAV (Web-based Distributed Authoring and Versioning) es un protocolo que implementa Alfresco para poder conectar unidades y/o recursos compartidos y poder subir, modificar y borrar documentos de una forma sencilla.

Este protocolo además es bastante simple y se basa en comunicaciones vía HTTP y HTTPS con lo que es además muy sencillo de configurar entre balanceadores y firewalls. No obstante presenta algunos problemas cuando se conecta a través de Windows.

Uno de ellos es la codificación, Windows usa generalmente la ISO-8859-15 (en España) y Alfresco usa generalmente UTF-8 a nivel de Java y sobre todo si está instalado en máquinas Linux. Este problema de codificación cambia caracteres con tildes, eñes, etc. por lo que hay que prestar atención a la configuración y establecer todo al mismo sistema de codificación para evitar sorpresas.

Otro problema que me he encontrado en un cliente ha sido la conexión directamente con el servidor desde las estaciones de trabajo tanto Windows XP como Windows 7.

Realizando pruebas con un Apache 2.2 y mod_proxy_balancer hacia dos máquinas virtuales con Alfresco 3.3.4 no he tenido problemas siempre y cuando se sigan las indicaciones de los siguientes enlaces:

http://wiki.alfresco.com/wiki/File_Server_Configuration
http://wiki.alfresco.com/wiki/Client_WebDAV
http://support.microsoft.com/kb/841215
http://support.microsoft.com/kb/912152
http://www.webdavsystem.com/server/documentation/authentication/basic_auth_vista

Básicamente es actualizar el software del cliente WebDAV así como activar la autenticación básica tanto en plano como por SSL usando el registro de Windows.

Ejecutar regedit.exe

En Windows XP, crear un valor DWORD en HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWebClientParameters llamado UseBasicAuth con el valor a 1.

En Windows 7, crear un valor DWORD en HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWebClientParameters llamado BasicAuthLevel con el valor a 2.

Una vez realizados estos cambios solo hay que reiniciar el servicio cliente de WebDAV, reiniciando la máquina o parando e iniciando el servicio como:

NET STOP webclient
NET START webclient

Hasta aquí todo correcto, en las máquinas virtuales de laboratorio todo fue correctamente, pero en el cliente seguía habiendo problemas cuando se intentaba conectar con Windows XP, no así con Windows 7, ¿cual era la diferencia básica?

En el cliente, los accesos se realizan hacia un balanceador hardware que a su vez dirige las peticiones a sendos IBM HTTP Servers que no son más que un Apache modificado y estos se conectaban a los nodos de Alfresco en clúster (estos están en WAS o IBM WebSphere Application Server).

Para el balanceo de los servidores IBM HTTP Server se usa un plugin propio. Este se configura a través de un fichero llamado plugin-cfg.xml

En el siguiente enlace hay una descripción de los parámetros y valores posibles: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rwsv_plugincfg.html

En su configuración, el parámetro AcceptAllContent está desactivado y su misión es la de si permite que los usuarios puedan incluir o no el contenido en las peticiones POST, PUT, GET, y HEAD cuando la cabecera de petición incluye una cabecera de longitud del contenido o de codificación de la transferencia.

Se puede especificar True para leer todas las peticiones o False en la que se espera sólo el contenido y sólo para las peticiones POST y PUT.

Poniendo este valor a True todo se ha solucionado y ahora los Windows XP (SP1, SP2 y SP3) pueden conectarse sin ningún problema.

Agradezco la ayuda aportada a la solución de este problema a Roberto Herrero Guindal, experto en WebSphere del departamento de sistemas del cliente que ha tenido este problema.

Autenticación NTLM en Alfresco con Active Directory

En muchas ocasiones, aunque el servidor de autenticación sea un Windows 2000 Server, Windows 2003 Server o posterior y sus usuarios estén en el Active Directory no es necesario tener que configurar Alfresco para que autentique como tal vía LDAP/Active Directory.

Windows 2000 y superiores utilizan la autenticación mixta vía LDAP (Active Directory) y TLM v2 y por tanto podemos configurar Alfresco tocando solamente 3 ficheros, que serán:

web.xml
ntlm-authentication-context.xml
file-servers-custom.xml

En Alfresco, este tipo de autenticación donde no solo se usa el protocolo «desafío/respuesta» NTLM sino que además se usa contra una base de datos de usuarios de Windows, para la identificación de cada persona, se le denomina «NTLM passthru».

Se usa ${tomcat} como identificador del punto de comienzo del servidor de aplicaciones que en este caso es Apache-Tomcat.

Primero hay que activar los filtros necesarios para la autenticación vía web en ${tomcat}/webapps/alfresco/WEB-INF/web.xmldescomentando las líneas siguientes:

org.alfresco.web.app.servlet.NTLMAuthenticationFilter

org.alfresco.repo.webdav.auth.NTLMAuthenticationFilter


Authentication
Filter
/navigate/*


Authentication
Filter
/command/*


Authentication
Filter
/download/*


Authentication
Filter
/template/*


Authentication
Filter
/n/*


Authentication
Filter
/c/*


Authentication
Filter
/t/*


Authentication
Filter
/d/*


Authentication
Filter
/ajax/*


Authentication
Filter
/wcs/*


Authentication
Filter
/wcservice/*

Lo mejor es buscar la cadena «NTLM» y a partir de ahí descomentar estas líneas.

El siguiente fichero a configurar es ${tomcat}/share/classes/alfresco/extension/ntlm-authentication-context.xml donde solo hay que establecer el servidor o servidores Windows que contienen el Active Directory.

En este caso, por ejemplo:


MIDOMINIOserv001, serv001


Y por último el fichero ${tomcat}/share/classes/alfresco/extension/file-servers-custom.xml que es el que nos permitirá acceder a los recursos CIFS (SMB) desde Windows o desde Linux. Aquí se configura para usar «passthru» así como los servidores necesarios.

Por ejemplo:
MIDOMINIOserv001, serv001



Con esto ya estaría configurado nuestro sistema para autenticación NTLM y acceso a los recursos vía CIFS/SMB. Bastará con poner en la dirección del navegador de ficheros la dirección del host o servidor Alfresco:

En Windows como \serv001

En Linux, generalmente como smb://srv001

Observaciones: Hay que tener en cuenta que si es un entorno Linux los puertos usados
para los recursos CIFS/SMB (puertos 137, 138, 139 y 445) solo pueden abrirse por el usuario root y no por un usuario sin privilegios de administración. En este último caso habría que utilizar puertos por encima del 1024 reasignándose dentro de la configuración (en el
propio fichero file-servers-custom.xml) y utilizando un sistema de «forwading» o «NAT» con un router.