[Jderobot-admin] Política de nombres y cambio de versión de Debian

Jue Mayo 30 12:45:45 CEST 2013

El 30/05/2013 12:08, Borja Mon Serrano escribió:
> Os pongo dos temas a tratar a modo de consulta.
>
> - Lo primero de todo, hemos estado valorando la opción de quitar el 
> index.php que aparece en la url del mediawiki de jderobot. Realmente 
> es algo que no tiene mucho sentido que esté ahí. He estado realizando 
> los pasos que se detallan en [1], en concreto la sección "Setting up 
> the rewrite rules". La verdad es que es bastante sencillo y he podido 
> comprobar que funciona.

Yo lo tengo así y, la verdad, es que da un aspecto más elegante a las 
URLs. Habría que pensar también en dejar un index.php que redirigiera 
las URLs viejas (enviando una respuesta HTTP de redirección permanente 
http://en.wikipedia.org/wiki/HTTP_301) o bien usar un "RedirectMatch 
permanent" en el .htaccess que hiciera la misma función.

Así no perderíamos las entradas a la wiki que contengan URLs antiguas, 
no sólo de buscadores, si no de páginas personales, blogs, etc que 
tengan otros usuarios.

> El único problema que existe en esa solución son los recursos 
> almacenados en el recurso /store (donde los usuarios tenemos nuestros 
> documentos, vídeos, imágenes, etc. de jderobot), ya que entonces los 
> considera parte del mediawiki y te dice de crear una página de 
> mediawiki. ¿Sabéis si hay alguna manera directa de evitar esto?

Claro que sí, hay dos soluciones:

  * Crear un directorio "/mediawiki/" con el código fuente y el alias
    (no necesita rewrite) en "/wiki/". Así es como lo tengo en dos wikis
    que tenemos en la empresa, permite tener varias páginas y contenidos
    de diferente índole en una misma URL base. Con un "Alias /wiki
    "/ruta_base/mediawiki/index.php" sería suficiente (en .htaccess o en
    la configuración del virtualhost en apache).
  * Hacer una regla de rewrite que haga un "break" en aquellos
    directorios que queramos mantener. Esto tiene el inconveniente de
    tener que agregar un "RewriteRule ^directorio($|/) - [L]" por cada
    directorio que queramos mantener sin reglas de reescritura.

Yo, personalmente, prefiero la primera opción por darte menos trabajo de 
mantenimiento, un usuario o webmaster puede crear nuevos directorios sin 
tener que contactar con el sysadmin para que los incluya en las 
excepciones de las reglas de reescritura.

> Si no, lo que he pensado como solución (supongo que sencilla y que 
> valdría) es crear un nuevo servicio que gestione los recursos de los 
> usuarios, de forma que al final todos colgasen de algo parecido a 
> store.jderobot.org/ <http://store.jderobot.org/><user>, 
> media.jderobot.org/ <http://media.jderobot.org/><user> o algo por el 
> estilo, vaya. ¿Qué opináis? ¿Es la mejor solución?

Es también otra opción, pero si ya hay que arreglar las redirecciones 
persistentes de la wiki... hacerlo también con las imágenes será más 
trabajo.

> - Lo segundo, como ya sabréis, han puesto como estable a Debian 7.0 y 
> el servidor está bajo Debian 6.0, que dejará de tener soporte dentro 
> de muy poco. Habíamos pensado en actualizar, claro, y en un principio 
> no debería de haber problemas, pero, a parte de hacer un backup de lo 
> más importante, ¿qué precauciones adicionales habría que tomar? 
> ¿Conocéis de alguna incompatibilidad con nuevos paquetes que pudieran 
> afectar a la migración? Yo, por lo que he visto en [2], creo que el 
> mayor problema sería el del LDAP, los demás no parecen afectar en 
> mucho a nuestro servidor; pero quería tener más valoraciones sobre 
> esta migración.

Hace poco acabo de migrar dos máquinas de Debian 6 a 7 y en cuanto a la 
autenticación LDAP de usuarios con nslcd, libnss-ldapd, etc y todo ha 
ido como la seda. Todo lo contrario, ahora tengo la funcionalidad de 
obtener los uid y gid a partir del propio objectSid usando "map    
passwd uidNumber     objectSid:S-...", cosa que no tenía con la versión 
anterior, tenía que meter los uids en cada usuario de dominio windows 
para que funcionara.

En cuanto a clientes web o PHP supongo que tampoco, pero siempre puedes 
montar un entorno de desarrollo o calidad (preproducción) para probar la 
migración, es lo que hacemos en mi empresa (por eso he migrado y probado 
dos servidores, el de calidad primero y el de producción después).

>
> Un saludo,
> Borja.

Un saludo.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jderobot-admin/attachments/20130530/eec55c75/attachment.htm 