2012-10-10 20 views
8

Estoy tratando de usar delayed_job para programar tareas usando Sqlite3, y parece que apache no puede leer mi archivo production.sqlite3.Rails: SQLite3 :: CantOpenException: no se puede abrir el archivo de base de datos

Aquí es mi database.yml:

production: 
    adapter: sqlite3 
    database: db/production.sqlite3 
    pool: 5 
    timeout: 5000 

Aquí está el error que estoy recibiendo (en log/production.log):

ActiveRecord::StatementInvalid (SQLite3::CantOpenException: unable to open database file:) 

He corrido RAILS_ENV=production rake db:create y RAILS_ENV=production rake db:migrate. El archivo db/production.sqlite3 existe, y el directorio db y todas sus subcarpetas son propiedad de apache:apache, que es con quien se ejecuta apache. Estoy usando Phusion Passenger en Amazon EC2.

+0

Cambié al uso de PostgreSQL y parece funcionar bien. Todavía no sé por qué SQLite 3 no funcionó. – rdasxy

+0

¿Alguna vez descubrió por qué? – digitalWestie

+0

No. Me di por vencido y cambié a PostgreSQL. – rdasxy

Respuesta

8

SQLLite funciona haciendo que el proceso Rails escriba en un archivo de sistema dentro del árbol de directorios Rails. El proceso Rails es propiedad de Apache, que establece un usuario "apache" y un grupo "apache" de forma predeterminada. Para que funcione, deberá otorgar permisos de escritura al usuario o grupo de apache en el directorio /db.

O

configurar Apache para correr con un grupo ya que tiene write permisos al directorio. Una buena estrategia es crear un grupo de varios procesos que pueden necesitar acceso a varias ubicaciones; por ejemplo, tengo un grupo "implementador" del que forma parte el usuario que hace lanzamientos, junto con la instancia de Apache. Me parece que tener por lo general un grupo que los diversos usuarios del proceso de inicio de sesión y son parte del facilita la vida (por ejemplo, para buscar en los registros del servidor), escribir archivos o archivos almacenados en caché, etc.

Y/O

Utilice un servidor de base de datos real como PostgreSQL o MySQL; funcionan porque son sus propios procesos que administran sus propios archivos. El proceso Rails (apache, en su caso) se conecta al proceso del servidor de la base de datos en un puerto Unix. Cada proceso de servidor gestiona de forma segura solo los archivos que conoce.

SQLLite está bien para empezar - muy fácil y con poca sobrecarga, pero muy pronto tendrá que ejecutar un servidor de base de datos normal en producción. Y pronto descubrirá que las cosas no son exactamente las mismas entre SQLLite y los demás, y en ese momento debería instalar el mismo servidor de base de datos en su máquina de desarrollo.

+0

Fui a hacer esto (en una aplicación ficticia en la carpeta 'test' de una joya) y encontré que' db/'faltaba por completo. 'mkdir db' lo arregló para mí. – PJSCopeland

3

Es porque nginx crear el usuario www-data, y este usuario no tiene una previlegues leer el archivo sqlite3 y su aplicación ...

Tiene que ejecutar comandos:

1. sudo chown -R www-data:www-data rails_project/

2. sudo chmod -R 777 rails_project/

y comprobar que dar comienzo a su aplicación en el modo de producción.

+0

Esto es una falla de seguridad completa, por favor ** NUNCA ** 'chmod 777' tus archivos en un servidor de producción. Lee la respuesta de @Tom Harrison Jr. – jperelli

+0

@jperelli 644? – bmalets

-1

Se ha topado con este problema en una aplicación donde todo es propiedad de root.

Así es como me solucionaron.

[email protected]:/var/www/auth_whateveryousay# chmod -R 0777 db/ 


[email protected]:/var/www/auth_whateveryousay# ls -lad * 
drwxr-xr-x 11 root root 4096 Nov 27 17:23 app 
drwxr-xr-x 2 root root 4096 Nov 27 17:23 bin 
drwxr-xr-x 5 root root 4096 Nov 27 17:23 config 
-rw-r--r-- 1 root root 130 Nov 27 17:23 config.ru 
drwxrwxrwx 3 root root 4096 Nov 27 17:33 db 
-rw-r--r-- 1 root root 879 Nov 27 17:23 Gemfile 
-rw-r--r-- 1 root root 6367 Nov 27 17:24 Gemfile.lock 
drwxr-xr-x 4 root root 4096 Nov 27 17:23 lib 
drwxr-xr-x 2 root root 4096 Nov 27 17:25 log 
drwxr-xr-x 2 root root 4096 Nov 27 17:23 public 
-rw-r--r-- 1 root root 227 Nov 27 17:23 Rakefile 
-rw-r--r-- 1 root root 898 Nov 27 17:23 README 
-rw-r--r-- 1 root root 26632 Nov 27 17:23 README.textile 
drwxr-xr-x 6 root root 4096 Nov 27 17:23 spec 
drwxrwxrwx 5 root root 4096 Nov 27 17:25 tmp 
drwxr-xr-x 3 root root 4096 Nov 27 17:23 vendor 

conclusión es: esto es cuestión premssions y se necesita para asegurarse de que todo aquel que posee la aplicación Ya sea que sea root o no root, sólo tendrá que dar a leer ese usuario y el acceso de escritura en el base de datos en uso chmod -R 0777 db/. Ajusta esto para que se ajuste a tu propio nivel de seguridad.

+0

Esto es una falla de seguridad completa, por favor ** NUNCA ** 'chmod 777' sus archivos en un servidor de producción. Lee la respuesta de @Tom Harrison Jr. – jperelli

+0

@jperelli gracias por los comentarios: el punto aquí es que solo necesitamos cambiar los permisos en la carpeta afectada "db" y no en toda la carpeta de aplicaciones "Proyecto Rails". Al final de la respuesta, mencioné "Ajuste esto para que se ajuste a su propio nivel de seguridad", lo que implica lo que ha dicho. – zee

+0

De acuerdo, enfatice la seguridad antes en su respuesta, por lo que las personas deben tener cuidado al aplicar su solución. – jperelli

Cuestiones relacionadas