10000 Environment variables from vhost not passed to service container in production · Issue #19015 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

Environment variables from vhost not passed to service container in production #19015

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
kinekt4 opened this issue Jun 10, 2016 · 6 comments
Closed

Environment variables from vhost not passed to service container in production #19015

kinekt4 opened this issue Jun 10, 2016 · 6 comments

Comments

@kinekt4
Copy link
kinekt4 commented Jun 10, 2016 •
edited
Loading

I'm using the following technique to set some environment variables (db params in particular):

As described in the document, they need to be set in two different places:

  • In Apache vhost
  • In command line (prior to running symfony commands)

When in the development environment (app_dev.php) and connecting to the DB

$db = Propel::getWriteConnection('default');

the $db object references the correct database as defined in my vhost.

However, when in production environment (app.phpp) and connecting to the DB, the $db object references the database as defined in the CLI instead.

I've been able to mitigate this issue by setting debug to true in the front controller:

// app.php
$kernel = new AppKernel('prod', true);

So, it seems like a caching issue but I'm not sure if it's a Symfony or a Propel issue.

Also, I wonder if this issue may be related: #7555

How To Reproduce

Vhost

<VirtualHost *:443>    
  ...
  # DATABASE PARAM BY VHOST
  SetEnv          SYMFONY__DATABASE__HOST 127.0.0.1
  SetEnv          SYMFONY__DATABASE__USER test-user
  SetEnv          SYMFONY__DATABASE__PASSWORD test-password
  SetEnv          SYMFONY__DATABASE__NAME test-db
  ...
</VirtualHost>

config.yml

propel:
    database:
        connections:
            default:
                adapter:                %database_adapter%
                user:                   %database_user%
                password:               %database_password%
                dsn:                    %database_driver%:host=%database_host%:%database_port%;dbname=%database_name%;
                options:
                    ATTR_PERSISTENT:    NULL
                attributes:             []

parameters.yml

parameters:
    database_adapter: mssql
    database_driver: pdo_dblib
    database_host: '%database.host%'
    database_port: 1433
    database_name: '%database.name%'
    database_user: '%database.user%'
    database_password: '%database.password%'

Clear Cache CLI

export SYMFONY__DATABASE__HOST=127.0.0.1
export SYMFONY__DATABASE__USER=test-user
export SYMFONY__DATABASE__PASSWORD=test-password
export SYMFONY__DATABASE__NAME=test-db

php app/console cache:clear --env=prod

Environment
OS: CentOS 7
Apache: 2.4.6
PHP: 5.6
Symfony: 2.8 (standard framework edition)
ORM: Propel
Database adapter: mssql
Database driver: pdo_dblib
@WebBamboo
Copy link

@denormalizer Can you post the relevant parts of config.yml(with passwords masked of course), I'll try to repeat the issue?

Also I'm assuming you did:
php bin/console cache:clear --env=prod

@kinekt4
Copy link
Author
kinekt4 commented Jun 14, 2016 •
edited
Loading

Hi @PavelPetrov-WebBambooLtd,

That's correct. I did run cache:clear --env=production.

I've updated the post to make it clearer.

@magnusnordlander
Copy link
Contributor

This is related to #18155 (and a bunch of older tickets referenced in that).

@kinekt4
Copy link
Author
kinekt4 commented Jul 5, 2016

@magnusnordlander Thanks for the headsup

@kinekt4
Copy link
Author
kinekt4 commented Sep 22, 2016

This seems to be the solution moving forward: #19681

Although only available from Symfony 3.2

@fabpot
Copy link
Member
fabpot commented Sep 22, 2016

Yes, and unfortunately, there is no way to "fix" this for older versions.

@fabpot fabpot closed this as completed Sep 22, 2016
@jakzal jakzal mentioned this issue Sep 22, 2016
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@fabpot @magnusnordlander @WebBamboo @kinekt4
0