docker/docker.env variables not expanded to empty strings #6578

JonathonReinhart · 2019-01-10T23:30:12Z

I'm running the snipe/snipe-it:v4.6.7 Docker image via docker-compose. Of course, I modeled my docker-compose.yml off of the settings described in https://snipe-it.readme.io/docs/docker.

(I'm actually setting up multiple instances to run against a single DB, due to #3520, and in-part #6501).

The relevant part of docker-compose.yml:

  assets-corp:
    image: snipe/snipe-it:v4.6.7 
    links:
      - db
    volumes:
      - ./data/snipeit/snipeit_corp:/var/lib/snipeit
    environment:
      VIRTUAL_HOST: assets-corp.example.com

      MYSQL_PORT_3306_TCP_ADDR: db
      #MYSQL_PORT_3306_TCP_PORT: 3306
      MYSQL_DATABASE: snipeit_corp
      MYSQL_USER: snipeit_corp
      MYSQL_PASSWORD: ReDaCtEd

      APP_KEY: base64:ReDaCtEd

Expected Behavior

I would expect no strange behavior with other environment variables

I would expect that the default MySQL port (3306) would be used everywhere, as the MYSQL_PORT_3306_TCP_PORT environment variable is not set.

Actual Behavior

It appears that environment variables which are not set, but referenced in docker/docker.env are kept as literals (and not expanded to empty strings as one would expect).

This has caused (so far) the following bad behaviors:

${MAIL_ENV_FROM_ADDR} (literal) shows up in several places:

On the initial /setup page:
On /setup/user? page:

${MYSQL_PORT_3306_TCP_PORT} shows up on /admin/backups after clicking
:

I can work around this by un-commenting MYSQL_PORT_3306_TCP_PORT in my docker-compose.yml file and setting it to 3306.

The text was updated successfully, but these errors were encountered:

stale · 2019-03-12T00:23:48Z

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

JonathonReinhart · 2019-03-12T11:17:45Z

Dear @Stale,

Despite what you may think, issues aren't magically fixed after 60 days.

stale · 2019-03-12T11:17:47Z

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

stale · 2019-05-12T06:48:22Z

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

JonathonReinhart · 2019-05-12T21:17:28Z

Yes.

stale · 2019-05-12T21:17:31Z

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

stale · 2019-07-11T21:19:19Z

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

JonathonReinhart · 2019-07-11T23:14:48Z

Yes.

stale · 2019-07-11T23:14:51Z

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

stale · 2019-09-10T00:06:15Z

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

JonathonReinhart · 2019-09-10T10:05:09Z

.

stale · 2019-09-10T10:05:12Z

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

stale · 2019-11-09T10:57:57Z

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

stale · 2019-11-16T11:21:31Z

This issue has been automatically closed because it has not had recent activity. If you believe this is still an issue, please confirm that this issue is still happening in the most recent version of Snipe-IT and reply to this thread to re-open it.

jasonh-arusd · 2020-07-20T16:02:38Z

I've had the same issue and same resolution as @JonathonReinhart here. Launching a fresh instance of Snipe-IT with docker-compose will throw errors when it tries to do database backups and a few other tasks, since it's trying to use the string "${MYSQL_PORT_3306_TCP_PORT}" instead of an integer port number. Setting MYSQL_PORT_3306_TCP_PORT=3306 in the .env file does fix this error.

I think something in the conversion from local .env file (passed to docker-compose) to the generated .env file within Docker (that Snipe-IT actually uses) is not working; as was mentioned, if the environment variable is missing it should probably default to an empty string and let Snipe-IT use whatever defaults it wants, instead of passing the literal string, e.g. "${MYSQL_PORT_3306_TCP_PORT}".

If there's no easy resolution to the root issue, I would recommend at least updating the example .env file at the Docker installation instructions to include the other needed variables, so nobody else runs into this.

Thanks!

JonathonReinhart · 2021-01-01T18:13:47Z

@uberbrady @snipe Please reopen this issue representing a current bug, confirmed present in v5.0.11:

stale · 2021-01-02T01:05:10Z

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

JonathonReinhart · 2021-01-02T04:09:21Z

Looking at the running config,I see the following items with this problem:

docker-compose exec snipeit php artisan tinker
Psy Shell v0.10.3 (PHP 7.2.24-0ubuntu0.18.04.7 — cli) by Justin Hileman
>>> config('mail')
=> [
     "driver" => "smtp",
     "host" => "${MAIL_PORT_587_TCP_ADDR}",
     "port" => "${MAIL_PORT_587_TCP_PORT}",
     "from" => [
       "address" => "${MAIL_ENV_FROM_ADDR}",
       "name" => "${MAIL_ENV_FROM_NAME}",
     ],
     "reply_to" => [
       "address" => "${MAIL_ENV_FROM_ADDR}",
       "name" => "${MAIL_ENV_FROM_NAME}",
     ],
     "encryption" => "${MAIL_ENV_ENCRYPTION}",
     "username" => "${MAIL_ENV_USERNAME}",
     "password" => "${MAIL_ENV_PASSWORD}",
     "sendmail" => "/usr/sbin/sendmail -bs",
     "markdown" => [
       "theme" => "default",
       "paths" => [
         "/var/www/html/resources/views/vendor/mail",
       ],
     ],
   ]
>>> config('database.connections.mysql.port')
=> "${MYSQL_PORT_3306_TCP_PORT}"

(Still tracking down how these get in here like this)

JonathonReinhart · 2021-01-02T05:53:14Z

I feel like this is simply a limitation of PHP dotenv:

<?php
    require __DIR__.'/bootstrap/autoload.php';
    use Dotenv\Dotenv;

    $d = Dotenv::create(__DIR__);
    $d->load();
    print_r($_ENV);
?>

Output:

$ docker-compose exec -T snipeit php < foo.php 
Array
(
    [PATH] => /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
    [HOSTNAME] => c72436aefa39
    [MYSQL_PORT_3306_TCP_ADDR] => db
    [MYSQL_DATABASE] => snipeit
    [MYSQL_USER] => snipeit
    [MYSQL_PASSWORD] => password
    [APP_KEY] => base64:XXXXXXXXXXXXXXXXXXXXXXXXXX
    [HOME] => /root
    [DB_CONNECTION] => mysql
    [DB_HOST] => db
    [DB_PORT] => ${MYSQL_PORT_3306_TCP_PORT}
    [DB_DATABASE] => snipeit
    [DB_USERNAME] => snipeit
    [DB_PASSWORD] => password
    [DB_PREFIX] => null
    [DB_DUMP_PATH] => /usr/bin
    [MAIL_DRIVER] => smtp
    [MAIL_HOST] => ${MAIL_PORT_587_TCP_ADDR}
    [MAIL_PORT] => ${MAIL_PORT_587_TCP_PORT}
    [MAIL_USERNAME] => ${MAIL_ENV_USERNAME}
    [MAIL_PASSWORD] => ${MAIL_ENV_PASSWORD}
    [MAIL_ENCRYPTION] => ${MAIL_ENV_ENCRYPTION}
    [MAIL_FROM_ADDR] => ${MAIL_ENV_FROM_ADDR}
    [MAIL_FROM_NAME] => ${MAIL_ENV_FROM_NAME}
    [MAIL_REPLYTO_ADDR] => ${MAIL_ENV_FROM_ADDR}
    [MAIL_REPLYTO_NAME] => ${MAIL_ENV_FROM_NAME}
    [IMAGE_LIB] => gd
    [SESSION_LIFETIME] => 12000
    [EXPIRE_ON_CLOSE] => false
    [ENCRYPT] => false
    [COOKIE_NAME] => snipeit_session
    [COOKIE_DOMAIN] => null
    [SECURE_COOKIES] => false
    [CACHE_DRIVER] => file
    [SESSION_DRIVER] => file
    [QUEUE_DRIVER] => sync
)

JonathonReinhart · 2021-01-04T03:07:46Z

I've reported this issue upstream: vlucas/phpdotenv#468

But, it will certainly be a while before it is fixed in phpdotenv, and even then, Laravel will have to update its reference.

So that means snipe-it is going to have to work around this. I think we're going to have to fix up the .env file in startup.sh, perhaps using envsubst.

JonathonReinhart mentioned this issue Jan 19, 2019

Run Laravel schedule in docker image using supervisord #6606

Merged

stale bot added the stale label Mar 12, 2019

stale bot removed the stale label Mar 12, 2019

snipe assigned uberbrady Mar 13, 2019

snipe added ❓ not sure if bug This issue has not been confirmed as a bug yet docker labels Mar 13, 2019

stale bot added the stale label May 12, 2019

stale bot removed the stale label May 12, 2019

stale bot added the stale label Jul 11, 2019

stale bot removed the stale label Jul 11, 2019

stale bot added the stale label Sep 10, 2019

stale bot removed the stale label Sep 10, 2019

stale bot added the stale label Nov 9, 2019

stale bot closed this as completed Nov 16, 2019

uberbrady reopened this Jan 2, 2021

stale bot removed the stale label Jan 2, 2021

JonathonReinhart mentioned this issue Jan 4, 2021

References to variables which are not set are left expanded vlucas/phpdotenv#468

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

docker/docker.env variables not expanded to empty strings #6578

docker/docker.env variables not expanded to empty strings #6578

JonathonReinhart commented Jan 10, 2019 •

edited

stale bot commented Mar 12, 2019

JonathonReinhart commented Mar 12, 2019

stale bot commented Mar 12, 2019

stale bot commented May 12, 2019

JonathonReinhart commented May 12, 2019

stale bot commented May 12, 2019

stale bot commented Jul 11, 2019

JonathonReinhart commented Jul 11, 2019

stale bot commented Jul 11, 2019

stale bot commented Sep 10, 2019

JonathonReinhart commented Sep 10, 2019

stale bot commented Sep 10, 2019

stale bot commented Nov 9, 2019

stale bot commented Nov 16, 2019

jasonh-arusd commented Jul 20, 2020

JonathonReinhart commented Jan 1, 2021

stale bot commented Jan 2, 2021

JonathonReinhart commented Jan 2, 2021

JonathonReinhart commented Jan 2, 2021

JonathonReinhart commented Jan 4, 2021

docker/docker.env variables not expanded to empty strings #6578

docker/docker.env variables not expanded to empty strings #6578

Comments

JonathonReinhart commented Jan 10, 2019 • edited

Expected Behavior

Actual Behavior

stale bot commented Mar 12, 2019

JonathonReinhart commented Mar 12, 2019

stale bot commented Mar 12, 2019

stale bot commented May 12, 2019

JonathonReinhart commented May 12, 2019

stale bot commented May 12, 2019

stale bot commented Jul 11, 2019

JonathonReinhart commented Jul 11, 2019

stale bot commented Jul 11, 2019

stale bot commented Sep 10, 2019

JonathonReinhart commented Sep 10, 2019

stale bot commented Sep 10, 2019

stale bot commented Nov 9, 2019

stale bot commented Nov 16, 2019

jasonh-arusd commented Jul 20, 2020

JonathonReinhart commented Jan 1, 2021

stale bot commented Jan 2, 2021

JonathonReinhart commented Jan 2, 2021

JonathonReinhart commented Jan 2, 2021

JonathonReinhart commented Jan 4, 2021

JonathonReinhart commented Jan 10, 2019 •

edited