Pregunta “La forma correcta” para habilitar módulos / hosts virtuales en Apache


Los sistemas Debian (y quizás otros) tienen el siguiente diseño en / etc / apache2 /

mods-available/   mods-enables/   sites-available/   sites-enabled/

La configuración predeterminada tiene una tonelada de archivos tanto en mods disponibles como en sitios disponibles, y luego hay enlaces simbólicos a esos archivos en * -abilitado /.

Nunca me he molestado con los enlaces simbólicos. Siempre he movido los archivos.

Sostengo que esto le permite ver fácilmente qué mods / sitios se han habilitado y cuáles no. Los enlaces simbólicos solo le permiten ver cuáles han sido habilitados (fácilmente, de todos modos, sin recurrir a diff). Sin embargo, mi colega cree de manera diferente.

Entonces, ¿cuál es el camino correcto y por qué?


5
2017-09-21 09:48


origen




Respuestas:


La "forma correcta" es utilizar a2enmod y a2dismod para habilitar y deshabilitar módulos, a2ensite y a2dissite para habilitar y deshabilitar sitios.

Los comandos a2 * mod le presentan una lista de módulos [deshabilitados | habilitados] que están instalados en su sistema, los cuales puede [habilitar | deshabilitar]. Lo mismo ocurre con los comandos del sitio a2 *, sin embargo, funcionan con la lista de archivos de configuración del sitio (tanto los disponibles de forma predeterminada como los que ha creado) en el directorio de sitios disponibles.

También puede hacer un enlace simbólico manual desde * -avaliable a * -abilitado, pero esos comandos se proporcionan y lo están haciendo prácticamente de todos modos.

Ejemplo de salida de a2enmod:

Your choices are: actions alias asis auth_basic auth_digest authn_alias 
    authn_anon authn_dbd authn_dbm authn_default authn_file authnz_ldap authz_dbm 
    authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache 
    cern_meta cgi cgid charset_lite dav dav_fs dav_lock dbd deflate dir disk_cache dump_io 
    env expires ext_filter file_cache filter headers ident imagemap include info ldap 
    log_forensic mem_cache mime mime_magic negotiation pagespeed php5 proxy proxy_ajp 
    proxy_balancer proxy_connect proxy_ftp proxy_http proxy_scgi reqtimeout rewrite setenvif 
    speling ssl status substitute suexec unique_id userdir usertrack version vhost_alias
Which module(s) do you want to enable (wildcards ok)?

11
2017-09-21 10:02



Esa es la forma "realmente" correcta, +1. - weeheavy
Punto justo :-) Lo he usado en el pasado, pero siempre he revertido solo para trabajar con los archivos.


Siempre soy un fan de la creación de directorios de inicio para cuentas de alojamiento virtual. Esto tiene un par de ventajas como chroot fácil con ftp y ssh y, por supuesto, los permisos son más fáciles de administrar.

No creo que haya una manera "correcta", que haya diferentes formas y que cada uno tenga sus propios métodos.

Una cosa es segura. No me gusta la forma en que los servidores apache de debian (o Ubuntu) configuran los hosts virtuales. Me gusta la instalación de apache de CentOS.

Puede obtener una vista de mi tipo de configuración en mi script generar hosts virtuales (https://github.com/metalmini/vhostusers/blob/master/vhostusers.sh)


2
2017-09-21 09:58





¿Hay algún punto en tener una lista de módulos deshabilitados? Seguramente el factor relevante es si el servidor soporta algo o no, y puedes saberlo mirando si está en la lista habilitada o no.


0
2017-09-21 09:53



Lo más probable es que no lo uses, totalmente correcto. Pero cuando los enlaces simbólicos no ofrecen otras características o beneficios (en los que pueda pensar), usted también podría, imo. Otra ventaja también: puede ver inmediatamente qué sitios / mods son personalizados desde la instalación básica de Apache, ya que no son enlaces simbólicos, mientras que los módulos predeterminados sí lo son.


Habilitado siempre es enlaces simbólicos a disposición.

Así que siempre tienes la lista completa, y la lista de trabajos ahora. También los enlaces simbólicos pueden tener un nombre como 001-site, Client-id-12-site, etc., así que algún tipo de estructura.

Además, no es necesario hacer cambios en toneladas de lugar. Cambiar solo un archivo.

También su solo se ve bonito.

Y no veo nada negativo con esta estructura, ¿por qué no? ;)


0
2017-09-21 10:01



Si mueve los archivos en lugar de symlinking, tiene una lista de "funciona ahora", una lista de "disponible" y, si ambos directorios están juntos, también una lista completa. Cuando mueves un archivo, solo necesitas cambiarlo en un lugar. Simplemente se ve bonito? Podría decir lo mismo acerca de mover los archivos. No hay aspectos negativos con este enfoque, pero hay potencialmente más aspectos positivos con el movimiento de los archivos.
Sí, en.wikipedia.org/wiki/There's_more_than_one_way_to_do_it - Korjavin Ivan
Del zen de Python, cito: "Debería haber una, y preferiblemente solo una, una forma obvia de hacerlo".