20130617 - Datalytics - Instalacion y Administracion de la Plataforma - Romina Pontiroli (1)

Agenda Schedule

Schedule El scheduler permite crear, actualizar, eliminar, ejecutar, suspender y reanudar una o más tareas programadas (privadas o públicas) en la Plataforma BI. Por ejemplo, enviar periódicamente reportes por mail, ejecutar xactions, etc. Configurando en el PAC Se debe ingresar a la consola administrativa http://localhost:8099 Hacer click en el botón Administration y luego en la pestaña Scheduler. Para crear una tarea, click en el ícono

Schedule Se abrirá una nueva venta la cual solicita la siguiente información:  Name: Nombre de la tarea a programar.  Group: Grupo al cual pertenece la tarea a programar.  Description: Descripción de lo que hace la tarea.  Recurrence: Cada cuanto se desea que se ejecute la tarea a programar; Puede ser una única vez o cada segundo, minuto, hora, meses, etc.  Range of recurrence: Establece el comienzo y fin de la tarea a ejecutar. También se puede elegir si la tarea va a ser pública o privada tildando o no dicha opción. Que sea pública va a permitir que cualquier usuario de la plataforma pueda utilizar la tarea. Si es privada sólo está disponible para el usuario que la creó.

Schedule Haciendo click en OK se guarda la tarea y como se ve en la siguiente imagen, queda lista para ejecutarse. Ahora se está en condiciones de elegir la actividad que se quiere ejecutar con la tarea que se acaba de crear. Para ello se debe ir al PUC ingresando usuario y contraseña para acceder a la consola y hacer click derecho en la actividad elegida y luego click en compartir, como muestra la siguiente imagen:

Schedule

Schedule Se abrirá una venta con tres solapas, elegir la llamada “Avanzado”. Para este ejemplo como la tarea creada Test es pública se debe tildar el checkbox, pasar Test de Disponible a Actual y hacer click en OK. Ahora ésta actividad será ejecutada por la tarea creada de acuerdo a lo que se ha configurado.

AgendaPermisos y Seguridad

Permisos y Seguridad Pentaho permite que a un elemento o carpeta de la solución se le pueda asignar diferentes permisos para distintos roles o usuarios. Para esto se debe hacer click derecho en la carpeta o elemento al cual se le quiere otorgar permisos y seleccionar Compartir como se ve en la imagen inferior, se abrirá una nueva venta y allí se debe hacer click nuevamente en Compartir. En la imagen lateral se observa como se muestran los roles o usuarios que tienen permisos hasta el momento y debajo que tipo de permisos.

Permisos y Seguridad Haciendo click en Añadir se abre una nueva ventana como la de la imagen. Allí se puede seleccionar el nuevo rol o usuario al cual se le quiere otorgar nuevos permisos. Una vez seleccionado se habilitarán los diferentes permisos que se le puede otorgar al rol o usuario elegido. Cabe recordar que para poder realizar esto se debe ingresar a la plataforma con un usuario administrador o con un usuario con la posibilidad de otorgar permisos. Al hacer click en Remover se eliminarán los permisos del usuario o rol seleccionado.

Permisos y Seguridad Se puede realizar lo mismo desde http://localhost:8080/pentaho/Admin Seleccionar aquí Luego elegir el directorio/archivo Seleccionar Agregar

Permisos y Seguridad Elegir el rol o usuario Por último elegir el nivel de permisos

Agenda Laboratorio Crear una planificación pública Suscribir un reporte a la planificación (usuario admin) Crear la carpeta Personal (privada) y la carpeta Publica (todos con permisos de lectura)

Soluciones Definición de Solución Una solución es un conjunto de objetos de usuario (reportes, cubos, etc) que están Repositorio de agrupados para dar respuesta a un concepto Soluciones (Finanzas, Marketing, etc).Repositorio de soluciones Soluciones

Soluciones Cada directorio contiene un archivo index.xml y, opcionalmente, index.properties Index.xml define:  La visibilidad del directorio  La imagen del directorio  Puede ser localizado Sin index.xml, el directorio/solución permanece oculto

Soluciones

Refresco de cache Pentaho tiene varias caches para mejorar la performance de la plataforma, pero muchas veces es necesario refrescarlas para que la misma tome los cambios que hemos realizado. A continuación se detallan las mas importantes:  Cache del repositorio de soluciones: Es necesario refrescarla cuando se realiza algún cambio en dicho repositorio, por ejemplo al guardar un nuevo archivo, agregar o modificar un cubo, etc.  Metadata de Reporte: Es necesaria refrescarla ante una nueva metada o modificación de una existente para visualizar los cambios.  Cache de esquemas de Mondrian: Se realiza el refresco cuando se agrega o modifica un cubo además de refrescar la cache del repositorio.  Reporting Data Cache: Se necesita este refresco ante un nuevo reporte hecho con Pentaho Report Designer o ante una modificación de uno existente. Previamente se debe refrescar la cache del repositorio.

Refresco de cache Si la plataforma cuenta con el plug-in Ctools, va a tener además la opción de refrescar CDA Cache Manager, la cual sirve para actualizar las consultas utilizadas por CDE para la creación/edición de dashboards. Todas estas caches mencionadas se pueden refrescar desde el PUC en Herramientas > Actualizar > “cache elegida”. También se puede realizar desde http://localhost:8080/pentaho/Admin.

Refresco de cache Para refrescar la cache de tomcat, se debe borrar todo lo que se encuentra en el directorio tomcat\work\Catalina\localhost. Sólo se debe realizar este refresco cuando haya algún problema con Tomcat y no lo haga automáticamente o cuando se quiera forzar un refresco por algún motivo.

Agenda Laboratorio Crear una nueva solución desde el SO Refrescar las cache’s correspondientes Implementar desde el SO el cubo y el reporte “curso”

Agenda Servidor Web (Tomcat)

Logs Como se mencionó al comienzo, los logs más importantes se encuentran en el directorio biserver-ce\tomcat\logs. Allí se guardan:  catalina.YYYY-MM-DD.log  pentaho.log Cada uno de estos logs comienzan con la fecha, hora y un valor. Los valores posibles son: DEBUG, INFO, WARN Y ERROR o GRAVE. Para analizar el log lo primero que se debe mirar es éste valor, ya que dan una idea de la gravedad del problema. Generalmente sólo hay que focalizarse en los registros que comienzan con ERROR o GRAVE. Tomcat escribe registros en catalina.YYYY-MM-DD.log, esto incluye los registros de las aplicaciones en el directorio tomcat\logs\webapps. Pentaho mantiene sus propios registros en pentaho.log.

LogsPara ajustar el nivel de logging buscado editar /pentaho/server/biserver-ee/tomcat/webapps/pentaho/WEB-INF/classes/log4j.xml: Modificar la prioridad en el raíz, definiendo alguno de los siguientes niveles: WARN, ERROR, FATAL, DEBUG o TRACE.<root> <priority value=\"DEBUG\" /> <appender-ref ref=\"PENTAHOCONSOLE\"/> <appender-ref ref=\"PENTAHOFILE\"/></root> Agregar arriba del tag anterior: <category name=\"org.springframework.security“> <priority value=\"DEBUG\" /> </category> <category name=\"org.pentaho.platform.engine.security\"> <priority value=\"DEBUG\" /> </category> <category name=\"org.pentaho.platform.plugin.services.security\"> <priority value=\"DEBUG\" /> </category>

Logs Además se puede habilitar el logueo específico de mondrian, MDX y SQL. Para ello se debe editar el archivo “log4j.xml” que se encuentra en el directorio “…\biserver-ce\tomcat\webapps\pentaho\WEB-INF\classes”. Se deben descomentar la líneas que se muestran en las siguientes imágenes, guardar los cambios y reiniciar el servicio.  Mondrian

Logs  MDX

Logs  SQL

Rotación de logs Este procedimiento asume que no se quiere utilizar una aplicación a nivel SO para hacer rotación de logs (logrotate por ejemplo). Tanto la consola de administrativa como la consola de usuario utilizan Apache log4j como framework para el manejo de logs. La configuración por defecto de log4j.xml puede que resulte muy detallada para ambientes productivos y termine produciendo archivos de logs demasiado grandes. Para modificar esto y configurar Log4j para que los logs roten y se compriman automáticamente, seguir los siguientes pasos: 1. Detener todos los servicios de Pentaho que correspondan. 2. Bajar el zip de Apache Extras Companion para log4j: http://logging.apache.org/log4j/companions/extras/ a) Copiar el JAR de apache-log4j-extras en los siguientes directorios: b) BA Server:\tomcat\webapps\pentaho\WEB-INF\lib\ c) Administration Console:\administration-console\lib\

Rotación de logs 3. Editar el archivo log4j.xml para cada servidor que se esté configurando. Los mismos se encuentran en los siguientes directorios: a) BA Server:\tomcat\webapps\pentaho\WEB-INF\classes\ b) Administration Console:\administration-console\resource\config\ 4. Eliminar todos los appenders PENTAHOCONSOLE de la configuración. 5. Modificar el appender PENTAHOFILE para que se ajuste a las condiciones de rotación que se deseen. Si bien existen muchas formas de configuración, se listan a continuación dos ejemplos típicos: a) Rotación diaria con compresión. b) Rotación basada en tamaño con compresión.

Rotación de logs Rotación diario con compresión <appender name=\"PENTAHOFILE\" class=\"org.apache.log4j.rolling.RollingFileAppender\"> <!-- The active file to log to; this example is for BA/DI Server. Enterprise console would be \"server.log\" --> <param name=\"File\" value=\"../logs/pentaho.log\" /> <param name=\"Append\" value=\"false\" /> <rollingPolicy class=\"org.apache.log4j.rolling.TimeBasedRollingPolicy\"> <!-- See javadoc for TimeBasedRollingPolicy --> <!-- Change this value to \"server.%d.log.gz\" for PEC --> <param name=\"FileNamePattern\" value=\"../logs/pentaho.%d.log.gz\" /> </rollingPolicy> <layout class=\"org.apache.log4j.PatternLayout\"> <param name=\"ConversionPattern\" value=\"%d %-5p [%c] %m%n\"/> </layout> </appender>

Rotación de logs Rotación basada en tamaño con compresión <appender name=\"PENTAHOFILE\" class=\"org.apache.log4j.rolling.RollingFileAppender\"> <!-- The active file to log to; this example is for BA/DI Server. Enterprise console would be \"server.log\" --> <param name=\"File\" value=\"../logs/pentaho.log\" /> <param name=\"Append\" value=\"false\" /> <rollingPolicy class=\"org.apache.log4j.rolling.FixedWindowRollingPolicy\"> <!-- Change this value to \"server.%i.log.gz\" for PEC --> <param name=\"FileNamePattern\" value=\"../logs/pentaho.%i.log.gz\" /> <param name=\"maxIndex\" value=\"10\" /> <param name=\"minIndex\" value=\"1\" /> </rollingPolicy> <triggeringPolicy class=\"org.apache.log4j.rolling.SizeBasedTriggeringPolicy\"> <!-- size in bytes --> <param name=\"MaxFileSize\" value=\"10000000\" /> </triggeringPolicy> <layout class=\"org.apache.log4j.PatternLayout\"> <param name=\"ConversionPattern\" value=\"%d %-5p [%c] %m%n\" /> </layout> </appender> 6. Guardar y cerrar los archivos, reiniciar los servicios que correspondan.

Modificación de time-outs A continuación se detallan las tareas para deshabilitar los timeouts de la consola de usuario. Importante: Estas instrucciones aplican en un ambiente de testing. En un ambiente de producción es recomendado generar el timeout a los 5-10 minutos para que información sensible esté mayormente protegida. Pasos: 1. Abrir el archive server.xml, ubicado en …\tomcat\conf. 2. Buscar el parámetro connectionTimeout=\"20000\" y modificar el valor a 0. 3. Abrir el archivo web.xml, ubicado en ...\tomcat\webapps\pentaho\WEB-INF\web.xml. 4. Buscar el parámetro session-timeout y modificar el valor por uno negativo. 5. Guardar ambos archivos y refrescar la cache del repositorio.

Encriptación por SSL Para habilitar la encriptación por SSL se requiere en primer medida generar un certificado que será utilizado por Tomcat para encriptar los datos. Para hacerlo, utilizando la aplicación keytool debe ejecutarse lo siguiente: keytool -genkey -alias tomcat -keyalg RSA –validity 365 -keystore c:\keystore Con el comando mencionado se generará un certificado con una validez de un año.

Encriptación por SSLEs importante remarcar que para que el certificado pueda ser usado por Tomcat,tanto la contraseña de almacén de claves como la contraseña para Tomcat(definida al final del procedimiento) deben ser las mismas.Posteriormente, con la plataforma baja editar el archivo \biserver-ce\tomcat\conf\server.xml, incluyendo en la sección de conectores el siguientefragmento:<Connectorprotocol=\"org.apache.coyote.http11.Http11Protocol\"port=\"8443\" maxThreads=\"200\" scheme=\"https\"secure=\"true\" SSLEnabled=\"true\"keystoreFile=\"c:/keystore\" keystorePass=\"password\"clientAuth=\"false\" sslProtocol=\"TLS\"/>En la clave “keystorePass” debe ingresarse la clave definida al momento de crearel certificado.En caso de crear un nuevo certificado para reemplazar el existente, respetando laclave utilizada (password), solo será necesario reemplazar el archivo \biserver-ce\tomcat\.keystore y reiniciar la plataforma.

Depuración del repositorio Eliminación de cubos publicados Cada vez que se actualiza o publica un nuevo cubo desde Schema Workbench, una nueva conexión XMLA se crea en el archivo datasources.xml. …\biserver-ce\pentaho-solutions\system\olap\datasources.xml. A través de esto, se le indica a la plataforma hay un nuevo cubo disponible y muestra el mismo en los listados generados (siempre y cuando el mismo no tenga errores). A menos que se requiera una configuración particularmente avanzada, este archivo no debiera ser modificado manualmente durante las tareas de publicación/actualización. Siendo que la consola de usuario utiliza las conexiones XMLA a cubos para mostrar los mismos a los usuarios finales, en caso que se requiera eliminar un cubo se deberá editar este archivo y eliminar manualmente la entrada <dataSource> que corresponda.

Depuración del repositorio Por ejemplo: <DataSources> <DataSource> <DataSourceName>Provider=Mondrian;DataSource=Pentaho</DataSourceName> <DataSourceDescription>Pentaho BI Platform Datasources</DataSourceDescription> <URL>http://localhost:8080/pentaho/Xmla?userid=joe&amp;password=password</URL> <DataSourceInfo>Provider=mondrian</DataSourceInfo> <ProviderName>PentahoXMLA</ProviderName> <ProviderType>MDP</ProviderType> <AuthenticationMode>Unauthenticated</AuthenticationMode> <Catalogs> <Catalog name=\"SteelWheels\"> <DataSourceInfo>Provider=mondrian;DataSource=SampleData</DataSourceInfo> <Definition>solution:steel-wheels/analysis/steelwheels.mondrian.xml</Definition> </Catalog> <Catalog name=\"SampleData\"> <DataSourceInfo>Provider=mondrian;DataSource=SampleData</DataSourceInfo> <Definition>solution:steel-wheels/analysis/SampleData.mondrian.xml</Definition> </Catalog> </DataSource> </DataSources> Eliminando la entrada marcada y refrescando la cache del repositorio se elimina el cubo (catalogo) “SampleData”.

Depuración del repositorio Limpieza manual de archivos temporales Cada vez que se genera contenido a través de la consola de usuario de Pentaho, se crean archivos temporales en el directorio: \biserver-ce\pentaho- solutions\system\tmp\. Si bien este directorio se purga automáticamente, en caso de shutdowns forzados puede darse el caso que no se terminen de eliminar archivos y comience a acumular espacio. En caso de ser necesario, es seguro eliminar los archivos de más de una semana de antigüedad a través de un script croneado que corra con una frecuencia dada.

Agenda Laboratorio Modificar para que la plataforma no use timeouts Eliminar el cubo “curso.mondrian.xml”

Agenda Repositorio de Soluciones

Hibernate y Quartz Pentaho guarda toda su metadata y tareas programadas en dos bases, hibernate y quartz, que por defecto vienen en el motor Hypersonic, pero como veremos más adelante dicho repositorio puede ser migrado a otros. Hibernate Esta base le proporciona persistencia a los objetos de Pentaho: pentaho no lee el filesystem, lee la base de datos, de aquí la importancia del refresco. Mantiene toda la información que se genera al trabajar con el repositorio de soluciones y toda la información referida a los usuarios y roles de la plataforma. Las tablas más importantes son:  datasource: Guarda las conexiones a las bases de datos de las soluciones que se configuran en la consola administrativa.  granted_authorities: Guarda para cada usuario los roles a los que pertenece.

Hibernate y Quartz  pro_files: Guarda información de cada uno de los elementos que se almacenan en el repositorio de soluciones. Dentro de los campos más destacados se puede mencionar:  DIRECTORY es 1 si el elemento es un directorio o 0 si no lo es.  CHILD_ID se utiliza para encontrar los archivos hijos de un directorio.  FULLPATH almacena donde se ubica el directorio o archivo a partir de pentaho-solutions.  FILENAME indica el nombre del directorio o archivo.  pro_acls_list: Guarda un registro por cada rol y/o usuario que se le asigna a un directorio o archivo del repositorio de soluciones. Los campos que comprende dicha tabla son:  ACL_ID almacena el identificador que le asigna Pentaho y el cual se relaciona con FILE_ID de la tabla pro_files antes comentada.

Hibernate y Quartz  ACL_MASK, define el tipo de permiso para cada rol/usuario. Los posibles valores son:  RECIPIENT_TYPE, tiene un 0 si el permiso es para un usuario y un 1 si es para un rol.  RECIPIENT, contiene el nombre del rol/usuario.  ACL_POSITION, inserta la posición en que coloca al usuario/rol para ese archivo.

Hibernate y Quartz  users: Guarda la información correspondiente a todos los usuarios.  USERNAME, identifica al usuario.  PASSWORD, almacena la clave encriptada.  DESCRIPTION, se puede insertar alguna descripción del usuario (opcional).  ENABLED, contiene un 1 si el usuario está habilitado y un 0 si no lo está. Quartz Almacena toda la información de las tareas programadas que necesita la plataforma para ejecutar los diferentes procesos.

Migración del Repositorio Como se mencionó en otros pasajes del curso, Pentaho por defecto utiliza Hypersonic como motor de sus bases de datos, pero permite migrar a otros motores como:  MySQL  Microsoft SQL Server  PostgreSQL  Oracle XE Ver documento “20121204 - Datalytics - Migrar repositorio Pentaho a MySQL.pdf”.

AgendaPentaho + Protocolos de Seguridad

LDAP Lightweight Directory Access Protocol (Protocolo Compacto de Acceso a Directorios), es un protocolo estándar que permite administrar directorios, esto es, acceder a bases de información de usuarios de una red mediante protocolos TCP/IP. Generalmente las compañías desean tener centralizada la seguridad de sus aplicaciones y para ello pueden utilizar un servidor LDAP, por lo que es importante saber que tanto Pentaho EE como Pentaho CE pueden configurarse para que la validación de los usuarios sea gestionada por dicho servidor, logrando así tener configurados los usuarios/grupos en un sólo lugar. Ver documento “20121204 - Datalytics - Manual de configuracion Pentaho- LDAP.pdf”.

Active Directory Su funcionamiento es similar a LDAP, almacena en forma centralizada y jerarquizada toda la información relativa a un dominio de autenticación. La ventaja que presenta esto es la sincronización presente entre los distintos servidores de autenticación de todo el dominio. A su vez, cada uno de estos objetos tendrá atributos que permiten identificarlos en modo unívoco. Toda esta información queda almacenada en Active Directory replicándose de forma automática entre todos los servidores que controlan el acceso al dominio. Conclusión, Active Directory es una implementación de servicio de directorio centralizado en una red distribuida que facilita el control, la administración y la consulta de todos los elementos lógicos de una red. Ver documento, “20121204 - Datalytics - Manual de configuracion Pentaho Active Directory.pdf”.

CAS CAS (Central Authentication Service) es una aplicación web que nos permite implementar SSO (Single Sign On). Protocolo de autenticación que habilita a un usuario para acceder a distintas aplicaciones web (en distintos dominios y en distintos servidores) con hacer login una única vez. En general, cuando un usuario se conecta a una de estas aplicaciones el sistema comprueba si está autenticado y si no lo está, lo redirige a la pantalla del servidor de autenticación. Si el login es correcto el sistema, en este caso CAS, vuelve a redirigir al usuario a la página a la que quería acceder en un primer momento. Es muy importante remarcar que CAS se encarga única y exclusivamente de la autenticación es decir, de comprobar contra una fuente de datos específica si el usuario y contraseña facilitados existen, NO se encarga de la autorización, que sería la gestión de lo que puede o no puede hacer ese usuario en función de sus roles. Ver documento, “20121204 - Datalytics - Manual de configuracion Pentaho- CAS-LDAP.pdf”.

Agenda Plugins

Marketplace

Marketplace

Marketplace