YOURLS not re-reading config when running in Docker? about images

[dgw]

Issues with the YOURLS Docker should be handled in the docker-yourls repo. I've transferred the issue so you don't have to resubmit. :)

[dgw]

What you're missing is the fact that YOURLS runs per request, not as a daemon. require_once also happens once per request. Changes written to the config file take effect on the next request, if not immediately due to being made in memory first before the write.

Or am I misunderstanding the question? Docker is not exactly my area. 😸

[pcolmer]

This has initially be reported at vvanasten/YOURLS-Change-Password#2 but it does look like the plugin is doing what it should be doing.

[LeoColomb]

Thanks for opening this issue @pcolmer.

I just checked and it does read the updated /var/www/html/user/config.php.
Some tips:

• Volumes on Windows sometimes block file updates for the container.
• Be sure the plugin is updating the file (just open a bash in the container and print the file).
• Check your volumes are correctly managed.

[pcolmer]

Hi @LeoColomb. Thanks for the feedback. I'm running this on Linux. I've run docker exec... /bin/bash to check that the container is "seeing" the updated file and it is, but the new password isn't being accepted.

Is there any logging or debugging I can enable to troubleshoot this further?

[LeoColomb]

I'm running this on Linux.

Ah, did you check file permissions behind the volume?

Is there any logging or debugging

Yes, you can enable debug with:

-e YOURLS_DEBUG=true

[pcolmer]

Ah, did you check file permissions behind the volume?

Yes, the files are owned by www-data on the host so that is the same UID as being used within the container.

Yes, you can enable debug with:

Since I'm using docker-compose, I've added YOURLS_DEBUG: "true" under the environment section. This seems to have turned debugging on in that I'm now seeing output on the browser like this:

Connected to database yourls on mysql 
SQL: SELECT option_name, option_value FROM yourls_options WHERE 1=1 (0.00033 s)
Check for new version: no
SQL: SELECT COUNT(keyword) as count, SUM(clicks) as sum FROM `yourls_url` WHERE 1=1  (0.00024 s)
Could not store cookie: headers already sent in /var/www/html/includes/functions-html.php on line 82
Could not store cookie: headers already sent in /var/www/html/includes/functions-html.php on line 82
Could not store cookie: headers already sent in /var/www/html/includes/functions-html.php on line 82
Could not store cookie: headers already sent in /var/www/html/includes/functions-html.php on line 82
Could not store cookie: headers already sent in /var/www/html/includes/functions-html.php on line 82
Could not store cookie: headers already sent in /var/www/html/includes/functions-html.php on line 82
Could not store cookie: headers already sent in /var/www/html/includes/functions-html.php on line 82
Could not store cookie: headers already sent in /var/www/html/includes/functions-html.php on line 82
Could not store cookie: headers already sent in /var/www/html/includes/functions-html.php on line 82
Could not store cookie: headers already sent in /var/www/html/includes/functions-html.php on line 82
Could not store cookie: headers already sent in /var/www/html/includes/functions-html.php on line 82
Could not store cookie: headers already sent in /var/www/html/includes/functions-html.php on line 82
Could not store cookie: headers already sent in /var/www/html/includes/functions-html.php on line 82
Could not store cookie: headers already sent in /var/www/html/includes/functions-html.php on line 82
SQL: SELECT * FROM `yourls_url` WHERE 1=1  ORDER BY `timestamp` desc LIMIT 0, 15; (0.00025 s)
SQL: SELECT click_time, ip_address, country_code, referrer, a.shorturl AS shorturl, b.url AS longurl, b.title as title
        FROM yourls_log a, yourls_url b
        WHERE a.shorturl = b.keyword
        ORDER BY click_time DESC
        LIMIT '10'; (0.00029 s)

but I'm not seeing anything to suggest that YOURLS is re-loading the config file.

[pcolmer]

I'm struggling to understand how YOURLS manages to reload the config file whenever it gets updated.

As far as I can tell from looking at the code:

• includes/load-yourls.php is responsible for loading the PHP config file into the running environment. Since the require_once directive is used, the file will only be loaded once.

• includes/auth.php mentions YOURLS_CONFIGFILE (which is set by includes/load-yourls.php) and that calls yourls_hash_passwords_now from includes/functions-auth.php which actually uses the require directive so that it can reload the file into memory. If the passwords are hashed, they get written back to disc but are not re-loaded into memory at that point.

What am I overlooking? I simply cannot find anywhere in the code where YOURLS would seem to re-load the config because it has been changed beneath its feet (e.g. adding a new user to the config).

[LeoColomb]

@dgw is right.

It's more about PHP deamon than YOURLS management. Did you push a special config for the PHP deamon?

[pcolmer]

My docker-compose.yml file specifies some environment values (YOURLS_SITE, etc) but also maps the container's /var/www/html/user folder onto a yourls_user folder on the host. This was done to allow incorporate of plugins (per #16) but also to allow users to be added to the $yourls_user_passwords array which is stored at the end of the file beneath the "Personal settings would go after here" comment.

If I didn't do that then the config.php file would be stored within the running container's environment and would be lost if the container stops running.

[LeoColomb]

@pcolmer Sure, but again, I was talking about PHP configuration, not YOURLS config.

Anyway, can you share your docker-compose.yml?

[pcolmer]

I was talking about PHP configuration, not YOURLS config.

My apologies for misunderstanding that. I haven't done anything beyond running the container as provided.

The docker-compose.yml is below with some redactions in it. The reference to docker/stikked-envvars.txt is purely to provide some initialisation to MySQL that a different container uses (and which I've removed from this file for testing).

version: "3.2"

services:
  mysql:
    image: mysql:5.7
    volumes:
      - db_data:/var/lib/mysql
    env_file: docker/stikked-envvars.txt

  yourls:
    depends_on:
      - mysql
    image: yourls
    ports:
      - 8001:80
    volumes:
      - ./yourls_user:/var/www/html/user
    environment:
      YOURLS_DB_NAME: "yourls"
      YOURLS_SITE: "http://link1804.linaro.org"
      YOURLS_UNIQUE_URLS: "false"
      YOURLS_PRIVATE: "true"
      YOURLS_URL_CONVERT: "62"
      YOURLS_DB_PASS: "xxxxxxxxxxxxxxxxxxxx"
      YOURLS_USER: "yourls_admin"
      YOURLS_PASS: "phpass:!2a!08!xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
      YOURLS_DEBUG: "true"

# You should use persistant storage for this,
# as if the volume is deleted, everything is gone!
volumes:
  db_data:

[pcolmer]

OK ... I've been spending a few days trying to (a) learn PHP (!) and (b) figure out what is going on.

@dgw is (obviously) right about YOURLS being run per request. I can add output statements around the initialisation and the shutdown parts of YOURLS and it gets fired off per page.

If I change my YOURLS password, log out and then wait, there will be a point at which time logging in with the new password works.

So the cause of the new password not being recognised seems to be that the PHP files are getting cached ... except that PHP doesn't cache anything. However, Zend does, with OpCache.

And, indeed, adding an .ini file that sets opcache.enable=0 "fixes" my problem. I can now log in, change my password, log out and log back in with the new password and it all works.

I don't know enough about PHP or YOURLS to be able to say whether or not disabling the OpCache is going to have a significant performance hit.

Hopefully @dgw or @LeoColomb might be able to shed some light on this or even perhaps suggest if there is a cleaner/safer way of flushing config.php from the cache when it has been updated?

[LeoColomb]

OpCache is going to have a significant performance hit.

At some point, yes, it have a significant performance hit.

sets opcache.enable=0 "fixes"

OPCache should be able to revalidate files, it should ne be an issue.
I still don't understand why on your side revalidation did not work.

there is a cleaner/safer way of flushing config.php from the cache when it has been updated

Take a look at https://ma.ttias.be/how-to-clear-php-opcache/

[pcolmer]

OPCache should be able to revalidate files, it should ne be an issue.
I still don't understand why on your side revalidation did not work.

It does ... eventually, but it takes around 50 seconds. So if someone logs in, changes their password, logs out and tries to log in again, they could take less than 50 seconds to do that, in which case their attempts will fail until the cache catches up.

I'm not seeing this on our older server, which is running YOURLS 1.7.2 under PHP 5. I'm not sure if this is being caused by Docker and mapped filing systems or by the OPCache. It is curious that if I re-enable the OPCache (and so see this problem again) but then use the flush cache script:

<?php
opcache_reset();
?>

that does fix the problem. So I do have a workaround that allows the cache to be used but it will affect anyone expecting a new password to work immediately.

[vitalyzhakov]

@pcolmer , hello!
May be it caused by volume instruction #36 ?

[LeoColomb]

@vitalyzhakov Haha, good try but I don't think so. 🙂

[LeoColomb]

Closing as very PHP specific, nothing we can do from YOURLS I'm afraid.
#36 might help a bit.
Workaround explained above.

Thanks!

[strarsis]

@LeoColomb: I am using YOURLS as a Docker container. It works really well. However, I also get he same warning.
How can this be fixed? Is this due to Docker mounts/permissions?

[LeoColomb]

@strarsis If you get the exact same issue, you have the full process right above. Just go through it! 🙂