Juan Pablo Orradre

Serializar objetos a JSON en Python

noreply@blogger.com (Juan Pablo Orradre) — Thu, 10 Dec 2015 16:15:00 +0000

Una de las tareas frecuentes que se deben realizar a la hora de implementar cualquier aplicación hoy en día que precise generar datos a archivo es la serialización de datos a formato JSON.

En Java por ejemplo existe la librería JSON-Java para tal motivo (https://github.com/douglascrockford/JSON-java).

En Python, de las mejores maneras de realizar esta tarea es con la librería jsonpickle.

jsonpickle es una librería que permite serializar objetos complejos a formato JSON, a diferencia de la librería nativa json de Python que no tiene esa funcionalidad, ya que únicamente serializa objetos simples (sin objetos como atributos), colecciones o tuplas, por ejemplo.

Para instalar la librería, basta correr un pip install jsonpickle.

A continuación un ejemplo de uso:

import jsonpickle;

from Object import Object;

mObjects = [];

mObjects.append(Object(1,"Object 1"));

mObjects.append(Object(2,"Object 2"));

mJSON = jsonpickle.encode(mObjects);

file = open("/path/file/objects.json", "w");

file.write(mJSON);

file.close();

Ejecutar el anterior código resultaría en un archivo .json con el siguiente contenido:

[

{"code":1 , "name":"Object1"},

{"code":2 , "name":"Object2"}

]

Chequeos pasivos con Nagios, NSCA y Swatch

noreply@blogger.com (Juan Pablo Orradre) — Sun, 06 Sep 2015 21:20:00 +0000

En el mundo del monitoreo de sistemas, Nagios es tal vez una de las más completas y utilizadas soluciones en ese rubro.

Generalmente, los chequeos que uno realiza son activos, es decir, se configura Nagios para controlar ciertos aspectos de distintos servicios/servidores.

Sin embargo, en ocasiones es necesario que el propio server que maneja servicios que se utilizan , realice los chequeos ante la presencia de algún evento en particular y luego le comunique a Nagios para que realice alguna acción eventualmente. Esto se conoce como chequeo pasivo en Nagios.

Tiene como desventajas principales la necesidad de estar realizando avisos periódicos desde el server a Nagios para notificar el estado del servicio a monitorear, y también una mayor complejidad en la configuración.

En la presente entrada voy a explicar una manera de implementar un chequeo de log sobre un servidor Linux utilizando tres componentes: Nagios, NSCA y Swatch.

NSCA

En palabras de Nagios: "NSCA es un demonio de Linux / Unix que permite integrar las alertas y controles pasivos de las máquinas remotas y aplicaciones con Nagios. Útil para las alertas de seguridad de proceso, así como las configuraciones de Nagios redundantes y distribuidos.".

Se implementa mediante un demonio a la escucha de avisos desde los diferentes servers, el cual notifica al servicio de Nagios correspondiente; y el agente send_nsca ubicado en el nodo a monitorear, quien se encarga de enviar el aviso al demonio NSCA del servidor Nagios.

Dicho demonio se recomienda que sea manejado por el servicio xinetd, quien se encarga de gestionar el acceso y funcionamiento seguro al servicio.

Swatch

Swatch (Simple Log Watcher) , es un software que aprovecha las virtudes de Perl para el trabajo con expresiones regulares, para realizar búsqueda de texto en archivos de texto.

El siguiente recuadro resume la disposición de cada elemento en el esquema que vamos a desarrollar:

Servidor Nagios

Configuración de NSCA

Para comenzar la implementación, en primera instancia desde el lado del servidor Nagios se debe levantar el demonio NSCA, y después habilitar el servicio Nagios.

Para lo primero, en el caso de un server Nagios instalado desde cero personalizadamente, se precisan descargar los fuentes desde Sourceforge, compilarlo y configurarlo como un demonio sobre xinetd. En caso de que Nagios corra sobre la máquina virtual que proporciona la firma no hay que realizar todo esto ya que viene incluido el binario con su configuración.

Para el segundo caso, se precisa únicamente configurar el acceso desde xinetd (/etc/xinetd.d/nsca) y la encripción de los datos (/usr/local/nagios/etc/nsca.cfg).

En /etc/xinetd.d/nsca se deben especificar los hosts o redes a aceptar para recibir los chequeos desde send_nsca:

only_from = REDES_O_HOSTS_A_ACEPTAR

En el archivo de configuración /usr/local/nagios/etc/nsca.cfg se debe especificar la autenticación de la comunicación con el server a monitorear:

password=contrasenia_secreta

decryption_method=10

Configuración del servicio pasivo

Para la configuración del servicio, se puede implementar un template para servicios pasivos y heredar desde el servicio a implementar desde él. En este caso se configura en /usr/local/nagios/etc/services/HOST_A_REVISAR.cfg lo siguiente:

define service{

use generic-service

name passive_service

active_checks_enabled 0

passive_checks_enabled 1 # We want only passive checking

flap_detection_enabled 0

is_volatile 0

check_period 24x7

max_check_attempts 1

normal_check_interval 5

retry_check_interval 1

check_freshness 0

contact_groups admins

check_command check_dummy!0!"Initial OK"

notification_interval 60

notification_period 24x7

notification_options w,u,c,r

stalking_options w,c,u

}

define service{

use passive_service

service_description TestMessage

host_name localhost

check_freshness 1

freshness_threshold 60 # Time in second it will recheck and if not get result will alert as Critical

check_command check_dummy!2!"Didn't not got the response from Passive Check (Please Check)"

}

Servidor a chequear

Del lado del servidor a chequear, se debe instalar Swatch para revisar el o los logs correspondientes, y send_nsca para la notificación al servidor Nagios.

Send_nsca

Para instalar send_nsca se deben descargar los fuentes desde su repositorio en Sourceforge, compilarlos y configurar la aplicación:

[root@server ~]# cd /tmp; wget http://prdownloads.sourceforge.net/sourceforge/nagios/nsca-2.7.2.tar.gz ; tar xvfz nsca-2.7.2.tar.gz; cd nsca-2.7.2; ./configure

En este paso, es posible que se avise que no está instalado el módulo mcrypt, necesario para encriptar la comunicación entre NSCA y el server a monitorear. En dicho caso deberá ser instalado con sus herramientas de desarrollo:

[root@server nsca-2.7.2]# yum install libmcrypt libmcrypt-devel

Luego se compila y se copia el binario y la configuración a sus respectivos directorios:

[root@server nsca-2.7.2]# make all

[root@server nsca-2.7.2]# mkdir -p /usr/local/nagios/bin /usr/local/nagios/etc

[root@server nsca-2.7.2]# cp src/send_nsca /usr/local/nagios/bin/

[root@server nsca-2.7.2]# cp sample-config/send_nsca.cfg /usr/local/nagios/etc/

[root@server nsca-2.7.2]# cd /usr/local/nagios/etc

Paso siguiente, se configuran las credenciales de acceso a NSCA:

[root@server etc]# vi send_nsca.cfg

password=contrasenia_secreta

encryption_method=10

Swatch

Bajar Swatch y descomprimirlo en /tmp desde http://sourceforge.net/projects/swatch/files/latest/download

Correr archivo Makefile.pl para generar Makefile :

[root@server swatch-3.2.3]# perl Makefile.PL
Checking if your kit is complete...
Looks good
Warning: prerequisite Date::Calc 0 not found.
Warning: prerequisite Date::Format 0 not found.
Warning: prerequisite Date::Manip 0 not found.
Warning: prerequisite File::Tail 0 not found.
Writing Makefile for swatch

En caso que falten módulos, instalarlos (Ver http://www.thegeekstuff.com/2008/09/how-to-install-perl-modules-manually-and-using-cpan-command/)

Ejemplo:

[root@server swatch-3.2.3]# cpan
Terminal does not support AddHistory.

cpan shell -- CPAN exploration and modules installation (v1.7602)
ReadLine support available (try 'install Bundle::CPAN')

cpan>install Date::Calc

Luego se debe instalar Swatch:

[root@server swatch-3.2.3]# make
[root@server swatch-3.2.3]# make test
[root@server swatch-3.2.3]# make install
[root@server swatch-3.2.3]# make realclean

Posteriormente , se debe crear el archivo de configuración de Swatch:

[root@server swatch-3.2.3]# mkdir -p /usr/local/swatch/etc/

[root@server swatch-3.2.3]# cd /usr/local/swatch/etc/

En el archivo .swatchrc se indican las acciones al encontrar un match con la expresión a buscar.  En este caso, al encontrar un matching, se graban en archivos temporales la línea del log y el código de error correspondiente a un warning; así como también se ejecuta el script que envía al servidor Nagios la información necesaria:

[root@server etc]# vi .swatchrc

watchfor /string_a_revisar/

    exec "echo $_ > /var/run/svc_alertlogerr.msg"
    exec "echo 2 > /var/run/svc_alertlogerr.stat"
    exec "sh /usr/local/nagios/bin/svc_alertlogerr_stat.sh"

[root@server etc]# chmod 755 .swatchrc
Luego se setea en el archivo /etc/init.d/swatch a Swatch como un demonio para que permanezca continuamente revisando el o los logs:

#!/bin/bash
# Simple Log Watcher Init Script

case "$1" in
'start')
  echo "0" > /var/run/svc_alertlogerr.stat
  /usr/bin/swatch --daemon --config-file=/usr/local/swatch/etc/.swatchrc --tail-file=/var/log/messages --pid-file=/var/run/swatch.pid
  ;;
'stop')
  PID=`cat /var/run/swatch.pid`
  kill $PID
  ;;
*)
  echo "Usage: $0 { start | stop }"
  ;;
esac
exit 0



[root@server init.d]# chmod 755 swatch


Posteriormente, se agenda una tarea en cron para que envíe al servidor Nagios el aviso de que el servicio está vivo según la frecuencia de refresco especificada en el servicio pasivo de Nagios:


[root@server etc]# crontab -e
*/2 * * * * /usr/local/nagios/bin/svc_alertlogerr_stat.sh

Se debe agregar también una regla de iptables en /etc/sysconfig/iptables para aceptar la salida y entrada del server Nagios a través del puerto 5667 que utiliza NSCA por defecto, además de permitir el ping entrante para el control de actividad general del servidor en Nagios:

-A OUTPUT -p tcp -d IP_SERVER_NAGIOS --dport 5667 -j ACCEPT
-A INPUT -p tcp -d IP_SERVER_NAGIOS --sport 5667 -j ACCEPT
-A INPUT -p icmp -d IP_SERVER_NAGIOS --icmp-type echo-request -j ACCEPT
-A OUTPUT -p icmp -d IP_SERVER_NAGIOS --icmp-type echo-reply -j ACCEPT

Por último, en el servidor Nagios se deben reiniciar los servicios de xinetd y Nagios. Del lado del server a monitorear se deben reiniciar los servicios de iptables y ejecutar por primera vez el script de swatch (/etc/init.d/swatch).

Oracle OTN LATAM tour 2015

noreply@blogger.com (Juan Pablo Orradre) — Sat, 15 Aug 2015 22:45:00 +0000

Los pasados 3 y 4 de agosto se llevó a cabo la edición 2015 del evento OTN LATAM tour de Oracle en la Facultad de Ingeniería de la Universidad ORT en Montevideo.

Dicho evento se viene realizando anualmente desde hace seis ediciones (por lo menos en Uruguay), y cuenta con el apoyo del grupo de usuarios Oracle del Uruguay - UYOUG -, la misma Universidad y del Ministerio de Educación y Cultura; además de Tilsor y Quanam, partners de Oracle aquí.

En él, durante cada año se conforma una gira por varios países del continente donde se realizan speeches y talleres prácticos de corte técnico y de actualización sobre productos y servicios que ofrece Oracle (Oracle, MySQL, Java, etc.), brindados por reconocidos Oracle ACEs regionales e internacionales.

Personalmente, desde el año pasado que estaba con ánimo de participar, pero por motivos ajenos a mi voluntad no pude hacerlo. Este año tuve la revancha y me dirigí a ver de qué se trataba el evento, ya que se orienta a profesionales vinculados a las áreas de DBA, TI y desarrollo, principalmente.

La verdad es que quedé sorprendido para bien por el buen nivel del evento en general, principalmente por la jerarquía y experiencia de los oradores, así como la practicidad al explicar conceptos un poco difíciles de asimilar que se introducen en las actualizaciones que se vienen dando.

Las charlas y talleres este año giraron en torno a la más reciente versión mayor de la BD Oracle, la 12c; además de los nuevos conceptos que se introducen con el trabajo en la nube.

El principal concepto que se introdujo en la 12c es el de Multitenant y según parece viene a significar en un cambio de paradigma en cuanto a su administración y funcionamiento.

Multitenant

Multitenant se basa en un cambio de arquitectura de las bases de datos, en donde se implementa una base de datos contenedora, que viene a ser una base de datos "raíz"; sobre las que trabajan todas las bases de datos pluggables que se dispongan (hasta 252 en la 12.1). Estas PDBs se pueden attachear o desattachear en pocos pasos, sin necesidad de exportar ni realizar otras tareas para enviarlas a otro servidor.

En la base de datos raíz ahora se pasa a alojar la metadata del SGBD (esquemas, tablas, secuencias, etc. del sistema).

En tanto, en las PDBs (pluggeable databases) se almacena la metadata propia de la aplicación, así como los objetos que contienen los datos de la aplicación en esa BD.

Este cambio de arquitectura trae varias ventajas como ser:

Posibilidad de transportar una PDB de un container a otro de manera muy limpia y fácil (incluso en sistemas con distinto endianness).
Fácil clonación de BDs. Éstos últimos dos items son de gran ayuda por ejemplo en el caso de copia de bases de desarrollo a producción.
Unificación de diversas tareas de administración, recovery, upgrade, etc., ya que se realizan ahora sobre la base raíz.
Unificación de recursos de BDs: Bajo este esquema se comparten por ejemplo redo, undo logs y la SGA, donde el SGBD comparte y gestiona la memoria y los procesos background de todas las bases de datos en la container.

Datos de interés de Multitenant

Si bien no es necesario tener una licencia especial para utilizar este tipo de arquitectura con 12c, para poder tener más de una PDB en un container se debe tener paga la opción de Multitenant.
Para poder pluggear una BD con versión anterior a 12c a una BD raíz, se debe anteriormente actualizar a 12c.
Para poder actualizar de una versión anterior a 12c, existen varios métodos disponibles, por lo que se debe elegir cual es el método de conveniencia: http://www.oracle.com/technetwork/database/upgrade/upgrading-oracle-database-wp-12c-1896123.pdf
Una vez que se migra a 12c, no se puede hacer downgrade de una PDB hacia una base de datos standalone. En este caso se debe pensar en algún método alternativo como un export por ejemplo.
A efectos de upgrade, instalación, ejecutar scripts de mantenimiento, etc; Oracle recomienda utilizar el PERL script catcon.pl. Este script, que tiene una cantidad grande de parámetros y utilidades, se debe correr con el ejecutable perl que se dispone en los binarios del SGBD.
En la versión 12.2 se va a eliminar la posibilidad de utilizar BDs standalone. En su lugar se deberá implementar una BD single-tenant.

In Memory Database

Otra característica importante que se incluye a partir de la versión 12.1 (no de la 12.0), es la funcionalidad In Memory.

Esta función permite que fragmentos o la totalidad de una base de datos trabaje en memoria para conseguir una mejora de performance significativa en cuanto a consultas.

El funcionamiento a grandes rasgos consiste en el almacenamiento de los datos de cada tupla ,paralelamente, en un formato columnar. Bajo este precepto, y como el motor de base de datos en cada consulta recorre campo por campo de una fila hasta llegar al requerido,al estar los datos de una sola columna alojados en una fila, las que consultas que levantan gran cantidad de datos experimentan una mejora sustancial en el tiempo que insumen.

Esto es particularmente útil por ejemplo si se desea mantener un ambiente transaccional en la misma base de datos que se utiliza para reportes, sin perjudicar mayormente la performance del sistema productivo.

Las estructuras In Memory se alojan en una nueva área de memoria dentro del servidor destinada para las mismas.

Además incluye varios niveles de compresión en cuanto a los datos alojados en esta área reservada, dependiendo la rapidez que se quiera obtener, de manera que el aumento de uso de memoria respecto a si no se utiliza esta funcionalidad ronda en un 20% aproximadamente.

Teniendo en cuenta las ventajas en cuanto arquitectura, y además que el acceso a memoria es bastante más rápido que el de disco duro, supone una mejora drástica.

Fuentes

Instructivo de actualización a 12c

https://drive.google.com/file/d/0B1nC__G5gAGlVEYwQkE0ajZYX0k/view?usp=sharing

Multitenant

http://www.oracle.com/technetwork/es/articles/database-performance/oracle-multitenant-parte1-2065486-esa.html

In Memory

http://www.oracle.com/technetwork/database/in-memory/overview/twp-dbim-usage-2441076.html?ssSourceSiteId=ocomen

Resumen

Es totalmente recomendable anotarse a estos eventos de OTN, ya que ofrece un pantallazo de lo que está a la vanguardia en cuanto al mundo Oracle.

Además es para tener en cuenta la actualización a 12c por todas las funcionalidades y mejoras que incluye, además de ser la versión que estará siendo referenciada en el mediano plazo.

Python: una tecnología a tener en cuenta

noreply@blogger.com (Juan Pablo Orradre) — Sun, 02 Aug 2015 16:28:00 +0000

Generalmente y en estos últimos tiempos se ha venido hablando de Python como una tecnología que se impone en los diversos estratos de la informática.

Hasta hace no mucho, no conocía este lenguaje salvo por haber oído opiniones de propios y ajenos, donde el denominador común era la buena crítica.

Finalmente me decidí por interiorizarme un poco de su historia, su propósito, sus ventajas y desventajas; para poder elaborar un juicio que me permitiese incluirlo dentro de las opciones a utilizar cuando de scripting se tratase.

Resulta que me encontré con algo más que con un lenguaje de scripting...

Python resultó ser una tecnología open source muy versátil que nos permite ya sea realizar scripts para hacer tareas simples, complejas para un script batch,pero también es perfectamente usable en aplicación más complejas.

Su arquitectura modular, multiparadigma (orientado a objetos, funcional, etc.) y altamente portable lo convierten en una de las primeras opciones a considerar en cualquier proyecto.
Por si fuera poco, su sintaxis simple y delimitada por tabulaciones y no por llaves como los lenguajes C-like, hacen que el resultado sea un desarrollo rápido, con código limpio y muy mantenible, resultando también en una menor cantidad de errores de programación.

Como muestra un botón, Google lo utiliza en muchos de sus proyectos, incluido su motor de búsqueda, por todas estas características mencionadas.

Además tiene una comunidad grande y activa, algo siempre muy útil cuando de dudas y proyectos se trata.

Uno podrá pensar también: bueno, es muy lindo pero sigue sin llegar a satisfacer mis necesidades para levantar una aplicación en un ambiente empresarial, como lo hace Java con su especificación J2EE y sus frameworks (Spring por ejemplo).

Pues bien, resulta que se dispone de un web framework muy completo llamado Django que hace las veces de esto último que mencioné. Es open source y gratis además.

Como si esto fuera poco, Python dispone de buenas librerías para las acciones cotidianas que podemos estar necesitando realizar (SSH - Paramiko, REST - Django REST Framework, etc,etc...).

Dejo a disposición la introducción de un libro de O'Reilly que ahonda en un análisis todos estos detalles que menciono.

Algunos piques:

- Existen dos ramas de evolución de Python: la 2.x y la 3.x.
A la hora tener que instalar debemos elegir cual de ellas vamos a utilizar.

En resumen, si se va a correr SW que no requiera módulos muy específicos que no hayan sido portado aún a la rama 3.x, es preferible instalar dicha versión, ya que posee varias mejoras y se trabaja con lo más actualizado. En caso contrario, instalar la 2.x de preferencia.

- En ambientes Unix-like , para instalar Python basta con un # dnf install python2.x/python3.x , o el gestor de paquetes utilizado.

Sus diversos paquetes se puede realizar fácilmente mediante un # dnf install python-nombre_del_paquete. También se puede instalar pip, que es un gestor de paquetes muy bueno también: # wget https://bootstrap.pypa.io/get-pip.py ; python get-pip.py;

- En Windows, se basta con correr el instalador msi preferido que se disponibiliza en la web de https://www.python.org/downloads/windows/

- Como IDE para desarrollo existen unos cuantos que mediante plugins o de manera nativa incluyen soporte para desarrollo en Python. Personalmente prefiero el PyCharm que es un IDE muy completo y simple de usar. Producto de JetBrains, creadores de IntelliJ Idea, de una modalidad muy similar.

- Para una introducción de Django se puede visitar http://www.djangobook.com/en/2.0/chapter01.html

Mediawiki

noreply@blogger.com (Juan Pablo Orradre) — Mon, 20 Jul 2015 02:52:00 +0000

La documentación de los procesos de una organización es un item fundamental a la hora de intentar establecer una mejor en la calidad de los mismos.

Frecuentemente las organizaciones de cualquier índole y tamaño, suelen guardar sus documentaciones en ficheros de archivos con una estructura un poco desorganizada (con suerte...). Esto ocasiona que cuando aumenta la cantidad de información allí alojada se convierta en una tarea cada vez más complicada el hecho de encontrar la información que estamos buscando.

Para solucionar estos problemas existe una alternativa libre y muy utilizada en todo el mundo: Mediawiki.

Se trata del software que utiliza Wikipedia , ni más ni menos, como plataforma en producción.

Es una solución hecha en PHP mayormente, que puede trabajar con diversos motores de bases de datos y posee una instalación y funcionamiento bastante modular, lo cual nos obliga a trabajar un poco pero a la vez lo convierte en un software bastante modular y personalizable según las necesidades de la organización en cuestión.

En esta entrada voy a publicar los pasos necesarios para realizar su instalación en un servidor Ubuntu 15.04 con una instalación mínima como ejemplo sobre un entorno LAMP.

Agregar repositorio de MariaDB

sudo apt-get install software-properties-common
sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xcbcb082a1bb943db
sudo add-apt-repository 'deb http://mirror.edatel.net.co/mariadb//repo/10.0/ubuntu vivid main'

Actualizar repositorios

sudo apt-get update

Apache2

sudo apt-get install apache2

PHP (versión > 5.3.3)

sudo apt-get install php5 php5-intl php5-mysql php5-gd php-apc

MariaDB

sudo apt-get install mariadb-server

Descargar e instalar Mediawiki

sudo sh -c "cd /var/www/html && wget 'https://releases.wikimedia.org/mediawiki/1.25/mediawiki-1.25.1.tar.gz' && tar xvfz mediawiki-1.25.1.tar.gz && rm mediawiki-1.25.1.tar.gz && mv mediawiki-1.25.1/ mediawiki/ && chown apache:apache mediawiki/ "

Habilitar logging de la aplicación

sudo sh -c "cd /var/www/html/mediawiki && mkdir log && chmod 775 log && cd log && touch debug-my_wiki.log && chmod 775 debug-my_wiki.log"

Agregar lo siguiente al final del LocalSettings.php

$wgDebugLogFile = '/var/www/html'.$wgScriptPath.'/log/debug-'.$wgDBname.'.log';
$wgShowExceptionDetails = true;
#Cuando se quiera debuggear en la misma web, habilitar la linea de abajo
#$wgShowDebug = true;

$wgFavicon = "$wgResourceBasePath/resources/assets/favicon.png";

$wgConfirmAccountRequestFormItems['Biography']['minWords'] = 0;

$wgSMTP = array(
'host' => 'ssl://smtp.gmail.com',
'IDHost' => 'mydomain.com',
'port' => 465,
'username' => 'webmaster@mydomain.com', ## or info@mydomain.com, or whatever email account you've set up for your Mediawiki installation
'password' => 'emailpasswordforwebmaster',
'auth' => true
);

Agregar extensión WYSIWYG para la edición de artículos

Bajar fuentes desde https://github.com/Mediawiki-wysiwyg/WYSIWYG-CKeditor
Ubicar el contenido en la carpeta extensions dentro de la carpeta de los archivos de Mediawiki.
Agregar luego al final del LocalSettings.php:

require_once '/var/www/html'.$wgScriptPath.'/extensions/WYSIWYG/WYSIWYG.php';

$wgGroupPermissions['*']['wysiwyg'] = true;

$wgDefaultUserOptions['cke_show'] = 'richeditor'; //Enable CKEditor
$wgDefaultUserOptions['riched_use_toggle'] = false; //Editor can toggle CKEditor/WikiText
$wgDefaultUserOptions['riched_start_disabled'] = false; //Important!!! else bug...
$wgDefaultUserOptions['riched_toggle_remember_sate'] = true; //working/bug?
$wgDefaultUserOptions['riched_use_popup'] = false; //Deprecated

Comentar el siguiente bloque en el archivo extensions/WYSIWYG/CKeditor.body.php por problema de compatibilidad:

/* foreach ( $out->styles as $key => $val ) {
if (count($out->styles[$key]) > 0) {
if (isset($out->styles[$key]['condition']) ||
isset($out->styles[$key]['dir']) ||
strpos($key, '?') !== false ||
strpos($key, 'jquery.fancybox') !== false) continue;
$count = 1;
$cssFile = dirname(__FILE__) . '/../../' . str_replace($wgScriptPath, '', $key, $count);
$cssFile = str_replace('//', '/', $cssFile);
if (isset($out->styles[$key]['media']) &&
file_exists($cssFile)) {
$cssCont = file_get_contents($cssFile);
if ($cssCont !== false) {
if (! isset($inlineStyles[$out->styles[$key]['media']]))
$inlineStyles[$out->styles[$key]['media']] = '';
$inlineStyles[$out->styles[$key]['media']] .= $cssCont."\n";
unset($out->styles[$key]);
}
}
}
}
*/

Modificar la carpeta images para la subida de imágenes:

mkdir /var/www/html/mediawiki-1.25.1/images/temp
chmod -R 777 /var/www/html/mediawiki-1.25.1/images

Agregar extensión CategoryTree para listar las categorías de artículos

Ver documentación de instalación en https://www.mediawiki.org/wiki/Extension:CategoryTree

Crear usuarios

cd /var/www/html/mediawiki/maintenance && read -s PASS && php createAndPromote.php --bureaucrat nomusuario $PASS && unset PASS

Migrar documentación existente en otro formato

Finalmente y luego de la puesta a punto de la Wiki, generalmente es necesario migrar toda nuestra documentación de otros formatos de texto tales como .doc, .docx y .odt al formato wiki.

Estuve revisando un tiempo mientras estuve con mi primera instalación y encontré que la wiki no tiene un conversor de este tipo embebido, ni tampoco hay mucho software que se maneje con estos tres formatos y realice la conversión.

Por esta razón es que decidí crearme un script hecho en Python que resuelva este tema:

https://github.com/jporradre/Useful-scripts/blob/master/docs_to_wiki.py

Instalación de PHP (RHEL like)

noreply@blogger.com (Juan Pablo Orradre) — Sat, 27 Jun 2015 00:25:00 +0000

En esta segunda entrada voy a compartir mi experiencia al instalar PHP en un servidor con SO RHEL like (RHEL, CentOS, Fedora).

Resulta que estando en mi casa trabajando en mi home server realizando la instalación de Owncloud (software para crear una nube privada), precisaba instalar PHP arriba del httpd que tenía como webserver.

Al estar sin apuro y en el afán de investigar un poco intenté instalar PHP desde su código fuente, pensando que era soplar y hacer botella.

Resulta que no fue tan así je, ya que se precisan especificar todos los módulos de PHP a levantar previamente .

Tengan en consideración que los módulos a instalar dependen de la necesidad de cada uno, esta configuración por ejemplo sirve para poder instalar Owncloud como mencionaba.

En principio lo que tuve que hacer fue bajarme los fuentes :

wget http://www.php.net/get/php-5.6.9.tar.bz2/from/this/mirror;
tar xf php-5.6.9.tar.bz2;

cd php-5.6.9/;

Luego instalar todas las herramientas y librerías de desarrollo necesarias:

dnf install gcc gcc-c++ ne2c bison httpd-devel libxml2-devel openssl-devel bzip2-devel curl-devel libpng-devel libjpeg-devel libXpm-devel freetype-devel t1lib-devel gmp-devel libicu-devel libmcrypt-devel postgresql-devel aspell-devel libtidy libtidy-devel readline-devel libxslt-devel;

Luego preparar la instalación con configure e instalar desde el archivo makefile

./configure --with-libdir=lib64 --prefix=/usr/local --with-layout=PHP --with-pear --with-apxs2=/usr/sbin/apxs --enable-calendar --enable-bcmath --with-gmp --enable-exif --with-mcrypt --enable-ctype --with-zlib --enable-fileinfo --with-bz2=/usr/bin/bzip2 --enable-zip --with-pgsql=/usr/pgsql-9.3 --with-pdo-pgsql --enable-ftp --enable-mbstring --with-iconv --enable-intl --with-icu-dir=/usr --with-gettext --with-pspell --enable-sockets --with-openssl --with-curl --with-gd --enable-gd-native-ttf --with-jpeg-dir=/usr/lib--with-png-dir=/usr/lib --with-zlib-dir=/usr/lib --with-xpm-dir=/usr --with-freetype-dir=/usr/lib --with-t1lib=/usr/lib --with-libxml-dir=/usr/lib --enable-soap --with-xmlrpc --with-xsl --with-tidy --with-readline --enable-pcntl --enable-sysvshm --enable-sysvmsg --enable-shmop;

make && make install;

Luego, se debe copiar el archivo template de configuración de php.ini y modificar a gusto de consumidor:

cp php.ini-dist /usr/local/lib/php.ini;

Por último y no menos importante, se reinicia el servicio httpd para que queden

systemctl restart httpd;

Para verificar que haya quedado todo correcto se debe crear un script que ejecute la función phpinfo de PHP, ubicarlo en la carpeta contenedora de httpd, y abrir en un navegador web la URL http://URLDELSERV/info.php

echo "<?php phpinfo(); ?>" > info.php && mv info.php /var/www/html;

Érase una vez...

noreply@blogger.com (Juan Pablo Orradre) — Wed, 24 Jun 2015 21:32:00 +0000

Porque todo debe tener un principio (y también un final), es que inicio este blog con el motivo de compartir un poco las actividades que desarrollo, mis vivencias en el universo DevOps , retroalimentarme con sus devoluciones y mechar de tanto en tanto con alguna entrada referida a mis hobbies je.