Errores con fichero YAML en produccion

Buenas lista.

Tengo un error 500 al tratar de leer un fichero yml en producción, es
“raro” por que en local el fichero se lee correctamente, tengo algo asi:

config/initializers/users.rb

require ‘yaml’
APP_CONFIG = YAML.load_file("#{RAILS_ROOT}/config/users.yml")

config/users.yml

username: yo
password: 123456

En producción me lanza el error “uninitialized constant” haciendo
referencia a APP_CONFIG

Creo que es “raro” por que la app al inicializarse si carga
correctamente el fichero yml de la base de datos, con lo cual no es
tema de que falte la libreria yaml en el servidor ¿no?

Gracias por la ayuda que puedan facilitarme.

Un saludo.

On Sat, Sep 20, 2008 at 12:11 AM, alarkspur [email protected] wrote:

Tengo un error 500 al tratar de leer un fichero yml en producción, es “raro”
por que en local el fichero se lee correctamente, tengo algo asi:

config/initializers/users.rb

require ‘yaml’
APP_CONFIG = YAML.load_file(“#{RAILS_ROOT}/config/users.yml”)

config/users.yml

username: yo
password: 123456
En producción me lanza el error “uninitialized constant” haciendo referencia
a APP_CONFIG

O sea, user.rb se ejecuta sin problema y el error salta en otro lugar
al tratar de usar la constante? Si es asi puedes enviar el lugar donde
sucede y la traza de error tal cual con copy & paste?

On Sat, Sep 20, 2008 at 00:11, alarkspur [email protected] wrote:

a APP_CONFIG
Creo que es “raro” por que la app al inicializarse si carga correctamente el
fichero yml de la base de datos, con lo cual no es tema de que falte la
libreria yaml en el servidor ¿no?
Gracias por la ayuda que puedan facilitarme.
Un saludo.

¿Estás utilizando la misma versión de Rails en producción y en
desarrollo? (ya sea “freezeada” o mediante gemas). Porque los
initializers son relativamente modernos (¿Rails 2.1?).

También podrías hacer que ese initializer tuviera un efecto que
pudieses observar: escribir en un log, crear un archivo temporal, …
de forma que puedas comprobar que esa línea sí se ejecuta.

Suerte.

¿Estás utilizando la misma versión de Rails en producción y en
desarrollo?

la versión de rails es la 2.1.0 1que tengo congelada en vendor.

O sea, user.rb se ejecuta sin problema y el error salta en otro lugar
al tratar de usar la constante? Si es asi puedes enviar el lugar donde
sucede y la traza de error tal cual con copy & paste?

sucede cuando hace la autentificación en el metodo login de un
controlador, en mi caso en el application, tambien probando <%=
APP_CONFIG.inspect %> he visto que se genera el mismo error si se usa
la constante en las vistas

def login
authenticate_or_request_with_http_basic do |username, password|
if username == APP_CONFIG[‘username’] && password ==
APP_CONFIG[‘password’]
session[:user] = APP_CONFIG[‘username’]
end
end
end

El log

Processing ApplicationController#login (for 84.245.71.217 at
2008-09-20 00:59:26) [GET]
Session ID: 4e115d86af526c18e930d7d98a401d55
Parameters: {“action”=>“login”, “controller”=>“application”}
Completed in 0.00056 (1773 reqs/sec) | Rendering: 0.00035 (62%) | DB:
0.00000 (0%) | 401 Unauthorized [http://miservidordepruebas.com/login]

Processing ApplicationController#login (for 84.245.71.217 at
2008-09-20 00:59:33) [GET]
Session ID:
BAh7BiIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNo
SGFzaHsABjoKQHVzZWR7AA==–b7e9df11fb3c65b35e7b7fa5a70d2eba416411dc
Parameters: {“action”=>“login”, “controller”=>“application”}

NameError (uninitialized constant ApplicationController:: APP_CONFIG):
/vendor/rails/activerecord/lib/…/…/activesupport/lib/
active_support/dependencies.rb:492:in const_missing' /app/controllers/application.rb:13:in login’
/vendor/rails/actionpack/lib/action_controller/
http_authentication.rb:95:in call' /vendor/rails/actionpack/lib/action_controller/ http_authentication.rb:95:in authenticate’
/vendor/rails/actionpack/lib/action_controller/
http_authentication.rb:85:in authenticate_with_http_basic' /vendor/rails/actionpack/lib/action_controller/ http_authentication.rb:81:in authenticate_or_request_with_http_basic’
/app/controllers/application.rb:12:in login' /vendor/rails/actionpack/lib/action_controller/base.rb:1162:in send’
/vendor/rails/actionpack/lib/action_controller/base.rb:1162:in
perform_action_without_filters' /vendor/rails/actionpack/lib/action_controller/filters.rb:580:in call_filters’
/vendor/rails/actionpack/lib/action_controller/filters.rb:573:in
perform_action_without_benchmark' /vendor/rails/actionpack/lib/action_controller/benchmarking.rb: 68:in perform_action_without_rescue’
/usr/local/lib/ruby/1.8/benchmark.rb:293:in measure' /vendor/rails/actionpack/lib/action_controller/benchmarking.rb: 68:in perform_action_without_rescue’
/vendor/rails/actionpack/lib/action_controller/rescue.rb:201:in
perform_action_without_caching' /vendor/rails/actionpack/lib/action_controller/caching/ sql_cache.rb:13:in perform_action’
/vendor/rails/activerecord/lib/active_record/connection_adapters/
abstract/query_cache.rb:33:in cache' /vendor/rails/activerecord/lib/active_record/query_cache.rb:8:in cache’
/vendor/rails/actionpack/lib/action_controller/caching/
sql_cache.rb:12:in perform_action' /vendor/rails/actionpack/lib/action_controller/base.rb:529:in send’
/vendor/rails/actionpack/lib/action_controller/base.rb:529:in
process_without_filters' /vendor/rails/actionpack/lib/action_controller/filters.rb:569:in process_without_session_management_support’
/vendor/rails/actionpack/lib/action_controller/
session_management.rb:130:in sass_old_process' /home/miservidordepruebas/ruby/gems/gems/haml-2.0.2/lib/sass/ plugin/rails.rb:19:in process’
/vendor/rails/actionpack/lib/action_controller/base.rb:389:in
process' /vendor/rails/actionpack/lib/action_controller/dispatcher.rb: 149:in handle_request’
/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:
107:in dispatch' /vendor/rails/actionpack/lib/action_controller/dispatcher.rb: 104:in synchronize’
/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:
104:in dispatch' /vendor/rails/actionpack/lib/action_controller/dispatcher.rb: 120:in dispatch_cgi’
/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:
35:in dispatch' /vendor/rails/railties/lib/fcgi_handler.rb:103:in process_request’
/vendor/rails/railties/lib/fcgi_handler.rb:153:in
with_signal_handler' /vendor/rails/railties/lib/fcgi_handler.rb:101:in process_request’
/vendor/rails/railties/lib/fcgi_handler.rb:78:in
process_each_request' /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:612:in each_cgi’
/usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:609:in
each' /usr/local/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:609:in each_cgi’
/vendor/rails/railties/lib/fcgi_handler.rb:77:in
process_each_request' /vendor/rails/railties/lib/fcgi_handler.rb:76:in catch’
/vendor/rails/railties/lib/fcgi_handler.rb:76:in
process_each_request' /vendor/rails/railties/lib/fcgi_handler.rb:50:in process!’
/vendor/rails/railties/lib/fcgi_handler.rb:24:in `process!’
dispatch.fcgi:24

Rendering /home/miservidordepruebas/app/public/500.html (500 Internal
Server Error)

On Sat, Sep 20, 2008 at 1:10 AM, alarkspur [email protected] wrote:

Es muy raro. Dejame preguntar mas cosas:

  1. Si lanzas la consola en produccion y evaluas APP_CONFIG a pelo que
    pasa?

  2. Si corres en tu maquina la app en modo produccion que pasa?

  3. Que sistemas operativos hay en cada caso?

  4. Si produccion es un Unix puedes cambiar las credenciales,
    reproducir el pete con esas, ejecutar esto

    od -t c config/users.yml

en una shell y enviar el ouput? Si puedes usar pastie para evitar
word-wrap mejor.

On Sat, Sep 20, 2008 at 3:13 AM, alarkspur [email protected] wrote:

Muchas gracias por la paciencia y ayuda, ya veras como al final es una
tontería.

Puedes hacer lo mismo con el initializer que lo carga?

Muchas gracias, yo ya no sabia que probar

  1. Si lanzas la consola en produccion y evaluas APP_CONFIG a pelo
    que pasa?
  2. Si corres en tu maquina la app en modo produccion que pasa?

En el servidor

NameError: uninitialized constant APP_CONFIG
from /home/miservidordepruebas/app/vendor/rails/activerecord/
lib/…/…/activesupport/lib/active_support/dependencies.rb:278:in
load_missing_constant' from /home/miservidordepruebas/app/vendor/rails/activerecord/ lib/../../activesupport/lib/active_support/dependencies.rb:467:inconst_missing’
from /home/miservidordepruebas/app/vendor/rails/activerecord/
lib/…/…/activesupport/lib/active_support/dependencies.rb:479:in
`const_missing’
from (irb):3

pero… esto si lo había probado y es lo que mas “mosca” me tiene,
si en el servidor en la consola en producción ejecuto YAML funciona
correctamente

$ script/console production

APP_CONFIG = YAML.load_file("#{RAILS_ROOT}/config/users.yml")
=> {“username”=>“yo”, “password”=>123456}

APP_CONFIG
=> {“username”=>“yo”, “password”=>123456}

En local todo OK tanto en development como en production,

APP_CONFIG
=> {“username”=>“yo”, “password”=>“123456”}

  1. Que sistemas operativos hay en cada caso?

En el servidor en produccion es un Linux Red Hat y mac osx en local

od -t c config/users.yml

en una shell y enviar el ouput?

0000000 u s e r n a m e : y o \n p a s
0000020 s w o r d : 1 2 3 4 5 6 \n
0000036

Muchas gracias por la paciencia y ayuda, ya veras como al final es una
tontería.

Saludos.

config/initializers/app_config.rb

0000000 r e q u i r e ’ y a m l ’ \n A
0000020 P P _ C O N F I G = Y A M L
0000040 . l o a d _ f i l e ( " # { R A
0000060 I L S _ R O O T } / c o n f i g
0000100 / u s e r s . y m l " ) \n

El 20/09/2008, a las 3:19, Xavier N. escribió:

Puedes entrar en la consola de producción y llamar a APP_CONFIG?

Eso te ha de funcionar.

Todo parece correcto asi que vamos a ir poco a poco.

Si una constante fue definida aunque hagas mil cosas con lo que
almacena la constante sigue ahi salvo que ejecutes un remove_const.

La primera conjetura seria que el initializer NO se esta ejecutando en
produccion. Eso seria facil de verificar poniendo una traza.

Si es asi, la siguiente conjetura seria que Rails en realidad no es
2.1 en produccion. No se que cosa rara podria hacer que este en
vendor, una posibilidad loca seria que en desarrollo tengas en
realidad un link simbolico, pero lo veo improbable.

Sea como sea, si podemos determinar algo de eso habremos avanzado.

Desafortunadamente script/about llevaba muchisimo tiempo sin funcionar
en modo produccion:

http://dev.rubyonrails.org/ticket/8349

y no fue hasta hace poco que se arreglo:

#370 script/about not working - Ruby on Rails - rails

Si una constante fue definida aunque hagas mil cosas con lo que
almacena la constante sigue ahi salvo que ejecutes un remove_const.

no, no ejecuto remove_const en ningún momento

La primera conjetura seria que el initializer NO se esta ejecutando en
produccion. Eso seria facil de verificar poniendo una traza.

Aquí me tienes que echar (aun más si cabe) una ayudita, no se como
tirar una traza en producción, imagino que te referiras a escribir en
el log ¿no?
en config/environments/production he añadido
config.log_level = :debug

y luego en el inicializador un

logger.info “=============”

ejecuto nuevamente la app pero no me lo muestran en log/production.log

Al final creo que lo mejor sera cambiar la constante por un string
donde se evalúa y listo :stuck_out_tongue:

Saludos

Parece que el fichero no se ejecuta, vamos a seguir esa pista. Ahora
lanzaria la consola y evaluaria

Rails::VERSION::STRING

=> “2.1.0”

exit

2008/9/20 alarkspur [email protected]:

el log ¿no?
en config/environments/production he añadido
config.log_level = :debug

y luego en el inicializador un

logger.info “=============”

Si. De hecho logger.info sale en production.log sin necesidad de tocar
configuracion.

Parece que el fichero no se ejecuta, vamos a seguir esa pista. Ahora
lanzaria la consola y evaluaria

Rails::VERSION::STRING

Podria ser que tengas algun

config.gem

en environtment.rb que no se cumpla y por algun motivo se esta
enmascarando el pete? Si tienes alguno puedes revisar que todas esas
gemas estan instaladas?

Has hecho en la consola:

APP_CONFIG

2008/9/20 alarkspur [email protected]:

2008/9/20 Xavier N. [email protected]:

Parece claro que no ejecuta el initializer.

Has modificado el boot.rb? Puedes mandar un pastie con su contenido?

Igualmente comentar que a mi no me cuadra. Como estas subiendo los
ficheros al servidor? Que no sea que no tenga un boot incorrecto en el
servidor.

2008/9/20 Xavier N. [email protected]:

Podria ser que tengas algun

config.gem

en environtment.rb que no se cumpla y por algun motivo se esta
enmascarando el pete? Si tienes alguno puedes revisar que todas esas
gemas estan instaladas?

Valga decir que esta pregunta esta motivada por la implementacion de
la carga de initializers:

def load_application_initializers
  if @gems_dependencies_loaded
    Dir["#{configuration.root_path}/config/initializers/**/*.rb"].sort.each

do |initializer|
load(initializer)
end
end
end

Si no entra en el if no se ejecuta la carga, que es lo que observamos.
Ese flag basicamente dice que todos los config.gem fueron cargados.

On Sat, Sep 20, 2008 at 3:45 PM, Francesc E.
[email protected] wrote:

Has hecho en la consola:

APP_CONFIG

Si esta unos mensajes mas arriba, y copy and paste del codigo del
initializer carga el fichero en consola, por lo que hay que suponer
que el codigo y el nombre del fichero en la maquina de produccion son
correctos.

Parece claro que no ejecuta el initializer.

Interesante … entonces si las gemas necesarias no se han cargado, la
aplicación no deberia arrancar no?

2008/9/20 Xavier N. [email protected]:

2008/9/20 Francesc E. [email protected]:

Interesante … entonces si las gemas necesarias no se han cargado, la
aplicación no deberia arrancar no?

Parece ser que no, sale un warning pero arranca, observa el mensaje
que aparece por ahi sobre la gema foo:

fxn@feynman:~/tmp/test_gem$ script/server
=> Booting Mongrel (use ‘script/server webrick’ to force WEBrick)
=> Rails 2.1.0 application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment…
These gems that this application depends on are missing:

  • foo
    Run “rake gems:install” to install them.
    ** Rails loaded.
    ** Loading any Rails specific GemPlugins
    ** Signals ready. TERM => stop. USR2 => restart. INT => stop (no
    restart).
    ** Rails signals registered. HUP => reload (without restart). It
    might not work well.
    ** Mongrel 1.1.5 available at 0.0.0.0:3000
    ** Use CTRL-C to stop.

Me parece que es buena pista.