Siempre he tenido problemas con varios archivos pathsfor nginxy dónde deberían ubicarse. Como sabemos, podremos cambiar dónde podemos aparcar tanto elwwwdirectorios para nuestro web app, así como los logarchivos asociados.
El problema que encontré es que tengo bashscripts Rubyde usuario tanto para SSHllamadas como crontabscripts que necesitan acceso a varias partes de estos nginxarchivos, así como copias de red programadas de varios archivos, sin mencionar las actualizaciones de estos archivos.
Me he adherido a las rutas estáticas recomendadas por la instalación del paquete nginxen varias distribuciones, sin embargo, a menudo me he encontrado con permissionsproblemas porque pathno era óptima con respecto a la accesibilidad. Así que investigaría las distintas linuxrutas principales y elegiría algo que estuviera diseñado teniendo todo esto en mente, manteniendo al mismo tiempo un buen nivel de seguridad. He visto varias ubicaciones, y ahora que estoy en esto nuevamente ( crontabsno funciona, permissionsproblemas con varios elementos, etc.), pensé en preguntar dónde debería ubicarse todo esto.
Mis aplicaciones no son staticaplicaciones HTML estándar. Tengo una Rackaplicación en app serverejecución Gemfile, así como cualquier carga entrante, etc.
Las dos ubicaciones que estoy evaluando son:
- /usr/locallinuxfoundation.org
- /usr/compartirlinuxfoundation.org
Sin embargo... esto es lo que leí para el /usrdirectorio:
/usr es la segunda sección principal del sistema de archivos. /usr son datos que se pueden compartir y de solo lectura. Eso significa que /usr debe poder compartirse entre varios hosts compatibles con FHS y no debe escribirse en él. Cualquier información que sea específica del host o que varíe con el tiempo se almacena en otro lugar.
Los paquetes de software grandes no deben utilizar un subdirectorio directo bajo la jerarquía /usr.
Entonces estoy perdido. ¿Alguien puede recomendar una ubicación para archivos legibles/escribibles que me dé la mínima molestia al intentar escribir scripts y cron?
Respuesta1
La ubicación adecuada "por supuesto" para alojar archivos de sitios web es /srv/www. A partir de ahí, normalmente "particiono" esto en directorios relacionados con el dominio.
Entonces, en general, /srv/www/example.comtiene esta estructura/subdirectorios:
publicalmacena cualquier archivo de acceso público vinculado a ese dominio/sitio weblogsalmacena cualquier archivo de registro (ya sea NGINX, PHP-FPM, etc.) vinculado a ese dominiosessionsalmacena sesiones específicas del usuario, por ejemplo, sesiones PHP
Ya sea que use PHP-FPM o cualquier otro "demonio de script", desea configurar los permisos correctamente, ajustando la configuración de su demonio y modificando/chown los archivos correctamente. No existe un lugar mágico que te proteja de tener queconfigurar el modelo de permisos. VerNGINX y PHP-FPM. ¿Cuáles deberían ser mis permisos?- esto se aplica muy bien a la mayoría de las configuraciones de sitios web, independientemente de PHP-FPM:
- Agregue un usuario separado para cada sitio web, para un aislamiento adecuado, por ejemplo
example - Configure su demonio de secuencia de comandos para que se ejecute como ese usuario
- Haga que el usuario de su servidor web (NGINX) sea el miembro del grupo del usuario de su sitio:
usermod -a -G example nginx. Esto permite que NGINX lea archivos que tienen permiso de grupo configurado para leer, y puede proteger los archivos que no desea que lea (archivos de configuración) simplemente eliminando el bit de permiso de grupo dechmod
Al final de todo, nunca hay un problema de permisos: ¡todo es propiedad del mismo usuario y "se ejecuta"!
Respuesta2
Votar para cerrar esto porque la pregunta es realmente vaga. También busca culpar a sus herramientas por la situación cuando no son la fuente del problema. Hasta cierto punto, está limitado en lo que puede/debe hacer por el subsistema MAC y también en cómo el sistema de administración de paquetes maneja los archivos de configuración. Sin embargo, dado que no nos dijo qué distribución era, no sabemos si es relevante y mucho menos estaremos en condiciones de hacer sugerencias.
Donde debería COMENZAR al intentar abordar este problema es creando listas completas de qué cuentas de usuario necesitan acceso a qué archivos (antes de considerar dónde se encuentran esos archivos) y elaborando un modelo de permisos apropiado.
Ciertamente, es MUY improbable que sea apropiado almacenar scripts o contenido en /usr