Oct 31

Actualizando mediawiki

 

Respecto al crackeo sufrido, me puse manos a la obra. Borré los scripts maliciosos que me habían puesto en la página y estuve vigilando el log de errores de acceso, para ver desde qué IP intentaban acceder a ellos. Una vez localizada la IP, la he "baneado"  (supongo que no servirá de mucho, porque el que sea tendrá posibilidad fácil de cambiarse de IP) y he visto que después de los accesos fallidos ha intentado acceder a la Chuwiki.

Pues bien, wordpress (este blog) y el SMF (el foro de java) se actualizan muy fácilmente. Basta entrar como administrador y el mismo panel de control te avisa de que hay una versión nueva. Le das a un botón y se actualiza todo solo. Pero no es así con mediawiki y por eso no tenía actualizada mediawiki a la última. De hecho, la versión es la primera que instalé hace ya fácilmente tres años. Tiene toda la pinta de que se han colado por ahí, explotando alguna vulnerabilidad de la mediawiki (aunque no tengo ninguna garantía). Por ello la he actualizado a la última…. ¡¡ y me he entretenido un montón !!.

Resulta que la actualización es más o menos sencilla, basta con hacer el consabido backup por si acaso, desempaquetar la nueva mediawiki sobre la antigua, tocar un fichero para poner el usuario y password de base de datos y  … ¡¡ ejecutar un script php desde línea de comandos !!. En este último punto es donde ha venido el entretenimiento.

No puedo ejecutar ese script llamándolo desde el navegador. El script detecta que no se está haciendo desde la máquina local y te dice que no tienes permisos. Tampoco tengo acceso a una línea de comandos de mi proveedor. Bueno, quizás sí tengo acceso, pero con todo el tema de certificados de seguridad, firmas digitales y demás que por un lado, no tengo ni idea de cómo se hace y que por otro lado, desde mi windows, no es tan sencillo y hay que andar instalando cosas como Putty. Así que por no echarme unas horas con eso, busqué otro método.

Y encontré uno la mar de entretenido. Resulta que desde mi panel de control web puedo programar tareas a ejecutarse en el servidor (comando cron para los que sabe de linux). Así que a eso me puse.

  1. Comando cron para ejecutar "php -version" cada cinco minutos y recibir el correo con la salida del comando. Esto me sirve para saber si está el ejecutable php accesible. Lo de cada cinco minutos es porque como el servidor está en estados unidos, cualquiera adivina su hora exacta. Y cinco minutos para darme tiempo a recibir el correo y parar el cron. antes de que se ejecute por segunda vez. Correo afirmativo, está accesible php.
  2. Ahora otro cron cada cinco minutos para ejecutar un ‘pwd’ (ver el directorio en el que se ejecuta el cron) y así saber que path tengo que poner para llegar al script de php. A los cinco minutos, ya sé el directorio de ejecución.
  3. Y finalmente otro cron ejecutar el comando ‘php path/update_wiki.php’. Espera y ejecución correcta. Pruebo la wiki recién instalada y funciona bien, salvo un pequeño susto que comento al final.

Bueno, lo del cron no es que sea nada del otro mundo, pero lo que me ha llamado muchísimo la atención es la forma rupestre de ir ejecutando los comandos. Es como si estuviras programando un satélite a dos minutos luz. Ejecutas el comando y entre que va y vuelve, esperas cinco minutos por el resultado (lo siento, leo mucha ciencia ficción).

Y una pequeña estupidez de la actualización. Resulta que han cambiado la página principal de la mediawiki y ahora, en vez de "Portada", se llama "Página Prncipal", así que me llevé un pequeño susto cuando veo por primera vez la wiki recién instalada y aparace la página incial vacía.

 

ACTUALIZACIÖN: Mandé el Jueves la solicitud a google para volver a aparecer en el buscador y hoy, sábado, parece que ya aparezco. :-)

Mar 12

Personalizando MediaWiki

 

Hace tiempo comenté que tenía un problema con la página aleatoria de la Wiki y el amigo google. Buscando una palabra en google, este me mostraba un enlace a la Chuwiki. Casualmente, este enlace, en vez de ser al artículo original, era la página aleatoria de la Chuwiki, por lo que pulsando el enlace mostrado por google, me iba a una página aleatoria y no a la buscada.

Hace un par de días volví a tropezarme con el problema. Busqué no sé qué en google, apareció un artículo de la Chuwiki, pinché el enlace y acabé en una página aleatoria. Así que me he decidido a arreglarlo. Por supuesto, para variar y por culpa mía, el cambio ha sido una pequeña odisea.

Lo primero de todo, por supuesto, ponerme a urgar en los ficheros php de MediaWiki, a ver dónde demonios está ese enlace de página aleatoria para quitarlo. Después de un par de horas de revisar el código, ir de un lado a otro, dar mil vueltas y no llegar a ningún sitio (está oculto el dichoso enlace), me decidí a hacer lo que debería haber hecho desde el principio: consultar la ayuda de la MediaWiki.

Las cajas de menú de la izquierda de la MediaWiki son bastante fáciles de modificar. Con permisos de administrador basta desde la misma web, editar la página MediaWiki:Sidebar. En esa página aparece el menú y se puede modificar a gusto. Para editar esa página, que no está fácilmente accesible, hay que poner la url directamente en el navegador:

http://www.tuwiki.com/index.php?title=MediaWiki:Sidebar&action=edit

y listo, ahí ponemos lo que queramos, incluso más cajas de menús. Tienes los detalles en Manual:Interface/Sidebar de la MediaWiki.

De todas formas y como siempre tiene que haber algo que incordie, después de hacer los cambios no veia en absoluto modificado el menú. El dichoso firefox tenía guardada la página en memoria y no me cambiaba el menú. Me dí cuenta al visitar otra página de la Chuwiki y ver que ahí si estaban cambiados los menús. Así que cada vez que hacía un cambio, no me quedaba más remedio que vaciar la caché del firefox ("herramientas"->"limpiar datos privados").

Dec 04

Segundas impresiones con Redmine

Ya llevamos una semana larga usando redmine y ya voy encontrando algunas "peguillas". Realmente no son fallos del programa, sino que estoy mal acostumbrado a otras herramientas.

Por un lado, usamos habitualmente bugzilla, que es una herramienta específica para llevar el tema de bugs. Y por supuesto, una herramienta específica que lleva ya bastante tiempo en funcionamiento es mucho más completa y con más posibilidades que una gestión de incidencias en una herramienta que hace más cosas y es más nueva. Ahí van unas cuantas cosas que echo en falta (y que algunos compañeros me han comentado también):

  • En redmine no hay posibilidad de poner "con copia" en los bugs para que reciba el correo no solo la persona asignada, sino quizás también su jefe u otra persona que pueda saber algo sobre ese bug aunque no sea la encargada de resolverla. Parece que tampoco puede enviar automáticamente el correo semanal recordando a la gente que tiene "un montón de bugs pendientes".
  • También echo en falta la facilidad de bugzilla para cambiar estados de los bugs. Con redmine me he encontrado, por ejemplo, que no puedo reabrir una incidencia cerrada, pero no sé en qué ocasiones, porque en otras sí me deja.
  • Finalmente, la posibilidad de generar informes con las incidencias, no es que bugzilla sea ninguna maravilla generando informes, pero tiene más posibilidades que redmine.
  • Tampoco parece muy lógico en redmine que mezcla los comentarios de resolución de incidencias/tareas con comentarios de cambios en el porcentaje de tiempo invertido en la tarea. Si miro la historia de una incidencia/tarea, veré consecutivamente todos los comentarios asociados, tanto específicos de la resolución, como de cambios de tiempos.

En cuanto a la wiki integrada en redmine, estoy acostumbrado a usar mediawiki, otra herramienta específica de wiki con mucha andadura (de hecho, es la que usa wikipedia). No he usado demasiado la wiki de redmine, pero da la impresión de ser más sencilla que mediawiki.

Así que todo esto me está haciendo replantear algunas cosas:

  • Seguir usando redmine, pero sólo como herramienta de planificación, con hitos, versiones y tareas a realizar.
  • Seguir usando bugzilla para los bugs, pero sólo bugs de los que son fallos, no mejoras.
  • Usar la wiki de redmine para especificaciones y cosas propias de los proyectos. Seguir usando mediawiki para cosas más generales no específicas de un proyecto concreto, como guía de estilo, de buenas costumbres, tutoriales, normas generales a seguir en todos los proyectos, etc.

No me gusta lo de tener las tareas por un lado y los bugs por otro, así que le daré otra "pensada" al tema.

Apr 21

Más spam en la Chuwiki

Llevo unos días recibiendo spam en la Chuwiki. Varias veces al día crean una página de nombre "Titulo incorrecto" con un montón de enlaces de spam y desde IPs distintas.

Llevo varios días borrando esa página. Al ver que el tema seguía, me decidí a bloquear las IPs de donde proviene ese spam, pero parece que no se les acaban. Seguramente están usando un proxy de IP dinámica, de esos que sirven para ocultar la IP real.

Mirando en la documentación de MediaWiki veo que existen cosas como Captchas estilo ConfirmEdit, pero no parece que sea de fácil instalación y sobre todo porque en los primeros párrafos empiezan a contar rollos de versiones que, por supuesto, yo no tengo.

Así que al final, encontré cómo hacer para que un usuario no registrado no pueda crear páginas, que básicamente consiste en editar el fichero LocalSettings.php y añadirle una línea como

$wgGroupPermissions['*']['create'] = false;

con lo que no permite a usuarios anónimos (debe ser el *) crear (por lo de create) páginas nuevas.

Es una pequeña limitación, pero supongo que a alguien que quiera crear una página y se vaya a poner a escribir algo en serio en ella, no le costará mucho más esfuerzo registrarse y darse de alta.