Replies: 3 comments 10 replies
-
|
Hi, first and foremost, thank you for your thorough update hints.
Yes that is correct. This was no longer required since I nuked the old "symlink" functionality where symbolic links would be generated as a way to mask the real url of the image.
Thank you for the heads up. I will add it.
Possible, I will investigate this, in the meantime I will document the requirement on the env_file in docker-compose yaml.
I did not see this one coming, sorry, I always had the DB_PORT set :/
This one is trickier, because AFAIK, caddy with frankenphp allows to directly route to it on 443 and caddy is taking care of providing the certificate then.
Funny thing, I literally updated it a few seconds ago: https://lycheeorg.dev/docs/docker.html
I will track this one, may need a small migration to update the associated setting (if still the default value).
Sorry I forgot to document that, but it is there :) If you go to the maintenance page, you should see: I will add it to the documentation! |
Beta Was this translation helpful? Give feedback.
-
I guess your best approach would be then the php artisan command with |
Beta Was this translation helpful? Give feedback.
-
To address this point, it should no longer be an issue, Lychee automatically do chunking so that the upload limit is no longer a concern. If you want to modify it, I just know that it is located in |
Beta Was this translation helpful? Give feedback.
-
I double checked the Dockerfile and it appears to be the case. Line 145 in c9e68b0 |
Beta Was this translation helpful? Give feedback.
-
|
@cdauth I updated the entrypoint.sh to not fail when APP_KEY is not provided. Will release soon. |
Beta Was this translation helpful? Give feedback.
-
|
@cdauth I updated the entrypoint script, APP_KEY that should no longer be an issue. :) |
Beta Was this translation helpful? Give feedback.
-
|
Also in case this helps anybody else, the issue I ran into upgrading v6 -> v7 was a missing constraint in the DB (I'm not sure why the constraint was missing in the first place). I got these errors when updating: To fix, I connected to my Postgres DB using pgAdmin and ran the following query to just manually add that constraint ALTER TABLE size_variants
ADD CONSTRAINT size_variants_photo_id_foreign
FOREIGN KEY (photo_id) REFERENCES photos(id);Then I restarted the app which ran the migrations successfully this time. |
Beta Was this translation helpful? Give feedback.
-
|
I am also surprised that this happened, because the full migration is tested on all Db backends: sqlite, mysql/mariadb, pgsql. |
Beta Was this translation helpful? Give feedback.
-
|
I did at some point on v6 (manually) migrate from a maria DB to postgres, so it's quite possible there was an issue introduced then on my part. |
Beta Was this translation helpful? Give feedback.
-
|
A couple of notes from me in my 6->7 upgrade as well. FWIW I came across all of the issues described above (including missing album thumbnails etc) I had the same permission error messages in the diagnostic. So I went into those mounted directories on my host at did However, when restarting the containers, the "permissions check" code in the app startup changes the permissions back, and the warnings return. Previously, I was using PUID/PGID = 1000 in the docker env vars, and the directories on my host were using those IDs (my default user/group id). The defaults in the new image are set to UID 33 (www-data) and 82 (unknown group). I wonder if this might be an issue, because: (This is after I've run the However: trying Is this file perms? Something else perhaps? |
Beta Was this translation helpful? Give feedback.
-
|
The access rights, I need to double check if those are still necessary. Yes you noticed the 33/84 Those are permissions of the www-data user in alpine which is run by frankenphp, I am looking into what can be done in that direction. I am also considering a switch to debian franken php, but that means that the size of the container will switch from 600MB to 1GB. For the encoding, this is probably due to the miss match between the permissions. I tried to have this fixed with: |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Lychee version
v7.0.0
Did you check the latest Lychee version?
Yes, I did
Which PHP version are you using?
PHP 8.4
Detailed description of the problem
I am upgrading my docker-compose setup to Lychee v7. Previously I was running v6.9.2, although the configuration has evolved and followed upgrades through many years. I have followed the upgrade guide from v6 to v7 and found that it was missing some steps. I am documenting these here with the intention that they would either be added to the documentation or made obsolete by changing the code.
Previously, I had the following volumes
/uploads,/confand/sym. This is also explained in the upgrade guide. The guide also explains that the app now requires the volumes/app/public/uploads,/app/storage/app,/app/storage/logs,/app/storage/tmpand/app/.env. It is clear from the docs that the path of the uploads volume has changed and that the conf directory is not needed anymore, but only its.envfile. What is not clear from the docs is what happens to thesymvolume. My guess is that it is obsolete and the directory can be removed, but I am not sure about it, so I think the guide should explain this.With the 3 volumes under
/app/storage, I though I could simplify the configuration by specifying one single volume for/app/storageinstead. Turns out I was wrong. Doing so makes the app exit with the errorThe /app/bootstrap/cache directory must be present and writable.. Maybe this could be clarified in the guide as well.After changing the volumes and starting the upgraded service, it crashes with the error message
❌ ERROR: Required environment variable APP_KEY is not set. This can be fixed by adding the env file asenv_fileto the docker service itself, wihch also makes all theenvironmentvariables obsolete, as they happen to be duplicated in the.envfile anyways. Using this file as anenv_filewas previously not necessary, but it is not mentioned in the upgrade guide.I also find it a bit confusing why the
.envfile needs to be mounted as a volume and at the same time loaded into the environment. I found that the app still seems to be working when omitting the volume. It seems to me like the app supports both approaches (volume orenv_file), but the entrypoint script has a bug where it only recognizes theenv_fileapproach?With the environment properly set, I got the message
⏳ Waiting for database to be ready.... After 30 attempts, the app gave up and exited. After digging through the code, I found out that I have to setDB_PORT=3306in the env file (for mysql). Previously the port was empty and the app was using the default port. I feel like this is a bug in the entrypoint script, as the rest of the app still seems to be fine with not specifying the database port.I am running Lychee behind traefik. Previously, I believe the app was listening on port 80. Now it runs on port 8000, but the docker image still specifies ports 80 and 443 as
expose. This causes traefik not to find the right port anymore and now requires manual configuration of the port. I feel like the docker image should nowexposeport 8000 only.The guide mentions to run
docker exec lychee php artisan migrate. I found this step unnecessary, as the migrations are automatically run when the service starts. Running this command gives the outputNothing to migrate..I found that after the upgrade, the app still showed “Lychee v6” as its title. Surely I have never set this title by hand. I found it possible to change this in the admin settings UI of the app.
The rest of the docs still seem to refer to the old Lychee version. For example, the Docker guide still uses the old volumes and settings. What I haven’t found out yet is what effects the change of the PHP runtime has on upload size limits. Previously, I was mounting a custom
php.inias/var/www/html/Lychee/public/.user.inito raise upload limit. With the new version, I am not sure yet whether there are upload limits and how to change them.After the update, my albums don’t have a preview image anymore. When opening the album, all the previews are really blurry. It seems to use a 200×200 square thumbnail, even though the previews are not shown as rectangles of various much larger sizes. Switching to the lefternmost square preview style, they are not blurry anymore.
Running
docker-compose exec lychee php artisan lychee:diagnosticsshowed me various commands to run to generate missing thumbnails. After running these commands, the thumbnails inside the albums look fine. As I have a lot of Lychee instances, running all these commands is a bit cumbersome. It would be better if there was a single command to generate all the missing thumbnails. Also, it would be nice if this was mentioned in the guide.The albums themselves still don’t have thumbnails. I haven’t found a fix for this yet.
Steps to reproduce the issue
No response
Diagnostics [REQUIRED]
Browser & System [REQUIRED]
Server: Arch Linux, running docker
Client: Arch Linux, latest Chromium
Please confirm (incomplete submissions will not be addressed)
Beta Was this translation helpful? Give feedback.
All reactions