Presentación tema 4 de la asignatura "Servidores web" del Máster Universitario en Desarrollo de Aplicaciones y Servicios Web. sobre pruebas a servicios web
Este documento describe la configuración del servidor web Apache. Apache es un servidor web de código abierto altamente configurable creado por la Apache Software Foundation. Explica cómo instalar y configurar Apache en sistemas Linux y Windows, incluyendo la configuración de módulos como PHP y SSL. Además, detalla las directivas clave del archivo de configuración apache2.conf para administrar el comportamiento y los recursos de Apache.
Presentación de la clase sobre el protocolo HTTP de la asignatura Servidores Web del Máster Universitario en Desarrollo de Aplicaciones y Servicios Web.
Este módulo proporciona funcionalidades para crear, cambiar y mover documentos en un servidor remoto a través de WebDAV, permitiendo la edición de documentos en un servidor web de forma más fácil que FTP. Se debe configurar la autenticación y cuotas de almacenamiento para proteger los archivos de ataques de denegación de servicio, y se recomienda usarlo sobre una conexión SSL para mayor seguridad.
Presentación tema 4 de la asignatura "Servidores web" del Máster Universitario en Desarrollo de Aplicaciones y Servicios Web. sobre pruebas a servicios web
Este documento describe la configuración del servidor web Apache. Apache es un servidor web de código abierto altamente configurable creado por la Apache Software Foundation. Explica cómo instalar y configurar Apache en sistemas Linux y Windows, incluyendo la configuración de módulos como PHP y SSL. Además, detalla las directivas clave del archivo de configuración apache2.conf para administrar el comportamiento y los recursos de Apache.
Presentación de la clase sobre el protocolo HTTP de la asignatura Servidores Web del Máster Universitario en Desarrollo de Aplicaciones y Servicios Web.
Este módulo proporciona funcionalidades para crear, cambiar y mover documentos en un servidor remoto a través de WebDAV, permitiendo la edición de documentos en un servidor web de forma más fácil que FTP. Se debe configurar la autenticación y cuotas de almacenamiento para proteger los archivos de ataques de denegación de servicio, y se recomienda usarlo sobre una conexión SSL para mayor seguridad.
Servidores web de altas prestaciones. Tema 0. Presentaciónpacvslideshare
Este documento presenta la asignatura "Servidores Web de Altas Prestaciones" de 3er semestre. La asignatura cubre conceptos como alta disponibilidad, balanceo de carga y tolerancia a fallos para configurar granjas web escalables y de alta disponibilidad. El temario incluye teoría sobre estas temáticas así como prácticas de configuración, seguridad, balanceo de carga y medición de rendimiento en granjas web. La evaluación consta de exámenes, participación en clase, prácticas y una exposición del trabajo real
El documento describe herramientas de código abierto como NGINX, HAProxy, Varnish Cache y RabbitMQ que pueden usarse para implementar arquitecturas de alta disponibilidad. Explica que el objetivo de la alta disponibilidad es permitir que las aplicaciones siempre funcionen con el mejor rendimiento y estén disponibles. Recomienda una arquitectura que use NGINX como servidor principal, luego un proveedor de colas como RabbitMQ, seguido de un balanceador de carga y varios servidores con procesadores de colas para garantizar un sistema altamente disponible
Webinar –Conectar servidores dedicados con Servidores CloudArsys
Webinar donde realizamos una práctica de conexión entre dos servidores, con dos modalidades distintas, como son los Servidores Dedicados y los Servidores Cloud. Además, demostramos que es posible trabajar con ambos tipos de servidores de una manera cómoda y ágil, gestionando los servicios a través de un único panel.
Presentación de Alta Disponibilidad con SQL Server 2012. Taller corganizado por Mug Perú, dirigido por Alberto De Rossi de dbLearner. Se trataron temas como trasvase de registro (log shipping), reflejo de base de datos (db mirroring), replicación transaccional punto a punto, clúster y Always On
Este documento presenta una introducción a Node.js, un framework de JavaScript para el desarrollo de aplicaciones web en tiempo real. Explica conceptos clave como el modelo de programación basado en eventos asíncronos, el uso de módulos y librerías como Express para crear servidores web y aplicaciones, y el acceso a bases de datos como MySQL a través de módulos. También menciona algunas herramientas y técnicas avanzadas como el uso de clusters para aprovechar múltiples procesadores.
Presentacion instaladores os debian centosOpenStack-VE
Este documento describe un instalador semiautomatizado de OpenStack para CentOS 6 y Debian 7. Proporciona características como la selección del backend de base de datos y mensajería, módulos opcionales como SNMP, e instalación y configuración automatizada de los componentes de OpenStack. También incluye demostraciones de instalaciones completas en CentOS 6 y Debian 7, configuración de DHCP, almacenamiento mediante NFS, uso de múltiples backends de almacenamiento, e implementación de balanceo de carga web con lbaas.
Recuperación de desastres y soluciones de alta disponibilidad con SQL ServerSpanishPASSVC
Esta presentación presenta las soluciones de recuperacion de desastres (Disaster Recovery) y alta disponibilidad (High Availability) con SQL Server y ofrece escenarios creativos por usar las soluciones para reportages (Reporting), BI y almacen de datos (Datawarehouse).
Filtrado der contenido web con GNU/Linux y SquidJorge Medina
Este documento describe cómo usar Squid, un proxy HTTP de código abierto, para filtrar y almacenar en caché contenido web en GNU/Linux. Explica las ventajas de los proxies HTTP como el control de acceso, aceleración web mediante caché y registro de accesos. Luego describe características clave de Squid como listas de control de acceso, filtrado de URLs, monitoreo y generación de informes. Finalmente, incluye una demostración de Squid.
Este documento describe cómo crear un cluster de 4 nodos para proporcionar alta disponibilidad. A nivel físico, enumera los componentes hardware necesarios para cada nodo, incluyendo torres, fuentes de alimentación, procesadores, placas base, discos duros y tarjetas de red, con un presupuesto total de 2,876€. A nivel software, explica que se necesita middleware como Linux para proporcionar una interfaz única y herramientas de balanceo de carga y tolerancia a fallos, así como gestionar la migración de proces
Este documento describe cómo HTTP Cache y Varnish pueden mejorar el rendimiento de un sitio web al almacenar en caché recursos estáticos y dinámicos. Varnish es un acelerador de aplicaciones web que actúa como proxy inverso y almacena en caché las respuestas para evitar generar la misma respuesta dos veces. Usando cabeceras como Cache-Control, Expires y ETag, Varnish determina si una respuesta está fresca o debe validarse. Combinando estas técnicas con otras optimizaciones, el rendimiento de un sitio puede mejorar
Taller HA y Balanceo de Cargas con NIGX.Luis Toscano
Este documento describe la alta disponibilidad (HA) y cómo usar Nginx para lograr HA. HA es una técnica que permite compartir procesos, redes, bases de datos entre equipos para soportar picos de tráfico. Nginx es un servidor ideal para HA porque puede balancear carga y actuar como proxy inverso. El documento explica cómo instalar y configurar Nginx para agregar capacidades de balanceo de carga y HA a una aplicación.
Este documento proporciona una introducción a JavaScript en el lado del servidor usando Node.js y el framework Express. Explica cómo instalar las dependencias necesarias como Express y Jade, y cómo crear una primera aplicación Express con una estructura de carpetas estándar que incluye archivos para configuración, rutas, plantillas y recursos públicos. También enfatiza que aprender un nuevo lenguaje de programación toma tiempo y paciencia.
SQL Server Alta disponibilidad en ambientes empresarialesEduardo Castro
El documento describe varias opciones para lograr alta disponibilidad y recuperación ante desastres con SQL Server 2014 y en Azure. Explica tecnologías como AlwaysOn Availability Groups, log shipping y database mirroring. También cubre consideraciones de planificación como RPO, RTO y costos, así como ejemplos de implementación para diferentes industrias.
Este documento presenta un curso avanzado sobre Squid. Explica qué es Squid y por qué es software libre. Proporciona algunos datos técnicos sobre Squid e ilustra sus diferentes modos de funcionamiento mediante esquemas. También cubre temas como la instalación, configuración básica, ACLs, logs y autenticación de usuarios.
Cómo aumentar la disponibilidad y el rendimiento utilizando sql server 2012 w...Eduardo Castro
En esta presentacion se ven las mejoras en SQL Server 2012 y cómo pueden establecerse mecanismos de alta disponibilidad con base en SMB 3.0 y Windows 2012.
Eduardo Castro
Comunidad Windows Costa Rica
http://ecastrom.blogspot.com
http://comunidadwindows.org
Este documento proporciona información sobre las opciones de alta disponibilidad en SQL Server 2012, incluyendo AlwaysOn Availability Groups, que permiten la configuración de múltiples copias secundarias activas para cargas de trabajo de solo lectura y procesos como respaldos. También cubre mejoras en el clustering de Windows Server 2012 como CSV y soporte para almacenamiento SMB, lo que permite almacenar bases de datos de SQL Server en directorios compartidos.
Estableciendo escenarios de Alta Disponibilidad en las empresas de hoy con MS...Joseph Lopez
Este documento presenta una introducción a la alta disponibilidad con SQL Server 2012. Explica conceptos clave como Windows Server Failover Clustering, SQL Server SMB Shares y AlwaysOn Availability Groups. Detalla la arquitectura de alta disponibilidad y recuperación de desastres usando estas características. También cubre temas como el failover del cliente y el uso de servidores secundarios activos.
Este documento resume los principales conceptos sobre servidores web Apache: 1) Apache es un servidor web de código abierto ampliamente utilizado; 2) Explica la arquitectura y funcionamiento de los servidores web, incluyendo Apache; 3) Detalla la instalación, configuración y uso de Apache para publicar sitios web y recursos, así como autenticar acceso de usuarios.
Un clúster MySQL integra un servidor MySQL estándar y un motor de almacenamiento en memoria llamado NDB clúster funcionando en un conjunto de computadoras. Las tablas de la base de datos se almacenan utilizando el motor NDB en los nodos de almacenamiento, y los nodos de datos funcionan utilizando un esquema de espejado permitiendo soportar caídas de nodos individuales. Una solución software como HAProxy puede ser usada para balancear la carga entre los nodos SQL.
Servidores web de altas prestaciones. Tema 0. Presentaciónpacvslideshare
Este documento presenta la asignatura "Servidores Web de Altas Prestaciones" de 3er semestre. La asignatura cubre conceptos como alta disponibilidad, balanceo de carga y tolerancia a fallos para configurar granjas web escalables y de alta disponibilidad. El temario incluye teoría sobre estas temáticas así como prácticas de configuración, seguridad, balanceo de carga y medición de rendimiento en granjas web. La evaluación consta de exámenes, participación en clase, prácticas y una exposición del trabajo real
El documento describe herramientas de código abierto como NGINX, HAProxy, Varnish Cache y RabbitMQ que pueden usarse para implementar arquitecturas de alta disponibilidad. Explica que el objetivo de la alta disponibilidad es permitir que las aplicaciones siempre funcionen con el mejor rendimiento y estén disponibles. Recomienda una arquitectura que use NGINX como servidor principal, luego un proveedor de colas como RabbitMQ, seguido de un balanceador de carga y varios servidores con procesadores de colas para garantizar un sistema altamente disponible
Webinar –Conectar servidores dedicados con Servidores CloudArsys
Webinar donde realizamos una práctica de conexión entre dos servidores, con dos modalidades distintas, como son los Servidores Dedicados y los Servidores Cloud. Además, demostramos que es posible trabajar con ambos tipos de servidores de una manera cómoda y ágil, gestionando los servicios a través de un único panel.
Presentación de Alta Disponibilidad con SQL Server 2012. Taller corganizado por Mug Perú, dirigido por Alberto De Rossi de dbLearner. Se trataron temas como trasvase de registro (log shipping), reflejo de base de datos (db mirroring), replicación transaccional punto a punto, clúster y Always On
Este documento presenta una introducción a Node.js, un framework de JavaScript para el desarrollo de aplicaciones web en tiempo real. Explica conceptos clave como el modelo de programación basado en eventos asíncronos, el uso de módulos y librerías como Express para crear servidores web y aplicaciones, y el acceso a bases de datos como MySQL a través de módulos. También menciona algunas herramientas y técnicas avanzadas como el uso de clusters para aprovechar múltiples procesadores.
Presentacion instaladores os debian centosOpenStack-VE
Este documento describe un instalador semiautomatizado de OpenStack para CentOS 6 y Debian 7. Proporciona características como la selección del backend de base de datos y mensajería, módulos opcionales como SNMP, e instalación y configuración automatizada de los componentes de OpenStack. También incluye demostraciones de instalaciones completas en CentOS 6 y Debian 7, configuración de DHCP, almacenamiento mediante NFS, uso de múltiples backends de almacenamiento, e implementación de balanceo de carga web con lbaas.
Recuperación de desastres y soluciones de alta disponibilidad con SQL ServerSpanishPASSVC
Esta presentación presenta las soluciones de recuperacion de desastres (Disaster Recovery) y alta disponibilidad (High Availability) con SQL Server y ofrece escenarios creativos por usar las soluciones para reportages (Reporting), BI y almacen de datos (Datawarehouse).
Filtrado der contenido web con GNU/Linux y SquidJorge Medina
Este documento describe cómo usar Squid, un proxy HTTP de código abierto, para filtrar y almacenar en caché contenido web en GNU/Linux. Explica las ventajas de los proxies HTTP como el control de acceso, aceleración web mediante caché y registro de accesos. Luego describe características clave de Squid como listas de control de acceso, filtrado de URLs, monitoreo y generación de informes. Finalmente, incluye una demostración de Squid.
Este documento describe cómo crear un cluster de 4 nodos para proporcionar alta disponibilidad. A nivel físico, enumera los componentes hardware necesarios para cada nodo, incluyendo torres, fuentes de alimentación, procesadores, placas base, discos duros y tarjetas de red, con un presupuesto total de 2,876€. A nivel software, explica que se necesita middleware como Linux para proporcionar una interfaz única y herramientas de balanceo de carga y tolerancia a fallos, así como gestionar la migración de proces
Este documento describe cómo HTTP Cache y Varnish pueden mejorar el rendimiento de un sitio web al almacenar en caché recursos estáticos y dinámicos. Varnish es un acelerador de aplicaciones web que actúa como proxy inverso y almacena en caché las respuestas para evitar generar la misma respuesta dos veces. Usando cabeceras como Cache-Control, Expires y ETag, Varnish determina si una respuesta está fresca o debe validarse. Combinando estas técnicas con otras optimizaciones, el rendimiento de un sitio puede mejorar
Taller HA y Balanceo de Cargas con NIGX.Luis Toscano
Este documento describe la alta disponibilidad (HA) y cómo usar Nginx para lograr HA. HA es una técnica que permite compartir procesos, redes, bases de datos entre equipos para soportar picos de tráfico. Nginx es un servidor ideal para HA porque puede balancear carga y actuar como proxy inverso. El documento explica cómo instalar y configurar Nginx para agregar capacidades de balanceo de carga y HA a una aplicación.
Este documento proporciona una introducción a JavaScript en el lado del servidor usando Node.js y el framework Express. Explica cómo instalar las dependencias necesarias como Express y Jade, y cómo crear una primera aplicación Express con una estructura de carpetas estándar que incluye archivos para configuración, rutas, plantillas y recursos públicos. También enfatiza que aprender un nuevo lenguaje de programación toma tiempo y paciencia.
SQL Server Alta disponibilidad en ambientes empresarialesEduardo Castro
El documento describe varias opciones para lograr alta disponibilidad y recuperación ante desastres con SQL Server 2014 y en Azure. Explica tecnologías como AlwaysOn Availability Groups, log shipping y database mirroring. También cubre consideraciones de planificación como RPO, RTO y costos, así como ejemplos de implementación para diferentes industrias.
Este documento presenta un curso avanzado sobre Squid. Explica qué es Squid y por qué es software libre. Proporciona algunos datos técnicos sobre Squid e ilustra sus diferentes modos de funcionamiento mediante esquemas. También cubre temas como la instalación, configuración básica, ACLs, logs y autenticación de usuarios.
Cómo aumentar la disponibilidad y el rendimiento utilizando sql server 2012 w...Eduardo Castro
En esta presentacion se ven las mejoras en SQL Server 2012 y cómo pueden establecerse mecanismos de alta disponibilidad con base en SMB 3.0 y Windows 2012.
Eduardo Castro
Comunidad Windows Costa Rica
http://ecastrom.blogspot.com
http://comunidadwindows.org
Este documento proporciona información sobre las opciones de alta disponibilidad en SQL Server 2012, incluyendo AlwaysOn Availability Groups, que permiten la configuración de múltiples copias secundarias activas para cargas de trabajo de solo lectura y procesos como respaldos. También cubre mejoras en el clustering de Windows Server 2012 como CSV y soporte para almacenamiento SMB, lo que permite almacenar bases de datos de SQL Server en directorios compartidos.
Estableciendo escenarios de Alta Disponibilidad en las empresas de hoy con MS...Joseph Lopez
Este documento presenta una introducción a la alta disponibilidad con SQL Server 2012. Explica conceptos clave como Windows Server Failover Clustering, SQL Server SMB Shares y AlwaysOn Availability Groups. Detalla la arquitectura de alta disponibilidad y recuperación de desastres usando estas características. También cubre temas como el failover del cliente y el uso de servidores secundarios activos.
Este documento resume los principales conceptos sobre servidores web Apache: 1) Apache es un servidor web de código abierto ampliamente utilizado; 2) Explica la arquitectura y funcionamiento de los servidores web, incluyendo Apache; 3) Detalla la instalación, configuración y uso de Apache para publicar sitios web y recursos, así como autenticar acceso de usuarios.
Un clúster MySQL integra un servidor MySQL estándar y un motor de almacenamiento en memoria llamado NDB clúster funcionando en un conjunto de computadoras. Las tablas de la base de datos se almacenan utilizando el motor NDB en los nodos de almacenamiento, y los nodos de datos funcionan utilizando un esquema de espejado permitiendo soportar caídas de nodos individuales. Una solución software como HAProxy puede ser usada para balancear la carga entre los nodos SQL.
Mod_Security es un módulo de código abierto para el servidor web Apache que añade una capa adicional de seguridad mediante la detección y prevención de posibles ataques en aplicaciones web a través del filtrado y análisis del tráfico HTTP/HTTPS entrante antes de que llegue al servidor. Funciona como un firewall de aplicaciones web y se configura mediante reglas basadas en expresiones regulares.
Mod_Security es un módulo de código abierto para el servidor web Apache que añade una capa adicional de seguridad mediante la detección y prevención de posibles ataques en aplicaciones web a través del filtrado y análisis del tráfico HTTP/HTTPS entrante antes de que llegue al servidor. Funciona como un firewall de aplicaciones web que analiza las peticiones y respuestas según reglas definidas mediante expresiones regulares.
Este documento proporciona instrucciones para configurar un entorno de desarrollo PHP en diferentes sistemas operativos como Ubuntu, Windows y Mac. Explica cómo instalar PHP, un servidor web como Apache y MySQL, y configurar el IDE phpStorm para ejecutar y probar código PHP. También cubre temas como crear proyectos PHP, configurar virtual hosts y resolver problemas comunes de permisos.
El documento describe cómo configurar varias herramientas de seguridad de red como proxies, firewalls, IPtables, IPchains y TCP Wrappers. También explica cómo configurar un servidor Kerberos básico, incluyendo la creación de la base de datos Kerberos, la configuración de los archivos krb5.conf y kdc.conf, y el inicio de los servicios krb5kdc, kadmin y krb524.
Este documento proporciona una introducción a Apache, el servidor web de código abierto más popular. Describe las principales versiones de Apache, sus características clave como su alta configurabilidad y extensibilidad, y cómo se puede instalar y configurar, incluida la configuración de servidores virtuales y control de acceso. El documento también explica los ficheros y directorios de configuración de Apache y las directivas de configuración más importantes.
1) El documento describe cómo instalar y configurar Apache, PHP y MySQL en Windows 98 para desarrollo local y pruebas, aunque no es recomendable usar este entorno para producción. 2) Explica los pasos para descargar e instalar los componentes y realizar la configuración necesaria. 3) Como prueba, crea un archivo PHP simple que muestra "Hola Mundo" y verifica que funcione correctamente al acceder desde el navegador.
Este documento describe cómo crear un servidor virtualizado utilizando Proxmox VE. Explica cómo instalar el hipervisor Proxmox VE, configurar particiones para almacenamiento y máquinas virtuales, e implementar servicios como firewalls, copias de seguridad y panel de control Virtualmin para administrar sitios web alojados.
Este documento proporciona una guía básica para mejorar la seguridad del servidor web Apache. Explica cómo configurar de forma segura los archivos y directivas de Apache, ocultar información sensible, implementar autenticación y autorización, y monitorear el servidor para detectar posibles amenazas.
El documento describe varias configuraciones de seguridad para los servicios HTTP (Apache), FTP (Vsftpd) y SMTP (Postfix) en un servidor Linux. Explica cómo restringir el acceso, autenticar usuarios, cifrar tráfico HTTPS, establecer límites de tamaño de archivo y filtrar correo no deseado mediante cabeceras.
Este documento proporciona una introducción al servidor web Apache. Apache es el servidor HTTP de código abierto más popular debido a su modularidad, código abierto, compatibilidad multiplataforma y extensibilidad. El documento describe los módulos, logs, virtual hosts y operaciones básicas de Apache, así como su instalación, configuración y herramientas como AWStats para generar estadísticas.
1. El documento describe los pasos para configurar el servidor proxy Squid, incluyendo la instalación del software requerido, la configuración de parámetros básicos como el puerto HTTP, la memoria caché y el tamaño del directorio de caché, y la implementación de listas y reglas de control de acceso para restringir el acceso a Squid.
2. Explica cómo definir listas de control de acceso basadas en direcciones IP, redes o archivos de lista, y cómo aplicar reglas de acceso para permitir o denegar el
Este documento contiene la práctica 4 sobre el servidor web Apache en Linux. Se compone de 11 ejercicios en los que se exploran conceptos como HTTP, la instalación de Apache y su configuración, la creación de sitios virtuales, la configuración de puertos de escucha, directivas de configuración, logs y errores, directorios virtuales y módulos de Apache.
Este documento describe los pasos para instalar el service manager de Mysql Enterprise Monitor en un sistema Linux. Incluye verificar los requisitos del usuario mysql, crear el directorio de instalación, ejecutar el instalador, y configurar la base de datos y usuarios del service manager.
El documento describe los pasos para instalar y configurar Policyd v2, un servicio multiplataforma que permite implementar políticas de seguridad anti-spam. Estos pasos incluyen instalar los requisitos, crear la base de datos, configurar el archivo de configuración, instalar los directorios y servicios necesarios, y configurar el servicio Postfix para que use Policyd.
Este documento proporciona instrucciones para instalar y configurar OCS Inventory en Ubuntu para administrar el inventario de hardware y software de una red. Explica los requisitos, cómo descargar e instalar OCS Inventory, configurar la base de datos MySQL, modificar los archivos de configuración y acceder a la interfaz web.
Un cluster Beowulf es un tipo de cluster computacional de bajo costo formado por nodos estándar conectados en red. Ofrece beneficios como mayor velocidad de procesamiento, confiabilidad y escalabilidad. Se pueden configurar usando software libre como Linux, MPI o LAM/MPI para ejecutar aplicaciones de forma paralela. Los clusters Beowulf son útiles para simulaciones, biotecnología y otros usos que requieren gran potencia de cómputo.
Este documento explica el protocolo DHCP y cómo configurar servidores y clientes DHCP. DHCP asigna automáticamente información de TCP/IP a máquinas clientes. Los clientes se conectan al servidor DHCP central que devuelve la configuración de red del cliente, incluyendo la dirección IP, puerta de enlace y servidores DNS. El documento también describe cómo configurar archivos, opciones y parámetros en el servidor DHCP, así como iniciar y detener el servicio DHCP.
21 protocolo de configuración dinámica de hosts dhcpAprende Viendo
Este documento explica el protocolo DHCP y cómo configurar servidores y clientes DHCP. DHCP asigna automáticamente información de TCP/IP a máquinas clientes. Los clientes se conectan al servidor DHCP central que devuelve la configuración de red del cliente, incluyendo la dirección IP, puerta de enlace y servidores DNS. También describe cómo configurar el servidor DHCP, incluyendo el archivo de configuración, la base de datos de arrendamiento y cómo iniciar y detener el servicio DHCP.
Este documento trata sobre la gestión de usuarios en sistemas Linux. Explica conceptos clave como cuentas de usuario, grupos, PAM y LDAP. PAM permite establecer políticas de autenticación de forma flexible mediante módulos. LDAP proporciona un directorio ligero para almacenar información de usuarios de forma jerárquica. El usuario root tiene privilegios totales sobre el sistema aunque existen buenas prácticas para limitar su uso directo.
Este documento describe varios conceptos relacionados con la seguridad perimetral, incluyendo routers, filtros de paquetes NetFilter y iptables. Los routers permiten encaminar paquetes entre redes y aplicar listas de control de acceso para filtrar el tráfico. NetFilter es el módulo del núcleo Linux que implementa filtros de paquetes, y iptables es el conjunto de comandos para configurar las tablas, cadenas y reglas de filtrado de NetFilter.
Este documento describe diferentes herramientas de búsqueda como Google, Bing y Shodan que pueden usarse para la evaluación de seguridad. Explica los operadores y funcionalidades de cada buscador, así como sus limitaciones. También proporciona ejemplos de cómo usar Shodan para encontrar dispositivos conectados a Internet con puertos abiertos y vulnerabilidades de seguridad.
Transparencias clase de DNS.
Utilizé esas transparencias, con pequeñas variaciones, en las clases de:
.-Administración de Sistemas Operativos en Red (Ingeniería Ténica en Informática de Sistemas)
.-Administración e Instalación de Redes de Computadores (optativa de las 3 titulaciones de informática)
.-Gestión e Implantación de Redes de Computadores (de Grado de Ingeniería Informática en el curso 2012-2013)
Transparencias clase de DHCP
Utilizé esas transparencias, con pequeñas variaciones, en las clases de:
.-Administración e Instalación de Redes de Computadores (optativa de las 3 titulaciones de informática)
.-Gestión e Implantación de Redes de Computadores (de Grado de Ingeniería Informática en el curso 2012-2013)
Este documento describe un curso sobre sistemas de detección de intrusos basados en Snort. Incluye información sobre la instalación de Snort, personalización de configuraciones, y ejemplos de reglas para detectar actividades maliciosas como escaneos de puertos, intentos de acceso no autorizados, y búsquedas prohibidas. El documento también explica cómo probar las reglas mediante herramientas como nmap y netcat.
Este documento describe Snort, un sistema de detección de intrusos basado en software libre. Explica las características, instalación, funcionamiento y configuración de Snort. Snort es un NIDS multiplataforma que utiliza firmas y detección de anomalías para identificar tráfico malicioso a través de la inspección y el análisis de paquetes de red. El documento proporciona detalles sobre cómo configurar Snort para monitorear el tráfico de red específico y generar alertas.
El documento describe la instalación y configuración del programa Honeyd para crear honeypots o señuelos de seguridad. Explica cómo configurar dispositivos de muestra que emulan sistemas como Cisco IOS, Windows 2000 y Linux, asignándoles personalidades, puertos abiertos/filtrados y scripts de simulación. El objetivo es que Honeyd presente una red falsa para detectar intrusiones.
El documento describe Honeyd, una herramienta de detección de intrusos que simula sistemas y servicios de red para detectar actividad no autorizada. Honeyd permite configurar dispositivos virtuales con diferentes sistemas operativos y servicios, y monitorea el tráfico dirigido a ellos para identificar ataques. El documento explica cómo instalar y configurar Honeyd, así como ejemplos de configuraciones para simular redes completas con routers, servidores web y de correo.
Catalogo Refrigeracion Miele Distribuidor Oficial Amado Salvador ValenciaAMADO SALVADOR
Descubre el catálogo general de la gama de productos de refrigeración del fabricante de electrodomésticos Miele, presentado por Amado Salvador distribuidor oficial Miele en Valencia. Como distribuidor oficial de electrodomésticos Miele, Amado Salvador ofrece una amplia selección de refrigeradores, congeladores y soluciones de refrigeración de alta calidad, resistencia y diseño superior de esta marca.
La gama de productos de Miele se caracteriza por su innovación tecnológica y eficiencia energética, garantizando que cada electrodoméstico no solo cumpla con las expectativas, sino que las supere. Los refrigeradores Miele están diseñados para ofrecer un rendimiento óptimo y una conservación perfecta de los alimentos, con características avanzadas como la tecnología de enfriamiento Dynamic Cooling, sistemas de almacenamiento flexible y acabados premium.
En este catálogo, encontrarás detalles sobre los distintos modelos de refrigeradores y congeladores Miele, incluyendo sus especificaciones técnicas, características destacadas y beneficios para el usuario. Amado Salvador, como distribuidor oficial de electrodomésticos Miele, garantiza que todos los productos cumplen con los más altos estándares de calidad y durabilidad.
Explora el catálogo completo y encuentra el refrigerador Miele perfecto para tu hogar con Amado Salvador, el distribuidor oficial de electrodomésticos Miele.
Todo sobre la tarjeta de video (Bienvenidos a mi blog personal)AbrahamCastillo42
Power point, diseñado por estudiantes de ciclo 1 arquitectura de plataformas, esta con la finalidad de dar a conocer el componente hardware llamado tarjeta de video..
Infografia TCP/IP (Transmission Control Protocol/Internet Protocol)codesiret
Los protocolos son conjuntos de
normas para formatos de mensaje y
procedimientos que permiten a las
máquinas y los programas de aplicación
intercambiar información.
La inteligencia artificial sigue evolucionando rápidamente, prometiendo transformar múltiples aspectos de la sociedad mientras plantea importantes cuestiones que requieren una cuidadosa consideración y regulación.
SOPRA STERIA presenta una aplicació destinada a persones amb discapacitat intel·lectual que busca millorar la seva integració laboral i digital. Permet crear currículums de manera senzilla i intuitiva, facilitant així la seva participació en el mercat laboral i la seva independència econòmica. Aquesta iniciativa no només aborda la bretxa digital, sinó que també contribueix a reduir la desigualtat proporcionant eines accessibles i inclusives. A més, "inCV" està alineat amb els Objectius de Desenvolupament Sostenible de l'Agenda 2030, especialment els relacionats amb el treball decent i la reducció de desigualtats.
KAWARU CONSULTING presenta el projecte amb l'objectiu de permetre als ciutadans realitzar tràmits administratius de manera telemàtica, des de qualsevol lloc i dispositiu, amb seguretat jurídica. Aquesta plataforma redueix els desplaçaments físics i el temps invertit en tràmits, ja que es pot fer tot en línia. A més, proporciona evidències de la correcta realització dels tràmits, garantint-ne la validesa davant d'un jutge si cal. Inicialment concebuda per al Ministeri de Justícia, la plataforma s'ha expandit per adaptar-se a diverses organitzacions i països, oferint una solució flexible i fàcil de desplegar.
3. MWS NGINX
Proyecto de código abierto
https://nginx.org/en/docs/
Servidor web, proxy HTTP y correo
Event Drive y asíncrono*
Presenta buen rendimiento y escalabilidad
(problema C10K: https://es.wikipedia.org/wiki/Problema_C10k)
Modular
Proceso master y varios procesos
worker
HTTP2
*Comparativa con Apache https://anturis.com/blog/nginx-vs-apache/
introducción
5. MWS nginx
sudo apt-get install nginx (como el resto)
Proceso master: debe iniciarse como 'root'
Procesos workers: se inician por master con
usuario indicado en configuración.
Ficheros configuración (puede cambiarse)
l
/etc/nginx/nginx.conf: configuración básica
l
mime.types
l
fastcgi_params:
l
Proxy.conf
l
sites.conf
Podemos tener más con directiva include:
include otra_configuracion.conf;
include sites/*.conf;
Configuración
6. MWS nginx
Directivas:
l
worker_processes: Número máximo de
procesos para el servidor web. ¿Cuál?
Recomendación:
grep processor /proc/cpuinfo | wc -l
l
worker_connections: Número máximo de
conexiones simultáneas para workers
l
keepalive_timeout: Tiempo de espera (75”
por defecto)
l
user nobody nobody;
l
error_log logs/error.log;
l
pid logs/nginx.pid;
Directivas de configuración
7. MWS nginx
Directivas, sintaxis:
l
k, m, g (K, M, G) kilobytes, Mega, Giga→
l
ms,s,m,h,d-> Milisegundos, segundos, minutos,
horas, días
l
w, M, y semanas, meses, años→
Variables: pueden ser usadas en la definición de
valores de las directivas. Siempre comienzan con $.
l
Referidas a las cabeceras cliente: $http_hosts,
$http_user_agent, $http_referer,
$http_x_forwarded_for (ip del cliente si está tras
proxy), $http_cookie, $http_ (para cabeceras
adicionales enviadas por cliente, con nombre
cabecera en minúsculas y '-' remplaza a '_')
l
$nginx_version
Configuración: variables
8. MWS nginx
Sobre las cabeceras de respuesta:
l
$sent_http_content_type
l
$sent_http_content_length
l
$sent_http_location
l
$sent_http_last_modified
l
$sent_http_connection (si keepalive o cerrada)
l
$sent_http_keep_alive (tiempo que estará “viva”)
l
$sent_http_transfer_encoding
l
$sent_http_cache_control
l
$sent_http_
Configuración: variables
9. MWS nginx
Sobre Nginx
l
$arg-XXX: query_string con XXX el nombre
parámetro
l
$args: todos los args de query_string
l
$binary_remote_addr: IP en binario (4 bytes)
l
$body_bytes_sent: número bytes (sin cabeceras)
l
$bytes_sent: total
l
$connection: num serie que identifica la conexión
l
$connection_requests: num request de conexión
activa
l
$cookie_XXX: acceso a cookies, con XXX nombre
l
$document_root
l
$host: la de la cabecera HTTP
l
$hostname: del servidor
l
$https: se usa o no (vacía)
Configuración: variables
10. MWS nginx
Sobre Nginx
l
$limit_rate
l
$msec: tiempo actual en ms
l
$remote_addr, $remote_port,
$remote_user, $query_string,
$request_method,....
l
$status: código de respuesta
l
$uri: igual a $document_uri: uri de la
petición
l
...
Configuración: variables
11. MWS nginx
Directivas de bloque: Admiten otras directivas, pero
no cualquiera y pueden anidarse y se hereda la del
bloque superior
l
events { worker_connections 1024; }
l
http { server {
l
listen 80;
l
server_name example.com;
l
access_log /var/log/nginx/example.com.log;
l
location ^~ /admin/ {
l
index index.php;
l
access_log off;
l
}
l
}
l
include mime.types;
l
}
Directivas de bloque
13. MWS nginx
daemon (on|off); Modo background o no. Por
defecto on. Útil para depurar.
debug_points (stop|abort); Por defecto
inhabilitada
env MI_VARIABLE=mi_valor;
error_log fichero nivel; (nivel: debug, info,
notice, warn, error, crit, alert, emerg de→
más a menos detallado, emerg solo reporta
los críticos) Para deshabilitar: /dev/null
l
Contexto: main, http, server y location
log_not_found (on|off); registra HTTP 404
master_process (on|off); Habilitar 1 master
más workers. Si no, solo 1 proceso.
Core module directives
14. MWS nginx
pcre_jit (on|off); Habilita Just-in-Time
compilation para expresiones regulares
(rendimiento) Exige –with-pcre-jit y –enable-
jit en compilación de nginx
pid fichero; Por defecto, en compilación
ssl_engine enginename; Por defecto, none.
Enginename es el nombre del acelerador SSL
HW en tu sistema (openssl engine -t para
comprobar)
thread_pool name threads=number
[max_queue=number]; (defecto threads=32
y max_queu=65536) Pool para la directiva
aio para servir grandes ficheros
Core module directives
15. MWS nginx
user username groupname;
worker_processes number;
worker_directory directorio; Directorio de
trabajo (para ficheros core) y debe tener +w
para username
worker_rlimit_nofile número; De ficheros que
un worker puede procesar simultáneamente
worker_rlimit_core tam; Tamaño de los
ficheros core por worker.
worker_aio_request número; aio+epoll →
número máximo de operaciones I/O
pendiente por worker
Core module directives
16. MWS nginx
Permite configurar los
mecanismos/funcionamiento de red
En events bloks (events {})
Directivas:
l
accept_mutex (on|off); Exclusión mútua para→
escuchar sockets
l
accept_mutex_delay time; Espera para adquirir
un recurso (solo si anterior ON)
l
debug_connection IP; Logs detallados para un
equipo concreto (exige compilación con
--debug)
l
worker_connections number; Número de
conexiones que un worker puede procesar
simultáneamente
events module
17. MWS nginx
use kqueue; Modelo de eventos:
l
select: Es el de defecto. No recomendado para
elevada carga.
l
poll: Es mejor que select para gran carga, pero
no admitido por todos los sistemas
l
Kqueue: eficiente para FreeBSD 4.1+, MacOS
X, OpenBSD 2.9+
l
epoll: Eficiente para Linux 2.6+
l
/dev/poll: Eficiente para Solaris 7 11/99+, IRIX
6.5.15+
events module directives
18. MWS nginx
Solo es para habilitar la inclusión de ficheros:
include sites/*.conf
Importante: si el path es relativo, siempre se
toma como base el directorio de configuración
configuration module
19. MWS nginx
Contiene todo lo relacionado con bloques,
directivas y variables del servidor HTTP
Dispone de 3 bloques lógicos:
l
http: define faceta HTTP server de Nginx
l
server: relacionado con los “servidores web”
Solo se usa con un bloque http
l
location: define un grupo de configuraciones
para aplicar a una localización concreta del sitio
web. Puede ser usado en un bloque server o en
otro location
HTTP Core module
21. MWS nginx
Directivas de socket y host
l
listen [address][:port] [options];
Context:server
l
Options: ssl, default_server (web site por
defecto), spdy, proxy_protocol
l
server_name name [*.domain name2 ...];
Context: server
l
server_name *.website.*;
l
server_name ~^(www).example.com$;
l
server_name _ "";
l
server_name_in_redirect (on|off);
l
Context: http, server, location
l
port_in_redirect (on|off); (Añadir o no el puerto
en la URL de redirección)
HTTP Core module
22. MWS nginx
Directivas de paths y documentos
l
root directorio; Define documentroot
l
Context: http, server, location, if Acepta variables
l
alias directorio;
l
Context: location Acepta variables
l
error_page codigo1 [codig2 …] [=otro_code]
[=@block | URI ]
l
Context: http, server, location, if. Acepta vars
l
error_page 404 =200 /index.html
l
error_page 404 @notfound; #va al bloque de
location “notfound”
l
index file1 [file2...];
l
Context: http, server, location Acepta vars
l
try_files file1 [file2...] [@block | URI ];
l
Context: http, server, location Acepta vars
HTTP Core module
23. MWS nginx
Directivas sobre las peticiones de los clientes
l
keepalive_requests num; Número máx de
peticiones por conexión
l
Context: http, server, location
l
keepalive_timeout secs [secs2];timeout
header=secs2
l
Context: http, server, location
l
send_timeout secs; Para cerrar conexión inactiva
l
Context: http, server, location
l
client_body_* Sobre el cuerpo de la petición→
l
Context: http, server, location
l
types { mimetype1 extension1;[...]}
l
Context: http, server, location
l
→ include mime.types; (para incluir todos)
l
default_type mimetype; para los tipo no incluidos→
HTTP Core module
24. MWS nginx
Directivas sobre límites y restricciones
l
limit_except método {allow,deny}; previene el uso de
métodos excepto el que explícitamente se habilita
l
Context: location
l
limit_rate bps; Limita ratios de transferencia de
conexiones individuales de clientes
l
Context: http, server, location,if
l
limit_rate_after bytes; Pasada la cantidad marcada
por bytes a máxima velocidad, se aplica la de
limit_rate
l
satisfay uri {}; Marca condiciones que debe cumplir
el cliente (allow, deny, auth_basic,...,any, all)
l
Context: location
l
Internal;-> No puede ser accedido desde exterior
l
Context: location
HTTP Core module
25. MWS nginx
Directivas sobre caché y procesamiento de ficheros
l
disable_symlinks (on|if_not_owner)
l
directio (off|value); Ficheros > value, serán leídos
con mecanismos Direct I/O
l
Context: http,server, location
l
open_file_cache max=N inactive=T; N entradas
como máximo y T segundos sin acceso en caché.
Guarda info sobre el fichero, no contenido.
l
Context: http,server, location
l
log_not_found (on|off);
l
Context: http,server, location
l
resolver IP_DNS [valid=time];
l
Context: http,server, location
l
resolver_timeout time; Timeout para la query DNS
l
Context: http,server, location
HTTP Core module
26. MWS nginx
LOCATION: permite especificar un patrón que se
comprobará con el documento en las URI de las
peticiones. Sintaxis:
location [= |~|~*|^~|@] pattern { ... }
La parte opcional se denomina location modifier y
define qué debe hacer nginx con el patrón indicado
l
Sin modifier El inicio del documento debe→
concordar con el patrón
l
= Documento debe concordar exactamente y el→
patrón debe ser una cadena literal
l
~ Debe concordar case-sensitive con la expresión→
regular; ~* case-insensitive→
l
^~ Similar al 1º, pero parando la búsqueda de→
otros
l
@ referencia a un bloque
HTTP Core module: location block
27. MWS nginx
LOCATION: Se pueden definir múltiples bloques con
diferentes patrones, buscando la concordancia en
este orden:
l
Con modifier =
l
Sin modifier, coincidencia exacta
l
Con modifier ^~
l
Con modifier ~ o ~*
l
Sin modifier Si el string coincide con el inicio de la
URI, se devuelve el bloque
HTTP Core module: location block
28. MWS nginx
server{
server_name website.com;
location /files/ {
# applies to any request starting with "/files/"
# for example /files/doc.txt, /files/, /files/temp/
}
location = /files/ {
# applies to the exact request to "/files/"
# and as such does not apply to /files/doc.txt
# but only /files/
}
}
URI: http://website.com/files/doc.txt se aplica 1º→
URI: http://website.com/files/ se aplica el 2º→
HTTP Core module: location block
29. MWS nginx
server{
server_name website.com;
location /doc {
[...] # requests beginning with "/doc"
}
location ~* ^/document$ {
[...] # requests exactly matching "/document"
}
}
URI: http://website.com/document Ambos coinciden, se→
aplica orden de prioridad y el seleccionado será el 2º
Si en el 1º, ponemos ^~, se aplicaría el 1º (por prioridad)
HTTP Core module: location block
33. MWS nginx
server {
If ($request_method = POST) {
[….]
}
}
Rewrite module: Conditional structure
Para aplicar configuraciones de acuerdo a condiciones
específicas
Operadores:
l
None: Condición true si la variable o datos no es
vacia
l
=, !=
l
~ , ~* , Coincide con expresión regular. ~ es
case-sensitive, ~* es case-insensitive. Negación: !
~ , !~*
l
-f , !-f fichero
l
-d , !-d Directorio
l
-x , !-x Como -f, que existe y, además, ejecutable
34. MWS nginx
if (-f $uri) {
break; # break if the file exists
}
if ($uri ~ ^/search/(.*)$) {
set $query $1;
rewrite ^ /search.php?q=$query?;
Rewrite module: Directivas
rewrite regexp replacement [flag]
l
Context: server, location, if
l
Flag: last, break, redirect (302), permanet (301)
Break. Ejemplo. SI existe, no reescribe
Context: server, location, if
return code | text;
Context: server, location, if
set $var1 “some”
Context: server, location, if
uninitialized_variable_warn; Log cuando se use una no→
inicializada
rewrite_log (on|off) registrará cada operación realizada→
35. MWS nginx
Rewrite module: ejemplos reescrituras
rewrite ^/([0-9]+)/.*$ /article.php?id=$1?;
l
URI: http://website.com/33526/us-economy-strengthens
l
Rewritten: http://website.com/article.php?id=33526
rewrite ^/topic-([0-9]+)-([0-9]+)-(.*).html$
/viewtopic.php?topic=$1&start=$2?;
l
URI: http://website.com/topic-1234-50-some-
keywords.html
l
RW: http://website.com/viewtopic.php?
topic=1234&start=50
rewrite ^/wiki/(.*)$ /wiki/index.php?title=$1?;
l
URI:http://website.com/wiki/Some_keyword
l
RW: http://website.com/wiki/index.php?
title=Some_keyword
36. MWS nginx
Módulos
l
HTTP Referer: filtrar peticiones en función de la
cabecera HTTP Referer *
l
HTTP Limit Zone: Limita el nº conexiones
simultáneas del mismo cliente
l
User ID: cookies identificativas
l
FLV: reproducir vídeos en streaming
l
Perl: Ejecución de guiones Perl
l
WebDAV
l
SecureLink: para proteger páginas con claves
secretas
l
XSLT: postprocesamiento de páginas mediante
XSLT
* http://www.elladodelmal.com/2017/04/pon-un-referrer-policy-y-mejora-la.html Y https://securityheaders.io
Configuración
37. MWS nginx
En un servidor Nginx se debe ajustar:
l
user -> no privilegiado
l
worker_process auto Por defecto es 1,→
aunque lo mejor es uno por CPU disponible
l
worker_priority 0; Reasignar prioridad en→
función del servidor (recordad -20 max
prioridad, 20 min prioridad y el kernel suele
tener -5)
l
log_not_found on;Puede ser interesante para
depurar nuestro sitio
l
worker_connections 1024; Para definir al
número total de conexiones que acepta tu
servidor (junto con worker_process) y depende
de RAM y CPU
Ajustes necesarios
38. MWS nginx
NGINX puede ser muy útil a APPS en:
l
Caching integration
l
Changing content on-the-fly
l
Using Server Side Includes
l
Decision-making in NGINX
l
Creating a secure link
l
Generating images
l
Tracking website visitors
l
Preventing inadvertent code execution
Para desarrolladores
39. MWS nginx
Para desarrolladores: Caching integration
Objetivo: mejorar el rendimiento de nuestra
app
App no usa caché:
l
Uso de proxy_cache_ * y/o fastcgi_cache_*
l
Para páginas individuales, cabeceras: Expires
and Cache-Control headers y X-Accel-Expires
Las interpreta NGINX y no las envía al cliente.
l
Ejemplo: Página de noticias en la que se
decide
l
Página frontal será cacheada 1'
l
Cada artículo 1 día
l
Cada imagen tanto como sea posible
40. MWS nginx
Para desarrolladores: Caching integration
http {
# here we configure two separate shared memory zones for the keys/metadata
# and filesystem paths for the cached objects themselves
proxy_cache_path /var/spool/nginx/articles keys_zone=ARTICLES:16m
levels=1:2 inactive=1d;
proxy_cache_path /var/spool/nginx/images keys_zone=IMAGES:128m levels=1:2
inactive=30d;
# but both paths still lie on the same filesystem as proxy_temp_path
proxy_temp_path /var/spool/nginx;
server {
location / {
# this is where the list of articles is found
proxy_cache_valid 1m;
}
location /articles {
# each article has a URI beginning with "/articles"
proxy_cache_valid 1d;
}
location /img {
# every image is referenced with a URI under "/img"
proxy_cache_valid 10y;
}
}
41. MWS nginx
Para desarrolladores: Caching DB
Si tu app almacena páginas prerenderizadas en base
de datos, NGINX puede servirlas directamente desde
memcached
l
SI URI está en caché, se sirve
l
Si no, se pide a la app
location / {
set $memcached_key “$uri?$args”;
memcached_pass 127.0.0.1:11211;
error_page 404 502 504 = @app; //sustituirá el
código de error por el que devuelva app
}
Location @app {
proxy_pass 127.0.0.1:8080;
42. MWS nginx
Para desarrolladores: Caching FS
Si tu app escribe páginas prerenderizadas en el FS,
NGINX puede servirlas con cabeceras apropiadas:
Expires and Cache-Control
server{
root /var/www
location / {
location = /index.html {
expires 5m;
}
location ~* /.*.(js|css)$ {
expires 24h;
}
location ~* /.*.html$ {
expires 3d;
}
location /img {
expires max;
}
43. MWS nginx
Para desarrolladores: on-the-fly
Post-process: añadir un string, transformación del
HTML,... NGINX proporciona módulos para ello: addition,
sub y xslt (transformar XML usando XSLT)
server{
root /var/www
location / {
location / {
add_before_body /header;
add_after_body /footer;
}
location /header {
proxy_pass http://127.0.0.1:8080/header;
}
location /footer {
proxy_pass http://127.0.0.1:8080/footer;
}
}
sub_filter_once off;
sub_filter '<img src="img/' '<img src="/img/';
sub_filter </head> '<meta name="frontend" content="web3"></head>';
sub_filter_types text/css;
44. MWS nginx
Para desarrolladores: secure link
Protección de ciertas partes sin autenticación completa.
HASH MD5 del link + secret
location /downloads/ {
secure_link_secret supersecreto;
If ($secure_link = “”) {
Return 403;
}
try_files /downloads/$secure_link =404;
}
HTML:
<a href="/downloads/<hash>/libro_del_curso.pdf">Descarga libro del máster</a>
http://wiki.nginx.org/HttpSecureLinkModul
e
46. MWS nginx
Para desarrolladores: tracking web visitors
Para rastrear visitantes únicos: userid module. Configura una
cookie por cliente cuyo valor tenemos en $uid_set. Cuando
vuelve y la cookie es válida, estará en $uid_got
http {
log_format useridcomb '$remote_addr - $uid_got [$time_local] '
'"$request" $status $body_bytes_sent ' '"$http_referer"
"$http_user_agent"';
server {
server_name .example.com;
access_log logs/example.com-access.log useridcomb;
userid on;
userid_name uid;
userid_domain example.com;
userid_path /;
userid_expires 365d;
userid_p3p 'policyref="/w3c/p3p.xml", CP="CUR ADM OUR
NOR”';
}
47. MWS nginx
Para desarrolladores: preventing code exe
Para mandar todos los requerimiento PHP a FastCGI server,
tenemos la opción A. Si nuestros usuarios suben ficheros a la
misma estructura de directorio, puede ser un problema (podrían
subir ficheros .jpg, etc con php embebido que se interpretaría)
Para prevenir esta posibilidad, opción B. Con try_files nos
aseguramos que el fichero exista.
B
location ~* .php {
try_files $uri =404;
include fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
}
A
location ~* .php {
include fastcgi_params;
fastcgi_pass
127.0.0.1:9000;
}
48. MWS nginx
Para desarrolladores: proxy inverso URL
Ejemplo: la parte cliente y todas las rutas del frontend (con
AngularJS) se sirvan a través de la ruta /. Y que nuestra API
(con, por ejemplo, Node.js) se sirva a través de la ruta /api
# HTTP proxy
server {
listen 80;
server_name midominio.com;
access_log /var/log/nginx/nginx.access.log;
error_log /var/log/nginx/nginx.error.log;
client_max_body_size 5M;
location / {
add_header Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0";
# Ruta de los ficheros estáticos
root /var/www;
try_files $uri $uri/ /index.html =404;
}
location /api {
proxy_set_header 'Access-Control-Allow-Origin' 'http://midominio.com';
proxy_set_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
proxy_set_header 'Access-Control-Allow-Headers' 'X-Requested-With,Accept,Content-Type,
Origin';
proxy_pass http://127.0.0.1:3000;
proxy_redirect off;
proxy_buffering on;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header origin 'http://midominio.com';
}
}
49. MWS nginx
Balanceo de carga: round robin
peticiones distribuidas entre los servidores de forma cíclica.
Las más pesadas pueden asignarse al mismo servidor
Distribuye las peticiones de forma ecuánime pero la carga no
salvo que usemos la directiva weight
upstream app {
server app1:8080;weight=3;
server app2:8080;
server app3:8080;
}
server {
listen 80;
location / {
proxy_pass http://app;
add_header X-Upstream $upstream_addr;
}
}
50. MWS nginx
Balanceo de carga: least-conected
La siguiente petición es atendida por el servidor con menos
conexiones activas.
Como el anterior, no reparte por sesión
upstream app {
least_conn;
server app1:8080;
server app2:8080;
server app3:8080;
}
server {
listen 80;
location / {
proxy_pass http://app;
add_header X-Upstream $upstream_addr;
}
}
51. MWS nginx
Balanceo de carga: ip-hash
Se usará la dirección IP de origen para redirigir todas las peticiones
al mismo servidor que se conoce como sticky session
También: hash $cookie_username; en vez de IP, usa la cookie de
usuario
upstream app {
ip_hash;
server app1:8080;
server app2:8080;
server app3:8080;
}
server {
listen 80;
location / {
proxy_pass http://app;
add_header X-Upstream $upstream_addr;
}
}
52. MWS nginx
Balanceo de carga
Los chequeos de salud se hacen de forma pasiva según el
resultado de las peticiones que se envían.
>max_fails, estado erróneo y estará durante fail_timeout
Tras fail_timeout, se le envía nueva petición. Si se responde
bien, pasa estado correcto.
La directiva health_check permite configurar la pruebas de
funcionamiento que se realizan a los servidores
upstream app {
ip_hash;
server app1:8080 max_fails=5 fail_timeout=30s;
server app2:8080;
server app3:8080;
}
54. MWS nginx
nginx -t
nginx -t -c fichero_de_configuración
nginx -V información sobre el→
argumentos de compilación, módulo
incluídos.
nginx -g Permite incluir→
configuraciones de directivas que no
estén en el fichero de configuración:
nginx -g “timer_resolution 200ms”
Testing configuration
Solicitudes múltiples acceso concurrente o única llamada para obtener todos los recursos (multiples peticiones por concexión)
Version 1.1 of the protocol made bandwidth optimization improvements to HTTP/1.0. For example, HTTP/1.1 introduced chunked transfer encoding to allow content on persistent connections to be streamed, rather than buffered. HTTP pipelining further reduces lag time, allowing clients to send multiple requests before a previous response has been received to the first one. Another improvement to the protocol was byte serving, which is when a server transmits just the portion of a resource explicitly requested by a client.
FastCGI es una alternativa al CGI estándar, cuya diferencia radica principalmente en el hecho de que el servidor crea un único proceso persistente por cada programa FastCGI en lugar de uno por cada solicitud del cliente.
Ventajas [editar]
Ahorro de Tráfico: Las peticiones de páginas Web se hacen al servidor Proxy y no a Internet directamente. Por lo tanto, aligera el tráfico en la red y descarga los servidores destino, a los que llegan menos peticiones.
Velocidad en Tiempo de respuesta: El servidor Proxy crea un caché que evita transferencias idénticas de la información entre servidores durante un tiempo (configurado por el administrador) así que el usuario recibe una respuesta más rápida.
Demanda a Usuarios: Puede cubrir a un gran número de usuarios, para solicitar, a través de él, los contenidos Web.
Filtrado de contenidos: El servidor proxy puede hacer un filtrado de páginas o contenidos basándose en criterios de restricción establecidos por el administrador dependiendo valores y características de lo que no se permite, creando una restricción cuando sea necesario.
Modificación de contenidos: Basándose en la misma función del filtrado, y llamado Privoxy, tiene el objetivo de proteger la privacidad en Internet, puede ser configurado para bloquear direcciones y Cookies por expresiones regulares y modifica en la petición el contenido.
Desventajas [editar]
Las páginas mostradas pueden no estar actualizadas si éstas han sido modificadas desde la última carga que realizó el proxy caché.
Un diseñador de páginas web puede indicar en el contenido de su web que los navegadores no hagan una caché de sus páginas, pero este método no funciona habitualmente para un proxy.
El hecho de acceder a Internet a través de un Proxy, en vez de mediante conexión directa, impide realizar operaciones avanzadas a través de algunos puertos o protocolos.
Almacenar las páginas y objetos que los usuarios solicitan puede suponer una violación de la intimidad para algunas personas.
SSI (Server Side Includes) are directives that are placed in HTML pages, and evaluated on the server while the pages are being served. They let you add dynamically generated content to an existing HTML page, without having to serve the entire page via a CGI program, or other dynamic technology.
The decision of when to use SSI, and when to have your page entirely generated by some program, is usually a matter of how much of the page is static, and how much needs to be recalculated every time the page is served. SSI is a great way to add small pieces of information, such as the current time. But if a majority of your page is being generated at the time that it is served, you need to look for some other solution.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
EN 2.4, MaxClients es MaxRequestWorkers
Wherever in your URL-space you do not have an Options FollowSymLinks, or you do have an Options SymLinksIfOwnerMatch, Apache will need to issue extra system calls to check up on symlinks. (One extra call per filename component.) For example, if you had:
DocumentRoot &quot;/www/htdocs&quot;
&lt;Directory &quot;/&quot;&gt;
Options SymLinksIfOwnerMatch
&lt;/Directory&gt;
and a request is made for the URI /index.html, then Apache will perform lstat(2) on /www, /www/htdocs, and /www/htdocs/index.html. The results of these lstats are never cached, so they will occur on every single request. If you really desire the symlinks security checking, you can do something like this:
DocumentRoot &quot;/www/htdocs&quot;
&lt;Directory &quot;/&quot;&gt;
Options FollowSymLinks
&lt;/Directory&gt;
&lt;Directory &quot;/www/htdocs&quot;&gt;
Options -FollowSymLinks +SymLinksIfOwnerMatch
&lt;/Directory&gt;