Mostrando entradas con la etiqueta Configurar Apache. Mostrar todas las entradas
Mostrando entradas con la etiqueta Configurar Apache. Mostrar todas las entradas

2019-08-07

Problema después de hacer un APT UPDATE con la extension MSSQL 17 y PHP 7 en linux debian 9

Hola gente después de hacer un mantenimiento en mi server me encontré con un problema después de hacer APT Update.

En la lista de actualizaciones, tenia que actualizaba la versión de mi extensiones PHP para MSSQL de la msodbcsql17:amd64 (17.3.1.1-1, 17.4.1.1-1) y mssql-tools:amd64 (17.3.0.1-1, 17.4.1.1-1)

Pero como esto me trajo problema de conexión entre PHP y MSSQL dejo la solución para volver atrás esos cambio y que funcione de nuevo eso.

  1. Mira en ./../apt/history.log y recuperar las versión (vieja y nueva) en mi caso msodbcsql17:amd64 (17.3.1.1-1, 17.4.1.1-1) y mssql-tools:amd64 (17.3.0.1-1, 17.4.1.1-1)  
  2. apt install msodbcsql17=17.3.1.1-1 
  3. apt install mssql-tools=17.3.0.1-1
    Listo eso es todo para volver a una versión puntual con APT-GET

    Esto también es valido para volver atrás cualquier actualizacion por APT-GET a una versión puntal; el lugar útil para encontrar los datos correcto de los cambios lo podes ver en 

    /var/log/apt/history.log y /var/log/apt/term.log

    2010-09-01

    Proteje tu sitio web con Apache por medio de .htaccess

    Gran trabajo de Jeff Star y que ha publicado en su web con el nombre de The Perishable Press 4G Blacklist, una lista de directivas para su uso en servidores Apache y que se implemente fácilmente a través de .htaccess o el archivo de configuración httpd.conf. La lista está formada por varias partes e integra una serie de instrucciones que aseguran nuestros sitios web contra una amplia gama de actividades maliciosas.


    Contenido del archivo .htaccess

    1. ### PERISHABLE PRESS 4G BLACKLIST ###  
    2.   
    3. # ESSENTIALS  
    4. RewriteEngine on  
    5. ServerSignature Off  
    6. Options All -Indexes  
    7. Options +FollowSymLinks  
    8.   
    9. # FILTER REQUEST METHODS  
    10. <IfModule mod_rewrite.c>  
    11. RewriteCond %{REQUEST_METHOD} ^(TRACE|DELETE|TRACK) [NC]  
    12. RewriteRule ^(.*)$ - [F,L]  
    13. </IfModule>  
    14.   
    15. # BLACKLIST CANDIDATES  
    16. <Limit GET POST PUT>  
    17. Order Allow,Deny  
    18. Allow from all  
    19. Deny from 75.126.85.215 "# blacklist candidate 2008-01-02 = admin-ajax.php attack "  
    20. Deny from 128.111.48.138 "# blacklist candidate 2008-02-10 = cryptic character strings "  
    21. Deny from 87.248.163.54 "# blacklist candidate 2008-03-09 = block administrative attacks "  
    22. Deny from 84.122.143.99 "# blacklist candidate 2008-04-27 = block clam store loser "  
    23. Deny from 210.210.119.145 "# blacklist candidate 2008-05-31 = block _vpi.xml attacks "  
    24. Deny from 66.74.199.125 "# blacklist candidate 2008-10-19 = block mindless spider running "  
    25. Deny from 203.55.231.100 "# 1048 attacks in 60 minutes"  
    26. Deny from 24.19.202.10 "# 1629 attacks in 90 minutes"  
    27. </Limit>  
    28.   
    29. # QUERY STRING EXPLOITS  
    30. <IfModule mod_rewrite.c>  
    31. RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]  
    32. RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]  
    33. RewriteCond %{QUERY_STRING} tag\= [NC,OR]  
    34. RewriteCond %{QUERY_STRING} ftp\: [NC,OR]  
    35. RewriteCond %{QUERY_STRING} http\: [NC,OR]  
    36. RewriteCond %{QUERY_STRING} https\: [NC,OR]  
    37. RewriteCond %{QUERY_STRING} mosConfig [NC,OR]  
    38. RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>|'|"|;|\?|\*).* [NC,OR]  
    39. RewriteCond %{QUERY_STRING} ^.*(%22|%27|%3C|%3E|%5C|%7B|%7C).* [NC,OR]  
    40. RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]  
    41. RewriteCond %{QUERY_STRING} ^.*(globals|encode|config|localhost|loopback).* [NC,OR]  
    42. RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare|drop).* [NC]  
    43. RewriteRule ^(.*)$ - [F,L]  
    44. </IfModule>  
    45.   
    46. # CHARACTER STRINGS  
    47. <IfModule mod_alias.c>  
    48. # BASIC CHARACTERS  
    49. RedirectMatch 403 \,  
    50. RedirectMatch 403 \:  
    51. RedirectMatch 403 \;  
    52. RedirectMatch 403 \=  
    53. RedirectMatch 403 \@  
    54. RedirectMatch 403 \[  
    55. RedirectMatch 403 \]  
    56. RedirectMatch 403 \^  
    57. RedirectMatch 403 \`  
    58. RedirectMatch 403 \{  
    59. RedirectMatch 403 \}  
    60. RedirectMatch 403 \~  
    61. RedirectMatch 403 \"  
    62. RedirectMatch 403 \$  
    63. RedirectMatch 403 \<  
    64. RedirectMatch 403 \>  
    65. RedirectMatch 403 \|  
    66. RedirectMatch 403 \.\.  
    67. RedirectMatch 403 \/\/  
    68. RedirectMatch 403 \%0  
    69. RedirectMatch 403 \%A  
    70. RedirectMatch 403 \%B  
    71. RedirectMatch 403 \%C  
    72. RedirectMatch 403 \%D  
    73. RedirectMatch 403 \%E  
    74. RedirectMatch 403 \%F  
    75. RedirectMatch 403 \%22  
    76. RedirectMatch 403 \%27  
    77. RedirectMatch 403 \%28  
    78. RedirectMatch 403 \%29  
    79. RedirectMatch 403 \%3C  
    80. RedirectMatch 403 \%3E  
    81. RedirectMatch 403 \%3F  
    82. RedirectMatch 403 \%5B  
    83. RedirectMatch 403 \%5C  
    84. RedirectMatch 403 \%5D  
    85. RedirectMatch 403 \%7B  
    86. RedirectMatch 403 \%7C  
    87. RedirectMatch 403 \%7D  
    88. # COMMON PATTERNS  
    89. Redirectmatch 403 \_vpi  
    90. RedirectMatch 403 \.inc  
    91. Redirectmatch 403 xAou6  
    92. Redirectmatch 403 db\_name  
    93. Redirectmatch 403 select\(  
    94. Redirectmatch 403 convert\(  
    95. Redirectmatch 403 \/query\/  
    96. RedirectMatch 403 ImpEvData  
    97. Redirectmatch 403 \.XMLHTTP  
    98. Redirectmatch 403 proxydeny  
    99. RedirectMatch 403 function\.  
    100. Redirectmatch 403 remoteFile  
    101. Redirectmatch 403 servername  
    102. Redirectmatch 403 \&rptmode\=  
    103. Redirectmatch 403 sys\_cpanel  
    104. RedirectMatch 403 db\_connect  
    105. RedirectMatch 403 doeditconfig  
    106. RedirectMatch 403 check\_proxy  
    107. Redirectmatch 403 system\_user  
    108. Redirectmatch 403 \/\(null\)\/  
    109. Redirectmatch 403 clientrequest  
    110. Redirectmatch 403 option\_value  
    111. RedirectMatch 403 ref\.outcontrol  
    112. # SPECIFIC EXPLOITS  
    113. RedirectMatch 403 errors\.  
    114. RedirectMatch 403 config\.  
    115. RedirectMatch 403 include\.  
    116. RedirectMatch 403 display\.  
    117. RedirectMatch 403 register\.  
    118. Redirectmatch 403 password\.  
    119. RedirectMatch 403 maincore\.  
    120. RedirectMatch 403 authorize\.  
    121. Redirectmatch 403 macromates\.  
    122. RedirectMatch 403 head\_auth\.  
    123. RedirectMatch 403 submit\_links\.  
    124. RedirectMatch 403 change\_action\.  
    125. Redirectmatch 403 com\_facileforms\/  
    126. RedirectMatch 403 admin\_db\_utilities\.  
    127. RedirectMatch 403 admin\.webring\.docs\.  
    128. Redirectmatch 403 Table\/Latest\/index\.  
    129. </IfModule>  
    Para funcionar correctamente, el archivo .htaccess requiere de dos módulos específicos de Apache: mod_rewrite y mod_alias.
    Más información acerca de las instrucciones de uso y explicaciones del código en Perishable Press

    2010-06-04

    ZeroDayScan – Detecta problemas de seguridad en tu sitio web

    Después de solicitar la inclusión de un archivo de texto en la raiz de nuestro sitio web, ZeroDayScan realiza una serie de análisis que pretenden detectar problemas de seguridad de varios tipos, desde archivos y directorios ocultos hasta problemas de SQL injection o ataques Cross Site Scripting (XSS).

    Con informes generados en PDF, el resultado puede tardar hasta 72 horas en ser enviado por email. Disponen de un blog donde explican las novedades y detalles del proyecto, tendremos que estar atentos…

    Vía Killerstartups

    2010-03-13

    bitnami.org - Los proyectos web mas populares enpaquetados para instalar



    BitNami.org es un sitio donde encontrar los proyecto mas populares para alojar en un servidor web, empaquetado y listos para instalar de manera muy simple.



    Utiliza tu aplicación web, favorita como... Alfresco, Joomla!, Drupal, Redmine, Mediawiki, Trac, Wordpress, Roller, DokuWiki, Subversion, SugarCRM... sobre tu sistema operativo favorito como Windows, Linux, Mac, Solaris.. Y lo mejor de todo, que es gratis....!!!

    Todo de manera muy simple, muy recomendado para los desarrolladores que quieren crear un entorno de desarrollo de manera rápida.





    Alfresco Coppermine Photo Gallery DokuWiki Drupal

    Enano CMS Gallery JasperServer Joomla

    KnowledgeTree Liferay Mantis MediaWiki

    Moodle Opina Radiant CMS Redmine

    Roller Spree Subversion SugarCRM

    Trac Tracks Typo WordPress

    eZ Publish ocPortal phpBB Empty Stack








    WAMPStack LAMPStack MAMPStack SAMPStack

    WAPPStack LAPPStack MAPPStack Empty Stack









    RubyStack JRubyStack DjangoStack






    Link: BitNami.org

    2010-02-24

    21 hacks de htaccess que todo desarrollador debería conocer

    La configuración del archivo .htaccess de Apache (hypertext access) puede ser una herramienta muy ponderosa en el desarrollo web si se utiliza de la forma adecuada.

    Mediante .htaccess podremos realizar redirecciones, proteger archivos y directorios con contraseña, prevenir el hotlinking y el robo de ancho de banda, comprimir archivos y mucho, mucho más. Entérate cómo.

    Asegúrate de hacer un backup de tu archivo .htaccess actual antes de aplicar cualquiera de estos hacks.

    1. Prevenir el Hotlinking

    ¿Estás cansado de que la gente utilice tu ancho de banda poniendo las imágenes albergadas en tu servidor en su sitio web? Añade el siguiente código al final de tu archivo .htaccess para prevenir el hotlinking:

    1. Options +FollowSymlinks
    2. #Protect against hotlinking
    3. RewriteEngine On
    4. RewriteCond %{HTTP_REFERER} !^$
    5. RewriteCond %{HTTP_REFERER} !^http://(www.)?nombrededominio.com/ [nc]
    6. RewriteRule .*.(gif|jpg|png)$ http://nombrededominio.com/img/no_robar_ancho_de_banda.gif[nc]

    2. Bloquea todas las peticiones del user-agent

    Es posible bloquear a todos los user-agents indeseados que pueden ser potencialmente dañinos o quizá simplemente para mantener la carga del servidor lo más baja posible.

    1. #Block bad bots
    2. SetEnvIfNoCase user-Agent ^FrontPage [NC,OR]
    3. SetEnvIfNoCase user-Agent ^Java.* [NC,OR]
    4. SetEnvIfNoCase user-Agent ^Microsoft.URL [NC,OR]
    5. SetEnvIfNoCase user-Agent ^MSFrontPage [NC,OR]
    6. SetEnvIfNoCase user-Agent ^Offline.Explorer [NC,OR]
    7. SetEnvIfNoCase user-Agent ^[Ww]eb[Bb]andit [NC,OR]
    8. SetEnvIfNoCase user-Agent ^Zeus [NC]
    9. "" post="" head="">
    10. Order Allow,Deny
    11. Allow from all
    12. Deny from env=bad_bot

    3. Redirecciona a todos, excepto a ciertas IPs

    Si por alguna razón deseas denegar el acceso a todos los usuarios o sólo permitir a un cierto grupo de direcciones IP para que tengan acceso a tu sitio, añade el siguiente código a tu archivo .htaccess:

    1. ErrorDocument 403 http://www.nombrededominio.com
    2. Order deny,allow
    3. Deny from all
    4. Allow from 124.34.48.165
    5. Allow from 102.54.68.123

    4. Redirecciones 301 amigables con SEO

    Si has transferido nombres de dominio o deseas redireccionar a una página específica sin que afecte a los resultados de los motores de búsqueda como Google, utiliza el siguiente código:

    1. Redirect 301 /d/file.html http://www.nombrededominio.com/r/file.html

    5. Crea una página personalizada para cada tipo de error

    Si te cansaste del diseño por defecto de las páginas de error 401, 403, 404, 500, etc. puedes fácilmente crear la tuya propia y referirte hacía ella de esta forma:

    1. ErrorDocument 401 /error/401.php
    2. ErrorDocument 403 /error/403.php
    3. ErrorDocument 404 /error/404.php
    4. ErrorDocument 500 /error/500.php

    6. Crea una lista de IPs prohibidas

    ¿Te cansaste de obtener siempre los mismos comentarios de ciertos usuarios una y otra vez? Simplemente prohíbe el acceso a determinadas IPs, añadiendo el siguiente código:

    1. allow from all
    2. deny from 145.186.14.122
    3. deny from 124.15

    7. Setea una dirección de e-mail por defecto para el administrador de servidor

    Con el siguiente código puedes especificar la dirección de correo electrónico por defecto para el administrador de servidor:

    1. ServerSignature EMail
    2. SetEnv SERVER_ADMIN default@dominio.com

    8. Deshabilita la ventana de aviso de descarga

    Usualmente al descargar algo de un sitio web, saltará una ventana que pregunta si deseas abrir el archivo o guardarlo en tu PC. Para prevenir esto, utiliza el siguiente código:

    1. AddType application/octet-stream .pdf
    2. AddType application/octet-stream .zip
    3. AddType application/octet-stream .mov

    9. Protege un archivo específico

    El código que sigue te permite denegar el acceso a cualquier archivo que desees, mostrando una página de error 403 cuando alguien intenta acceder al mismo:

    1. #Protect the .htaccess File
    2. "">
    3. order allow,deny
    4. deny from all

    10. Comprime componentes con mod_deflate

    Como alternativa a la compresión de archivos mediante Gzip, puedes implementar mod_deflate (que se supone es más rápido). Coloca el siguiente código en la parte superior de tu archivo .htaccess:

    1. "">
    2. (js|css)$="">
    3. SetOutputFilter DEFLATE

    11. Agrega headers de expiración a los archivos

    El siguiente código muestra cómo agregar fechas de expiración en las cabeceras de los archivos:

    1. (ico|pdf|flv|jpg|jpeg|png|gif|swf)$="">
    2. Header set Expires "Wed, 21 May 2010 20:00:00 GMT"

    12. Seteando la página por defecto

    Puedes hacer que la página a mostrar ni bien un usuario llegue a tu sitio no sea la archiconocida "index". Aquí seteamos "about.html" como página de inicio:

    1. #Serve Alternate Default Index Page
    2. DirectoryIndex about.html

    13. Proteje tus archivos y directorios con una contraseña

    1. #proteger un archivo con contraseña
    2. "">
    3. AuthType Basic
    4. AuthName "Prompt"
    5. AuthUserFile /home/path/.htpasswd
    6. Require valid-user
    7. # proteger un directorio con contraseña
    8. resides
    9. AuthType basic
    10. AuthName "This directory is protected"
    11. AuthUserFile /home/path/.htpasswd
    12. AuthGroupFile /dev/null
    13. Require valid-user

    14. Hacer una redirección 301 de un dominio viejo a uno nuevo

    Incluyendo este snippet en el .htaccess de tu viejo dominio, conseguirás redigir a otro nuevo (sin ser penalizado por Google por duplicar contenido, dado que el 301 es un aviso de "redirección permanente"):

    1. # Redirigir de un dominio viejo a uno nuevo
    2. RewriteEngine On
    3. RewriteRule ^(.*)$ http://www.nuevodominio.com/$1 [R=301,L]

    15. Forzar el cacheo

    El siguiente snippet no va a incrementar directamente la velocidad de carga de tu sitio en general, pero sí va a cargar más rápido cuando el mismo usuario vuelva a visitarlo al enviar un status 304 cuando se pidan elementos que no han sido modificados. Puedes cambiar la frecuencia de cacheo al cambiar el número de segundos (en este ejemplo se da una vez al día):

    1. FileETag MTime Size
    2. ExpiresActive on
    3. ExpiresDefault "access plus 86400 seconds"

    16. Comprimir componentes al activar Gzip

    Esto hace que sea más rápida la carga de tu sitio:

    1. AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
    2. BrowserMatch ^Mozilla/4 gzip-only-text/html
    3. BrowserMatch ^Mozilla/4.0[678] no-gzip
    4. BrowserMatch bMSIE !no-gzip !gzip-only-text/html

    17. Quitar palabras o strings de una URL

    En este ejemplo, quitaremos "category" de nuestras URL, es decir: http://tudominio.com/category/blue -> http://tudominio.com/blue

    Agrega este código al final de tu .htaccess:

    1. RewriteRule ^category/(.+)$ http://www.tudominio.com/$1 [R=301,L]

    18. Deshabilitar la navegación por los directorios de tu sitio

    1. Options All -Indexes

    19. Redirigir los Feeds de WordPress a FeedBurner

    1. #Redirect wordpress content feeds to feedburner
    2. "">
    3. RewriteEngine on
    4. RewriteCond %{HTTP_USER_AGENT} !FeedBurner [NC]
    5. RewriteCond %{HTTP_USER_AGENT} !FeedValidator [NC]
    6. RewriteRule ^feed/?([_0-9a-z-]+)?/?$ http://feeds.feedburner.com/tufeed [R=302,NC,L]

    20. Remover la extensión del archivo de una URL

    Para que sea más amigable al usuario y a los buscadores, por ejemplo "http://www.tudominio.com/autos.html" -> "http://www.tudominio.com/autos"

    1. RewriteRule ^(([^/]+/)*[^.]+)$ /$1.php [L]

    21. Quitar el "www" del dominio

    1. #remove www from URI
    2. RewriteEngine On
    3. RewriteCond %{HTTP_HOST} ^www\.dominio\.com$ [NC]
    4. RewriteRule ^(.*)$ http://dominio.com/$1 [L,R=301]

    Más sobre .htaccess (en inglés):

    Fuente: DevMoose

    Fuente: LINK

    2010-01-27

    Configurar Apache con Subversion

    Servidor basado en Apache

    Introducción

    La configuración más flexible de todas las instalaciones de servidor posibles para Subversion es la que se basa en Apache. Aunque es un poco más complicada de preparar, ofrece beneficios que otros servidores no pueden dar:

    WebDAV

    El servidor de Subversion basado en Apache utiliza el protocolo WebDAV que se utiliza por muchos otros programas. Por ejemplo, podría montar dicho repositorio como una “Carpeta web” en el explorador de Windows y luego acceder a ella como cualquier otra carpeta en su sistema de ficheros.

    Navegando por el repositorio

    Puede apuntar su navegador a la URL del repositorio y navegar por sus contenidos sin tener un cliente de Subversion. Esto da acceso a sus datos a un mayor círculo de usuarios.

    Autentificación

    Puede utilizar cualquier mecanismo de autentificación que Apache soporte, incluyendo SSPI y LDAP.

    Seguridad

    Dado que Apache es muy estable y seguro, automáticamente obtendrá la misma seguridad para su repositorio. Esto incluye la encriptación SSL.

    Instalando Apache

    La primera cosa que necesita antes de instalar Apache es un ordenador con Windows 2000, Windows XP con SP1, Windows 2003, Vista o Server 2008.

    Aviso

    Por favor tenga en cuenta que utilizar Windows XP sin el Service Pack 1 corrompe datos de la red y por tanto ¡podría corromper su repositorio!

    1. Descargue la última versión del servidor web Apache desde http://httpd.apache.org/download.cgi. Asegúrese de que descarga la versión 2.2.x - ¡las versiones 1.3.xx no servirán!

      El instalador MSI de Apache se puede encontrar haciendo click en other files (otros ficheros), y luego navegando a binaries/win32. Puede que quiera seleccionar el fichero MSI apache-2.2.x-win32-x86-openssl-0.9.x.msi (el que incluye OpenSSL).

    2. Una vez que tenga el instalador de Apache2 puede hacer doble click en él y le guiará a través del proceso de instalación. Asegúrese de que ha introducido la URL del servidor correctamente (si no tiene un nombre DNS para su servidor introduzca la dirección IP). Es recomendable que instale Apache para Todos los usuarios, en el Puerto 80, como un Servicio. Nota: si ya tiene IIS u otro programa ejecutándose que escuche en el puerto 80 la instalación puede fallar. Si esto ocurre, vaya al directorio de Archivos de programa, \Apache Group\Apache2\conf y localice el fichero httpd.conf. Edite dicho fichero para cambiar Listen 80 por un puerto libre, por ejemplo, Listen 81. Luego reinicie la instalación - esta vez debería terminar sin problemas.

    3. Ahora compruebe si el servidor web Apache funciona correctamente apuntando desde su navegador web a la dirección http://localhost/ - debería aparecer un sitio web preconfigurado.

    Atención

    Si decide instalar Apache como un servicio, queda avisado de que por defecto se ejecutará con la cuenta de sistema local. Sería una práctica más segura que creara una cuenta separada para que Apache se ejecutara bajo ella.

    Asegúrese de que la cuenta en el servidor bajo la que se ejecuta Apache tenga una entrada explícita en la lista de control de acceso del directorio del repositorio (click con el botón derecho en el directorio | propiedades | seguridad), con control total. Si no lo hace así, los usuarios no podrán confirmar sus cambios.

    Incluso si Apache se ejecuta como sistema local, aún así necesitará dicha entrada (que en este caso debería ser la cuenta SYSTEM).

    Si Apache no tiene este permiso configurado, sus usuarios tendrán mensajes de error “Acceso denegado”, que se mostrarán en el registro de errores de Apache como error 500.

    Instalando Subversion

    1. Descarge la última versión de los binarios de Subversion para Apache y Windows 32. Asegúrese de obtener la versión correcta para integrarla en su versión de Apache, porque si no obtendrá un oscuro mensaje de error cuando intente reiniciar. Si tiene Apache 2.2.x acuda a http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=8100.

    2. Ejecute el instalador de Subversion y siga las instrucciones. Si el instalador de Subversion reconoce que ha instalado Apache, habrá casi terminado. Si no puede encontrar un servidor de Apache entonces tendrá que realizar algunos pasos adicionales.

    3. Utilizando el explorador de Windows, vaya al directorio de instalación de Subversion (normalmente C:\Archivos de programa\Subversion) y busque los ficheros /httpd/mod_dav_svn.so y mod_authz_svn.so. Copie estos ficheros al directorio de módulos de Apache (normalmente C:\Archivos de programa\Apache Group\Apache2\modules).

    4. Copie el fichero /bin/libdb*.dll y /bin/intl3_svn.dll desde el directorio de instalación de Subversion al directorio bin de Apache.

    5. Edite el fichero de configuración de Apache (normalmente C:\Archivos de Programa\Apache Group\Apache2\conf\httpd.conf) con un editor de texto como el Bloc de Notas y haga los siguientes cambios:

      Descomente (quitando la marca '#') las siguientes líneas:

      #LoadModule dav_fs_module modules/mod_dav_fs.so
      #LoadModule dav_module modules/mod_dav.so

      Añada las dos líneas siguientes al final de la sección LoadModule.

      LoadModule dav_svn_module modules/mod_dav_svn.so
      LoadModule authz_svn_module modules/mod_authz_svn.so

    Configuración

    Ahora ya ha preparado Apache y Subversion, pero Apache aún no sabe cómo manejar los clientes de Subversion como TortoiseSVN. Para que Apache sepa qué URL debe utilizarse para los repositorios de Subversion debe editar el fichero de configuración de Apache (normalmente está en C:\Archivos de programa\Apache Group\Apache2\conf\httpd.conf) con cualquier editor de texto que desee (por ejemplo, el Bloc de notas):

    1. Al final del fichero de configuración, añada las siguientes líneas:


      DAV svn
      SVNListParentPath on
      SVNParentPath D:\SVN
      #SVNIndexXSLT "/svnindex.xsl"
      AuthType Basic
      AuthName "Repositorios de Subversion"
      AuthUserFile passwd
      #AuthzSVNAccessFile svnaccessfile
      Require valid-user

      Esto configura el Apache de forma que todos sus repositorios de Subversion están físicamente localizados bajo D:\SVN. Los respositorios se sirven al mundo exterior desde la URL: http://MiServidor/svn/ . El acceso está restringido a los usuarios/contraseñas listados en el fichero passwd

    2. Para crear el fichero passwd, abra el Símbolo del sistema o la línea de comandos (ventana DOS) de nuevo, cambie a la carpeta Apache2 (normalmente C:\Archivos de programa\Apache Group\Apache2) y cree el fichero mediante

      bin\htpasswd -c passwd 

      Esto creará un nuevo fichero con el nombre passwd que se utilizará para la autentificación. Se pueden crear usuarios adicionales con

      bin\htpasswd passwd 
    3. Reinice el servicio de Apache de nuevo.

    4. Apunte su navegador a http://MiServidor/svn/MiNuevoRepositorio (donde MiNuevoRepositorio es el nombre del repositorio de Subversion que creó antes). Si todo ha ido bien debería ver una ventana preguntando por un usuario y una contraseña, y luego podrá ver los contenidos de su repositorio.

    Una explicación breve sobre lo que acaba de introducir:

    Tabla 3.1. Configuración de httpd.conf de Apache

    ConfiguraciónExplicación
    significa que los repositorios de Subversion están disponibles en la URL http://MiServidor/svn/
    DAV svnle dice a Apache qué módulo será responsable de servir esa URL - en este caso, el módulo de Subversion.
    SVNListParentPath onPara Subversion 1.3 y superiores, esta directiva habilita el listado de todos los repositorios disponibles bajo SVNParentPath.
    SVNParentPath D:\SVNle dice a Subversion que busque repositorios bajo D:\SVN
    SVNIndexXSLT "/svnindex.xsl"Utilizado para mejorar la visualización desde un navegador de web.
    AuthType Basicse utiliza para activar la autentificación básica, es decir, Usuario/contraseña
    AuthName "Subversion repositories"se utiliza cuando le aparezca un diálogo de autentificación al usuario como información para decirle para qué se necesita su autentificación
    AuthUserFile passwdespecifica qué fichero de contraseñas se utiliza para la autentificación
    AuthzSVNAccessFilelugar del fichero de Acceso para las rutas dentro del repositorio de Subversion
    Require valid-userespecifica que sólo los usuarios que hayan introducido un par usuario/contraseña válido podrán acceder a la URL


    Pero eso es sólo un ejemplo. Hay muchas, muchas más posibilidades de lo que puede hacer con el servidor web Apache.

    • Si desea que su repositorio tenga acceso de lectura para todo el mundo pero el acceso de escritura sólo para usuarios específicos, puede cambiar la línea

      Require valid-user

      por


      Require valid-user

    • Utilizando un fichero passwd se limita y se otorga acceso a todos sus repositorios como si fueran uno solo. Si desea más control sobre qué usuarios tienen acceso a cada carpeta dentro de un repositorio, puede descomentar la línea

      #AuthzSVNAccessFile svnaccessfile

      y crear un fichero de acceso de Subversion. Apache se asegurará que sólo los usuarios válidos pueden acceder su ruta /svn, y luego pasará el nombre de usuario al módulo de Subversion AuthzSVNAccessFile para que pueda forzar un acceso más controlado basado en las reglas que se especifican en el fichero de acceso de Subversion. Tenga en cuenta que las rutas se especifican o bien como repos:ruta o simplemente ruta. Si no especifica un repositorio en concreto, la regla de acceso se aplicará a todos los repositorios bajo SVNParentPath. El formato del fichero de política de autorización utilizado por mod_authz_svn se describe en “Autorización basada en rutas”

    • Para hacer que la visualización del repositorio con un navegador web sea 'más bonita', descomente la línea

      #SVNIndexXSLT "/svnindex.xsl"

      y ponga los ficheros svnindex.xsl, svnindex.css y menucheckout.ico en su directorio raíz de documentos (normalmente C:/Archivos de programa/Apache Group/Apache2/htdocs). El directorio está establecido con la directiva DocumentRoot en su fichero de configuración de Apache.

      Puede obtener estos tres ficheros directamente desde nuestro repositorio de código fuente en http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/contrib/other/svnindex. (“¡TortoiseSVN es gratis!” le explica cómo acceder al repositorio de código de TortoiseSVN).

      El fichero XSL del repositorio de TortoiseSVN tiene una característica destacada: si navega el repositorio con su navegador web, todas las carpetas de su repositorio mostrarán un icono a la derecha. Si pulsa sobre dicho icono, se iniciará el diálogo de obtener de TortoiseSVN para esa URL.

    Múltiples repositorios

    Si ha utilizado la directiva SVNParentPath no necesita cambiar el fichero de configuración de Apache cada vez que añada un nuevo repositorio de Subversion. Simplemente cree el nuevo repositorio bajo la misma ruta que el primer repositorio, ¡y ya está! En mi compañía, tengo acceso directo a esa carpeta en concreto utilizando SMB (el acceso normal de ficheros de Windows). Por lo que simplemente creo una nueva carpeta allí, ejecuto el comando de TortoiseSVN TortoiseSVNCrear repositorio aquí... y ya hay un nuevo proyecto que tiene su hogar...

    Si está utilizando Subversion 1.3 o posterior, puede utilizar la directiva SVNListParentPath on para permitir que Apache produzca un listado de todos los proyectos disponibles si apunta su navegador a la ruta raíz en vez de a un repositorio en concreto.

    Autorización basada en rutas

    El módulo mod_authz_svn le permite un control detallado de los permisos de acceso basado en nombres de usuarios y rutas de repositorio. Esto está disponible si utiliza el servidor de Apache, y desde Subversion 1.3 también está disponible si utiliza svnserve.

    Esto sería un fichero de ejemplo:

    [groups]
    admin = john, kate
    devteam1 = john, rachel, sally
    devteam2 = kate, peter, mark
    docs = bob, jane, miguel
    training = zak
    # Regla de acceso por defecto para TODOS los repositorios
    # Todo el mundo puede leer, los administradores pueden escribir,
    # Donpe Ligro está exluído.
    [/]
    * = r
    @admin = rw
    donpeligro =
    # Permitir a los desarrolladores acceso completo
    # al repositorio de su proyecto
    [proj1:/]
    @devteam1 = rw
    [proj2:/]
    @devteam2 = rw
    [bigproj:/]
    @devteam1 = rw
    @devteam2 = rw
    trevor = rw
    # Dar a los documentadores acceso de escritura
    # a todas las carpetas de documentación
    [/trunk/doc]
    @docs = rw
    # Dar a los becarios acceso de escritura
    # sólo al repositorio de pruebas
    [TrainingRepos:/]
    @training = rw

    Tenga en cuenta que comprobar cada ruta puede ser una operación costosa, particularmente en el caso del registro de revisiones. El servidor toma cada ruta cambiada en cada revisión y comprueba si se puede leer, lo que puede ser lento en revisiones que afecten a un gran número de ficheros.

    La autentificación y la autorización son procesos separados. Si un usuario desea tener acceso a una ruta de un repositorio, tiene que cumplir ambos requisitos, los requerimientos usuales de autentificación y los requerimientos de autorización del fichero de acceso.

    Autentificación con un dominio de Windows

    Como habrá notado necesita introducir una entrada usuario/contraseña en el fichero passwd para cada usuario de forma separada. Y si (por razones de seguridad) quiere que sus usuarios cambien periódicamente sus contraseñas tendrá que hacer el cambio de forma manual.

    Pero hay una solución a este problema - al menos si accede al repositorio desde dentro de una LAN con un controlador de dominio de Windows: mod_auth_sspi!

    El módulo original de SSPI fue ofrecido por Syneapps incluyendo el código fuente. Pero su desarrollo se detuvo. No se desespere, la comunidad lo ha retomado y mejorado. Tiene un nuevo hogar en SourceForge.

    • Descargue el módulo que concuerde con su versión de Apache, y copie el fichero mod_auth_sspi.so en la carpeta de módulos de Apache.

    • Edite el fichero de configuración de Apache: añada la línea

      LoadModule sspi_auth_module modules/mod_auth_sspi.so

      a la sección LoadModule. Asegúrese de insertar esta línea antes de la línea

      LoadModule auth_module modules/mod_auth.so
    • Para que el localizador de Subversion utilice este tipo de autentificación tiene que cambiar la línea

      AuthType Basic

      por

      AuthType SSPI

      y también deberá añadir

      SSPIAuth On
      SSPIAuthoritative On
      SSPIDomain
      SSPIOmitDomain on
      SSPIUsernameCase lower
      SSPIPerRequestAuth on
      SSPIOfferBasic On

      dentro del bloque Si no tiene un controlador de dominio, deje el nombre del controlador de cominio como

    Tenga en cuenta que si se autentifica utilizando SSPI, ya no necesitará la línea AuthUserFile para definir un fichero de contraseñas. En su lugar, Apache autentifica su usuario y contraseña contra su dominio de Windows. También necesitará actualizar la lista de usuarios en su svnaccessfile para referirse a DOMINIO\usuario.

    Importante

    La autenticación SSPI sólo está habilitada para conexiones seguras por SSL (https). Si únicamente está utilizando conexiones http normales a su servidor, no funcionará.

    Para habilitar SSL en su servidor, vea el capítulo: “Asegurando el servidor con SSL”

    Sugerencia

    Los ficheros AuthzSVNAccessFile de Subversion distinguen mayúsculas y minúsculas respecto a los nombres de usuario (JuanPerez no es lo mismo que juanperez).

    En el mundo de Microsoft, los dominios y nombres de usuarios de Windows no distinguen mayúsculas y minúsculas. Incluso así, a algunos administradores de redes les gusta crear las cuentas de usuario en CamelCase (por ejemplo, JuanPerez).

    La diferencia puede morderle cuando utilice la autentificación SSPI ya que el dominio de Windows y los nombres de usuario se pasan a Subversion exactamente como los haya tecleado el usuario en la ventana. Internet Explorer a menudo pasa el nombre de usuario a Apache automáticamente utilizando el formato con el que se creó la cuenta.

    El resultado final es que puede necesitar al menos dos entradas en su fichero AuthzSVNAccessFile para cada usuario -- una entrada en minúsculas y una entrada con el formato que Internet Explorer pasa a Apache. También tendrá que convencer a sus usuarios para que escriban sus credenciales en minúsculas cuando accedan a los repositorios utilizando TortoiseSVN.

    Los registros de error y de acceso de Apache son su mejor aliado para descifrar problemas como estos, ya que le ayudarán a determinar la cadena de nombre de usuario pasada al módulo AuthzSVNAccessFile de Subversion. Puede que necesite experimentar con el formato exacto de la cadena del usuario en el svnaccessfile (por ejemplo, DOMINIO\usuario en vez de DOMINIO//usuario) para conseguir que todo funcione.

    Múltiples orígenes de autentificación

    También es posible tener más de un origen de autentificación para su repositorio de Subversion. Para conseguirlo, debe hacer que cada tipo de autentificación sea no-autoritario, para que Apache compruebe múltiples orígenes buscando un par usuario/contraseña que concuerden.

    Un escenario común es utilizar tanto la autentificación de dominio de Windows como un fichero passwd, para que pueda dar acceso a SVN a usuarios que no tienen usuario en el dominio de Windows.

    • Para habilitar tanto la autentificación de dominio de Windows como el fichero passwd, añada las siguientes entradas en el bloque de su fichero de configuración de Apache:

      AuthBasicAthoritative Off
      SSPIAuthoritative Off

    Aquí tiene un ejemplo de la configuración completa de Apache para combinar la autentificación de dominio de Windows y el fichero passwd:


    DAV svn
    SVNListParentPath on
    SVNParentPath D:\SVN

    AuthName "Repositorios de Subversion"
    AuthzSVNAccessFile svnaccessfile.txt

    # Usuarios de Dominio NT.
    AuthType SSPI
    SSPIAuth On
    SSPIAuthoritative Off
    SSPIDomain
    SSPIOfferBasic On

    # Usuarios htpasswd.
    AuthType Basic
    AuthBasicAuthoritative Off
    AuthUserFile passwd

    Require valid-user

    Asegurando el servidor con SSL

    Incluso aunque Apache 2.2.x tiene soporte para OpenSSL, no está activado por defecto. Necesitará activarlo manualmente.

    1. En el fichero de configuración de Apache, descomente las líneas:

      #LoadModule ssl_module modules/mod_ssl.so

      y al final

      #Include conf/extra/httpd-ssl.conf

      y luego cambie la línea (en una única línea)

      SSLMutex "file:C:/Archivos de programa/Apache Software Foundation/\
      Apache2.2/logs/ssl_mutex"

      a

      SSLMutex default
    2. Lo siguiente que necesita es crear un certificado SSL. Para hacer esto, abra un símbolo del sistema (ventana DOS) y vaya a la carpeta de Apache (por ejemplo, C:\Archivos de programa\Apache Group\Apache2) y escriba el siguiente comando:

      bin\openssl req -config conf\openssl.cnf -new -out my-server.csr

      Se le preguntará una contraseña. Por favor no utilice palabras sencillas, sino frases completas, por ejemplo, unos versos de un poema. Cuanto más larga sea la frase, mejor. También tendrá que introducir la URL de su servidor. Todas las demás preguntas son opcionales pero le recomendamos que las rellene también.

      Normalmente el fichero privkey.pem se crea automáticamente, pero si no es así, necesitará teclear este comando para generarlo:

      bin\openssl genrsa -out privkey.pem 2048

      Ahora escriba los comandos

      bin\openssl rsa -in conf\privkey.pem -out conf\server.key

      y (en una única línea)

      bin\openssl req -new -key conf\server.key -out conf\server.csr \
      -config conf\openssl.cnf

      y luego (en una única línea)

      bin\openssl x509 -in conf\server.csr -out conf\server.crt
      -req -signkey conf\server.key -days 4000

      Esto creará un certificado que expirará en 4000 días. Y finalmente, introduzca (también en una única línea):

      bin\openssl x509 -in conf\server.cert -out conf\server.der.crt
      -outform DER

      Estos comandos crearán algunos ficheros en la carpeta conf de Apache (server.der.crt, server.csr, server.key, .rnd, privkey.pem, server.cert).

    3. Reinicie el servicio de Apache.

    4. Apunte su navegador a https://nombredelservidor/svn/project ...

    SSL e Internet Explorer

    Si está asegurando su servidor con SSL y utiliza la autentificación contra un dominio de Windows se encontrará que la navegación de repositorios con el Internet Explorer ya no funcionará. No se preocupe - es sólo que Internet Explorer no se puede autentificar. Los demás navegadores no tienen ese problema y tanto TortoiseSVN como cualquier otro cliente de Subversion todavía podrán autentificarse.

    Si todavía quiere utilizar IE para navegar en el repositorio, puede:

    • Defina una directiva separada en el fichero de configuración de Apache, y añada SSPIBasicPreferred On. Esto permitirá que IE se autentifique de nuevo, pero los demás navegadores y Subversion no se podrán autentificar contra esa ruta.

    • Ofrezca también la navegación sin autentificación encriptada (sin SSL). Extrañamente, IE no tiene ningún problema para autentificarse si la conexión no está asegurada con SSL.

    • En la configuración "estándar" a menudo aparecen la siguiente sentencia en el host virtual SSL de Apache:

      SetEnvIf User-Agent ".*MSIE.*" \
      nokeepalive ssl-unclean-shutdown \
      downgrade-1.0 force-response-1.0

      Hay (¿había?) buenas razones para esta configuración, lea http://www.modssl.org/docs/2.8/ssl_faq.html#ToC49 Pero si desea usar autentificación NTLM deberá utilizar keepalive. Si descomenta toda la sentencia "SetEnvIf" debería ser capaz de autentificar IE con la autentificación de Windows sobre SSL contra un Apache sobre Win32 con el módulo incluído mod_auth_sspi.

    Forzando el acceso SSL

    Cuando haya preparado SSL para hacer su repositorio más seguro, puede que desee deshabilitar el acceso normal via no-SSL (http) y sólo permitir el acceso https. Para hacer esto, debería añadir otra directiva al bloque de Subversion: SSLRequireSSL.

    Un bloque de ejemplo se parecería a éste:


    DAV svn
    SVNParentPath D:\SVN
    SSLRequireSSL
    AuthType Basic
    AuthName "Repositorios de Subversion"
    AuthUserFile passwd
    #AuthzSVNAccessFile svnaccessfile
    Require valid-user

    Utilizando certificados de cliente con hosts SSL virtuales

    Enviado a la lista de correo de TortoiseSVN por Nigel Green. ¡Gracias!

    En algunas configuraciones de servidor puede que necesite configurar un único servidor que contenga 2 hosts SSL virtuales: el primero para acceso web público, sin requerimientos de un certificado de cliente; el segundo, seguro requiriendo un certificado de cliente, y ejecutando un servidor Subversion.

    Al añadir una directiva SSLVerifyClient Optional en la sección por-servidor de la configuración de Apache (es decir, fuera de cualquier bloque VirtualHost y Directory), se fuerza a Apache a pedir un certificado de cliente en el saludo inicial SSL. Debido a un bug en mod_ssl, es esencial que el certificado se pida en este punto, ya que no funciona si la conexión SSL se re-negocia.

    La solución es añadir la siguiente directiva en el directorio del host virtual que quiere bloquear para Subversion:

    SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"

    Esta directiva da acceso al directorio sólo si se recibió y verificó correctamente un certificado de cliente.

    Para resumir, las líneas relevantes de la configuración de Apache son:

    SSLVerifyClient Optional

    ### Configuración del virtual host para el host PÚBLICO
    ### (sin necesidad de un certificado de cliente)






    ### Configuración del virtual host para SUBVERSION
    ### (necesita un certificado de cliente)


    SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"



    DAV svn
    SVNParentPath /rutaalrepositorio