StyXman's glob http://grulicueva.homelinux.net/~mdione/glob//tags/mercurial/ StyXman's glob ikiwiki 2009-01-22T04:24:04Z http://grulicueva.homelinux.net/~mdione/glob//posts/trac-con-mercurial-en-etch/ 2009-01-22T04:24:04Z 2008-07-18T01:09:46Z <p>Desde hace como dos semanas que vengo esporádicamente peleando con un problema: Tenía que poner a andar el plugin de Mercurial para Trac. Según <a href= "http://trac.edgewall.org/wiki/TracMercurial">las instrucciones de la página</a>, sólo es cuestión de generar un <code>.egg</code> (<a href="http://grulicueva.homelinux.net/~mdione/glob//tags/mercurial/posts/trac-me-tiene-los-eggs-llenos/">¿se acuerdan?</a>), ponerlo en el directorio <code>plugins</code> del environment y ya. Pero corriendo <code>tracd</code> y entrando con un browser me daba:</p> <pre> <code>TracError: Unsupported version control system "hg" </code> </pre> <p>Mi primer sospechoso era el <code>.egg</code>; creía que no lo estaba encontrando. Prendiendo el logging en el <code>trac.ini</code> descubrí que en realidad si lo levantaba. Siguiendo un par de links encontré una sugerencia de correr todos los imports que corre el <code>backend.py</code> del plugin. Finalmente descubrí que la línea:</p> <pre> <code>from mercurial.revlog import LookupError </code> </pre> <p><a href= "http://trac.edgewall.org/ticket/7346#comment:6">fallaba</a>. Se vé que el Mercurial que viene en Etch (0.9.1-1+etch1) no es del todo compatible, a pesar que la página del plugin dice que lo es, inclusive hasta con 0.8. Para "repararlo" simplemente saué las (1) referencias a <code>LookupError</code>.</p> <p><a href="http://grulicueva.homelinux.net/~mdione/glob//tags/mercurial/../trac/">trac</a> <span class= "selflink">mercurial</span> <a href="http://grulicueva.homelinux.net/~mdione/glob//tags/mercurial/../sysadmin/">sysadmin</a></p> http://grulicueva.homelinux.net/~mdione/glob//posts/apache-como-wrapper-de-ssl/ 2009-01-22T04:24:04Z 2008-07-04T23:29:16Z <p>Hoy me tocó hacer una negrada marca cañón. Resulta que tenemos un <a href="https://beetroot.except.com.ar/xarope/">Xarope</a> andando. En la arquitectura de Xarope tenemos un Apache que nos hace de frontend a todos los sitios Zope que corren en los DomU's.</p> <p>El tema es que estaba poniendo a andar en uno de los DomU's un repo <a href= "http://www.selenic.com/mercurial/wiki/">Mercurial</a>, el cual corre detrás de un <a href="http://www.lighttpd.net/">lighty</a>. Ponerlo a andar no fue muy duro, salvo que no sabía mucho ni de uno ni del otro. Cuestión que llegué al punto en que podía hacer un <code>hg clone</code> para bajarme una copia del repo, mas no hacer un <code>push</code>. Acá es donde se ponía peluda la cosa.</p> <p>El problema es el siguiente: para que las passwds no anden volando en cueros tenía que poder acceder al repo por <code>https</code>. Ahora, repiensen el esquema: tengo un Apache al que le llegan los pedidos <code>https</code>, el que a través de un <code>Rewrite</code> forwardea el pedido al Lighttpd corriendo en otra máquina (virtual, pero no viene al caso). Por razones casi obvias forwardear de un 443 a un 443 no anda. ¡Pero resulta que si el forward es al 80 si!</p> <p>Es decir, el Apache recibe <code>https</code>, y cuando forwardea el pedido, lo hace en <code>http</code> plano. Esto responde a mi pregunta "¿Comocatzo vamos a hacer cuando los usuarios de Zope pidan acceso por <code>https</code>?". La única contra que le veo a este setup es que el sitio final (sea un Zope o un repo Mercurial) no sabe si el acceso viene con SSL o no.</p> <p><a href="http://grulicueva.homelinux.net/~mdione/glob//tags/mercurial/../sysadmin/">sysadmin</a> <a href="http://grulicueva.homelinux.net/~mdione/glob//tags/mercurial/../lighttpd/">lighttpd</a> <a href="http://grulicueva.homelinux.net/~mdione/glob//tags/mercurial/../apache/">apache</a> <a href="http://grulicueva.homelinux.net/~mdione/glob//tags/mercurial/../ssl/">ssl</a> <span class="selflink">mercurial</span> <a href="http://grulicueva.homelinux.net/~mdione/glob//tags/mercurial/../xarope/">xarope</a></p>