hgbook
annotate es/collab.tex @ 964:6b680d569bb4
deleting a bunch of files not longer necessary to build the documentation.
Adding missing newly files needed to build the documentation
Adding missing newly files needed to build the documentation
| author | Romain PELISSE <belaran@gmail.com> |
|---|---|
| date | Sun Aug 16 04:58:01 2009 +0200 (2009-08-16) |
| parents | 801442e58e6d |
| children |
| rev | line source |
|---|---|
| igor@412 | 1 \chapter{Colaborar con otros} |
| igor@402 | 2 \label{cha:collab} |
| igor@402 | 3 |
| igor@412 | 4 Debido a su naturaleza descentralizada, Mercurial no impone política |
| igor@412 | 5 alguna de cómo deben trabajar los grupos de personas. Sin embargo, si |
| jerojasro@414 | 6 usted es nuevo al control distribuido de versiones, es bueno tener |
| igor@412 | 7 herramientas y ejemplos a la mano al pensar en posibles modelos de |
| igor@412 | 8 flujo de trabajo. |
| igor@412 | 9 |
| igor@412 | 10 \section{La interfaz web de Mercurial} |
| igor@412 | 11 |
| igor@412 | 12 Mercurial tiene una poderosa interfaz web que provee bastantes |
| igor@412 | 13 capacidades útiles. |
| igor@412 | 14 |
| igor@412 | 15 Para uso interactivo, la interfaz le permite visualizar uno o varios |
| jerojasro@516 | 16 repositorios. Puede ver el historial de un repositorio, examinar cada |
| jerojasro@520 | 17 cambio (comentarios y diferencias), y ver los contenidos de cada |
| igor@412 | 18 directorio y fichero. |
| igor@412 | 19 |
| jerojasro@542 | 20 Adicionalmente la interfaz provee notificaciones RSS de los cambios de los |
| igor@412 | 21 repositorios. Que le permite ``subscribirse''a un repositorio usando |
| jerojasro@542 | 22 su herramienta de lectura de notificaciones favorita, y ser notificado |
| igor@412 | 23 automáticamente de la actividad en el repositorio tan pronto como |
| igor@412 | 24 sucede. Me gusta mucho más este modelo que el estar suscrito a una |
| igor@412 | 25 lista de correo a la cual se envían las notificaciones, dado que no |
| igor@412 | 26 requiere configuración adicional de parte de quien sea que está |
| igor@412 | 27 administrando el repositorio. |
| igor@412 | 28 |
| igor@412 | 29 La interfaz web también permite clonar repositorios a los usuarios |
| igor@412 | 30 remotos, jalar cambios, y (cuando el servidor está configurado para |
| jerojasro@542 | 31 permitirlo) publicar cambios en el mismo. El protocolo de entunelamiento |
| igor@412 | 32 de Mercurial comprime datos agresivamente, de forma que trabaja |
| igor@412 | 33 eficientemente incluso con conexiones de red con poco ancho de banda. |
| igor@412 | 34 |
| igor@412 | 35 La forma más sencilla de iniciarse con la interfaz web es usar su |
| igor@412 | 36 navegador para visitar un repositorio existente, como por ejemplo el |
| igor@412 | 37 repositorio principal de Mercurial \url{http://www.selenic.com/repo/hg?style=gitweb}. |
| igor@412 | 38 |
| igor@412 | 39 Si está interesado en proveer una interfaz web a sus propios |
| igor@412 | 40 repositorios, Mercurial provee dos formas de hacerlo. La primera es |
| igor@412 | 41 usando la orden \hgcmd{serve}, que está enfocada a servir ``de forma |
| igor@412 | 42 liviana'' y por intervalos cortos. Para más detalles de cómo usar |
| igor@412 | 43 esta orden vea la sección~\ref{sec:collab:serve} más adelante. Si |
| igor@412 | 44 tiene un repositorio que desea hacer permanente, Mercurial tiene |
| igor@412 | 45 soporte embebido del \command{ssh} para publicar cambios con seguridad |
| igor@412 | 46 al repositorio central, como se documenta en la |
| igor@412 | 47 sección~\ref{sec:collab:ssh}. Es muy usual que se publique una copia |
| igor@412 | 48 de sólo lectura en el repositorio que está corriendo sobre HTTP usando |
| igor@412 | 49 CGI, como en la sección~\ref{sec:collab:cgi}. Publicar sobre HTTP |
| igor@412 | 50 satisface las necesidades de la gente que no tiene permisos de |
| igor@412 | 51 publicación y de aquellos que quieren usar navegadores web para |
| jerojasro@516 | 52 visualizar el historial del repositorio. |
| igor@412 | 53 |
| igor@412 | 54 \subsection{Trabajo con muchas ramas} |
| igor@412 | 55 |
| jerojasro@542 | 56 Los proyectos de cierta talla tienden naturalmente a progresar de |
| igor@412 | 57 forma simultánea en varios frentes. En el caso del software, es común |
| igor@412 | 58 que un proyecto tenga versiones periódicas oficiales. Una versión |
| igor@412 | 59 puede entrar a ``modo mantenimiento'' por un tiempo después de su |
| igor@412 | 60 primera publicación; las versiones de mantenimiento tienden a contener |
| igor@412 | 61 solamente arreglos de fallos, pero no nuevas características. En |
| igor@412 | 62 paralelo con las versiones de mantenimiento puede haber una o muchas |
| igor@412 | 63 versiones futuras pueden estar en desarrollo. La gente usa normalmente |
| igor@412 | 64 la palabra ``rama'' para referirse a una de las direcciones |
| igor@412 | 65 ligeramente distintas en las cuales procede el desarrollo. |
| igor@412 | 66 |
| igor@412 | 67 Mercurial está especialmente preparado para administrar un buen número |
| igor@412 | 68 de ramas simultáneas pero no idénticas. Cada ``dirección de |
| igor@412 | 69 desarrollo'' puede vivir en su propio repositorio central, y puede |
| igor@412 | 70 mezclar los cambios de una a otra de acuerdo con las necesidades. Dado |
| igor@412 | 71 que los repositorios son independientes, uno del otro, los cambios |
| igor@412 | 72 inestables de una rama de desarrollo nunca afectarán una rama estable |
| igor@412 | 73 a menos que alguien explícitamente mezcle los cambios. |
| igor@412 | 74 |
| igor@412 | 75 A continuación un ejemplo de cómo podría hacerse esto en la |
| igor@412 | 76 práctica. Digamos que tiene una ``rama principal'' en un servidor |
| igor@412 | 77 central. |
| igor@402 | 78 \interaction{branching.init} |
| igor@412 | 79 Alguien lo clona, hace cambios locales, los prueba, y los publica allí |
| igor@412 | 80 mismo. |
| igor@412 | 81 |
| igor@412 | 82 Una vez que la rama principal alcanza una estado de versión se puede |
| igor@412 | 83 usar la orden \hgcmd{tag} para dar un nombre permanente a la revisión. |
| igor@402 | 84 \interaction{branching.tag} |
| igor@412 | 85 Digamos que en la rama principal ocurre más desarrollo. |
| igor@402 | 86 \interaction{branching.main} |
| igor@412 | 87 Cuando se usa la etiqueta con que se identificó la versión, la gente |
| igor@412 | 88 puede clonar el repositorio en cualquier momento en el futuro |
| igor@412 | 89 empleando \hgcmd{update} para obtener una copia del directorio de |
| igor@412 | 90 trabajo exacta como cuando se creó la etiqueta de la revisión que se |
| igor@412 | 91 consignó. |
| igor@402 | 92 \interaction{branching.update} |
| igor@402 | 93 |
| igor@412 | 94 Adicionalmente, justo después de que la rama principal se etiquete, |
| igor@412 | 95 alguien puede clonarla en el servidor a una nueva rama ``estable'', |
| igor@412 | 96 también en el servidor. |
| igor@402 | 97 \interaction{branching.clone} |
| igor@402 | 98 |
| igor@412 | 99 Alguien que requiera hacer un cambio en la rama estable puede clonar |
| igor@412 | 100 \emph{ese} repositorio, hacer sus cambios, consignar y publicarlos |
| igor@412 | 101 posteriormente al inicial. |
| igor@402 | 102 \interaction{branching.stable} |
| igor@412 | 103 Puesto que los repositorios de Mercurial son independientes, y que |
| igor@412 | 104 Mercurial no mueve los cambios de un lado a otro automáticamente, las |
| igor@412 | 105 ramas estable y principal están \emph{aisladas} la una de la otra. |
| igor@412 | 106 Los cambios que haga en la rama principal no ``se filtran'' a la rama |
| igor@412 | 107 estable o vice versa. |
| igor@412 | 108 |
| igor@412 | 109 Es usual que los arreglos de fallos de la rama estable deban hacerse |
| igor@412 | 110 aparecer en la rama principal también. En lugar de reescribir el |
| igor@412 | 111 arreglo del fallo en la rama principal, puede jalar y mezclar los |
| igor@412 | 112 cambios de la rama estable a la principal, Mercurial traerá tales |
| igor@412 | 113 arreglos por usted. |
| igor@402 | 114 \interaction{branching.merge} |
| jerojasro@542 | 115 La rama principal contendrá aún los cambios que no están en la |
| igor@412 | 116 estable y contendrá además todos los arreglos de fallos de la rama |
| igor@412 | 117 estable. La rama estable permanece incólume a tales cambios. |
| igor@402 | 118 |
| igor@417 | 119 \subsection{Ramas de Características} |
| igor@417 | 120 |
| igor@417 | 121 En proyectos grandes, una forma efectiva de administrar los cambios es |
| igor@417 | 122 dividir el equipo en grupos más pequeños. Cada grupo tiene una rama |
| igor@417 | 123 compartida, clonada de una rama ``principal'' que conforma el proyecto |
| igor@417 | 124 completo. Aquellos que trabajan en ramas individuales típicamente |
| igor@417 | 125 están aislados de los desarrollos de otras ramas. |
| igor@402 | 126 |
| igor@402 | 127 \begin{figure}[ht] |
| igor@402 | 128 \centering |
| igor@402 | 129 \grafix{feature-branches} |
| igor@417 | 130 \caption{Ramas de Características} |
| igor@402 | 131 \label{fig:collab:feature-branches} |
| igor@402 | 132 \end{figure} |
| igor@402 | 133 |
| igor@417 | 134 Cuando una rama particular alcanza un estado deseado, alguien del |
| igor@417 | 135 equipo de características jala y fusiona de la rama principal hacia |
| igor@417 | 136 la rama de características y publica posteriormente a la rama principal. |
| igor@417 | 137 |
| igor@417 | 138 \subsection{El tren de publicación} |
| igor@417 | 139 |
| igor@417 | 140 Algunos proyectos se organizan al estilo``tren'': Una versión se |
| igor@417 | 141 planifica para ser liberada cada cierto tiempo, y las características |
| igor@417 | 142 que estén listas cuando ha llegado el momento ``tren'', se incorporan. |
| igor@417 | 143 |
| igor@417 | 144 Este modelo tiene cierta similitud a las ramas de características. La |
| igor@417 | 145 diferencia es que cuando una característica pierde el tren, alguien en |
| igor@417 | 146 el equipo de características jala y fusiona los cambios que se fueron |
| igor@417 | 147 en la versión liberada hacia la rama de característica, y el trabajo |
| igor@417 | 148 continúa sobre lo fusionado para que la característica logre estar en |
| igor@417 | 149 la próxima versión. |
| igor@417 | 150 |
| igor@417 | 151 \subsection{El modelo del kernel linux} |
| igor@417 | 152 |
| igor@417 | 153 El desarrollo del Kernel Linux tiene una estructura jerárquica |
| igor@417 | 154 bastante horizontal, rodeada de una nube de caos aparente. Dado que la |
| igor@417 | 155 mayoría de desarrolladores usan \command{git}, una herramienta distribuida |
| igor@417 | 156 de control de versiones con capacidades similares a Mercurial, resulta |
| igor@417 | 157 de utilidad describir la forma en que el trabajo fluye en tal |
| igor@417 | 158 ambiente; si le gustan las ideas, la aproximación se traduce bien |
| igor@417 | 159 entre Git y Mercurial. |
| igor@417 | 160 |
| igor@417 | 161 En el centro de la comunidad está Linus Torvalds, el creador de Linux. |
| igor@417 | 162 Él publica un único repositorio que es considerado el árbol |
| igor@417 | 163 ``oficial'' actual por la comunidad completa de |
| igor@417 | 164 desarrolladores. Cualquiera puede clonar el árbol de Linus, pero él es |
| igor@417 | 165 muy selectivo acerca de los árboles de los cuales jala. |
| igor@417 | 166 |
| jerojasro@419 | 167 Linus tiene varios ``lugartenientes confiables''. Como regla, él jala |
| igor@417 | 168 todos los cambios que ellos publican, en la mayoría de los casos sin |
| igor@417 | 169 siquiera revisarlos. Algunos de sus lugartenientes generalmente |
| igor@417 | 170 aceptan ser los ``mantenedores'', responsables de subsistemas |
| igor@417 | 171 específicos dentro del kernel. Si un hacker cualquiera desea hacer un |
| igor@417 | 172 cambio a un subsistema y busca que termine en el árbol de Linus, debe |
| jerojasro@419 | 173 encontrar quién es el mantenedor del subsistema y solicitarle que |
| igor@417 | 174 tenga en cuenta su cambio. Si el mantenedor revisa los cambios y está |
| igor@417 | 175 de acuerdo en tomarlos, estos pasarán al árbol de Linus de acuerdo a |
| igor@417 | 176 lo expuesto. |
| igor@417 | 177 |
| igor@417 | 178 Cada lugarteniente tiene su forma particular de revisar, aceptar y |
| igor@417 | 179 publicar los cambios; y para decidir cuando hacerlos presentes a |
| igor@417 | 180 Linus. Adicionalmente existen varias ramas conocidas que mucha gente |
| igor@417 | 181 usa para propósitos distintos. Por ejemplo, pocas personas mantienen |
| igor@417 | 182 repositorios ``estables'' de versiones anteriores del kernel, a los |
| igor@417 | 183 cuales aplican arreglos de fallos críticos necesarios. Algunos |
| igor@417 | 184 mantenedores publican varios árboles: uno para cambios |
| igor@417 | 185 experimentales; uno para cambios que van a ofrecer al mantenedor |
| igor@417 | 186 principal; y así sucesivamente. Otros publican un solo árbol. |
| igor@417 | 187 |
| igor@417 | 188 Este modelo tiene dos características notables. La primera es que son |
| igor@417 | 189 de ``jalar exclusivamente''. Usted debe solicitar, convencer o |
| jerojasro@542 | 190 incluso rogar a otro desarrollador para que tome sus cambios, porque |
| igor@417 | 191 casi no hay árboles en los cuales más de una persona pueda publicar, y |
| igor@417 | 192 no hay forma de publicar cambios en un árbol que otra persona controla. |
| igor@417 | 193 |
| igor@417 | 194 El segundo está basado en reputación y meritocracia. Si usted es un |
| igor@417 | 195 desconocido, Linus probablemente ignorará sus cambios, sin siquiera |
| igor@417 | 196 responderle. Pero un mantenedor de un subsistema probablemente los |
| igor@417 | 197 revisara, y los acogerá en caso de que aprueben su criterio de |
| igor@417 | 198 aplicabilidad. A medida que usted ofrezca ``mejores'' cambios a un |
| jerojasro@419 | 199 mantenedor, habrá más posibilidad de que se confíe en su juicio y se |
| jerojasro@542 | 200 acepten los cambios. Si usted es reconocido y mantiene una rama |
| igor@417 | 201 durante bastante tiempo para algo que Linus no ha aceptado, personas |
| igor@417 | 202 con intereses similares pueden jalar sus cambios regularmente para |
| igor@417 | 203 estar al día con su trabajo. |
| igor@417 | 204 |
| igor@417 | 205 La reputación y meritocracia no necesariamente es transversal entre |
| igor@417 | 206 ``personas'' de diferentes subsistemas. Si usted es respetado pero es |
| igor@417 | 207 un hacker en almacenamiento y trata de arreglar un fallo de redes, |
| igor@417 | 208 tal cambio puede recibir un nivel de escrutinio de un mantenedor de |
| igor@417 | 209 redes comparable con el que se le haría a un completo extraño. |
| igor@417 | 210 |
| igor@417 | 211 Personas que vienen de proyectos con un ordenamiento distinto, sienten |
| igor@417 | 212 que el proceso comparativamente caótico del Kernel Linux es |
| igor@417 | 213 completamente lunático. Es objeto de los caprichos individuales; la |
| igor@417 | 214 gente desecha cambios cuando lo desean; y la fase de desarrollo es |
| igor@417 | 215 alucinante. A pesar de eso Linux es una pieza de software exitosa y |
| igor@417 | 216 bien reconocida. |
| igor@417 | 217 |
| igor@417 | 218 \subsection{Solamente jalar frente a colaboración pública} |
| igor@417 | 219 |
| igor@417 | 220 Una fuente perpetua de discusiones en la comunidad de código abierto |
| igor@417 | 221 yace en el modelo de desarrollo en el cual la gente solamente jala |
| igor@417 | 222 cambios de otros ``es mejor que'' uno en el cual muchas personas |
| igor@417 | 223 pueden publicar cambios a un repositorio compartido. |
| igor@417 | 224 |
| jerojasro@542 | 225 Típicamente los partidarios del modelo de publicar usan las herramientas |
| igor@417 | 226 que se apegan a este modelo. Si usted usa una herramienta |
| igor@417 | 227 centralizada de control de versiones como Subversion, no hay forma de |
| igor@417 | 228 elegir qué modelo va a usar: La herramienta le ofrece publicación |
| igor@417 | 229 compartida, y si desea hacer cualquier otra cosa, va a tener que |
| igor@417 | 230 aplicar una aproximación artificial (tal como aplicar parches a mano). |
| igor@417 | 231 |
| igor@417 | 232 Una buena herramienta distribuida de control de versiones, tal como |
| igor@417 | 233 Mercurial soportará los dos modelos. Usted y sus colaboradores |
| igor@417 | 234 pueden estructurar cómo trabajarán juntos basados en sus propias |
| igor@417 | 235 necesidades y preferencias, sin depender de las peripecias que la |
| igor@417 | 236 herramienta les obligue a hacer. |
| igor@417 | 237 |
| igor@417 | 238 \subsection{Cuando la colaboración encuentra la administración ramificada} |
| igor@417 | 239 |
| igor@417 | 240 Una vez que usted y su equipo configurar algunos repositorios |
| igor@417 | 241 compartidos y comienzan a propagar cambios entre sus repositorios |
| igor@417 | 242 locales y compartidos, comenzará a encarar un reto relacionado, pero |
| igor@417 | 243 un poco distinto: Administrar las direcciones en las cuales su equipo |
| jerojasro@542 | 244 puede moverse. A pesar de que está íntimamente ligado acerca de cómo |
| igor@417 | 245 interactúa su equipo, es lo suficientemente denso para ameritar un |
| igor@417 | 246 tratamiento en el capítulo~\ref{chap:branch}. |
| igor@417 | 247 |
| igor@417 | 248 \section{Aspectos técnicos de la colaboración} |
| igor@417 | 249 |
| igor@417 | 250 Lo que resta del capítulo lo dedicamos a las cuestiones de servir |
| igor@417 | 251 datos a sus colaboradores. |
| igor@417 | 252 |
| igor@417 | 253 \section{Compartir informalmente con \hgcmd{serve}} |
| igor@402 | 254 \label{sec:collab:serve} |
| igor@402 | 255 |
| igor@417 | 256 La orden \hgcmd{serve} de Mercurial satisface de forma espectacular |
| igor@417 | 257 las necesidades de un grupo pequeño, acoplado y de corto |
| igor@417 | 258 tiempo. Se constituye en una demostración de cómo se siente usar los |
| igor@417 | 259 comandos usando la red. |
| igor@417 | 260 |
| igor@417 | 261 Ejecute \hgcmd{serve} dentro de un repositorio, y en pocos segundos |
| igor@417 | 262 iniciará un servidor HTTP especializado; aceptará conexiones desde |
| igor@417 | 263 cualquier cliente y servirá datos de este repositorio mientrs lo |
| igor@417 | 264 mantenga funcionando. Todo el que sepa el URL del servidor que ha |
| igor@417 | 265 iniciado, y que puede comunicarse con su computador por la red, puede |
| igor@417 | 266 usar un navegador web o Mercurial para leer datos del repositorio. Un |
| igor@417 | 267 URL para una instancia de \hgcmd{serve} ejecutándose en un portátil |
| igor@417 | 268 debería lucir algo \Verb|http://my-laptop.local:8000/|. |
| igor@417 | 269 |
| igor@417 | 270 La orden \hgcmd{serve} \emph{no} es un servidor web de propósito |
| igor@417 | 271 general. Solamente puede hacer dos cosas: |
| igor@402 | 272 \begin{itemize} |
| jerojasro@516 | 273 \item Permitir que se pueda visualizar el historial del repositorio que |
| igor@417 | 274 está sirviendo desde navegadores web. |
| igor@417 | 275 \item Hablar el protocolo de conexión de Mercurial para que puedan hacer |
| igor@417 | 276 \hgcmd{clone} o \hgcmd{pull} (jalar) cambios de tal repositorio. |
| igor@402 | 277 \end{itemize} |
| igor@417 | 278 En particular, \hgcmd{serve} no permitirá que los usuarios remotos |
| igor@417 | 279 puedan \emph{modificar} su repositorio. Es de tipo solo lectura. |
| igor@417 | 280 |
| igor@417 | 281 Si está comenzando con Mercurial, no hay nada que le impida usar |
| igor@417 | 282 \hgcmd{serve} para servir un repositorio en su propio computador, y |
| igor@417 | 283 usar posteriormente órdenes como \hgcmd{clone}, \hgcmd{incoming}, para |
| igor@417 | 284 comunicarse con el servidor como si el repositorio estuviera alojado |
| igor@417 | 285 remotamente. Lo que además puede ayudarle a adecuarse rápidamente para |
| igor@417 | 286 usar comandos en repositorios alojados en la red. |
| igor@417 | 287 |
| igor@417 | 288 \subsection{Cuestiones adicionales para tener en cuenta} |
| igor@417 | 289 |
| igor@417 | 290 Dado que permite lectura sin autenticación a todos sus clientes, |
| igor@417 | 291 debería usar \hgcmd{serve} exclusivamente en ambientes en los cuáles |
| igor@417 | 292 no tenga problema en que otros vean, o en los cuales tenga control |
| igor@417 | 293 completo acerca de quien puede acceder a su red y jalar cambios de su |
| igor@417 | 294 repositorio. |
| igor@417 | 295 |
| igor@417 | 296 La orden \hgcmd{serve} no tiene conocimiento acerca de programas |
| igor@417 | 297 cortafuegos que puedan estar instalados en su sistema o en su red. No |
| igor@417 | 298 puede detectar o controlar sus cortafuegos. Si otras personas no |
| igor@417 | 299 pueden acceder a su instancia \hgcmd{serve}, lo siguiente que debería hacer |
| igor@417 | 300 (\emph{después} de asegurarse que tienen el URL correcto) es verificar |
| igor@417 | 301 su configuración de cortafuegos. |
| igor@417 | 302 |
| igor@417 | 303 De forma predeterminada, \hgcmd{serve} escucha conexiones entrantes en |
| igor@417 | 304 el puerto~8000. Si otro proceso está escuchando en tal puerto, usted |
| igor@417 | 305 podrá especificar un puerto distinto para escuchar con la opción |
| jerojasro@522 | 306 \hgopt{serve}{-p}. |
| igor@417 | 307 |
| igor@417 | 308 Normalmente, cuando se inicia \hgcmd{serve}, no imprime nada, lo cual |
| igor@417 | 309 puede ser desconcertante. Si desea confirmar que en efecto está |
| igor@417 | 310 ejecutándose correctamente, y darse cuenta qué URL debería enviar a |
| igor@417 | 311 sus colaboradores, inícielo con la opción \hggopt{-v}. |
| igor@402 | 312 |
| igor@427 | 313 \section{Uso del protocolo Secure Shell (ssh)} |
| igor@402 | 314 \label{sec:collab:ssh} |
| igor@402 | 315 |
| igor@427 | 316 Usted puede publicar y jalar cambios en la red de forma segura usando |
| igor@427 | 317 el protocolo Secure Shell (\texttt{ssh}). Para usarlo satisfactoriamente, |
| igor@427 | 318 tendrá que hacer algo de configuración a nivel de cliente o el |
| igor@427 | 319 servidor. |
| igor@427 | 320 |
| jerojasro@542 | 321 Si no está familiarizado con ssh, es un protocolo de red que le permite |
| igor@427 | 322 comunicarse con seguridad con otro computador. Para usarlo con |
| igor@427 | 323 Mercurial, estará estableciendo una o más cuentas de usuario en un |
| igor@427 | 324 servidor de forma tal que los usuarios remotos puedan entrar y |
| igor@427 | 325 ejecutar órdenes. |
| igor@427 | 326 |
| igor@427 | 327 (Si ssh le \emph{es} familiar, encontrará probablemente elemental una |
| igor@427 | 328 porción del material a continuación.) |
| igor@427 | 329 |
| igor@427 | 330 \subsection{Cómo leer y escribir URLs de ssh} |
| igor@427 | 331 |
| igor@427 | 332 Los URLs de ssh tienden a lucir de la siguiente forma: |
| igor@402 | 333 \begin{codesample2} |
| igor@402 | 334 ssh://bos@hg.serpentine.com:22/hg/hgbook |
| igor@402 | 335 \end{codesample2} |
| igor@402 | 336 \begin{enumerate} |
| igor@427 | 337 \item La parte ``\texttt{ssh://}'' indica a Mercurial que use el |
| igor@427 | 338 protocolo ssh. |
| igor@427 | 339 \item El componente ``\texttt{bos@}'' indica el nombre del usuario que |
| jerojasro@542 | 340 está entrando al servidor. Puede omitirlo si el usuario remoto |
| igor@427 | 341 coincide con el usuario local. |
| igor@427 | 342 \item ``\texttt{hg.serpentine.com}'' es el nombre del servidor al cual |
| igor@427 | 343 se desea entrar. |
| igor@427 | 344 \item El ``:22'' identifica el número del puerto en el servidor al cual |
| igor@427 | 345 se conectará. El predeterminado es el~22, así que solamente |
| igor@427 | 346 necesitará especificar esa porción si \emph{no} está usando el |
| igor@427 | 347 puerto~22. |
| igor@427 | 348 \item La última porción del URL es la ruta local al repositorio en el |
| igor@427 | 349 servidor. |
| igor@402 | 350 \end{enumerate} |
| igor@402 | 351 |
| igor@427 | 352 El componente de la ruta del URL para ssh es una fuente de confusión, |
| igor@427 | 353 puesto que no hay una forma estándar para que las herramientas puedan |
| igor@427 | 354 interpretarlo. Algunos programas se comportan de manera distinta a |
| igor@427 | 355 otros cuando manipulan estas rutas. No es la situación ideal, pero |
| igor@427 | 356 es muy poco probable que vaya a cambiar. Por favor lea los párrafos |
| igor@427 | 357 siguientes cuidadosamente. |
| igor@427 | 358 |
| igor@427 | 359 Mercurial trata la ruta al repositorio en el servidor como relativo al |
| jerojasro@542 | 360 directorio personal del usuario remoto. Por ejemplo, si el usuario |
| igor@427 | 361 \texttt{foo} en el servidor tiene el directorio casa |
| igor@427 | 362 \dirname{/home/foo}, |
| igor@427 | 363 entonces un URL ssh que contenga en su ruta a \dirname{bar} |
| igor@427 | 364 \emph{realmente} se refiere al directorio \dirname{/home/foo/bar}. |
| igor@427 | 365 |
| igor@427 | 366 Si desea especificar una ruta relativa a otro directorio de usuario, |
| igor@427 | 367 puede usar una ruta que comience con un caracter tildado, seguido del |
| jerojasro@520 | 368 nombre del usuario (llamémosle \texttt{otrousuario}, así |
| igor@427 | 369 \begin{codesample2} |
| igor@427 | 370 ssh://server/~otrousuario/hg/repo |
| igor@427 | 371 \end{codesample2} |
| igor@427 | 372 |
| igor@427 | 373 Y si realmente desea especifica una ruta \emph{absoluta} en el |
| igor@427 | 374 servidor, comience con el componente de la ruta con dos barras como |
| igor@427 | 375 en el siguiente ejemplo: |
| igor@402 | 376 \begin{codesample2} |
| igor@402 | 377 ssh://server//absolute/path |
| igor@402 | 378 \end{codesample2} |
| igor@402 | 379 |
| igor@427 | 380 \subsection{Encontrar un cliente ssh para su sistema} |
| igor@427 | 381 |
| igor@427 | 382 Casi todos los sistemas tipo Unix vienen con OpenSSH preinstalado. Si |
| igor@427 | 383 usted está usando un sistema de estos, ejecute \Verb|which ssh| para |
| igor@427 | 384 identificar dónde está instalada la orden \command{ssh} (usualmente |
| igor@427 | 385 estará en \dirname{/usr/bin}). Si por casualidad no está presente, |
| igor@427 | 386 vea la documentación de sus sistema para lograr instalarlo. |
| igor@427 | 387 |
| igor@427 | 388 En Windows, tendrá que escoger primero un cliente adecuado para |
| igor@427 | 389 descargarlo. Hay dos alternativas: |
| igor@402 | 390 \begin{itemize} |
| igor@427 | 391 \item El excelente paquete PuTTY~\cite{web:putty} de Simon Tatham, que |
| igor@427 | 392 ofrece un suite completo de órdenes de cliente ssh. |
| igor@427 | 393 \item Si tiene alta tolerancia al dolor, puede usar el porte de Cygwin |
| igor@427 | 394 para OpenSSH. |
| igor@402 | 395 \end{itemize} |
| igor@427 | 396 En cualquier caso, tendrá que editar su fichero \hgini\ para indicarle |
| igor@427 | 397 a Mercurial dónde encontrar la orden real del cliente. Por ejemplo, si |
| igor@427 | 398 está usando PuTTY, tendrá que usar la orden \command{plink} como un |
| igor@427 | 399 cliente de línea de órdenes. |
| igor@402 | 400 \begin{codesample2} |
| igor@402 | 401 [ui] |
| igor@427 | 402 ssh = C:/ruta/a/plink.exe -ssh -i "C:/ruta/a/mi/llave/privada" |
| igor@402 | 403 \end{codesample2} |
| igor@402 | 404 |
| igor@402 | 405 \begin{note} |
| igor@427 | 406 La ruta a \command{plink} no debería contener espacios o caracteres |
| igor@427 | 407 en blanco, o Mercurial no podrá encontrarlo correctamente (por lo |
| igor@427 | 408 tanto, probablemente no sería buena idea colocarlo en |
| igor@427 | 409 \dirname{C:\\Program Files} |
| igor@402 | 410 \end{note} |
| igor@402 | 411 |
| igor@427 | 412 \subsection{Generar un par de llaves} |
| igor@427 | 413 |
| jerojasro@542 | 414 Para evitar la necesidad de teclear una clave de forma repetitiva cada |
| igor@427 | 415 vez que necesita usar el cliente, recomiendo generar un par de llaves. |
| igor@427 | 416 En un sistema tipo Unix, la orden \command{ssh-keygen} también se |
| igor@427 | 417 comportará bien. En Windows, si está usando PuTTY, la orden |
| igor@427 | 418 \command{puttygen} es la que necesitará. |
| igor@427 | 419 |
| igor@427 | 420 Cuando genera un par de llaves, se aconseja \emph{comedidamente} |
| igor@427 | 421 protegerlas con una frase de clave. (La única oportunidad en la cual |
| igor@427 | 422 usted querría identificarse una única vez, es cuando está usando |
| igor@427 | 423 el protocolo ssh para tareas automatizadas en una red segura.) |
| igor@427 | 424 |
| igor@427 | 425 No basta con generar un par de llaves. Se requiere adicionar una llave |
| igor@427 | 426 pública al conjunto de llaves autorizadas para todos los usuarios |
| igor@427 | 427 remotos que se vayan a autenticar. Para aquellos servidores que usen |
| jerojasro@520 | 428 OpenSSH (la gran mayoría), significará añadir la llave pública a la |
| igor@427 | 429 lista en el fichero llamado \sfilename{authorized\_keys} en su |
| igor@427 | 430 directorio \sdirname{.ssh}. |
| igor@427 | 431 |
| igor@427 | 432 En sistemas tipo Unix, su llave pública tendrá la extensión |
| igor@427 | 433 \filename{.pub}. Si usa \command{puttygen} en Windows, puede |
| igor@427 | 434 guardar la llave pública en un fichero de su elección, o pegarla desde |
| igor@427 | 435 la ventana en la cual se despliega directamente en el fichero |
| igor@427 | 436 \sfilename{authorized\_keys}. |
| igor@402 | 437 |
| igor@428 | 438 \subsection{Uso de un agente de autenticación} |
| igor@428 | 439 |
| jerojasro@542 | 440 Un agente de autenticación es un demonio que almacena frases clave en |
| jerojasro@520 | 441 memoria (olvidará las frases clave si sale y vuelve a entrar). Un cliente |
| igor@428 | 442 ssh notará si está corriendo, y solicitará una frase clave. Si no hay |
| igor@428 | 443 un agente de autenticación corriendo, o el agente no almacena la frase |
| igor@428 | 444 clave necesaria, tendrá que teclear su frase clave cada vez que |
| jerojasro@520 | 445 Mercurial intente comunicarse con un servidor para usted (p.e.~cada vez |
| igor@428 | 446 que jale o publique cambios). |
| igor@428 | 447 |
| igor@428 | 448 El problema de almacenar frases claves en un agente es que es posible |
| igor@428 | 449 para un atacante bien preparado recuperar el texto plano de su frase |
| jerojasro@542 | 450 clave, en algunos casos incluso si su sistema sea muy alternante. |
| igor@428 | 451 Es su decisión si es un riesgo aceptable. Lo que si es seguro es que |
| igor@428 | 452 evita reteclear. |
| igor@428 | 453 |
| igor@428 | 454 En sistemas tipo Unix, el agente se llama \command{ssh-agent}, y |
| igor@428 | 455 usualmente se ejecuta automáticamente cuando usted entra. Tendrá que |
| igor@428 | 456 usar la orden \command{ssh-add} para añadir frases claves al agente. En |
| igor@428 | 457 Windows, si está usando PuTTY, la orden \command{pageant} actúa como |
| jerojasro@542 | 458 el agente. Añade un icono a su barra del sistema que le permitirá |
| igor@428 | 459 almacenar frases clave. |
| igor@428 | 460 |
| igor@428 | 461 \subsection{Configurar el lado del servidor apropiadamente} |
| igor@428 | 462 |
| igor@428 | 463 Dado que puede ser dispendioso configurar ssh si usted es nuevo, hay |
| igor@428 | 464 una variedad de cosas que podrían ir mal. Añada piense primero en |
| igor@428 | 465 Mercurial y hay mucho más en qué pensar. La mayor parte de estos |
| jerojasro@542 | 466 problemas potenciales ocurren en el lado del servidor, no en el cliente. |
| igor@428 | 467 Las buenas noticias es que una vez tiene una configuración funcional, |
| igor@428 | 468 usualmente continuará trabajando indefinidamente. |
| igor@428 | 469 |
| igor@428 | 470 Antes de intentar que Mercurial hable con un servidor ssh, es mejor |
| igor@428 | 471 asegurarse que puede usar la orden normal \command{ssh} o \command{putty} |
| igor@428 | 472 para comunicarse con el servidor primero. Si tiene problemas usando |
| igor@428 | 473 estas órdenes directamente, de seguro Mercurial no funcionará. Pero aún, |
| igor@428 | 474 esconderá el problema subyacente. Cuando desee revisar un problema |
| igor@428 | 475 relacionado con ssh y Mercurial, debería asegurarse primero que las |
| igor@428 | 476 órdenes de ssh en el lado del cliente funcionan primero, \emph{antes} |
| igor@428 | 477 de preocuparse por si existe un problema con Mercurial. |
| igor@428 | 478 |
| igor@428 | 479 Lo primero para asegurar en el lado del servidor es que puede entrar |
| igor@428 | 480 desde otra máquina. Si no puede entrar con \command{ssh} o |
| igor@428 | 481 \command{putty}, el mensaje de error que obtenga le puede dar pistas |
| igor@428 | 482 de qué ha ido mal. Los problemas más comunes son los siguientes: |
| igor@402 | 483 \begin{itemize} |
| jerojasro@542 | 484 \item Si obtiene un error de ``conexión rehusada'', es posible que no |
| jerojasro@542 | 485 haya un demonio SSH corriendo en el servidor o que no pueda accederse |
| igor@428 | 486 a él por configuraciones de cortafuegos. |
| igor@428 | 487 \item Si obtiene un error de ``no hay ruta hasta el servidor'', puede |
| igor@428 | 488 tener la dirección del servidor incorrecta o un cortafuegos con |
| igor@428 | 489 bloqueo agresivo que no permitirá su existencia. |
| igor@428 | 490 \item Si obtiene un mensaje de ``permiso denegado'', puede que haya |
| igor@428 | 491 tecleado mal el usuario en el servidor, o que haya tecleado |
| igor@428 | 492 incorrectamente la frase clave o la clave del usuario remoto. |
| igor@402 | 493 \end{itemize} |
| jerojasro@542 | 494 En resumen, si tiene problemas al comunicarse con el demonio ssh del |
| igor@428 | 495 servidor, primero asegúrese de que está corriendo. En muchos sistemas |
| igor@428 | 496 estará instalado, pero deshabilitado de forma predeterminada. Una vez |
| igor@428 | 497 que haya hecho este paso tendrá que revisar si el cortafuegos del |
| igor@428 | 498 servidor está configurado para recibir conexiones entrantes en el |
| jerojasro@542 | 499 puerto en el cual el demonio de ssh está escuchando (usualmente el~22). |
| igor@428 | 500 No trate de buscar otras posibilidades exóticas o configuraciones |
| jerojasro@542 | 501 erradas hasta que haya revisado primero estas dos. |
| igor@428 | 502 |
| igor@428 | 503 Si está usando un agente de autenticación en el lado del cliente para |
| igor@428 | 504 almacenar las frase claves de sus contraseñas, debería poder entrar al |
| igor@428 | 505 servidor sin necesidad de que se le solicite frases claves o |
| igor@428 | 506 contraseñas. Si se le pregunta alguna, a continuación algunas |
| igor@428 | 507 posibilidades: |
| igor@402 | 508 \begin{itemize} |
| igor@428 | 509 \item Puede haber olvidado usar \command{ssh-add} o |
| igor@428 | 510 \command{pageant} para guardar la frase clave. |
| igor@428 | 511 \item Puede haber almacenado una frase clave errónea para la llave. |
| igor@402 | 512 \end{itemize} |
| igor@428 | 513 Si se le solicita la clave del usuario remoto, hay otras posibilidades |
| igor@428 | 514 que deben revisarse: |
| igor@402 | 515 \begin{itemize} |
| igor@428 | 516 \item O bien el directorio del usuario o su directorio \sdirname{.ssh} |
| igor@428 | 517 tiene permisos excesivamente abiertos. Como resultado el daemonio |
| igor@428 | 518 ssh no creerá o leerá su fichero \sfilename{authorized\_keys}. |
| igor@428 | 519 Por ejemplo, un directorio casa o \sdirname{.ssh} causará aveces |
| igor@428 | 520 este síntoma. |
| igor@428 | 521 \item El fichero de usuario \sfilename{authorized\_keys} puede tener |
| igor@428 | 522 un problema. Si alguien distinto al usuario es dueño o puede |
| jerojasro@542 | 523 escribir el fichero, el demonio ssh no confiará o lo leerá. |
| igor@402 | 524 \end{itemize} |
| igor@402 | 525 |
| igor@428 | 526 En un mundo ideal, debería poder ejecutar la siguiente orden |
| jerojasro@542 | 527 exitosamente, y debería imprimir exactamente una línea de salida, |
| igor@428 | 528 la fecha y hora actual. |
| igor@428 | 529 \begin{codesample2} |
| igor@428 | 530 ssh miservidor fecha |
| igor@428 | 531 \end{codesample2} |
| igor@428 | 532 |
| jerojasro@542 | 533 Si en su servidor tiene guión que se ejecuta a la entrada e imprime |
| igor@428 | 534 letreros o cualquier otra cosa, incluso cuando se ejecutan órdenes no |
| igor@428 | 535 interactivas como esta, debería arreglarlo antes de continuar, de |
| igor@428 | 536 forma que solamente imprima algo si se ejecuta interactivamente. De |
| jerojasro@525 | 537 otra forma estos letreros al menos llenarán la salida de Mercurial. |
| jerojasro@525 | 538 Incluso podrían causar problemas potenciales cuando se ejecuten |
| igor@428 | 539 órdenes de forma remota. Mercurial intenta detectar e ignorar los |
| igor@428 | 540 letreros en sesiones no interactivas de \command{ssh}, pero no es |
| igor@428 | 541 a prueba de tontos. (Si edita sus guiones de entrada en el servidor, |
| jerojasro@542 | 542 la forma usual de ver si un guión de línea de comandos se ejecuta en un intérprete |
| igor@428 | 543 interactivo, es verificar el código de retorno de la orden |
| igor@428 | 544 \Verb|tty -s|.) |
| igor@428 | 545 |
| igor@428 | 546 Cuando verifique que el venerado ssh funciona en su servidor, el |
| igor@428 | 547 paso siguiente es asegurar que Mercurial corre en el servidor. La |
| igor@428 | 548 orden siguiente debería ejecutarse satisfactoriamente: |
| igor@428 | 549 \begin{codesample2} |
| igor@428 | 550 ssh miservidor hg version |
| igor@428 | 551 \end{codesample2} |
| igor@428 | 552 Si ve un mensaje de error en lugar de la salida usual de |
| igor@428 | 553 \hgcmd{version}, será porque no ha instalado Mercurial en |
| igor@428 | 554 \dirname{/usr/bin}. No se preocupe si este es el caso; no necesita |
| igor@428 | 555 hacerlo. Pero debería revisar los posibles problemas presentados a |
| igor@428 | 556 continuación: |
| igor@402 | 557 \begin{itemize} |
| igor@428 | 558 \item Está instalado Mercurial en el servidor? Se que suena trivial |
| igor@428 | 559 pero es mejor revisar! |
| igor@428 | 560 \item Tal vez la ruta de búsqueda de la interfaz de órdenes |
| igor@428 | 561 (normalmente vía la variable de ambiente \envar{PATH}) simplemente |
| igor@428 | 562 está mal configurada. |
| igor@428 | 563 \item Puede ser que su variable de ambiente \envar{PATH} soalamente |
| igor@428 | 564 apunte al lugar en el cual está el ejecutable \command{hg} si la |
| igor@428 | 565 sesión de entrada es interactiva. Puede suceder si establece la |
| jerojasro@542 | 566 ruta en el guión de línea de comandos de entrada incorrecto. Consulte la |
| igor@428 | 567 documentación de su línea de órdenes. |
| igor@428 | 568 \item La variable de ambiente \envar{PYTHONPATH} puede requerir la |
| jerojasro@542 | 569 ruta a los módulos de Mercurial en Python. Puede que ni siquiera |
| igor@428 | 570 está establecida; podría estar incorrecta; o puede ser que se |
| igor@428 | 571 establezca únicamente cuando hay entradas interactivas. |
| igor@402 | 572 \end{itemize} |
| igor@402 | 573 |
| igor@428 | 574 Si puede ejecutar \hgcmd{version} sobre una conexión ssh, |
| igor@428 | 575 felicitaciones! Ha logrado la interacción entre el cliente y el |
| igor@428 | 576 servidor. Ahora debería poder acceder a los repositorios de |
| igor@428 | 577 Mercurial que tiene el usuario en el servidor. Si tiene problemas |
| igor@428 | 578 con Mercurial y ssh en este punto, intente usar la opción |
| igor@428 | 579 \hggopt{--debug} para tener información más clara de lo que está |
| igor@428 | 580 sucediendo. |
| igor@428 | 581 |
| igor@428 | 582 \subsection{Compresión con ssh} |
| igor@428 | 583 |
| igor@428 | 584 Mercurial no comprime datos cuando usa el protocolo ssh, dado que |
| igor@428 | 585 el protocolo puede comprimir datos transparentemente. Pero el |
| igor@428 | 586 comportamiento predeterminado del cliente ssh es \emph{no} |
| igor@428 | 587 solicitar compresión. |
| igor@428 | 588 |
| jerojasro@520 | 589 Sobre cualquier red distinta a una LAN rápida (incluso con una red |
| igor@428 | 590 inalámbrica), hacer uso de compresión puede mejorar el rendimiento |
| igor@428 | 591 de las operaciones de Mercurial que involucren la red. Por ejemplo, |
| igor@428 | 592 sobre WAN, alguien ha medido la compresión reduciendo la cantidad |
| igor@428 | 593 de tiempo requerido para clonar un repositorio particularmente |
| igor@428 | 594 grande de~51 minutos a~17 minutos. |
| igor@428 | 595 |
| igor@428 | 596 Tanto \command{ssh} como \command{plink} aceptan la opción |
| igor@428 | 597 \cmdopt{ssh}{-C} que activa la compresión. Puede editar fácilmente |
| igor@428 | 598 su \hgrc\ para habilitar la compresión para todos los usos de |
| igor@428 | 599 Mercurial sobre el protocolo ssh. |
| igor@402 | 600 \begin{codesample2} |
| igor@402 | 601 [ui] |
| igor@402 | 602 ssh = ssh -C |
| igor@402 | 603 \end{codesample2} |
| igor@402 | 604 |
| igor@428 | 605 Si usa \command{ssh}, puede reconfigurarlo para que siempre use |
| igor@428 | 606 compresión cuando se comunique con su servidor. Para hacerlo, |
| jerojasro@520 | 607 edite su fichero \sfilename{.ssh/config} (que puede no existir |
| igor@428 | 608 aún), de la siguiente forma: |
| igor@402 | 609 \begin{codesample2} |
| igor@402 | 610 Host hg |
| igor@402 | 611 Compression yes |
| igor@428 | 612 HostName hg.ejemplo.com |
| igor@428 | 613 \end{codesample2} |
| igor@428 | 614 Que define un alias, \texttt{hg}. Cuando lo usa con la orden |
| igor@428 | 615 \command{ssh} o con una URL de Mercurial con protocolo\texttt{ssh}, |
| igor@428 | 616 logrará que \command{ssh} se conecte a \texttt{hg.ejemplo.com} |
| igor@428 | 617 con compresión. Que le dará un nombre más corto para teclear y |
| igor@428 | 618 compresión, los cuales por derecho propio son buenos. |
| igor@402 | 619 |
| igor@429 | 620 \section{Uso de CGI a través de HTTP} |
| igor@402 | 621 \label{sec:collab:cgi} |
| igor@402 | 622 |
| igor@429 | 623 Dependiendo de qué tan ambicioso sea, configurar la interfaz CGI |
| igor@429 | 624 de Mercurial puede tomar desde unos minutos hasta varias horas. |
| igor@429 | 625 |
| igor@429 | 626 Comenzaremos con el ejemplo más sencillo, y nos dirigiremos hacia |
| igor@429 | 627 configuraciones más complejas. Incluso para el caso más básico |
| igor@429 | 628 necesitará leer y modificar su configuración del servidor web. |
| igor@402 | 629 |
| igor@402 | 630 \begin{note} |
| igor@429 | 631 Configurar un servidor web es una actividad compleja, engorrosa y |
| igor@429 | 632 altamente dependiente del sistema. De ninguna manera podremos |
| igor@429 | 633 cubrir todos los casos posibles con los cuales pueda encontrarse. |
| jerojasro@542 | 634 Use su discreción y juicio respecto a las secciones siguientes. |
| igor@429 | 635 Esté preparado para cometer muchas equivocaciones, y emplear |
| igor@429 | 636 bastante tiempo leyendo sus bitácoras de error del servidor. |
| igor@402 | 637 \end{note} |
| igor@402 | 638 |
| igor@429 | 639 \subsection{Lista de chequeo de la configuración del servidor web} |
| igor@429 | 640 |
| igor@429 | 641 Antes de continuar, tómese un tiempo para revisar ciertos aspectos de |
| igor@429 | 642 la configuración de su sistema: |
| igor@402 | 643 |
| igor@402 | 644 \begin{enumerate} |
| igor@429 | 645 \item ¿Tiene un servidor web? Mac OS X viene con Apache, pero otros |
| igor@429 | 646 sistemas pueden no tener un servidor web instalado. |
| igor@429 | 647 \item Si tiene un servidor web instalado, ¿Está ejecutándose? En la |
| igor@429 | 648 mayoría de sistemas, aunque esté presente, puede no estar habilitado |
| igor@429 | 649 de forma predeterminada. |
| igor@429 | 650 \item ¿u servidor está configurado para permitir ejecutar programas |
| igor@429 | 651 CGI en el directorio donde planea hacerlo? Casi todos los |
| igor@429 | 652 servidores de forma predeterminada explícitamente inhiben la |
| igor@429 | 653 habilidad de ejecutar programas CGI. |
| igor@402 | 654 \end{enumerate} |
| igor@402 | 655 |
| igor@429 | 656 Si no tiene un servidor web instalado, y no tiene cierta experiencia |
| igor@429 | 657 configurando Apache, debería considerar usar el servidor web |
| igor@429 | 658 \texttt{lighttpd} en lugar de Apache. Apache tiene una reputación |
| igor@429 | 659 bien ganada por su configuración barroca y confusa. |
| igor@429 | 660 A pesar de que \texttt{lighttpd} tiene menos características que |
| igor@429 | 661 Apache en ciertas áreas, las mismas no son relevantes para servir |
| igor@429 | 662 repositorios de Mercurial. Definitivamente es mucho más sencillo |
| igor@429 | 663 comenzar con \texttt{lighttpd} que con Apache. |
| igor@429 | 664 |
| igor@429 | 665 \subsection{Configuración básica de CGI} |
| igor@429 | 666 |
| igor@429 | 667 En sistemas tipo Unix es común que los usuarios tengan un subdirectorio |
| igor@429 | 668 con un nombre como \dirname{public\_html} en su directorio personal, |
| igor@429 | 669 desde el cual pueden servir páginas web. Un fichero llamado \filename{foo} |
| igor@429 | 670 en este directorio será visible en una URL de la forma |
| igor@402 | 671 \texttt{http://www.example.com/\~username/foo}. |
| igor@402 | 672 |
| igor@429 | 673 Para comenzar, encuentre el guión \sfilename{hgweb.cgi} que debería |
| igor@429 | 674 estar presente en su instalación de Mercurial. Si no puede |
| igor@429 | 675 encontrarlo rápidamente una copia local en su sistema, puede |
| igor@429 | 676 descargarlo del repositorio principal de Mercurial en |
| igor@402 | 677 \url{http://www.selenic.com/repo/hg/raw-file/tip/hgweb.cgi}. |
| igor@402 | 678 |
| igor@429 | 679 Tendrá que copiar este guión en su directorio \dirname{public\_html}, |
| igor@429 | 680 y asegurarse que sea ejecutable. |
| igor@402 | 681 \begin{codesample2} |
| igor@402 | 682 cp .../hgweb.cgi ~/public_html |
| igor@402 | 683 chmod 755 ~/public_html/hgweb.cgi |
| igor@402 | 684 \end{codesample2} |
| igor@429 | 685 El argumento \texttt{755} de la orden \command{chmod} es un poco más |
| igor@429 | 686 general que hacerlo ejecutable: Asegura que el guión sea ejecutable |
| jerojasro@542 | 687 por cualquiera, y que el ``grupo'' y los ``otros'' \emph{no} tengan |
| igor@429 | 688 permiso de escritura. Si dejara los permisos de escritura abiertos, |
| igor@429 | 689 , el subsistema \texttt{suexec} de Apache probablemente se negaría |
| igor@429 | 690 a ejecutar el guión. De hecho, \texttt{suexec} también insiste en que |
| igor@429 | 691 el \emph{directorio} en el cual reside el guión no tenga permiso de |
| igor@429 | 692 escritura para otros. |
| igor@402 | 693 \begin{codesample2} |
| igor@402 | 694 chmod 755 ~/public_html |
| igor@402 | 695 \end{codesample2} |
| igor@402 | 696 |
| igor@436 | 697 \subsubsection{¿Qué \emph{podría} resultar mal?} |
| igor@402 | 698 \label{sec:collab:wtf} |
| igor@402 | 699 |
| igor@436 | 700 Cuando haya ubicado el CGI en el sitio correspondiente con un navegador |
| igor@436 | 701 intente visitar el URL \url{http://myhostname/~myuser/hgweb.cgi}, |
| igor@436 | 702 \emph{sin} dejarse abatir por un error. Hay una alta probabilidad de |
| igor@436 | 703 que esta primera visita al URL sea fallida, y hay muchas razones posibles |
| igor@436 | 704 para este comportamiento. De hecho, podría toparse con cada uno de los |
| igor@436 | 705 errores que describimos a continuación, así que no deje de leerlos |
| igor@436 | 706 cuidadosamente. A continuación presento los problemas que yo tuve en |
| igor@436 | 707 un sistema con Fedora~7, con una instalación nueva de Apache, y una |
| igor@436 | 708 cuenta de usuario que creé específicamente para desarrollar este |
| igor@436 | 709 ejercicio. |
| igor@436 | 710 |
| igor@436 | 711 Su servidor web puede tener directorios por usuario deshabilitados. Si |
| igor@436 | 712 usa Apache, busque el fichero de configuración que contenga la |
| igor@436 | 713 directiva \texttt{UserDir}. Si no está presente en sitio alguno, los |
| igor@436 | 714 directorios por usuario están deshabilitados. Si la hay, pero su |
| igor@436 | 715 valor es \texttt{disabled}, los directorios por usuario estarán |
| igor@436 | 716 deshabilitados. La directiva \texttt{UserDir} en caso contrario tendrá |
| igor@436 | 717 el nombre del subdirectorio bajo el cual Apache mirará en el |
| igor@436 | 718 directorio de cada usuario, por ejemplo \dirname{public\_html}. |
| igor@436 | 719 |
| igor@436 | 720 Los permisos de sus ficheros pueden ser demasiado restrictivos. El |
| igor@436 | 721 servidor web debe poder recorrer su directorio personal y los |
| igor@436 | 722 directorios que estén bajo \dirname{public\_html}, además de tener |
| jerojasro@542 | 723 permiso para leer aquellos que estén adentro. A continuación una |
| igor@436 | 724 receta rápida para hacer que sus permisos estén acordes con las |
| igor@436 | 725 necesidades básicas. |
| igor@402 | 726 \begin{codesample2} |
| igor@402 | 727 chmod 755 ~ |
| igor@402 | 728 find ~/public_html -type d -print0 | xargs -0r chmod 755 |
| igor@402 | 729 find ~/public_html -type f -print0 | xargs -0r chmod 644 |
| igor@402 | 730 \end{codesample2} |
| igor@402 | 731 |
| igor@436 | 732 Otra posibilidad con los permisos es que obtenga una ventana |
| jerojasro@542 | 733 completamente en blanco cuando trata de cargar el guión. En cuyo |
| igor@436 | 734 caso, es posible que los permisos que tiene son \emph{demasiado |
| igor@436 | 735 permisivos}. El subsistema \texttt{suexec} de Apache no ejecutará un |
| jerojasro@542 | 736 guión que tenga permisos de escritura para el grupo o el planeta, por |
| igor@436 | 737 ejemplo. |
| igor@436 | 738 |
| igor@436 | 739 Su servidor web puede estar configurado para evitar la ejecución de |
| igor@436 | 740 programas CGI en los directorios de usuario. A continuación presento |
| igor@436 | 741 una configuración predeterminada por usuario en mi sistema Fedora. |
| igor@436 | 742 |
| igor@402 | 743 \begin{codesample2} |
| igor@402 | 744 <Directory /home/*/public_html> |
| igor@402 | 745 AllowOverride FileInfo AuthConfig Limit |
| igor@402 | 746 Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec |
| igor@402 | 747 <Limit GET POST OPTIONS> |
| igor@402 | 748 Order allow,deny |
| igor@402 | 749 Allow from all |
| igor@402 | 750 </Limit> |
| igor@402 | 751 <LimitExcept GET POST OPTIONS> |
| igor@402 | 752 Order deny,allow |
| igor@402 | 753 Deny from all |
| igor@402 | 754 </LimitExcept> |
| igor@402 | 755 </Directory> |
| igor@402 | 756 \end{codesample2} |
| igor@436 | 757 Si encuentra un grupo de instrucciones de \texttt{Directory} similares |
| igor@436 | 758 en su configuración de Apache, la directiva a revisar es \texttt{Options}. |
| igor@436 | 759 Adicione \texttt{ExecCGI} al final de esta lista en caso de que haga |
| igor@436 | 760 falta y reinicie su servidor web. |
| igor@436 | 761 |
| jerojasro@542 | 762 Si resulta que Apache le muestra el texto del guión CGI en lugar de |
| jerojasro@520 | 763 ejecutarlo, necesitará o bien descomentar (si se encuentra presente) o |
| igor@436 | 764 adicionar una directiva como la siguiente: |
| igor@402 | 765 \begin{codesample2} |
| igor@402 | 766 AddHandler cgi-script .cgi |
| igor@402 | 767 \end{codesample2} |
| igor@402 | 768 |
| igor@436 | 769 Otra posibilidad es que observe una traza de Python en colores |
| igor@436 | 770 informando que no puede importar un módulo relacionado con |
| igor@436 | 771 \texttt{mercurial}. Esto es un gran progreso! El servidor es capaz |
| jerojasro@542 | 772 de ejecutar su guión CGI. Este error solamente ocurrirá si está |
| igor@436 | 773 ejecutando una instalación privada de Mercurial en lugar de una |
| igor@436 | 774 instalación para todo el sistema. Recuerde que el servidor que |
| igor@436 | 775 ejecuta el programa CGI no cuenta con variables de ambiente de las |
| igor@436 | 776 cuales usted si dispone en una sesión interactiva. Si este error le |
| igor@436 | 777 ocurre, edite su copia de \sfilename{hgweb.cgi} y siga las indicaciones |
| igor@436 | 778 dentro del mismo para establecer de forma adecuada su variable de |
| igor@436 | 779 ambiente \envar{PYTHONPATH}. |
| igor@436 | 780 |
| igor@436 | 781 Finalmente, si encuentra \emph{otra} traza a todo color de Python al visitar |
| igor@436 | 782 el URL: Esta seguramente se referirá a que no puede encontrar |
| igor@436 | 783 \dirname{/path/to/repository}. Edite su script \sfilename{hgweb.cgi} |
| jerojasro@542 | 784 y reemplace la cadena \dirname{/path/to/repository} con la ruta |
| igor@436 | 785 completa al repositorio que desea servir. |
| igor@436 | 786 |
| igor@436 | 787 En este punto, cuando trate de recargar la página, deberá visualizar |
| jerojasro@517 | 788 una linda vista HTML del historial de su repositorio. Uff! |
| igor@402 | 789 |
| igor@438 | 790 \subsubsection{Configuración de lighttpd} |
| igor@438 | 791 |
| igor@438 | 792 En mi intención de ser exhaustivo, intenté configurar |
| igor@438 | 793 \texttt{lighttpd}, un servidor web con creciente aceptación, para |
| igor@438 | 794 servir los repositorios de la misma forma como lo describí |
| igor@438 | 795 anteriormente con Apache. Después de superar los problemas que mostré |
| igor@438 | 796 con Apache, muchos de los cuáles no son específicos del servidor. Por |
| igor@438 | 797 lo tanto estaba seguro de que mis permisos para directorios y ficheros |
| igor@438 | 798 eran correctos y que mi guión \sfilename{hgweb.cgi} también lo era. |
| igor@438 | 799 |
| igor@438 | 800 Dado que ya Apache estaba en ejecución correctamente, lograr que |
| jerojasro@520 | 801 \texttt{lighttpd} sirviera mi repositorio fue rápido (en otras |
| igor@438 | 802 palabras, si está tratando de usar \texttt{lighttpd}, debe leer la |
| igor@438 | 803 sección de Apache). Primero tuve que editar la sección |
| igor@438 | 804 \texttt{mod\_access} para habilitar \texttt{mod\_cgi} y |
| igor@438 | 805 \texttt{mod\_userdir}, los cuales estaban inhabilitados en mi |
| igor@438 | 806 instalación predeterminada. Añadí posteriormente unas líneas al final |
| igor@438 | 807 del fichero de configuración, para hacer lo propio con los módulos. |
| igor@402 | 808 \begin{codesample2} |
| igor@402 | 809 userdir.path = "public_html" |
| igor@402 | 810 cgi.assign = ( ".cgi" => "" ) |
| igor@402 | 811 \end{codesample2} |
| igor@438 | 812 Hecho esto, \texttt{lighttpd} funcionó inmediatamente para |
| igor@438 | 813 mí. Configuré \texttt{lighttpd} antes que Apache, tuve casi los mismos |
| igor@438 | 814 reparos a nivel de configuración del sistema que con Apache. De todas |
| igor@438 | 815 maneras, considero que \texttt{lighttpd} es bastante más sencillo de |
| igor@438 | 816 configurar que Apache, a pesar de haber usado Apache por lo menos por |
| igor@438 | 817 una década, y esta fue mi primera experiencia con \texttt{lighttpd}. |
| igor@438 | 818 |
| jerojasro@542 | 819 \subsection{Compartir varios repositorios con un guión CGI} |
| igor@438 | 820 |
| igor@438 | 821 El guión \sfilename{hgweb.cgi} permite publicar únicamente un |
| igor@438 | 822 repositorio, una restricción frustrante. Si desea publicar más de uno |
| igor@438 | 823 sin complicarse con varias copias del mismo guión, cada una con un |
| igor@438 | 824 nombre distinto, resulta mucho mejor usar el guión |
| igor@438 | 825 \sfilename{hgwebdir.cgi}. |
| igor@438 | 826 |
| igor@438 | 827 El procedimiento para configurar \sfilename{hgwebdir.cgi} tiene una |
| igor@438 | 828 porción adicional frente al trabajo requerido con |
| igor@438 | 829 \sfilename{hgweb.cgi}. Primero se debe obtener una copia del |
| igor@438 | 830 guión. Si no tiene una a mano, puede descargar una copia del ftp |
| igor@438 | 831 principal del repositorio de Mercurial en |
| igor@402 | 832 \url{http://www.selenic.com/repo/hg/raw-file/tip/hgwebdir.cgi}. |
| igor@402 | 833 |
| igor@438 | 834 Necesitará una copia del guión en su directorio \dirname{public\_html}, |
| igor@438 | 835 y asegurarse de que sea ejecutable. |
| igor@402 | 836 \begin{codesample2} |
| igor@402 | 837 cp .../hgwebdir.cgi ~/public_html |
| igor@402 | 838 chmod 755 ~/public_html ~/public_html/hgwebdir.cgi |
| igor@402 | 839 \end{codesample2} |
| igor@438 | 840 Con la configuración básica, intente visitar en su navegador |
| jerojasro@524 | 841 \url{http://myhostname/~myuser/hgwebdir.cgi}. Debería mostrar una |
| igor@438 | 842 lista vacía de repositorios. Si obtiene una ventana en blanco o un |
| igor@438 | 843 mensaje de error, verifique la lista de problemas potenciales en la |
| igor@438 | 844 sección~\ref{sec:collab:wtf}. |
| igor@438 | 845 |
| igor@438 | 846 El guión \sfilename{hgwebdir.cgi} se apoya en un fichero externo de |
| igor@438 | 847 configuración. En principio, busca un fichero llamado |
| igor@438 | 848 \sfilename{hgweb.config} en el mismo directorio. Tendrá que crear el |
| igor@438 | 849 fichero, y permitir lectura de todo el mundo. El formato del fichero |
| igor@438 | 850 es similar a un fichero ``ini'' de Windows, que puede interpretar el módulo |
| igor@438 | 851 \texttt{ConfigParser}~\cite{web:configparser} de Python. |
| igor@438 | 852 |
| igor@438 | 853 La forma más sencilla de configurar \sfilename{hgwebdir.cgi} es con |
| igor@438 | 854 una sección llamada \texttt{collections}. Esta publicará automáticamente |
| igor@438 | 855 \emph{todos} los repositorios en los directorios que usted |
| igor@438 | 856 especifique. La sección debería lucir así: |
| igor@402 | 857 \begin{codesample2} |
| igor@402 | 858 [collections] |
| igor@438 | 859 /mi/ruta = /mi/ruta |
| igor@438 | 860 \end{codesample2} |
| igor@438 | 861 Mercurial lo interpreta buscando el nombre del directorio que esté a la |
| igor@438 | 862 \emph{derecha} del símbolo ``\texttt{=}''; encontrando repositorios en |
| igor@438 | 863 la jerarquía de directorios; y usando el texto a la \emph{izquierda} |
| igor@438 | 864 para eliminar el texto de los nombres que mostrará en la interfaz |
| igor@438 | 865 web. El componente restante de la ruta después de esta eliminación |
| igor@438 | 866 usualmente se llama ``ruta virtual''. |
| igor@438 | 867 |
| igor@438 | 868 Dado el ejemplo de arriba, si tenemos un repositorio cuya ruta local es |
| igor@438 | 869 \dirname{/mi/ruta/este/repo}, el guión CGI eliminará la porción inicial |
| igor@438 | 870 \dirname{/mi/ruta} del nombre y publicará el repositorio con una ruta |
| igor@438 | 871 virtual \dirname{este/repo}. Si el URL base de nuestro guión CGI es |
| igor@438 | 872 \url{http://myhostname/~myuser/hgwebdir.cgi}, el URL completo al |
| igor@438 | 873 repositorio será |
| igor@402 | 874 \url{http://myhostname/~myuser/hgwebdir.cgi/this/repo}. |
| igor@402 | 875 |
| igor@438 | 876 Si reemplazamos \dirname{/mi/ruta} en el lado izquierdo de este |
| igor@438 | 877 ejemplo con \dirname{/mi}, \sfilename{hgwebdir.cgi} eliminará solamente |
| igor@438 | 878 \dirname{/mi} del nombre del repositorio, y nos ofrecerá la ruta |
| igor@438 | 879 virtual \dirname{ruta/este/repo} en lugar de \dirname{este/repo}. |
| igor@438 | 880 |
| igor@438 | 881 El guión \sfilename{hgwebdir.cgi} buscará recursivamente en cada |
| jerojasro@516 | 882 directorio listado en la sección \texttt{collections} de su fichero de |
| igor@438 | 883 configuración, pero \texttt{no} hará el recorrido recursivo dentro de |
| igor@438 | 884 los repositorios que encuentre. |
| igor@438 | 885 |
| igor@438 | 886 El mecanismo de \texttt{collections} permite publicar fácilmente |
| igor@438 | 887 repositorios de una forma ``hacer y olvidar''. Solamente requiere |
| jerojasro@516 | 888 configurar el guión CGI y el fichero de configuración una vez. |
| igor@438 | 889 Después de eso puede publicar y sacar de publicación un repositorio en |
| igor@438 | 890 cualquier momento incluyéndolo o excluyéndolo de la jerarquía de |
| igor@438 | 891 directorios en la cual le haya indicado a \sfilename{hgwebdir.cgi} que |
| igor@438 | 892 mirase. |
| igor@438 | 893 |
| igor@438 | 894 \subsubsection{Especificación explícita de los repositorios a publicar} |
| igor@438 | 895 |
| igor@438 | 896 Además del mecanismo \texttt{collections}, el guión |
| igor@438 | 897 \sfilename{hgwebdir.cgi} le permite publicar una lista específica de |
| igor@438 | 898 repositorios. Para hacerlo, cree una sección \texttt{paths}, con los |
| igor@438 | 899 contenidos de la siguiente forma: |
| igor@402 | 900 \begin{codesample2} |
| igor@402 | 901 [paths] |
| igor@438 | 902 repo1 = /mi/ruta/a/un/repo |
| igor@438 | 903 repo2 = /ruta/a/otro/repo |
| igor@438 | 904 \end{codesample2} |
| igor@438 | 905 En este caso, la ruta virtual (el componente que aparecerá en el URL) |
| igor@438 | 906 está en el lado derecho de cada definición, mientras que la ruta al |
| igor@438 | 907 repositorio está a la derecha. Note que no tiene que haber relación |
| igor@438 | 908 alguna entre la ruta virtual que elija y el lugar del repositorio en |
| jerojasro@516 | 909 su sistema de ficheros. |
| igor@438 | 910 |
| igor@438 | 911 Si lo desea, puede usar los dos mecanismos \texttt{collections} y |
| jerojasro@516 | 912 \texttt{paths} simultáneamente en un sólo fichero de configuración. |
| igor@402 | 913 |
| igor@402 | 914 \begin{note} |
| igor@438 | 915 Si varios repositorios tienen la misma ruta virtual, |
| igor@438 | 916 \sfilename{hgwebdir.cgi} no reportará error. Pero se comportará |
| igor@438 | 917 impredeciblemente. |
| igor@402 | 918 \end{note} |
| igor@402 | 919 |
| igor@438 | 920 \subsection{Descarga de ficheros fuente} |
| igor@438 | 921 |
| jerojasro@542 | 922 La interfaz web de Mercurial permite a los usuarios descargar |
| igor@438 | 923 un conjunto de cualquier revisión. Este fichero contendrá una réplica |
| igor@438 | 924 del directorio de trabajo en la revisión en cuestión, pero no |
| igor@438 | 925 contendrá una copia de los datos del repositorio. |
| igor@438 | 926 |
| igor@438 | 927 De forma predeterminada esta característica no está habilitada. Para |
| igor@438 | 928 lograrlo adicione un \rcitem{web}{allow\_archive} a la sección \rcsection{web} |
| igor@438 | 929 de su fichero \hgrc. |
| igor@438 | 930 |
| igor@438 | 931 \subsection{Opciones de configuración en Web} |
| igor@438 | 932 |
| jerojasro@520 | 933 Las interfaces web de Mercurial (la orden \hgcmd{serve}, y los guiones |
| igor@438 | 934 \sfilename{hgweb.cgi} y \sfilename{hgwebdir.cgi}) tienen varias |
| igor@438 | 935 opciones de configuración para establecer. Todas ellas en la sección |
| igor@438 | 936 \rcsection{web}. |
| igor@402 | 937 \begin{itemize} |
| jerojasro@516 | 938 \item[\rcitem{web}{allow\_archive}] Determina cuáles tipos de ficheros |
| igor@438 | 939 de descarga soportará Mercurial. Si habilita esta característica, |
| igor@438 | 940 los usuarios de la interfaz web podrán descargar una copia de la |
| igor@438 | 941 revisión del repositorio que estén viendo. Para activar la |
| igor@438 | 942 característica de descarga de fichero, el valor tendrá una secuencia |
| igor@438 | 943 de palabras extraídas de la lista de abajo. |
| igor@402 | 944 \begin{itemize} |
| igor@438 | 945 \item[\texttt{bz2}] Un fichero \command{tar} con el método de |
| jerojasro@542 | 946 compresión \texttt{bzip2}. Tiene la mejor tasa de compresión, |
| igor@438 | 947 pero usa más tiempo de procesamiento en el servidor. |
| igor@438 | 948 \item[\texttt{gz}] Un fichero \command{tar}, comprimido con |
| igor@438 | 949 \texttt{gzip}. |
| igor@438 | 950 \item[\texttt{zip}] Un fichero \command{zip}, comprimido con LZW. |
| jerojasro@542 | 951 Este formato posee la peor tasa de compresión, pero es muy usado en |
| igor@438 | 952 el mundo Windows. |
| igor@402 | 953 \end{itemize} |
| igor@438 | 954 Si da una lista vacía o no tiene la entrada |
| igor@438 | 955 \rcitem{web}{allow\_archive}, esta característica se deshabilitará. |
| igor@438 | 956 A continuación un ejemplo de cómo habilitar los tres formatos soportados. |
| igor@402 | 957 \begin{codesample4} |
| igor@402 | 958 [web] |
| igor@402 | 959 allow_archive = bz2 gz zip |
| igor@402 | 960 \end{codesample4} |
| igor@438 | 961 \item[\rcitem{web}{allowpull}] Booleano. Determina si la interfaz web |
| igor@438 | 962 permite a los usuarios remotos emplear \hgcmd{pull} y \hgcmd{clone} |
| igor@438 | 963 sobre el repositorio~HTTP. Si se coloca \texttt{no} o |
| igor@438 | 964 \texttt{false}, solamente la porción de los procesos |
| igor@440 | 965 ``orientados-a-humanos'' se habilita de la interfaz web. |
| jerojasro@520 | 966 \item[\rcitem{web}{contact}] Cadena. Una cadena en forma libre (pero |
| igor@440 | 967 preferiblemente corta) que identifica a la persona o grupo a cargo |
| igor@440 | 968 del repositorio. Usualmente contiene el nombre y la dirección de |
| igor@440 | 969 correo electrónico de una persona o de una lista de correo. Aveces |
| igor@440 | 970 tiene sentido colocar esta opción en el fichero \sfilename{.hg/hgrc} |
| igor@440 | 971 del repositorio, pero en otras oportunidades en el \hgrc\ global si |
| igor@440 | 972 todos los repositorios tienen un único mantenedor. |
| igor@440 | 973 \item[\rcitem{web}{maxchanges}] Entero. La cantidad máxima de |
| igor@440 | 974 conjuntos de cambios a mostrar de forma predeterminada en cada página. |
| igor@440 | 975 \item[\rcitem{web}{maxfiles}] Entero. La cantidad máxima |
| igor@440 | 976 predeterminada de ficheros modificados a desplegar en una página. |
| igor@440 | 977 \item[\rcitem{web}{stripes}] Entero. Si la interfaz web despliega |
| igor@440 | 978 ``franjas'' para facilitar la visualización alineada de filas cuando |
| igor@440 | 979 se ve una tabla, este valor controla la cantidad de filas en cada |
| igor@440 | 980 franja. |
| igor@440 | 981 \item[\rcitem{web}{style}] Controla la plantilla que Mercurial usa para |
| igor@440 | 982 desplegar la interfaz web. Mercurial viene con dos plantillas web, |
| igor@440 | 983 llamadas \texttt{default} y \texttt{gitweb} (La primera es |
| igor@440 | 984 visualmente más atractiva). Puede especificar una plantilla propia; |
| igor@440 | 985 consulte el capítulo~\ref{chap:template}. A continuación mostramos |
| igor@440 | 986 cómo habilitar el estilo \texttt{gitweb}. |
| igor@402 | 987 \begin{codesample4} |
| igor@402 | 988 [web] |
| igor@402 | 989 style = gitweb |
| igor@402 | 990 \end{codesample4} |
| igor@440 | 991 \item[\rcitem{web}{templates}] Ruta. Directorio en el que se buscarán |
| jerojasro@516 | 992 los ficheros plantilla. De forma predeterminada, busca en el |
| igor@440 | 993 directorio en el cual fue instalado. |
| igor@402 | 994 \end{itemize} |
| igor@440 | 995 Si usa \sfilename{hgwebdir.cgi}, puede añadir otras opciones de |
| igor@440 | 996 configuración en una sección \section{web} del fichero |
| igor@440 | 997 \sfilename{hgweb.config} en lugar del fichero \hgrc\, si lo considera |
| igor@440 | 998 más conveniente. Estas opciones son \rcitem{web}{motd} y |
| igor@402 | 999 \rcitem{web}{style}. |
| igor@402 | 1000 |
| igor@440 | 1001 \subsubsection{Opciones específicas para repositorios individuales} |
| igor@440 | 1002 |
| igor@440 | 1003 Ciertas opciones de configuración de \rcsection{web} deben estar |
| igor@440 | 1004 ubicadas en el \sfilename{.hg/hgrc} de un repositorio en lugar del |
| igor@440 | 1005 fichero del usuario o el \hgrc global. |
| igor@402 | 1006 \begin{itemize} |
| igor@440 | 1007 \item[\rcitem{web}{description}] Cadena. Una cadena de forma |
| jerojasro@520 | 1008 libre (preferiblemente corta) que describa los contenidos o el |
| igor@440 | 1009 propósito del repositorio. |
| igor@440 | 1010 \item[\rcitem{web}{name}] Cadena. El nombre para visualizar en la |
| igor@440 | 1011 interfaz web del repositorio. Sustituye el nombre predeterminado, el |
| igor@440 | 1012 cual es el último componente de la ruta del repositorio. |
| igor@402 | 1013 \end{itemize} |
| igor@402 | 1014 |
| igor@440 | 1015 \subsubsection{Opciones específicas a la orden \hgcmd{serve}} |
| igor@440 | 1016 |
| igor@440 | 1017 Algunas opciones en la sección \rcsection{web} de un fichero \hgrc\ |
| igor@440 | 1018 son de uso exclusivo para la orden \hgcmd{serve}. |
| igor@402 | 1019 \begin{itemize} |
| igor@440 | 1020 \item[\rcitem{web}{accesslog}] Ruta. El nombre del fichero en el cual |
| igor@440 | 1021 se escribe la bitácora de acceso. En principio, la orden |
| igor@440 | 1022 \hgcmd{serve} escribe esta información a la salida estándar, no a un |
| igor@440 | 1023 fichero. Las líneas de la bitácora se escriben en un formato de |
| igor@440 | 1024 fichero ``combinado'' estándar, usado por casi todos los servidores |
| igor@440 | 1025 web. |
| igor@440 | 1026 \item[\rcitem{web}{address}] Cadena. La dirección local en la cual el |
| igor@440 | 1027 servidor debe escuchar peticiones entrantes. En principio, el |
| igor@440 | 1028 servidor escucha en todas las direcciones. |
| igor@440 | 1029 \item[\rcitem{web}{errorlog}] Ruta. El nombre de un fichero en el |
| igor@440 | 1030 cual escribir la bitácora de error. En principio, la orden |
| igor@440 | 1031 \hgcmd{serve} escribe esta información en la salida de error |
| igor@440 | 1032 estándar, no a un fichero. |
| igor@440 | 1033 \item[\rcitem{web}{ipv6}] Booleano. Si se usa o no el protocolo |
| igor@440 | 1034 IPv6. En principio, IPv6 no se usa. |
| igor@440 | 1035 \item[\rcitem{web}{port}] Entero. El número del puerto~TCP en el cuál |
| igor@440 | 1036 el servidor escuchará. El puerto predeterminado es el~8000. |
| igor@402 | 1037 \end{itemize} |
| igor@402 | 1038 |
| igor@440 | 1039 \subsubsection{Elegir el fichero \hgrc\ correcto para las |
| igor@440 | 1040 configuraciones de \rcsection{web}} |
| igor@440 | 1041 |
| igor@440 | 1042 Es importante recordar que un servidor web como Apache o |
| igor@440 | 1043 \texttt{lighttpd} se ejecutarán bajo el usuario~ID que generalmente no |
| igor@440 | 1044 es el suyo Los guiones CGI ejecutados por su servidor, tales como |
| igor@440 | 1045 \sfilename{hgweb.cgi}, se ejecutarán también con el usuario~ID. |
| igor@440 | 1046 |
| igor@440 | 1047 Si añade opciones \rcsection{web} a su fichero personal \hgrc\, Los |
| igor@440 | 1048 guiones CGI no leerán tal fichero \hgrc\. Tales configuraciones |
| igor@440 | 1049 solamente afectarán el comportamiento de la orden \hgcmd{serve} cuando |
| igor@440 | 1050 usted lo ejecuta. Para logar que los guiones CGI vean sus |
| igor@440 | 1051 configuraciones, o bien cree un fichero \hgrc\ en el directorio hogar |
| igor@440 | 1052 del usuario ID que ejecuta su servidor web, o añada tales |
| jerojasro@457 | 1053 configuraciones al fichero global \hgrc. |
| igor@402 | 1054 |
| igor@402 | 1055 |
| igor@402 | 1056 %%% Local Variables: |
| igor@402 | 1057 %%% mode: latex |
| igor@402 | 1058 %%% TeX-master: "00book" |
| igor@402 | 1059 %%% End: |