[BUG] Updated Bookstack/MariaDB and cannot access the container anymore at set APP URL #256
Comments
|
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid. |
|
Have you ran through the update that mariadb is telling you to do? |
|
You need to do the steps. |
|
Yes since performing that I have been unable to access Bookstack, I tried redploying and the same thing happens. |
|
If I redploy with the same db but to a different bookstack container at a different port and local IP, then run the commands to update the URL I can access the instance over the local IP but the login page is all broken and says there a problem. |
|
Looking through some logs I am seeing this in the nginx log: |
|
php logs: |
|
I missed this at the top of the terminal log output: 2025/01/09 18:34:56 [warn] 304#304: the "listen ... http2" directive is deprecated, use the "http2" directive instead in /config/nginx/site-confs/default.conf:7 |
|
Your container logs show that your nginx logs need updating, try that. |
|
The combination definitely works because I've upgraded my own instance without issue. The nginx errors look like standard bot spam rather than being related to any issue with the upgrade. |
|
@j0nnymoe can you elaborate on what update I need to do? @thespad good to know the logs look ok. I am still at an impass on what to do. My NPM Proxy logs do not look good: Wouldnt this rejection be from the bookstack container itself? |
|
This is in my custom nginx config: |
|
A quick test is to expose the bookstack ports directly and see if you can connect to it that way (or if it gives you some kind of error) Also check the laravel.log in /config/log to see if that contains anything that might indicate a cause. |
|
Got it I will forward bookstack and try it. My laravel log was so large I could not view it accurately so I copied it and made a new one but it was not generating any logs. I will check it now. |
|
yea the log file is empty I think I screwed up the permissions I will move it back. Is there any way to clear the current log so I can only see fresh data going forward? |
|
You should just be able to delete/rename the existing log and restart the container to get it to create a fresh one. |
|
So the current laravel log is showing this which definitely would explain why I am having issues, however these errors are not from today which is odd since I restarted the container. I am going to kill the log file and see if the new one has anything good in it: #19 /app/www/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\Container\BoundMethod::callBoundMethod() [previous exception] [object] (PDOException(code: 2002): SQLSTATE[HY000] [2002] Connection refused at /app/www/vendor/laravel/framework/src/Illuminate/Database/Connectors/Connector.php:65) |
|
welp thats not good, it is not creating a new log. Also seems to have stopped logging yesterday... |
|
Laravel won't log anything unless you're making connections to the site to trigger actions |
|
ok cool, let me forward it and see what we get, thank you for your help by the way I am going to be in some serious trouble if I cannot get this working. |
|
Ok with it forwarded my laravel says this: [2025-01-10 17:35:03] production.ERROR: Unsupported cipher or incorrect key length. Supported ciphers are: aes-128-cbc, aes-256-cbc, aes-128-gcm, aes-256-gcm. {"exception":"[object] (RuntimeException(code: 0): Unsupported cipher or incorrect key length. Supported ciphers are: aes-128-cbc, aes-256-cbc, aes-128-gcm, aes-256-gcm. at /app/www/vendor/laravel/framework/src/Illuminate/Encryption/Encrypter.php:55) to me this just looks like if I had working SSL I would be good, however when I proceed to the page this is what I see:
|
|
You have a missing/incorrect |
|
ok so regarding that, I have never had an app key on this instance. But in my troubleshooting I was trying to setup another bookstack container and just pointing it at the original DB. This did not work of course but I did see that the APP key was needed and generated one for the new instance. So when going back to my original container I then added the app key into the old container and generated it via the command. I just removed it to put that container back as it was lets see what happens now. |
|
that did it! I am in it without SSL so I am going to pull backups like mad now. My setup from 2022 did not have the app key section. Is this something I will need to find a way to add? |
|
The APP_KEY was always mandatory but in the old days we generated one and wrote it to the .env file if you didn't supply one. A while back we switched to requiring users to supply their own key (so that they were aware it was a thing they needed to keep track of) but if there was already a key in your .env we carried on using that. |
|
I want to ensure I am backing up the env file do you know its location in this image? |
|
I believe it's /config/www/.env, but we don't write anything to it any more, so you only need to back it up if it contains settings you've added (or an app key that you haven't moved to the environment variables). |
|
cool I have this APP_KEY.TXT file in the image root which is interesting. |
|
I think at one point we also wrote it there as a backup. |
|
damn immediately blocked again through the proxy, is there a trusted proxy setting somewhere? |
|
Not that we configure. |
|
hmm ok, I in theory know the steps to change the app url but if you dont mind confirming. Stop mariadb and bookstack, update the appurl variable. Start maria, start bookstack. Then issue docker exec -it bookstack php /app/www/artisan bookstack:update-url ${OLD_URL} ${NEW_URL} and clear the cache correct? |
|
You don't need to stop the db, but otherwise yes that's basically it. |
|
awesome thank you! I am going to move it to a different domain temporarily, I am locked out on that domain for letsencrypt so thats likely not helping and I know I had certificate issues in the past with this container. |
|
weird still wont connect on a new url with a new cert, kind of makes sense though as I was using a wildcard cert so it should not have been a cert issue. damn proxies. |
|
I got it! Ok so what seems to be happening (this makes no sense to me) I had to move my bookstack container to a separate IP (same subnet) then point my proxy at the container IP at port 80, I have bookstack set to run on port 6875 per the standard config so I have no clue at all what the hell happened here but its working. Hopefully if someone else has this issue they will see this. Thank you for your help I am going to mark this closed and update the title to hopefully reflect the issue better. |
samschultzponsys
changed the title
Is there an existing issue for this?
Current Behavior
I had an update for the Linuxserv.io MariaDB container that is tied to my Linuxserver.io Bookstack instance. After performing the image update and the update command shown in the logs:
An upgrade is required on your databases. #
Stop any services that are accessing databases
in this container, and then run the command
mariadb-upgrade -u root -p
My Bookstack instance is no longer reachable and I am getting a 502 error.
Expected Behavior
Update images as normal and continue to use Bookstack.
Steps To Reproduce
Environment
CPU architecture
x86-64
Docker creation
Relevant settings for containers:Container logs
MariaDB logs: User UID: 99 User GID: 100 ─────────────────────────────────────── Linuxserver.io version: 11.4.4-r1-ls167 Build-date: 2025-01-09T10:59:53+00:00 ─────────────────────────────────────── [custom-init] No custom files found, skipping... UMASK corrected from 022 to 0640 ... 250109 17:43:42 mysqld_safe Logging to '/config/databases/6d5b3c4b1fd8.err'. 250109 17:43:42 mysqld_safe Starting mariadbd daemon with databases from /config/databases [ls.io-init] done. Bookstack logs: GID/UID ─────────────────────────────────────── User UID: 99 User GID: 100 ─────────────────────────────────────── Linuxserver.io version: v24.12.1-ls186 Build-date: 2025-01-05T10:11:29+00:00 ─────────────────────────────────────── using keys found in /config/keys **** The following active confs have different version dates than the samples that are shipped. **** **** This may be due to user customization or an update to the samples. **** **** You should compare the following files to the samples in the same folder and update them. **** **** Use the link at the top of the file to view the changelog. **** ┌────────────┬────────────┬────────────────────────────────────────────────────────────────────────┐ │ old date │ new date │ path │ ├────────────┼────────────┼────────────────────────────────────────────────────────────────────────┤ │ 2022-08-16 │ 2024-12-17 │ /config/nginx/nginx.conf │ │ 2022-10-04 │ 2024-07-16 │ /config/nginx/site-confs/default.conf │ │ 2022-08-20 │ 2024-12-06 │ /config/nginx/ssl.conf │ └────────────┴────────────┴────────────────────────────────────────────────────────────────────────┘ Waiting for DB to be available INFO Nothing to migrate. [custom-init] No custom files found, skipping... [ls.io-init] done.The text was updated successfully, but these errors were encountered: